From julian.reschke@gmx.de Sun Jul 1 05:56:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B301311E838C for ; Sun, 1 Jul 2012 05:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.907 X-Spam-Level: X-Spam-Status: No, score=-104.907 tagged_above=-999 required=5 tests=[AWL=-2.308, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+tOLnUoPoBQ for ; Sun, 1 Jul 2012 05:56:19 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id AAED511E8385 for ; Sun, 1 Jul 2012 05:56:18 -0700 (PDT) Received: (qmail invoked by alias); 01 Jul 2012 12:56:19 -0000 Received: from p54BB25AE.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.37.174] by mail.gmx.net (mp027) with SMTP; 01 Jul 2012 14:56:19 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18hSLRnri8hwD+z5vrD2RTsewQAaQlFtOgA9YjIEh Hj37vgyG1C3tV7 Message-ID: <4FF048F0.4020502@gmx.de> Date: Sun, 01 Jul 2012 14:56:16 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <4FEB2003.9000508@isode.com> In-Reply-To: <4FEB2003.9000508@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2012 12:56:19 -0000 On 2012-06-27 17:00, Alexey Melnikov wrote: > Dear WG participants, > > The Working Group Last Call for this document has ended and there were a > couple of updates to it to address issues (-03 and -04). I believe all > issues were addressed, but it would be good for the WG to check the > latest version and confirm that. If one of your issues is not addressed > (and especially if it wasn't replied to), please let me know. > > In the meantime, I've started working on the shepherding write-up before > asking our AD Barry to review and initiate IETF Last Call for the document. > > Thank you, > Alexey, as an APPSAWG co-chair. > ... I had a quick look at , and the only thing I noticed was in the ABNF in Section 4: Forwarded = Forwarded-v Forwarded-v = 1#forwarded-element This is probably an artefact of the changes we made, and isn't consistent with the style in HTTPbis; so I'd prefer to simplify that to: Forwarded = 1#forwarded-element Best regards, Julian From barryleiba.mailing.lists@gmail.com Sun Jul 1 06:30:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968AD21F8A7C for ; Sun, 1 Jul 2012 06:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.152 X-Spam-Level: X-Spam-Status: No, score=-102.152 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_TOWRITE=1.05, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvO+6Kzvob0G for ; Sun, 1 Jul 2012 06:30:00 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4BB721F8A66 for ; Sun, 1 Jul 2012 06:29:59 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so7064617lbb.31 for ; Sun, 01 Jul 2012 06:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=Jml+2kEhEHHAB6Opjfol9+FBWtwLosQjsU8ZSRAPoNA=; b=kxKU+imRp8r/jxsdQ+Rv3QnYuPjbyhgqVsAR1us+MHZxCKDGUxq1NBpgjif7uJ+P2q N/55Y3bSOjCBOPxhHfkhunrBH2RJbwH6hgD82TAiyJwGptxMky/7ulvmTm4lMawYjTLS B11SXliimR1kZ2yBgj0i/BZNRo5+dIf81+KtDLBov4Sp37tsuhdOwXbWBjcdNVez/caF kfY/6G9GPlbHKRHF71Eq/F9oDOJJcB4b/lXReRO/8qnoSE4HB8Hjh61OVQSV9UJArDhG DfTTfBDfQhwN2KLI8WWimhdV7zvFoJx1pfObUaRMKAs15B9mPc11J2p9n6oxN1RdUFT6 UkXw== MIME-Version: 1.0 Received: by 10.152.111.200 with SMTP id ik8mr9175912lab.15.1341149401008; Sun, 01 Jul 2012 06:30:01 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Sun, 1 Jul 2012 06:30:00 -0700 (PDT) Date: Sun, 1 Jul 2012 09:30:00 -0400 X-Google-Sender-Auth: 963QUVYPXXw_prFPZKBuiQuYvYM Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: Graham Klyne , apps-discuss@ietf.org, "Murray S. Kucherawy" Subject: [apps-discuss] The acct: scheme definition -- draft-saintandre-acct-uri X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2012 13:30:00 -0000 >> Graham, I think you're right about the fact that these matters are >> underspecified. I hereby offer to propose some text, and will do that in >> the next few days. > > I went beyond proposing text and decided to write a standalone I-D: > > http://datatracker.ietf.org/doc/draft-saintandre-acct-uri/ > > Graham, I think that text answers the questions you posed, hopefully in > an accurate way. I have a couple/few comments. Very tiny minor: I might like to see informative references for mailto [RFC6068] and http (probably [RFC2616], so this isn't waiting on the httpbis set). Slightly less tiny: The Security Considerations are correct, as far as this goes, about the existence of an acct: URI. Only, this spec provides no way to expose or test the existence of an acct: URI, so it does not expose the security issue you're noting. I'm not sure what the right change is to this document's Security Considerations for that, but I really don't see how the creation of this scheme, without another document's definition of how it can actually be used, poses any security issue at all. Significantly less tiny, indeed; issues about the grammar: domainpart = domainlabel 1*( "." domainlabel) domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum First, to avoid ambiguity, please either domainlabel = alphanum / (alphanum *( alphanum / "-" ) alphanum) ...or, better, domainlabel = alphanum [ *( alphanum / "-" ) alphanum ] Second, and more important, it concerns me that we have so many varying definitions of the same entity, a domain name. Yours is a variant of what's in RFC 5321 (SMTP) -- a variant, not a reference nor a copy, though "domainlabel" here specifies exactly the same thing as "sub-domain" in 5321: Domain = sub-domain *("." sub-domain) sub-domain = Let-dig [Ldh-str] Let-dig = ALPHA / DIGIT Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig We have this, from RFC 3986 (URIs): host = IP-literal / IPv4address / reg-name reg-name = *( unreserved / pct-encoded / sub-delims ) We have this, from RFC 6068 (mailto): domain = dot-atom-text / "[" *dtext-no-obs "]" And those are just in the documents you're citing. Others surely exist in other places. I don't like adding one more to the set of different definitions. I suggest instead that you either use this: domainpart = sub-domain 1*( "." sub-domain) ; sub-domain is defined in SMTP [RFC5321] ...if you really want to keep the change that a domain has to have at least two parts, or this: domainpart = Domain ; Domain is defined in SMTP [RFC5321] ...if you're willing to accept that a domain can have just one part. Barry From stephen.farrell@cs.tcd.ie Sun Jul 1 06:39:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0A221F8648 for ; Sun, 1 Jul 2012 06:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uJQBYbQqYEx for ; Sun, 1 Jul 2012 06:39:24 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE0021F867B for ; Sun, 1 Jul 2012 06:39:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 122D1171838; Sun, 1 Jul 2012 14:39:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341149960; bh=CjMTkb1nwdoQAo /fq3zv3l4pZmYA7JVP+0+4R3LJG0k=; b=AgMfMhinTktsNfPX5rFU/WSdsuViNX 8aBQMrVi1g/9EUGpwgVCYMfDwDk3kG1Nk+S/FDcHDjOMqQwQxlK0FKXbb0rHEBta YaGRYpYd7tHwAVztOEk/ImZuQUc43bzKkNi8O2+ib4v0A6mAp7l7pGbYXOjUKH7n d848fg6CEQOSnidWL8a9ckCqiESbJCAtM78gw1GZCTXbpb2xGP4pEsOZehLiw19s 1pRbhJJiZDV9A6sXNm5lBMmZA1n3Nu+nVptarc8rhFfk7+oT0h2wbeZC192ipurS 0AwD3BdzzRsj6BFpLpJ38/a6lKtuxJ149YMKBRXkzvdEHWArmGxFRItQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ivYXb3ogJUab; Sun, 1 Jul 2012 14:39:20 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.52.206]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 10AE5171520; Sun, 1 Jul 2012 14:39:19 +0100 (IST) Message-ID: <4FF05306.2010301@cs.tcd.ie> Date: Sun, 01 Jul 2012 14:39:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <4FEB2003.9000508@isode.com> In-Reply-To: <4FEB2003.9000508@isode.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2012 13:39:26 -0000 On 06/27/2012 04:00 PM, Alexey Melnikov wrote: > Dear WG participants, > > The Working Group Last Call for this document has ended and there were a > couple of updates to it to address issues (-03 and -04). I believe all > issues were addressed, but it would be good for the WG to check the > latest version and confirm that. If one of your issues is not addressed > (and especially if it wasn't replied to), please let me know. > > In the meantime, I've started working on the shepherding write-up before > asking our AD Barry to review and initiate IETF Last Call for the document. I've only looked at 8.3, but I believe the privacy considerations section is wrong when it says that standardising this has no new privacy impact. One argument given is that a direct connection would expose the client IP anyway, but that's not comparing this proposal against today's reality, which ought to be the point. I also think the text in that section seems to be trying to sell this as having no privacy impact, and I just don't think that is the case. S > > Thank you, > Alexey, as an APPSAWG co-chair. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From wmills@yahoo-inc.com Sun Jul 1 08:38:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C1121F89F4 for ; Sun, 1 Jul 2012 08:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.073 X-Spam-Level: X-Spam-Status: No, score=-17.073 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, SARE_TOWRITE=1.05, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NplZD1PCgKeh for ; Sun, 1 Jul 2012 08:38:32 -0700 (PDT) Received: from nm32-vm5.bullet.mail.ne1.yahoo.com (nm32-vm5.bullet.mail.ne1.yahoo.com [98.138.229.53]) by ietfa.amsl.com (Postfix) with SMTP id 80CDC21F89E4 for ; Sun, 1 Jul 2012 08:38:32 -0700 (PDT) Received: from [98.138.90.52] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 01 Jul 2012 15:38:31 -0000 Received: from [98.138.89.234] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 01 Jul 2012 15:38:31 -0000 Received: from [127.0.0.1] by omp1049.mail.ne1.yahoo.com with NNFMP; 01 Jul 2012 15:38:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 601099.75760.bm@omp1049.mail.ne1.yahoo.com Received: (qmail 75738 invoked by uid 60001); 1 Jul 2012 15:38:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1341157111; bh=XFq4uFhBH0EfKmjcai4LCSLvXyDQ+FadDKc+/ZH8f7M=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=r9dyzO2DnBHa3oKT+copby5K1kOFLjAm1LVoYPpffB/acL0TuBGRwp09P65MiLQTc/ry3pT9FRzkfrbXMS5U9yqukgm2wylJKBNM0g50/DWkcxqqeCLHMLvX/IU9ROqbPv4q5fst13YxcQ6HbEEM15Kasmsxifq50E1S0ZQTsXw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Yp5/K6VGXAHhCejl2jP90bS5I/v6xsCadDtGgsLiqWzckp3Vn/hfjFhjN5RpCRx2QBoTzv4grVSX3JApUalN0j00CsE3ptG8SJ7yqIwej8uFoHp9UDcz9IbFOn6zCh2S641NCXmIVx61gwyoQB00I2ZHc/CpSHf+aapQoK6ENvY=; X-YMail-OSG: h70KiOoVM1nkIa6REUxGd47u11P8Q4plKsJTMVZKoc0yVxG FL6qgSsvGxwGt.7K3SFeGTeWwaP.USD8bMTwucksF9zs_8pSvXteo.65dhCm gwbDBoRTXzBvVqi6oZ3p_OOw_6pEil388wF.ECEb8jAJ_hGQ.Ml1KA6waR.l LxXjvzKIBqsC_puI_6sGImm5noVZrebhILiYMH8A7zWWPqha8ZvsEUmRXyF5 PdAjLwrnKcBLKJHlYqsCz7O6ev2Wf1B4iEO90o9vRedTMwP_UJJlnpyFV.QW MqOxpSW9MsDqzlCpLJDsZJXP4VdG0UUdpRAoNa7bbGDY8ELnyVyZRp47J.E1 Q9sfU8ZWktZvnitQ4iD55aOdWy9yxbY20Zf65D.ncGmvIaVc7.TRJE0k2tMJ 5m_YShmjdNF6Q5Th4nGMiRbNCHJ65HCBjuhgY1cNAv6CeC9ds.OPZlWy7d.q Y_Cfsw0rhy_6wxdGkWx09xbOL Received: from [99.31.212.42] by web31805.mail.mud.yahoo.com via HTTP; Sun, 01 Jul 2012 08:38:31 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> Message-ID: <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Sun, 1 Jul 2012 08:38:31 -0700 (PDT) From: William Mills To: Peter Saint-Andre , Graham Klyne In-Reply-To: <4FEFBF51.5000905@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 15:38:33 -0000 As susquepedalian as I frequently am, I would change 'discussants' in secti= on 2 to "working group".=0A=0Asection 3 para 3 "It is not assumed that an e= ntity will necessarily be able to interact with a user's account using any = particular application protocol, such as email...", I understand this but e= mail isn't a protocol, SMTP is for example.=A0 Maybe change "email" to SMTP= there?=A0 =0A=0A=0ASection 4.3:=A0 '"@" domainpart' should be optional.=A0= It's reasonable to think this might be used with local account identifiers= that don/t/need have a domain.=0A=0A=0ARegards,=0A=0A-bill=0A=0A=0A=0A=0A= =0A----- Original Message -----=0A> From: Peter Saint-Andre =0A> To: Graham Klyne =0A> Cc: apps-discuss@ietf.or= g; Murray S. Kucherawy =0A> Sent: Saturday, June 30, 201= 2 8:09 PM=0A> Subject: Re: [apps-discuss] The acct: scheme question=0A> =0A= > On 6/28/12 10:53 AM, Peter Saint-Andre wrote:=0A>> On 6/28/12 5:09 AM, G= raham Klyne wrote:=0A>>> On 28/06/2012 08:28, Melvin Carvalho wrote:=0A>>>= > Should acct: be rejected, we can simply use mailto: as per SWD. =0A>>>> = Similarly=0A>>>> you could simply use ?acct=3Duser@host as has been sugge= sted.=0A>>> =0A>>> Since my comments with reviewer hat on have been cited,= I feel I should=0A>>> summarize my personal feelings about the specificat= ion of the acct: =0A> scheme.=0A>>> =0A>>> *Reviewer hat OFF*=0A>>> =0A>>>= Roughly, I think the acct: scheme does provide a useful, possibly =0A> mi= nor,=0A>>> purpose that is not served by other URI schemes, and as such it= has=0A>>> reasonable claim to meet the bar for registering a new scheme.= =A0 But I=0A>>> think the description of the acct: scheme in the WebFinger= document =0A> does=0A>>> a poor job of explaining this; i.e. I think ther= e is a document quality=0A>>> issue here around the acct: scheme registrat= ion/specification.=0A>>> =0A>>> I've had private exchanges with one of the= document editors, but I =0A> don't=0A>>> think my suggestions have been r= eflected in the current draft.=A0 In=0A>>> summary, what I think is not as= clear as it should be in the scheme=0A>>> registration includes:=0A>>> *= what does an acct URI identify=0A>>> * how are acct URIs allocated; what'= s the assignment delegation =0A> structure?=0A>>> * how should an acct: UR= I be dereferenced?=A0 (e.g. if one were used as a=0A>>> link in a web page= , how should it be handled?).=0A>>> =0A>>> I suspect that most of this inf= ormation can be inferred if one has a=0A>>> detailed knowledge of WebFinge= r protocol, but for an average Joe web=0A>>> developer I don't think that'= s really helpful.=0A>>> =0A>>> I don't think this is a sufficiently import= ant issue for me to =0A> engage=0A>>> more actively with the discussion.= =0A>> =0A>> Graham, I think you're right about the fact that these matters= are=0A>> underspecified. I hereby offer to propose some text, and will do= that in=0A>> the next few days.=0A> =0A> I went beyond proposing text and= decided to write a standalone I-D:=0A> =0A> http://datatracker.ietf.org/do= c/draft-saintandre-acct-uri/=0A> =0A> Graham, I think that text answers the= questions you posed, hopefully in=0A> an accurate way.=0A> =0A> Feedback i= s welcome.=0A> =0A> Peter=0A> =0A> -- =0A> Peter Saint-Andre=0A> https://st= peter.im/=0A> =0A> =0A> =0A> =0A> _________________________________________= ______=0A> apps-discuss mailing list=0A> apps-discuss@ietf.org=0A> https://= www.ietf.org/mailman/listinfo/apps-discuss=0A> From stpeter@stpeter.im Sun Jul 1 15:02:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E33011E80FB for ; Sun, 1 Jul 2012 15:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X03wumB192qu for ; Sun, 1 Jul 2012 15:02:52 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CE57111E80BC for ; Sun, 1 Jul 2012 15:02:51 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.179.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 95B204005A; Sun, 1 Jul 2012 16:21:04 -0600 (MDT) Message-ID: <4FF0C90D.2060207@stpeter.im> Date: Sun, 01 Jul 2012 16:02:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: William Mills References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> In-Reply-To: <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2012 22:02:52 -0000 On 7/1/12 9:38 AM, William Mills wrote: > As susquepedalian as I frequently am, I would change 'discussants' in > section 2 to "working group". Those discussions far predated any consideration at the IETF. > section 3 para 3 "It is not assumed that an entity will necessarily > be able to interact with a user's account using any particular > application protocol, such as email...", I understand this but email > isn't a protocol, SMTP is for example. Maybe change "email" to SMTP > there? Sure. > Section 4.3: '"@" domainpart' should be optional. It's reasonable > to think this might be used with local account identifiers that > don/t/need have a domain. Making the domain name of the service provider implicit seems ill-advised to me. What's the harm of including the domainpart? Peter -- Peter Saint-Andre https://stpeter.im/ From mnot@mnot.net Sun Jul 1 17:01:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CE711E811E for ; Sun, 1 Jul 2012 17:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.346 X-Spam-Level: X-Spam-Status: No, score=-104.346 tagged_above=-999 required=5 tests=[AWL=-4.161, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kr9RrOWNyOPE for ; Sun, 1 Jul 2012 17:01:35 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0609111E80AE for ; Sun, 1 Jul 2012 17:01:34 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9261E22E25B; Sun, 1 Jul 2012 20:01:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <1340984775.31848.2.camel@pbryan-wsl.internal.salesforce.com> Date: Mon, 2 Jul 2012 10:01:26 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> <1340897879.2393.9.camel@pbryan-wsl.internal.salesforce.com> <1340922969.2393.13.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114F730FACE@WSMSG3153V.srv.dir.telstra.com> <1340984775.31848.2.camel@pbryan-wsl.internal.salesforce.com> To: Paul C. Bryan X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss , Joe Hildebrand Subject: Re: [apps-discuss] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 00:01:35 -0000 I've started to go in this direction in = ; feedback = appreciated. I think we'll need a few examples to show that the ordering of decoding = matters. Also, anyone interesting in starting to collect test cases, as we've = done for URI Templates = ? Cheers, On 30/06/2012, at 1:46 AM, Paul C. Bryan wrote: > I'll concede that ~0 is easier for humans and regular expression = parsers to process than ~~, so I'll retract any suggestion that it = should be so. >=20 > On Fri, 2012-06-29 at 10:19 +1000, Manger, James H wrote: >>=20 >> >> As a quoting character, ~ is a good choice. I might offer that 0 = and >> >> 1 are strange choices for the next character, but I wont offer an >> >> alternative except to note that double-escape is the more commonly >> >> used method for escaping the escape character. >>=20 >> > True, ~~ would just as good to escape ~ instead of ~0... >>=20 >> No. >>=20 >> Using "~~" to escape "~" means a "~" in a pointer can be >> either an escaper or an escapee -- and you have to count >> a potentially indefinite number of preceding "~"'s to >> determine the answer. That just makes parsing and matching >> with a regex harder. >>=20 >> The names in the following 2 pointers end in "1" or "/". >> Which is which? >>=20 >> /~~~~~~~~~~~~~~~~~~~~1 >> /~~~~~~~~~~~~~~~~~~~1 >>=20 >> It is much more obvious if we use "~0" as the escape for "~". >>=20 >> /~0~0~0~0~0~0~0~0~0~01 >> /~0~0~0~0~0~0~0~0~0~1 >>=20 >> -- >> James Manger >>=20 >=20 -- Mark Nottingham http://www.mnot.net/ From wmills@yahoo-inc.com Sun Jul 1 17:44:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BB021F8953 for ; Sun, 1 Jul 2012 17:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.336 X-Spam-Level: X-Spam-Status: No, score=-17.336 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMmdX+JGX5D9 for ; Sun, 1 Jul 2012 17:44:27 -0700 (PDT) Received: from nm11-vm0.bullet.mail.bf1.yahoo.com (nm11-vm0.bullet.mail.bf1.yahoo.com [98.139.213.136]) by ietfa.amsl.com (Postfix) with SMTP id 7541221F86E5 for ; Sun, 1 Jul 2012 17:44:27 -0700 (PDT) Received: from [98.139.215.141] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2012 00:44:30 -0000 Received: from [98.139.212.211] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2012 00:44:30 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 02 Jul 2012 00:44:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 495588.22548.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 28927 invoked by uid 60001); 2 Jul 2012 00:44:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1341189869; bh=Ksd5xXnyCR5jNZD1+ticaniDnH4jSuIdKp1j2oulIWA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LTCNNpqN6E1ezW+Y7KCI/8ep/UwIR5kI/IBkvwTM4QvLndK5/gmEwokI58sf1goMGlbU3bLGA4e9NPaQO7qzZPlHW6PvCgCEbUqr1dmrVaqg/s2U2L4sWsbyoaDmGc+Zb/RMGF06DzkXxrtkrhgwAZEzLukidVod/uohLFakQuk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=msDE+5JH8xZKWexNMmyD3p76cyRhlMW1xTOtGL/2MAo69saoPVwi+eL+fGUYV1ftRr+jcy7edxdVPJ6iG2jPHV71Zd7XJ5Fmc7T5+veE56DHBbgpZh75CNnlsNMzDAN5WhCOpHGAAcqK/3VZ3AHJeVoIFB/vvpz3QFZysKjDBaM=; X-YMail-OSG: g7SiNucVM1kqdUhmKddaWPUyCxtRlJ0UOOqRj9zzpA2Miw1 0bdiiop7EMY5eHWS2n6gM6YHM4Pacp4wZHCrPnATpzj1YnRjpNLmVF_8iftq NjN_x4GdX.2XvsFNbIS0lzspg.F2JpupnSyxXw4a.iVKeO3lbMdpix_x0aYW 4E9Iret3nFTChjE5m4SoOurak.V8AbR8qWpfeIU2oPXaBYiR81q2PwtF6GVp dTsqM0LxIdgqPueEn1N29RzfImgFE.H2AVhGOiDIE43vClfbBmc54DYoGPNi iHubxEXtOQOhGdMy.T9MQyJ7VBmHlT5H1iZjxeNX0VJPOgwfj2.nABgkWAEg nIwjuMYTtWYyuzPjNHufoo7aXRnWxQBlDOwZfYoc..UgTMbD5aPt5uT_fu4a s7GPYQZQzAeWFlecW5TEXE9VEPwyMHoneRiu7FoXixpj1mN8PjlRIgamfiKb L3AoVAqyL2QXy.YT_qQILqZBB Received: from [99.31.212.42] by web31802.mail.mud.yahoo.com via HTTP; Sun, 01 Jul 2012 17:44:29 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> Message-ID: <1341189869.28404.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Sun, 1 Jul 2012 17:44:29 -0700 (PDT) From: William Mills To: Peter Saint-Andre In-Reply-To: <4FF0C90D.2060207@stpeter.im> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-1739875664-1341189869=:28404" Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 00:44:28 -0000 ---1036955950-1739875664-1341189869=:28404 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A----- Original Message -----=0A> From: Peter Saint-Andre =0A> To: William Mills =0A> Cc: Graham = Klyne ; "apps-discuss@ietf.org" ;= Murray S. Kucherawy =0A> Sent: Sunday, July 1, 2012 3:0= 2 PM=0A> Subject: Re: [apps-discuss] The acct: scheme question=0A> =0A> On = 7/1/12 9:38 AM, William Mills wrote:=0A>> As susquepedalian as I frequentl= y am, I would change 'discussants' =0A> in=0A>> section 2 to "working grou= p".=0A> =0A> Those discussions far predated any consideration at the IETF.= =0A> =0A>> section 3 para 3 "It is not assumed that an entity will necessa= rily=0A>> be able to interact with a user's account using any particular= =0A>> application protocol, such as email...", I understand this but email= =0A>> isn't a protocol, SMTP is for example.=A0 Maybe change "email" =0A> = to SMTP=0A>> there?=0A> =0A> Sure.=0A> =0A>> Section 4.3:=A0 '"@" domainp= art' should be optional.=A0 =0A> It's reasonable=0A>> to think this might = be used with local account identifiers that=0A>> don/t/need have a domain.= =0A> =0A> Making the domain name of the service provider implicit seems=0A>= ill-advised to me. What's the harm of including the domainpart?=0A=0AI jus= t think it's something that won't be needed in some cases.=0A=0A> =0A> Pete= r=0A> =0A> -- =0A> Peter Saint-Andre=0A> https://stpeter.im/=0A> ---1036955950-1739875664-1341189869=:28404 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable


----- Original Message -----
> Fr= om: Peter Saint-Andre <stpeter@stpeter.im>
> To: William Mills= <wmills@yahoo-inc.com>
> Cc: Graham Klyne <GK@ninebynine.o= rg>; "apps-discuss@ietf.org" <apps-discuss@ietf.org>; Murray S. Ku= cherawy <msk@cloudmark.com>
> Sent: Sunday, July 1, 2012 3:02 = PM
> Subject: Re: [apps-discuss] The acct: scheme question
> =
> On 7/1/12 9:38 AM, William Mills wrote:
>> As susquepeda= lian as I frequently am, I would change 'discussants'
> in
>&g= t; section 2 to "working group".
>
> Those discussions far pr= edated any consideration at the IETF.
>
>> section 3 para = 3 "It is not assumed that an entity will necessarily
>> be able to interact with a user's account using any particular
>> a= pplication protocol, such as email...", I understand this but email
>= > isn't a protocol, SMTP is for example.  Maybe change "email" > to SMTP
>> there?
>
> Sure.
>
>&g= t; Section 4.3:  '"@" domainpart' should be optional. 
> = It's reasonable
>> to think this might be used with local account= identifiers that
>> don/t/need have a domain.
>
> M= aking the domain name of the service provider implicit seems
> ill-ad= vised to me. What's the harm of including the domainpart?

I just thi= nk it's something that won't be needed in some cases.

>
> = Peter
>
> --
> Peter Saint-Andre
> https://stpete= r.im/
>
---1036955950-1739875664-1341189869=:28404-- From stpeter@stpeter.im Sun Jul 1 20:31:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC18911E8156 for ; Sun, 1 Jul 2012 20:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.191 X-Spam-Level: X-Spam-Status: No, score=-102.191 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9AKrrXI2i9Y for ; Sun, 1 Jul 2012 20:31:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 41A4411E8140 for ; Sun, 1 Jul 2012 20:31:39 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.179.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D00604005A; Sun, 1 Jul 2012 21:49:53 -0600 (MDT) Message-ID: <4FF11620.8040901@stpeter.im> Date: Sun, 01 Jul 2012 21:31:44 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: William Mills References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <1341189869.28404.YahooMailNeo@web31802.mail.mud.yahoo.com> In-Reply-To: <1341189869.28404.YahooMailNeo@web31802.mail.mud.yahoo.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 03:31:39 -0000 On 7/1/12 6:44 PM, William Mills wrote: > > > ----- Original Message ----- >> From: Peter Saint-Andre >> To: William Mills >> Cc: Graham Klyne ; "apps-discuss@ietf.org" > ; Murray S. Kucherawy >> Sent: Sunday, July 1, 2012 3:02 PM >> Subject: Re: [apps-discuss] The acct: scheme question >> >> On 7/1/12 9:38 AM, William Mills wrote: >>> As susquepedalian as I frequently am, I would change 'discussants' >> in >>> section 2 to "working group". >> >> Those discussions far predated any consideration at the IETF. >> >>> section 3 para 3 "It is not assumed that an entity will necessarily >>> be able to interact with a user's account using any particular >>> application protocol, such as email...", I understand this but email >>> isn't a protocol, SMTP is for example. Maybe change "email" >> to SMTP >>> there? >> >> Sure. >> >>> Section 4.3: '"@" domainpart' should be optional. >> It's reasonable >>> to think this might be used with local account identifiers that >>> don/t/need have a domain. >> >> Making the domain name of the service provider implicit seems >> ill-advised to me. What's the harm of including the domainpart? > > I just think it's something that won't be needed in some cases. With all due respect, I think your suggestion is nonsensical. If I work at example.com and I want to send an email message to my co-worker Bill, is the URI for me mailto:bill instead of mailto:bill@example.com (as it would be for someone working at example.net)? Peter -- Peter Saint-Andre https://stpeter.im/ From ve7jtb@ve7jtb.com Sun Jul 1 20:56:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BD111E814F for ; Sun, 1 Jul 2012 20:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvqNAk7E0xYN for ; Sun, 1 Jul 2012 20:56:10 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6948D11E813D for ; Sun, 1 Jul 2012 20:56:10 -0700 (PDT) Received: by ggnc4 with SMTP id c4so4219350ggn.31 for ; Sun, 01 Jul 2012 20:56:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=rGdKb7kJBJcVuBGQA35PJVvPZ0cESY/UdwC7W/4jOdA=; b=MBUYsvAsFAA7fmlL8nJASTbvTY8fR3Hb+A/D6MaqZ6eWo0FmEZaAron5qtG6SIUXx/ Aohru9s2olpg6D8Xni96xtWRgPhCfw8AhAn6GhojbdnTFj9YsOSRARVUFrM3HPMqj+ky aCBaItZKu9PxW0hnVcf1e2hKa9DVRMz55jlsTclR78n8tScphtlMGEUvoZXfAcO/YICi i/xbU8Bbbd9w/Vylg47VQaMkqpTLm7n54YdiKZw7KNzsC9SS4fiOxHZPoGYU6Izon1Du 36GCRpfdFjlSG33ZNUQ83y86CfPhKGIooML0RP0D16/CWGQDAMUHFosxat9Zehjv2aR1 G/JQ== Received: by 10.236.78.36 with SMTP id f24mr13877443yhe.20.1341201374065; Sun, 01 Jul 2012 20:56:14 -0700 (PDT) Received: from [192.168.1.211] (190-20-50-6.baf.movistar.cl. [190.20.50.6]) by mx.google.com with ESMTPS id y66sm22632030yhi.10.2012.07.01.20.56.10 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Jul 2012 20:56:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_A298D10E-F2AA-404F-B1E5-52DB41CAA236"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4FF11620.8040901@stpeter.im> Date: Sun, 1 Jul 2012 23:56:05 -0400 Message-Id: <20503F9B-B87D-4983-A689-52755731AD0F@ve7jtb.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <1341189869.28404.YahooMailNeo@web31802.mail.mud.yahoo.com> <4FF11620.8040901@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlI1+O6XUMTF/0YzAYd0j7+kNZXAglg1EP89jd/ujqVCQ81MimvJpYjGrlcx+e/GlEU5m0+ Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 03:56:11 -0000 --Apple-Mail=_A298D10E-F2AA-404F-B1E5-52DB41CAA236 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii WF resolution won't work without a domain to provide the root of = discovery. =20 While it might be inferred from contact to create the URI. =20 Also the WF target server may be supporting multiple domains so a user = name on its own would not be a good pattern. If we are doing acct: it should have a mandatory domainpart. John B. On 2012-07-01, at 11:31 PM, Peter Saint-Andre wrote: > On 7/1/12 6:44 PM, William Mills wrote: >>=20 >>=20 >> ----- Original Message ----- >>> From: Peter Saint-Andre >>> To: William Mills >>> Cc: Graham Klyne ; "apps-discuss@ietf.org" >> ; Murray S. Kucherawy >>> Sent: Sunday, July 1, 2012 3:02 PM >>> Subject: Re: [apps-discuss] The acct: scheme question >>>=20 >>> On 7/1/12 9:38 AM, William Mills wrote: >>>> As susquepedalian as I frequently am, I would change 'discussants' >>> in >>>> section 2 to "working group". >>>=20 >>> Those discussions far predated any consideration at the IETF. >>>=20 >>>> section 3 para 3 "It is not assumed that an entity will necessarily >>>> be able to interact with a user's account using any particular >>>> application protocol, such as email...", I understand this but = email >>>> isn't a protocol, SMTP is for example. Maybe change "email" >>> to SMTP >>>> there? >>>=20 >>> Sure. >>>=20 >>>> Section 4.3: '"@" domainpart' should be optional.=20 >>> It's reasonable >>>> to think this might be used with local account identifiers that >>>> don/t/need have a domain. >>>=20 >>> Making the domain name of the service provider implicit seems >>> ill-advised to me. What's the harm of including the domainpart? >>=20 >> I just think it's something that won't be needed in some cases. >=20 > With all due respect, I think your suggestion is nonsensical. If I = work > at example.com and I want to send an email message to my co-worker = Bill, > is the URI for me mailto:bill instead of mailto:bill@example.com (as = it > would be for someone working at example.net)? >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_A298D10E-F2AA-404F-B1E5-52DB41CAA236 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw MjAzNTYwNVowIwYJKoZIhvcNAQkEMRYEFPPKBL+O2wATA7n/TDNSN3Ro1LKHMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AIdVJq+0oN/fH4ZJ/6EKYnw8DG9WWA1mLCplc0HWJGUAF5Tsw0pi5hNdEB0O95iClhGqOLdjq+il hGSXgJ95h3R1DAC49VHj49SZikEXvwU055DEQro/3lb7aflF/LyJPg06I77eXztS9suz1Rk+1H1p 8gLDnDK1yFKaJ54yFfMyPtKZidV063BCU8o1ULOX+XrWEjmnO9M81z2iXE2ADaWYlcqro+uSvdou dspjd5QCR6j/sLRkd3XUh+F3+VgwBF2HgwkbRINzzqwyMkJMhpWcPRIKqaU3iimYMHZTzMRyWmOg XtLDTTIPUqGZnTYcI3jVSvqMVcy14CuiiT+Sef0AAAAAAAA= --Apple-Mail=_A298D10E-F2AA-404F-B1E5-52DB41CAA236-- From duerst@it.aoyama.ac.jp Sun Jul 1 23:28:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F6821F8759 for ; Sun, 1 Jul 2012 23:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.537 X-Spam-Level: X-Spam-Status: No, score=-99.537 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwlZ0nuZWIhd for ; Sun, 1 Jul 2012 23:28:24 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id D669F21F86E2 for ; Sun, 1 Jul 2012 23:28:23 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q626SIrt014706 for ; Mon, 2 Jul 2012 15:28:18 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 530e_ee08_1cba06d0_c40f_11e1_aa94_001d096c5782; Mon, 02 Jul 2012 15:28:18 +0900 Received: from [IPv6:::1] ([133.2.210.1]:52453) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 2 Jul 2012 15:28:17 +0900 Message-ID: <4FF13F7F.9030806@it.aoyama.ac.jp> Date: Mon, 02 Jul 2012 15:28:15 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> In-Reply-To: <4FF0C90D.2060207@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 06:28:25 -0000 On 2012/07/02 7:02, Peter Saint-Andre wrote: > On 7/1/12 9:38 AM, William Mills wrote: >> As susquepedalian as I frequently am, I would change 'discussants' in >> section 2 to "working group". > > Those discussions far predated any consideration at the IETF. > >> section 3 para 3 "It is not assumed that an entity will necessarily >> be able to interact with a user's account using any particular >> application protocol, such as email...", I understand this but email >> isn't a protocol, SMTP is for example. Maybe change "email" to SMTP >> there? > > Sure. > >> Section 4.3: '"@" domainpart' should be optional. It's reasonable >> to think this might be used with local account identifiers that >> don/t/need have a domain. > > Making the domain name of the service provider implicit seems > ill-advised to me. Very much so indeed. While for an URI/IRI scheme with generic syntax (e.g. http, ftp), the lack of domain name can be recovered by relative resolution, there is no such concept as a relative URI/IRI (except just for lacking the scheme name) for scheme with a syntax similar to mailto:. Regards, Martin. From GK@ninebynine.org Mon Jul 2 04:57:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852D721F8BBD for ; Mon, 2 Jul 2012 04:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.074 X-Spam-Level: X-Spam-Status: No, score=-7.074 tagged_above=-999 required=5 tests=[AWL=-1.525, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_TOWRITE=1.05] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uZo+sKDZChM for ; Mon, 2 Jul 2012 04:57:15 -0700 (PDT) Received: from relay8.mail.ox.ac.uk (relay8.mail.ox.ac.uk [129.67.1.171]) by ietfa.amsl.com (Postfix) with ESMTP id 907D521F8BBB for ; Mon, 2 Jul 2012 04:57:15 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay8.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1SlfFm-0007Rl-Qt; Mon, 02 Jul 2012 12:57:18 +0100 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SlfFm-0002hB-79; Mon, 02 Jul 2012 12:57:18 +0100 Message-ID: <4FF18B9C.4010102@ninebynine.org> Date: Mon, 02 Jul 2012 12:53:00 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> In-Reply-To: <4FEFBF51.5000905@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: apps-discuss@ietf.org, "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 11:57:16 -0000 Pater, (comments below) On 01/07/2012 04:09, Peter Saint-Andre wrote: > On 6/28/12 10:53 AM, Peter Saint-Andre wrote: >> On 6/28/12 5:09 AM, Graham Klyne wrote: >>> On 28/06/2012 08:28, Melvin Carvalho wrote: >>>> Should acct: be rejected, we can simply use mailto: as per SWD. >>>> Similarly >>>> you could simply use ?acct=user@host as has been suggested. >>> >>> Since my comments with reviewer hat on have been cited, I feel I should >>> summarize my personal feelings about the specification of the acct: scheme. >>> >>> *Reviewer hat OFF* >>> >>> Roughly, I think the acct: scheme does provide a useful, possibly minor, >>> purpose that is not served by other URI schemes, and as such it has >>> reasonable claim to meet the bar for registering a new scheme. But I >>> think the description of the acct: scheme in the WebFinger document does >>> a poor job of explaining this; i.e. I think there is a document quality >>> issue here around the acct: scheme registration/specification. >>> >>> I've had private exchanges with one of the document editors, but I don't >>> think my suggestions have been reflected in the current draft. In >>> summary, what I think is not as clear as it should be in the scheme >>> registration includes: >>> * what does an acct URI identify >>> * how are acct URIs allocated; what's the assignment delegation structure? >>> * how should an acct: URI be dereferenced? (e.g. if one were used as a >>> link in a web page, how should it be handled?). >>> >>> I suspect that most of this information can be inferred if one has a >>> detailed knowledge of WebFinger protocol, but for an average Joe web >>> developer I don't think that's really helpful. >>> >>> I don't think this is a sufficiently important issue for me to engage >>> more actively with the discussion. >> >> Graham, I think you're right about the fact that these matters are >> underspecified. I hereby offer to propose some text, and will do that in >> the next few days. > > I went beyond proposing text and decided to write a standalone I-D: > > http://datatracker.ietf.org/doc/draft-saintandre-acct-uri/ > > Graham, I think that text answers the questions you posed, hopefully in > an accurate way. Generally, this is in line with my understanding of the intent of acct: scheme. Paul and/or the WebFinger folks will be better placed to judge. Some comments: == Section 3 == [[ For example, if a user has an account name of "foobar" on a microblogging service "status.example.net", it can be inferred that the user's 'acct' URI at that provider is acct:foobar@status.example.net even if the provider has not explicitly assigned such a URI. ]] I might say thus: [[ For example, if a user has an account name of "foobar" on a microblogging service "status.example.net", it is taken as convention that the string "foobar@status.example.net" designates that account. This is expressed as a URI using the acct: scheme as "acct:foobar@status.example.net". ]] (The phrasing is intended to take account of the fact that WebFinger clients are expected to accept the "foobar@status.example.net" without the acct: prefix.) == Section 4.4 == My understanding is that an acct: URI is intended to be dereferenced using the WebFinger protocol. I'm not sure about associated MIME types: does WebFinger define any such? == Section 4.6 == I'm a little unsure about the phrasing "only the WebFinger protocol uses the 'acct' URI scheme", but I can't put my finger on any problem or offer better phrasing at this time. == Section 5 == Maybe add: [[ Dereferencing an acct: URI could reveal information about a user's account. As such, care should be taken that personally identifying information is not released without appropriate permissions and/or credentials. ]] ? ... HTH, #g -- From GK@ninebynine.org Mon Jul 2 04:57:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED0D21F8BBB for ; Mon, 2 Jul 2012 04:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.837 X-Spam-Level: X-Spam-Status: No, score=-6.837 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCG23MVkJNhe for ; Mon, 2 Jul 2012 04:57:16 -0700 (PDT) Received: from relay9.mail.ox.ac.uk (relay9.mail.ox.ac.uk [163.1.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3B50221F8BBC for ; Mon, 2 Jul 2012 04:57:16 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay9.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1SlfFm-0004ai-Vk; Mon, 02 Jul 2012 12:57:18 +0100 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SlfFm-0002hF-8w; Mon, 02 Jul 2012 12:57:18 +0100 Message-ID: <4FF18C30.2040902@ninebynine.org> Date: Mon, 02 Jul 2012 12:55:28 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> In-Reply-To: <4FF0C90D.2060207@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 11:57:17 -0000 On 01/07/2012 23:02, Peter Saint-Andre wrote: > On 7/1/12 9:38 AM, William Mills wrote: >> Section 4.3: '"@" domainpart' should be optional. It's reasonable >> to think this might be used with local account identifiers that >> don/t/need have a domain. > > Making the domain name of the service provider implicit seems > ill-advised to me. What's the harm of including the domainpart? +1 (URIs are intended to be a global namespace.) #g -- From hallam@gmail.com Mon Jul 2 06:31:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55B221F85DB for ; Mon, 2 Jul 2012 06:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pF2f4oM9-DhH for ; Mon, 2 Jul 2012 06:31:05 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18A2221F85D3 for ; Mon, 2 Jul 2012 06:31:05 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9554926obb.31 for ; Mon, 02 Jul 2012 06:31:10 -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=x75eS5sRB8ymzgCY95FucFdeFGU+oHZlx89HsccwiWE=; b=Q01clwVgW2Lrgx+UDCa7k5kN6sePF5Z39uMReDRswKS7fLnMsuWiNUaj98JmjIGrCU vFxpDMCHv0T/fI51Cyi1cKeTGUWgG1jVa2N/hhnextBOtGJ6jTaWL5h/LklPtPBNB9I1 fkEGPwlAssTJuAek0g/GgHweVXNV/6qRqGThZI+2TKoHOgj0ESPcUvKOJ/bDpEKs7GvT tCtEqtGSYgFVbKb5/HZLJc9ZkgbR2QaBx0n26mAl3okx2s5nAz9gf5yyqOngS9vQ8l1N zg7skOF1WXdrK7O8u1LIj8Ofd3NF+QKn5Q282JWF3FUC+jD6yWYJOmRtpBfnf+3JzRq/ WY4A== MIME-Version: 1.0 Received: by 10.60.12.37 with SMTP id v5mr13633664oeb.25.1341235869911; Mon, 02 Jul 2012 06:31:09 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Mon, 2 Jul 2012 06:31:09 -0700 (PDT) In-Reply-To: <4FF18C30.2040902@ninebynine.org> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> Date: Mon, 2 Jul 2012 09:31:09 -0400 Message-ID: From: Phillip Hallam-Baker To: Graham Klyne Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 13:31:06 -0000 Relative URIs have existed from the start. That is one of the reasons they had to be renamed 'uniform' rather than universal. The idea is to have a uniform means of representing a name. If that name is ambiguous, then the URI form needs to be able to capture that. I don't think it helps in the slightest to argue over whether /fred.html is a URI or a URI fragment. Tim's original proposal is in my view rather better thought out than what others have proposed as 'improvements'. A name is merely a label for a concept and every URI is a name, some happen to be resolvable via a default protocol, others not, thats all. Incompletely specified account names are inevitable. If you want to use SAML or the like in a Windows environment then the Windows domain is not bound to a unique DNS address and picking a random one is only going to confuse matters. An acct: name that does not have a domain name part is going to have to be resolved in the same fashion as relative URIs are - by reference to context and local state. I don't see anything wrong in that. In the context of accounts, a domain name is not completely unambiguous unless you also have time. The real world is a fuzzy place. Trying to cope with the fuzzyness and ambiguity by wishing it away only leads to broken specs. Accounts have only recently come to be understood to have an intrinsic domain component. It is better to accept that fact and to build infrastructure that addresses the need than to pretend that the need can be magicked away. People who don't have a domain are going to drop it in any case. We saw the same thing happen with the news: and nntp: URL. Tim thought that the USENET space was uniform and tried to establish a URL that didn't have the domain name. Engineers trying to solve real world problems then added it back in because there is more to NNTP than USENET. On Mon, Jul 2, 2012 at 7:55 AM, Graham Klyne wrote: > On 01/07/2012 23:02, Peter Saint-Andre wrote: >> >> On 7/1/12 9:38 AM, William Mills wrote: >>> >>> Section 4.3: '"@" domainpart' should be optional. It's reasonable >>> to think this might be used with local account identifiers that >>> don/t/need have a domain. >> >> >> Making the domain name of the service provider implicit seems >> ill-advised to me. What's the harm of including the domainpart? > > > +1 > > (URIs are intended to be a global namespace.) > > #g > -- > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Website: http://hallambaker.com/ From melvincarvalho@gmail.com Mon Jul 2 06:42:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C3F21F85F2 for ; Mon, 2 Jul 2012 06:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2++MFDONXBt3 for ; Mon, 2 Jul 2012 06:42:10 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9EE121F85E6 for ; Mon, 2 Jul 2012 06:42:09 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3885044vbb.31 for ; Mon, 02 Jul 2012 06:42:14 -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=4ar1Vtaj5tJHYSFpPr8URHfWHEFz8tjDIQLylp67uak=; b=ZxIw7aqmUGTk5lzS8w1zUecpYqJwCXJiRQQuX5GfEBoTw2DQb2K/6ovfyH/41PiStw zNll873gDewCpOAwcpAqU/EFtKtyd6IJlvu37cBkp3knV+ecy6170OS0fVWEzTOp1ABg +kNIQzDS40DxZOaiYxVifMMVAVbG+oHwGGoU8JVaSyUYUy2ZrRtoUCgVyPThXVfzLLSq AI2wcSYvWqz9wBjgc3GEWOaX/FJihdF5Vt43/h4IYnsemytY/8iOtYCHSCal8nZzC/Cc MUaAKOy+WjD3eyakZ8J0nBHGbUBYe4RvkGyOXfPWbO59siZ8j22FddG8S9abCQ3xUnXP JsFw== MIME-Version: 1.0 Received: by 10.52.28.99 with SMTP id a3mr531156vdh.68.1341236534427; Mon, 02 Jul 2012 06:42:14 -0700 (PDT) Received: by 10.52.166.102 with HTTP; Mon, 2 Jul 2012 06:42:14 -0700 (PDT) In-Reply-To: References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> Date: Mon, 2 Jul 2012 15:42:14 +0200 Message-ID: From: Melvin Carvalho To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=20cf3079b92031c05804c3d8f71f Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 13:42:11 -0000 --20cf3079b92031c05804c3d8f71f Content-Type: text/plain; charset=ISO-8859-1 On 2 July 2012 15:31, Phillip Hallam-Baker wrote: > Relative URIs have existed from the start. That is one of the reasons > they had to be renamed 'uniform' rather than universal. > > The idea is to have a uniform means of representing a name. If that > name is ambiguous, then the URI form needs to be able to capture that. > > I don't think it helps in the slightest to argue over whether > /fred.html is a URI or a URI fragment. Tim's original proposal is in > my view rather better thought out than what others have proposed as > 'improvements'. A name is merely a label for a concept and every URI > is a name, some happen to be resolvable via a default protocol, others > not, thats all. > > > Incompletely specified account names are inevitable. If you want to > use SAML or the like in a Windows environment then the Windows domain > is not bound to a unique DNS address and picking a random one is only > going to confuse matters. > > An acct: name that does not have a domain name part is going to have > to be resolved in the same fashion as relative URIs are - by reference > to context and local state. I don't see anything wrong in that. In the > context of accounts, a domain name is not completely unambiguous > unless you also have time. > > > The real world is a fuzzy place. Trying to cope with the fuzzyness and > ambiguity by wishing it away only leads to broken specs. Accounts have > only recently come to be understood to have an intrinsic domain > component. It is better to accept that fact and to build > infrastructure that addresses the need than to pretend that the need > can be magicked away. > > People who don't have a domain are going to drop it in any case. We > saw the same thing happen with the news: and nntp: URL. Tim thought > that the USENET space was uniform and tried to establish a URL that > didn't have the domain name. Engineers trying to solve real world > problems then added it back in because there is more to NNTP than > USENET. > I enjoyed reading this. Just a remark regarding universal vs uniform. FWIW, Tim is on record saying that he regrets not insisting to the IETF, that the original 'Universal' should be used in URI, instead of changed form 'Uniform'. Depending on which circles you're in, I think informally, the two terms are used pretty interchangeably, these days. > > > > On Mon, Jul 2, 2012 at 7:55 AM, Graham Klyne wrote: > > On 01/07/2012 23:02, Peter Saint-Andre wrote: > >> > >> On 7/1/12 9:38 AM, William Mills wrote: > >>> > >>> Section 4.3: '"@" domainpart' should be optional. It's reasonable > >>> to think this might be used with local account identifiers that > >>> don/t/need have a domain. > >> > >> > >> Making the domain name of the service provider implicit seems > >> ill-advised to me. What's the harm of including the domainpart? > > > > > > +1 > > > > (URIs are intended to be a global namespace.) > > > > #g > > -- > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --20cf3079b92031c05804c3d8f71f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 July 2012 15:31, Phillip Hallam-Bak= er <hallam@gmail.com> wrote:



On Mon, Jul 2, 2012 at 7:55 AM, Graham Klyne <GK@ninebynine.org> wrote:
> On 01/07/2012 23:02, Peter Saint-Andre wrote:
>>
>> On 7/1/12 9:38 AM, William Mills wrote:
>>>
>>> Section 4.3: =A0'"@" domainpart' should be o= ptional. =A0It's reasonable
>>> to think this might be used with local account identifiers tha= t
>>> don/t/need have a domain.
>>
>>
>> Making the domain name of the service provider implicit seems
>> ill-advised to me. What's the harm of including the domainpart= ?
>
>
> +1
>
> (URIs are intended to be a global namespace.)
>
> #g
> --
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss



--
Website: http://halla= mbaker.com/
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--20cf3079b92031c05804c3d8f71f-- From GK@ninebynine.org Mon Jul 2 07:06:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A63221F8692 for ; Mon, 2 Jul 2012 07:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.757 X-Spam-Level: X-Spam-Status: No, score=-6.757 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdLV6Ru6cif6 for ; Mon, 2 Jul 2012 07:06:11 -0700 (PDT) Received: from relay1.mail.ox.ac.uk (relay1.mail.ox.ac.uk [129.67.1.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7141721F8690 for ; Mon, 2 Jul 2012 07:06:11 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay1.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1SlhGZ-00029j-4X for apps-discuss@ietf.org; Mon, 02 Jul 2012 15:06:15 +0100 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SlhGZ-00061e-6U for apps-discuss@ietf.org; Mon, 02 Jul 2012 15:06:15 +0100 Message-ID: <4FF1A6FE.9040306@ninebynine.org> Date: Mon, 02 Jul 2012 14:49:50 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 14:06:12 -0000 On 02/07/2012 14:31, Phillip Hallam-Baker wrote: > Relative URIs have existed from the start. That is one of the reasons > they had to be renamed 'uniform' rather than universal. Strictly, there are no relative URIs. There are, however, relative URI *references* that are resolved to URIs following rules set out in RFC 3986 (http://tools.ietf.org/html/rfc3986#section-5.2). The distinction here traces all the way back to Tim's original proposals (or as near as I have seen); cf. http://www.w3.org/DesignIssues/Model.html (the section of document sets and relative addressing, *not* the section on fragment identifiers, which is a completely different issue). The terminological clarification came later. #g -- > The idea is to have a uniform means of representing a name. If that > name is ambiguous, then the URI form needs to be able to capture that. > > I don't think it helps in the slightest to argue over whether > /fred.html is a URI or a URI fragment. Tim's original proposal is in > my view rather better thought out than what others have proposed as > 'improvements'. A name is merely a label for a concept and every URI > is a name, some happen to be resolvable via a default protocol, others > not, thats all. > > > Incompletely specified account names are inevitable. If you want to > use SAML or the like in a Windows environment then the Windows domain > is not bound to a unique DNS address and picking a random one is only > going to confuse matters. > > An acct: name that does not have a domain name part is going to have > to be resolved in the same fashion as relative URIs are - by reference > to context and local state. I don't see anything wrong in that. In the > context of accounts, a domain name is not completely unambiguous > unless you also have time. > > > The real world is a fuzzy place. Trying to cope with the fuzzyness and > ambiguity by wishing it away only leads to broken specs. Accounts have > only recently come to be understood to have an intrinsic domain > component. It is better to accept that fact and to build > infrastructure that addresses the need than to pretend that the need > can be magicked away. > > People who don't have a domain are going to drop it in any case. We > saw the same thing happen with the news: and nntp: URL. Tim thought > that the USENET space was uniform and tried to establish a URL that > didn't have the domain name. Engineers trying to solve real world > problems then added it back in because there is more to NNTP than > USENET. > > > > On Mon, Jul 2, 2012 at 7:55 AM, Graham Klyne wrote: >> On 01/07/2012 23:02, Peter Saint-Andre wrote: >>> >>> On 7/1/12 9:38 AM, William Mills wrote: >>>> >>>> Section 4.3: '"@" domainpart' should be optional. It's reasonable >>>> to think this might be used with local account identifiers that >>>> don/t/need have a domain. >>> >>> >>> Making the domain name of the service provider implicit seems >>> ill-advised to me. What's the harm of including the domainpart? >> >> >> +1 >> >> (URIs are intended to be a global namespace.) >> >> #g >> -- >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > From vesely@tana.it Mon Jul 2 07:13:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CD821F8620 for ; Mon, 2 Jul 2012 07:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.513 X-Spam-Level: X-Spam-Status: No, score=-4.513 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keAxN6QMmTNE for ; Mon, 2 Jul 2012 07:13:49 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7692A21F85E5 for ; Mon, 2 Jul 2012 07:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1341238433; bh=LHQv439uo9l4rcDS1fqx26ytbawQROwKyEeQ+HrAS+c=; l=1082; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Ch87BaByOHgtgU3SIo0bynOjjBzXo7PxHfVM0aPBgCMfVl40Xm90Gmu0+q9FGSik3 EajYCdIAvODTnERWEytTQsAZeeSsF/CjXhtgRhr/3a53YS568jzBmez23mGd584BEr P0pBevD0UfwQlEimZck2Rs6R9TNK8liXYs8mHmDs= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 02 Jul 2012 16:13:53 +0200 id 00000000005DC033.000000004FF1ACA1.00000C79 Message-ID: <4FF1ACA1.2090408@tana.it> Date: Mon, 02 Jul 2012 16:13:53 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <6.2.5.6.2.20120109155713.0b022fe0@resistor.net> <6.2.5.6.2.20120109171236.0ad2e840@resistor.net> <4F0C8F7E.4070809@tana.it> <6.2.5.6.2.20120110124010.0968e868@resistor.net> <4F0D57A6.70508@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Status of "Spam reporting using IMAP: SREP" draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 14:13:50 -0000 On Wed 11/Jan/2012 21:27:43 +0100 Murray S. Kucherawy wrote: > >> The IPR is filed here: >> https://datatracker.ietf.org/ipr/1609/ > > This looks and feels a lot like the IPR claim Yahoo! made against > DomainKeys (RFC4870). The difference here, I think, is that Yahoo! > also offered into the public domain an open source implementation > of DK. Does RIM plan to do something like that too? > > Otherwise, I'm concerned that we will be contributing, presumably > for "free", support in development of this toward the standards > track where the beneficiary is RIM. Not a very "open" approach to > an open standards body. I personally wouldn't be inclined to be > very supportive. > > Hopefully RIM can give us some good assurances that this is all on > the level. Or give us all free Blackberries. I've been wondering whether that was meant as in "free beer" or as in "free speech". I found http://blackberry.github.com/ but wasn't able to locate the native IMAP code, nor the Enhanced Gmail Plug-In source. Does the latter handle spam reporting over IMAP? From hallam@gmail.com Mon Jul 2 08:42:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAF921F86F4 for ; Mon, 2 Jul 2012 08:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1BwuvvzBDNb for ; Mon, 2 Jul 2012 08:42:14 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 445CB21F86BE for ; Mon, 2 Jul 2012 08:42:14 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9716382obb.31 for ; Mon, 02 Jul 2012 08:42:19 -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=3rpKDDp6sjjxgpcYjJH0Krh6hqauIqHWZsc7/U1n3Vg=; b=GR6pABoQg416Lko6OQOBQM6b5985/Hifvw2ydcK2ERk+QFfVjORVhBaEluJY42lgVY uwaN4KH+qmzV/uxxMqCqi6NusKWegQp4gjpc6gMh+gwgvj9Jfx1yRkVQnguF0KTkjKKg QYczNra7mv6cOpbg0O2mBz/SJw1sTupLU4gT1XGUZu7CEOp1tHNWhfELhHPndUgsA7EJ N0974P+Lja3sP5dSXOWtHD1FWX0JLo7TfLErkNXflcktcUSRMd1tQ5puJ73CvDyJfgf2 qX5EGT+6jDJHk2kMcpCB+ZJQRG3TL8sP83ACORbDSfpsV1nDz6uwkHl6EqKHI7XZl1HP qh9g== MIME-Version: 1.0 Received: by 10.182.116.2 with SMTP id js2mr8812325obb.38.1341243739247; Mon, 02 Jul 2012 08:42:19 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Mon, 2 Jul 2012 08:42:19 -0700 (PDT) In-Reply-To: References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> Date: Mon, 2 Jul 2012 11:42:19 -0400 Message-ID: From: Phillip Hallam-Baker To: Melvin Carvalho Content-Type: text/plain; charset=ISO-8859-1 Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 15:42:15 -0000 I think Tim regrets having been argued out of a lot of positions relating to naming that he was subsequently proved right on. Naming issues are an area where a lot of people have strong opinions that really turn out to be a matter of taste rather than grounded in semiotics. The whole business of differentiating URLs and URNs as distinct classes was bogus. Once the locator scheme has caching, a URL becomes a name. Once an application provides a default action for a name (e.g. look it up on Amazon) then a name becomes a locator. A URI scheme should simply provide people with a well defined syntax that allows them to express the concepts that applications that need to interoperate need to exchange references to. Trying to decide how people should use the identifiers is counterproductive. Trying to enforce particular approaches is destructive. The vast majority of computer systems that use accounts do not bind them to domain names. So there is a place in the acct: scheme for unbound references. I expect that practice to go down over time. I expect that deployment of technology that uses acct: will encourage that. But trying to force the issue by excluding unbound accounts is only going to hurt that transition by making acct: a special case of account objects rather than a technology that can ease the transition. On Mon, Jul 2, 2012 at 9:42 AM, Melvin Carvalho wrote: > > > On 2 July 2012 15:31, Phillip Hallam-Baker wrote: >> >> Relative URIs have existed from the start. That is one of the reasons >> they had to be renamed 'uniform' rather than universal. >> >> The idea is to have a uniform means of representing a name. If that >> name is ambiguous, then the URI form needs to be able to capture that. >> >> I don't think it helps in the slightest to argue over whether >> /fred.html is a URI or a URI fragment. Tim's original proposal is in >> my view rather better thought out than what others have proposed as >> 'improvements'. A name is merely a label for a concept and every URI >> is a name, some happen to be resolvable via a default protocol, others >> not, thats all. >> >> >> Incompletely specified account names are inevitable. If you want to >> use SAML or the like in a Windows environment then the Windows domain >> is not bound to a unique DNS address and picking a random one is only >> going to confuse matters. >> >> An acct: name that does not have a domain name part is going to have >> to be resolved in the same fashion as relative URIs are - by reference >> to context and local state. I don't see anything wrong in that. In the >> context of accounts, a domain name is not completely unambiguous >> unless you also have time. >> >> >> The real world is a fuzzy place. Trying to cope with the fuzzyness and >> ambiguity by wishing it away only leads to broken specs. Accounts have >> only recently come to be understood to have an intrinsic domain >> component. It is better to accept that fact and to build >> infrastructure that addresses the need than to pretend that the need >> can be magicked away. >> >> People who don't have a domain are going to drop it in any case. We >> saw the same thing happen with the news: and nntp: URL. Tim thought >> that the USENET space was uniform and tried to establish a URL that >> didn't have the domain name. Engineers trying to solve real world >> problems then added it back in because there is more to NNTP than >> USENET. > > > I enjoyed reading this. Just a remark regarding universal vs uniform. > > FWIW, Tim is on record saying that he regrets not insisting to the IETF, > that the original 'Universal' should be used in URI, instead of changed form > 'Uniform'. Depending on which circles you're in, I think informally, the > two terms are used pretty interchangeably, these days. > >> >> >> >> >> On Mon, Jul 2, 2012 at 7:55 AM, Graham Klyne wrote: >> > On 01/07/2012 23:02, Peter Saint-Andre wrote: >> >> >> >> On 7/1/12 9:38 AM, William Mills wrote: >> >>> >> >>> Section 4.3: '"@" domainpart' should be optional. It's reasonable >> >>> to think this might be used with local account identifiers that >> >>> don/t/need have a domain. >> >> >> >> >> >> Making the domain name of the service provider implicit seems >> >> ill-advised to me. What's the harm of including the domainpart? >> > >> > >> > +1 >> > >> > (URIs are intended to be a global namespace.) >> > >> > #g >> > -- >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss >> >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -- Website: http://hallambaker.com/ From Michael.Jones@microsoft.com Mon Jul 2 08:45:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8996E21F8702 for ; Mon, 2 Jul 2012 08:45:00 -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=[AWL=-0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oJqLTX24lQ8 for ; Mon, 2 Jul 2012 08:44:59 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0DE21F84B5 for ; Mon, 2 Jul 2012 08:44:59 -0700 (PDT) Received: from mail101-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Mon, 2 Jul 2012 15:43:07 +0000 Received: from mail101-ch1 (localhost [127.0.0.1]) by mail101-ch1-R.bigfish.com (Postfix) with ESMTP id 14B452E02D5; Mon, 2 Jul 2012 15:43:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zzbb2dI98dI9371I542M1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail101-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail101-ch1 (localhost.localdomain [127.0.0.1]) by mail101-ch1 (MessageSwitch) id 1341243785406350_17177; Mon, 2 Jul 2012 15:43:05 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail101-ch1.bigfish.com (Postfix) with ESMTP id 60E76C0045; Mon, 2 Jul 2012 15:43:05 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 2 Jul 2012 15:43:03 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Mon, 2 Jul 2012 15:44:59 +0000 From: Mike Jones To: Phillip Hallam-Baker , Melvin Carvalho Thread-Topic: [apps-discuss] The acct: scheme question Thread-Index: Ac0367W7uVNJxgK+Tf6qpowkmE64wgbqGMQAAAKM2jAAA8N6gAAAR9EQAD2/6AAAFom7AAAHs0aAAAwDwAAAehjTgAAaLHSAAA1sgoAAHRPgAAADV3qAAABjFwAABDGhgAAACndA Date: Mon, 2 Jul 2012 15:44:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366572961@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 15:45:00 -0000 +1 There are plenty of contexts, especially for non-Internet connect systems (= yes, these still exist :-) ) where account identifiers are strictly local. = The domain portion of the acct: identifier should be optional. -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Phillip Hallam-Baker Sent: Monday, July 02, 2012 8:42 AM To: Melvin Carvalho Cc: Graham Klyne; apps-discuss@ietf.org; Murray S. Kucherawy Subject: Re: [apps-discuss] The acct: scheme question I think Tim regrets having been argued out of a lot of positions relating t= o naming that he was subsequently proved right on. Naming issues are an area where a lot of people have strong opinions that r= eally turn out to be a matter of taste rather than grounded in semiotics. The whole business of differentiating URLs and URNs as distinct classes was= bogus. Once the locator scheme has caching, a URL becomes a name. Once an = application provides a default action for a name (e.g. look it up on Amazon) then a name becomes a locator. A URI scheme should simply provide people with a well defined syntax that a= llows them to express the concepts that applications that need to interoper= ate need to exchange references to. Trying to decide how people should use = the identifiers is counterproductive. Trying to enforce particular approach= es is destructive. The vast majority of computer systems that use accounts do not bind them to= domain names. So there is a place in the acct: scheme for unbound referenc= es. I expect that practice to go down over time. I expect that deployment o= f technology that uses acct: will encourage that. But trying to force the i= ssue by excluding unbound accounts is only going to hurt that transition by= making acct: a special case of account objects rather than a technology th= at can ease the transition. On Mon, Jul 2, 2012 at 9:42 AM, Melvin Carvalho = wrote: > > > On 2 July 2012 15:31, Phillip Hallam-Baker wrote: >> >> Relative URIs have existed from the start. That is one of the reasons=20 >> they had to be renamed 'uniform' rather than universal. >> >> The idea is to have a uniform means of representing a name. If that=20 >> name is ambiguous, then the URI form needs to be able to capture that. >> >> I don't think it helps in the slightest to argue over whether=20 >> /fred.html is a URI or a URI fragment. Tim's original proposal is in=20 >> my view rather better thought out than what others have proposed as=20 >> 'improvements'. A name is merely a label for a concept and every URI=20 >> is a name, some happen to be resolvable via a default protocol,=20 >> others not, thats all. >> >> >> Incompletely specified account names are inevitable. If you want to=20 >> use SAML or the like in a Windows environment then the Windows domain=20 >> is not bound to a unique DNS address and picking a random one is only=20 >> going to confuse matters. >> >> An acct: name that does not have a domain name part is going to have=20 >> to be resolved in the same fashion as relative URIs are - by=20 >> reference to context and local state. I don't see anything wrong in=20 >> that. In the context of accounts, a domain name is not completely=20 >> unambiguous unless you also have time. >> >> >> The real world is a fuzzy place. Trying to cope with the fuzzyness=20 >> and ambiguity by wishing it away only leads to broken specs. Accounts=20 >> have only recently come to be understood to have an intrinsic domain=20 >> component. It is better to accept that fact and to build=20 >> infrastructure that addresses the need than to pretend that the need=20 >> can be magicked away. >> >> People who don't have a domain are going to drop it in any case. We=20 >> saw the same thing happen with the news: and nntp: URL. Tim thought=20 >> that the USENET space was uniform and tried to establish a URL that=20 >> didn't have the domain name. Engineers trying to solve real world=20 >> problems then added it back in because there is more to NNTP than=20 >> USENET. > > > I enjoyed reading this. Just a remark regarding universal vs uniform. > > FWIW, Tim is on record saying that he regrets not insisting to the=20 > IETF, that the original 'Universal' should be used in URI, instead of=20 > changed form 'Uniform'. Depending on which circles you're in, I think=20 > informally, the two terms are used pretty interchangeably, these days. > >> >> >> >> >> On Mon, Jul 2, 2012 at 7:55 AM, Graham Klyne wrote: >> > On 01/07/2012 23:02, Peter Saint-Andre wrote: >> >> >> >> On 7/1/12 9:38 AM, William Mills wrote: >> >>> >> >>> Section 4.3: '"@" domainpart' should be optional. It's=20 >> >>> reasonable to think this might be used with local account=20 >> >>> identifiers that don/t/need have a domain. >> >> >> >> >> >> Making the domain name of the service provider implicit seems=20 >> >> ill-advised to me. What's the harm of including the domainpart? >> > >> > >> > +1 >> > >> > (URIs are intended to be a global namespace.) >> > >> > #g >> > -- >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss >> >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -- Website: http://hallambaker.com/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From stpeter@stpeter.im Mon Jul 2 08:46:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC88321F850B for ; Mon, 2 Jul 2012 08:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.97 X-Spam-Level: X-Spam-Status: No, score=-101.97 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, SARE_TOWRITE=1.05, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22Bbs5UiTPQ6 for ; Mon, 2 Jul 2012 08:46:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 353B621F8704 for ; Mon, 2 Jul 2012 08:46:07 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 576844005A; Mon, 2 Jul 2012 10:04:25 -0600 (MDT) Message-ID: <4FF1C243.2000008@stpeter.im> Date: Mon, 02 Jul 2012 09:46:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Graham Klyne References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <4FF18B9C.4010102@ninebynine.org> In-Reply-To: <4FF18B9C.4010102@ninebynine.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 15:46:08 -0000 Graham, thank you for the review. Comments inline. On 7/2/12 5:53 AM, Graham Klyne wrote: > Pater, > > (comments below) > > On 01/07/2012 04:09, Peter Saint-Andre wrote: >> On 6/28/12 10:53 AM, Peter Saint-Andre wrote: >>> On 6/28/12 5:09 AM, Graham Klyne wrote: >>>> On 28/06/2012 08:28, Melvin Carvalho wrote: >>>>> Should acct: be rejected, we can simply use mailto: as per SWD. >>>>> Similarly >>>>> you could simply use ?acct=user@host as has been suggested. >>>> >>>> Since my comments with reviewer hat on have been cited, I feel I should >>>> summarize my personal feelings about the specification of the acct: >>>> scheme. >>>> >>>> *Reviewer hat OFF* >>>> >>>> Roughly, I think the acct: scheme does provide a useful, possibly >>>> minor, >>>> purpose that is not served by other URI schemes, and as such it has >>>> reasonable claim to meet the bar for registering a new scheme. But I >>>> think the description of the acct: scheme in the WebFinger document >>>> does >>>> a poor job of explaining this; i.e. I think there is a document quality >>>> issue here around the acct: scheme registration/specification. >>>> >>>> I've had private exchanges with one of the document editors, but I >>>> don't >>>> think my suggestions have been reflected in the current draft. In >>>> summary, what I think is not as clear as it should be in the scheme >>>> registration includes: >>>> * what does an acct URI identify >>>> * how are acct URIs allocated; what's the assignment delegation >>>> structure? >>>> * how should an acct: URI be dereferenced? (e.g. if one were used as a >>>> link in a web page, how should it be handled?). >>>> >>>> I suspect that most of this information can be inferred if one has a >>>> detailed knowledge of WebFinger protocol, but for an average Joe web >>>> developer I don't think that's really helpful. >>>> >>>> I don't think this is a sufficiently important issue for me to engage >>>> more actively with the discussion. >>> >>> Graham, I think you're right about the fact that these matters are >>> underspecified. I hereby offer to propose some text, and will do that in >>> the next few days. >> >> I went beyond proposing text and decided to write a standalone I-D: >> >> http://datatracker.ietf.org/doc/draft-saintandre-acct-uri/ >> >> Graham, I think that text answers the questions you posed, hopefully in >> an accurate way. > > Generally, this is in line with my understanding of the intent of acct: > scheme. Paul and/or the WebFinger folks will be better placed to judge. Indeed. I expect a bit of back-and-forth to harmonize the two documents. > Some comments: > > > == Section 3 == > > [[ > For example, if a user has an account name of > "foobar" on a microblogging service "status.example.net", it can be > inferred that the user's 'acct' URI at that provider is > acct:foobar@status.example.net even if the provider has not > explicitly assigned such a URI. > ]] > > I might say thus: > [[ > For example, if a user has an account name of > "foobar" on a microblogging service "status.example.net", it > is taken as convention that the string "foobar@status.example.net" > designates that account. This is expressed as a URI using the > acct: scheme as "acct:foobar@status.example.net". > ]] > > (The phrasing is intended to take account of the fact that WebFinger > clients are expected to accept the "foobar@status.example.net" without > the acct: prefix.) Yes, I prefer your phrasing. Thank you for proposing text. > == Section 4.4 == > > My understanding is that an acct: URI is intended to be dereferenced > using the WebFinger protocol. My understanding is that the WebFinger protocol defines one way for 'acct' URIs to be dereferenced, but that other protocols might also define such ways in the future. If I am wrong about that and 'acct' is tightly coupled with WebFinger, then we need to make that clear in the 'acct' URI spec. > I'm not sure about associated MIME types: > does WebFinger define any such? WebFinger reuses the document formats for Extensible Resource Descriptor (XRD) and JSON Resource Descriptor (JRD). Is it the place of the 'acct' URI spec to define the media types associated with WebFinger, or only to say that protocols using 'acct' URIs need to specify if they have associated media types? > == Section 4.6 == > > I'm a little unsure about the phrasing "only the WebFinger protocol uses > the 'acct' URI scheme", but I can't put my finger on any problem or > offer better phrasing at this time. OK. > == Section 5 == > > Maybe add: > [[ > Dereferencing an acct: URI could reveal information about a user's > account. As such, care should be taken that personally identifying > information is not released without appropriate permissions and/or > credentials. > ]] Makes sense. Thanks. Peter -- Peter Saint-Andre https://stpeter.im/ From hallam@gmail.com Mon Jul 2 08:49:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE35221F8622 for ; Mon, 2 Jul 2012 08:49:27 -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=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xov2kACD-E9t for ; Mon, 2 Jul 2012 08:49:26 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C50921F8623 for ; Mon, 2 Jul 2012 08:49:26 -0700 (PDT) Received: by qcac10 with SMTP id c10so2252558qca.31 for ; Mon, 02 Jul 2012 08:49:31 -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=2dtTuOv+MjPKQ3aTen6VB4oZqJN7Wi94WXdkFMEaNpo=; b=AN3GWSbiuTeJi/bwTPGqte0ylkqVjTqXbWbT3/U9A7DwDTgxVw8c9eIeMA1mq5AyUM cGLYmyLWfb3QXNM3mD1krj+7Ec2lLCvklfxDb7wH2GcyGhZu0GwNPeQs+XQdLcFQNvKL +CdrI1dOWBHCEwTNvDLvRJsXMkiKAI9sI3tsAZTHNsnBH0nUWRTai0XMD3Lojlov2ulN 0XRQkKEzlIZvDBdGSMKLgjqh2nw0I0UrptskH9Ts0jW2i0ftn0owbdQiH4F7/U9tqHGZ +BUxm4pZG2kDGZeQ+1o6Rlb0AtF7OaXeoHurAwTsOpjj+e0y7Ua5xBJ/cihZ0lmfN5mm vxSg== MIME-Version: 1.0 Received: by 10.60.154.232 with SMTP id vr8mr14217752oeb.30.1341244171471; Mon, 02 Jul 2012 08:49:31 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Mon, 2 Jul 2012 08:49:31 -0700 (PDT) In-Reply-To: <4FF1A6FE.9040306@ninebynine.org> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> <4FF1A6FE.9040306@ninebynine.org> Date: Mon, 2 Jul 2012 11:49:31 -0400 Message-ID: From: Phillip Hallam-Baker To: Graham Klyne Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 15:49:27 -0000 That particular description comes six years after the argument I was referring to. But note the following: ----- In this case, the links between these documents are "relative URIs". What happens then is that the relative URI, which only has the locally different part of the URI in it, is handed back to what in the diagram I have called the "application", to be turned into an absolute URI by being combined with the absolute URI of the resource, which the application has remembered. Note that the application is aware of the absolute URI but still the resource does not have to. ------ Of course an application has to be able to be aware of the full context of a partial acct: URI just as a web browser has to know how to resolve a hypertext fragment. But the point is that these do not need to be fully specified in resources. This comes in very handy when testing Web content out before release of a version of the site to the public. I expect that all the practicalities that relate to content in test environments relate to accounts as well. Even more so because a tester will frequently have rather more access in a test environment than they would be allowed in a production one. On Mon, Jul 2, 2012 at 9:49 AM, Graham Klyne wrote: > On 02/07/2012 14:31, Phillip Hallam-Baker wrote: >> >> Relative URIs have existed from the start. That is one of the reasons >> they had to be renamed 'uniform' rather than universal. > > > Strictly, there are no relative URIs. There are, however, relative URI > *references* that are resolved to URIs following rules set out in RFC 3986 > (http://tools.ietf.org/html/rfc3986#section-5.2). > > The distinction here traces all the way back to Tim's original proposals (or > as near as I have seen); cf. http://www.w3.org/DesignIssues/Model.html (the > section of document sets and relative addressing, *not* the section on > fragment identifiers, which is a completely different issue). The > terminological clarification came later. > > #g > -- > > >> The idea is to have a uniform means of representing a name. If that >> name is ambiguous, then the URI form needs to be able to capture that. >> >> I don't think it helps in the slightest to argue over whether >> /fred.html is a URI or a URI fragment. Tim's original proposal is in >> my view rather better thought out than what others have proposed as >> 'improvements'. A name is merely a label for a concept and every URI >> is a name, some happen to be resolvable via a default protocol, others >> not, thats all. >> >> >> Incompletely specified account names are inevitable. If you want to >> use SAML or the like in a Windows environment then the Windows domain >> is not bound to a unique DNS address and picking a random one is only >> going to confuse matters. >> >> An acct: name that does not have a domain name part is going to have >> to be resolved in the same fashion as relative URIs are - by reference >> to context and local state. I don't see anything wrong in that. In the >> context of accounts, a domain name is not completely unambiguous >> unless you also have time. >> >> >> The real world is a fuzzy place. Trying to cope with the fuzzyness and >> ambiguity by wishing it away only leads to broken specs. Accounts have >> only recently come to be understood to have an intrinsic domain >> component. It is better to accept that fact and to build >> infrastructure that addresses the need than to pretend that the need >> can be magicked away. >> >> People who don't have a domain are going to drop it in any case. We >> saw the same thing happen with the news: and nntp: URL. Tim thought >> that the USENET space was uniform and tried to establish a URL that >> didn't have the domain name. Engineers trying to solve real world >> problems then added it back in because there is more to NNTP than >> USENET. >> >> >> >> On Mon, Jul 2, 2012 at 7:55 AM, Graham Klyne wrote: >>> >>> On 01/07/2012 23:02, Peter Saint-Andre wrote: >>>> >>>> >>>> On 7/1/12 9:38 AM, William Mills wrote: >>>>> >>>>> >>>>> Section 4.3: '"@" domainpart' should be optional. It's reasonable >>>>> to think this might be used with local account identifiers that >>>>> don/t/need have a domain. >>>> >>>> >>>> >>>> Making the domain name of the service provider implicit seems >>>> ill-advised to me. What's the harm of including the domainpart? >>> >>> >>> >>> +1 >>> >>> (URIs are intended to be a global namespace.) >>> >>> #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 -- Website: http://hallambaker.com/ From stpeter@stpeter.im Mon Jul 2 08:52:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C902021F8630 for ; Mon, 2 Jul 2012 08:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngK8OuIwVFHf for ; Mon, 2 Jul 2012 08:52:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2483821F85C0 for ; Mon, 2 Jul 2012 08:52:18 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 221374005A; Mon, 2 Jul 2012 10:10:36 -0600 (MDT) Message-ID: <4FF1C3B5.4090902@stpeter.im> Date: Mon, 02 Jul 2012 09:52:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mike Jones References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> <4E1F6AAD24975D4BA5B168042967394366572961@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366572961@TK5EX14MBXC283.redmond.corp.microsoft.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 15:52:19 -0000 On 7/2/12 9:44 AM, Mike Jones wrote: > +1 > > There are plenty of contexts, especially for non-Internet connect > systems (yes, these still exist :-) ) where account identifiers are > strictly local. The domain portion of the acct: identifier should be > optional. Be that as it may, do you expect to use URIs to identify systems that are not connected to the Internet? From Michael.Jones@microsoft.com Mon Jul 2 08:55:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4B021F85F1 for ; Mon, 2 Jul 2012 08:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJMfRqLQ25Rn for ; Mon, 2 Jul 2012 08:54:59 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD3021F8582 for ; Mon, 2 Jul 2012 08:54:59 -0700 (PDT) Received: from mail37-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.23; Mon, 2 Jul 2012 15:53:06 +0000 Received: from mail37-am1 (localhost [127.0.0.1]) by mail37-am1-R.bigfish.com (Postfix) with ESMTP id 75EA94C03C1; Mon, 2 Jul 2012 15:53:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zzbb2dI98dI9371I542M1432Izz1202hzz1033ILz2fh2a8h668h839h93fhd25hf0ah) Received-SPF: pass (mail37-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail37-am1 (localhost.localdomain [127.0.0.1]) by mail37-am1 (MessageSwitch) id 1341244384596342_1744; Mon, 2 Jul 2012 15:53:04 +0000 (UTC) Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.248]) by mail37-am1.bigfish.com (Postfix) with ESMTP id 7CF6F480046; Mon, 2 Jul 2012 15:53:04 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 2 Jul 2012 15:53:03 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0309.003; Mon, 2 Jul 2012 15:54:58 +0000 From: Mike Jones To: Peter Saint-Andre Thread-Topic: [apps-discuss] The acct: scheme question Thread-Index: Ac0367W7uVNJxgK+Tf6qpowkmE64wgbqGMQAAAKM2jAAA8N6gAAAR9EQAD2/6AAAFom7AAAHs0aAAAwDwAAAehjTgAAaLHSAAA1sgoAAHRPgAAADV3qAAABjFwAABDGhgAAACndAAABPPoAAAAa+kA== Date: Mon, 2 Jul 2012 15:54:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943665729B6@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> <4E1F6AAD24975D4BA5B168042967394366572961@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FF1C3B5.4090902@stpeter.im> In-Reply-To: <4FF1C3B5.4090902@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 15:55:03 -0000 SXQncyBkb25lIGEgbG90IC0gaXQncyBvbmUgb2YgdGhlIHByaW1hcnkgYXBwbGljYXRpb25zIG9m IHRoZSAibG9jYWxob3N0IiBuYW1lLiAgSSBzdXBwb3NlIHdlIGNvdWxkIGRlZmluZSBhY2N0OnVz ZXJAbG9jYWxob3N0LCBidXQgdGhhdCBzZWVtcyBsaWtlIG1vcmUgb2YgYSBoYWNrIHRoYW4ganVz dCBhbGxvd2luZyBhY2N0OnVzZXIuDQoNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBQZXRlciBTYWludC1BbmRyZSBbbWFpbHRvOnN0cGV0ZXJAc3RwZXRl ci5pbV0gDQpTZW50OiBNb25kYXksIEp1bHkgMDIsIDIwMTIgODo1MiBBTQ0KVG86IE1pa2UgSm9u ZXMNCkNjOiBQaGlsbGlwIEhhbGxhbS1CYWtlcjsgTWVsdmluIENhcnZhbGhvOyBHcmFoYW0gS2x5 bmU7IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzsgTXVycmF5IFMuIEt1Y2hlcmF3eQ0KU3ViamVjdDog UmU6IFthcHBzLWRpc2N1c3NdIFRoZSBhY2N0OiBzY2hlbWUgcXVlc3Rpb24NCg0KT24gNy8yLzEy IDk6NDQgQU0sIE1pa2UgSm9uZXMgd3JvdGU6DQo+ICsxDQo+IA0KPiBUaGVyZSBhcmUgcGxlbnR5 IG9mIGNvbnRleHRzLCBlc3BlY2lhbGx5IGZvciBub24tSW50ZXJuZXQgY29ubmVjdCANCj4gc3lz dGVtcyAoeWVzLCB0aGVzZSBzdGlsbCBleGlzdCA6LSkgKSB3aGVyZSBhY2NvdW50IGlkZW50aWZp ZXJzIGFyZSANCj4gc3RyaWN0bHkgbG9jYWwuICBUaGUgZG9tYWluIHBvcnRpb24gb2YgdGhlIGFj Y3Q6IGlkZW50aWZpZXIgc2hvdWxkIGJlIA0KPiBvcHRpb25hbC4NCg0KQmUgdGhhdCBhcyBpdCBt YXksIGRvIHlvdSBleHBlY3QgdG8gdXNlIFVSSXMgdG8gaWRlbnRpZnkgc3lzdGVtcyB0aGF0IGFy ZSBub3QgY29ubmVjdGVkIHRvIHRoZSBJbnRlcm5ldD8NCg0K From alexey.melnikov@isode.com Mon Jul 2 09:14:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA8521F86F0 for ; Mon, 2 Jul 2012 09:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.938 X-Spam-Level: X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAPdVpwLRtFa for ; Mon, 2 Jul 2012 09:14:02 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1F55121F86BE for ; Mon, 2 Jul 2012 09:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1341245640; d=isode.com; s=selector; i=@isode.com; bh=EPpnkJ8CkjN7s+y0LQj+GQhFxwUVYDrmGpcWtSZ3od8=; 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=K4gK6dAkCfrRnyHgSRGr8n2sQyBxdLoPTstsJK+3S6/k4jEb9kOeovDDlTUkkiVTVnNKY4 QTNesMOCmsmaIQXP2fg6cVCONcSc4GE6gOPASjckZoO6sad7kMSxgLAJrbaASmXbFPELA6 5/vPuOctRWzv5qNLdJXuMSdA4abc0cA=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 2 Jul 2012 17:14:00 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FF1C8C3.8050401@isode.com> Date: Mon, 02 Jul 2012 17:13:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Stephen Farrell References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> In-Reply-To: <4FF05306.2010301@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 16:14:02 -0000 Hi Stephen, On 01/07/2012 14:39, Stephen Farrell wrote: > On 06/27/2012 04:00 PM, Alexey Melnikov wrote: >> Dear WG participants, >> >> The Working Group Last Call for this document has ended and there were a >> couple of updates to it to address issues (-03 and -04). I believe all >> issues were addressed, but it would be good for the WG to check the >> latest version and confirm that. If one of your issues is not addressed >> (and especially if it wasn't replied to), please let me know. >> >> In the meantime, I've started working on the shepherding write-up before >> asking our AD Barry to review and initiate IETF Last Call for the document. > I've only looked at 8.3, but I believe the privacy considerations > section is wrong when it says that standardising this has no new > privacy impact. > > One argument given is that a direct connection would expose the > client IP anyway, but that's not comparing this proposal against > today's reality, which ought to be the point. > > I also think the text in that section seems to be trying to sell > this as having no privacy impact, and I just don't think that is > the case. Can you suggest some specific text or at least reraise this issue during IETF LC? From stpeter@stpeter.im Mon Jul 2 09:16:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3073E21F8705 for ; Mon, 2 Jul 2012 09:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.362 X-Spam-Level: X-Spam-Status: No, score=-101.362 tagged_above=-999 required=5 tests=[AWL=-1.013, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_48=0.6, SARE_TOWRITE=1.05, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93ndojNWSygB for ; Mon, 2 Jul 2012 09:16:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4518621F8738 for ; Mon, 2 Jul 2012 09:16:36 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8EBA64005A; Mon, 2 Jul 2012 10:34:54 -0600 (MDT) Message-ID: <4FF1C968.3070802@stpeter.im> Date: Mon, 02 Jul 2012 10:16:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Graham Klyne , apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme definition -- draft-saintandre-acct-uri X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 16:16:37 -0000 On 7/1/12 7:30 AM, Barry Leiba wrote: >>> Graham, I think you're right about the fact that these matters are >>> underspecified. I hereby offer to propose some text, and will do that in >>> the next few days. >> >> I went beyond proposing text and decided to write a standalone I-D: >> >> http://datatracker.ietf.org/doc/draft-saintandre-acct-uri/ >> >> Graham, I think that text answers the questions you posed, hopefully in >> an accurate way. > > I have a couple/few comments. With or without your area director hat on? ;-) > Very tiny minor: I might like to see informative references for mailto > [RFC6068] and http (probably [RFC2616], so this isn't waiting on the > httpbis set). Well, it wouldn't wait on the httpbis set if the reference were informational, but I agree that citations would be good. > Slightly less tiny: The Security Considerations are correct, as far as > this goes, about the existence of an acct: URI. Only, this spec > provides no way to expose or test the existence of an acct: URI, so it > does not expose the security issue you're noting. I'm not sure what > the right change is to this document's Security Considerations for > that, but I really don't see how the creation of this scheme, without > another document's definition of how it can actually be used, poses > any security issue at all. If a URI scheme is defined in a specification but isn't used by any protocol, does it introduce a security concern? Perhaps it would be best for this document to describe what specifications of using protocols need to explain in their security considerations sections. Thus I suggest: Because the 'acct' URI scheme does not directly enable interaction with a user's account at a service provider, possible security concerns are minimized. Protocols that make use of 'acct' URIs are responsible for defining security considerations related to such usage, e.g., the risks involved in dereferencing an 'acct' URI and the authentication and authorization methods that could be used to control access to personally identifying information. > Significantly less tiny, indeed; issues about the grammar: That's the one part of draft-jones-appsawg-webfinger I copied over as-is. :) > domainpart = domainlabel 1*( "." domainlabel) > domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum > > First, to avoid ambiguity, please either > > domainlabel = alphanum / (alphanum *( alphanum / "-" ) alphanum) > > ...or, better, > > domainlabel = alphanum [ *( alphanum / "-" ) alphanum ] > > Second, and more important, it concerns me that we have so many > varying definitions of the same entity, a domain name. I share your concern. > Yours is a > variant of what's in RFC 5321 (SMTP) -- a variant, not a reference nor > a copy, though "domainlabel" here specifies exactly the same thing as > "sub-domain" in 5321: > > Domain = sub-domain *("." sub-domain) > sub-domain = Let-dig [Ldh-str] > Let-dig = ALPHA / DIGIT > Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig > > We have this, from RFC 3986 (URIs): > > host = IP-literal / IPv4address / reg-name > reg-name = *( unreserved / pct-encoded / sub-delims ) > > We have this, from RFC 6068 (mailto): > > domain = dot-atom-text / "[" *dtext-no-obs "]" > > And those are just in the documents you're citing. Others surely > exist in other places. I don't like adding one more to the set of > different definitions. I suggest instead that you either use this: > > domainpart = sub-domain 1*( "." sub-domain) > ; sub-domain is defined in SMTP [RFC5321] > > ...if you really want to keep the change that a domain has to have at > least two parts, or this: > > domainpart = Domain > ; Domain is defined in SMTP [RFC5321] > > ...if you're willing to accept that a domain can have just one part. I would prefer to borrow the definition from RFC 3986 here, not tie this spec to SMTP or mailto definitions. Thus: The 'acct' URI syntax is defined here in Augmented Backus-Naur Form (ABNF) [RFC5234], borrowing the 'unreserved' and 'pct-encoded' rules from that specification and the 'host' rule from [RFC3986]: acctURI = "acct:" userpart "@" host userpart = 1*( unreserved / pct-encoded ) We could even borrow the 'userinfo' rule from RFC 3986: userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) I think there's good reason to exclude the user:password format in userinfo, as mentioned in RFC 3986. But what about sub-delims? Perhaps this is more appropriate: userpart = 1*( unreserved / pct-encoded / sub-delims ) Peter -- Peter Saint-Andre https://stpeter.im/ From stephen.farrell@cs.tcd.ie Mon Jul 2 09:18:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75B021F8716 for ; Mon, 2 Jul 2012 09:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 409w0fGD6t7d for ; Mon, 2 Jul 2012 09:18:48 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 08AA021F8702 for ; Mon, 2 Jul 2012 09:18:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0B09317151B; Mon, 2 Jul 2012 17:18:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341245932; bh=jMy93ncqMa1Coi ObO72MfC1uhq8LsRtcohya4J6Ezl0=; b=yyOK/6z9KyIBGsXB56vDZRF1KGkahA bzxzWWfsq+InRpmixq3Sg0c/Sg3FXMCBiPa3AumUFebYeKTPsUgqhbzin19I6Xop 7R7vzd2wkpalzKn/tBE4+IO3o7/61hKs8iAtLtjZ/EEXtP/2u4610gg1rJ7ijpBZ nu8k/AEfZJm5DkR8PcHDdQnfkkV9MZWKbqF4pAAeHzri1WSG0WdoCf6xD4c4h0zy AS82dHAPRCfLPtUqAjSPcqiH2RA1zBZu7vU2tQXUR7Ge60sQ+6cuFpHPzytYkyiw TB+6ZFekozzGuMLYWui35jVh/SbryZ1EjAO4lSuqdb5RTySI95z6o+lw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id gIsyQ0AqNQp3; Mon, 2 Jul 2012 17:18:52 +0100 (IST) Received: from [10.3.10.185] (unknown [193.1.186.252]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A9F8D17147C; Mon, 2 Jul 2012 17:18:52 +0100 (IST) Message-ID: <4FF1C9ED.2080801@cs.tcd.ie> Date: Mon, 02 Jul 2012 17:18:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <4FF1C8C3.8050401@isode.com> In-Reply-To: <4FF1C8C3.8050401@isode.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 16:18:48 -0000 On 07/02/2012 05:13 PM, Alexey Melnikov wrote: > Hi Stephen, > > On 01/07/2012 14:39, Stephen Farrell wrote: >> On 06/27/2012 04:00 PM, Alexey Melnikov wrote: >>> Dear WG participants, >>> >>> The Working Group Last Call for this document has ended and there were a >>> couple of updates to it to address issues (-03 and -04). I believe all >>> issues were addressed, but it would be good for the WG to check the >>> latest version and confirm that. If one of your issues is not addressed >>> (and especially if it wasn't replied to), please let me know. >>> >>> In the meantime, I've started working on the shepherding write-up before >>> asking our AD Barry to review and initiate IETF Last Call for the >>> document. >> I've only looked at 8.3, but I believe the privacy considerations >> section is wrong when it says that standardising this has no new >> privacy impact. >> >> One argument given is that a direct connection would expose the >> client IP anyway, but that's not comparing this proposal against >> today's reality, which ought to be the point. >> >> I also think the text in that section seems to be trying to sell >> this as having no privacy impact, and I just don't think that is >> the case. > > Can you suggest some specific text or at least reraise this issue during > IETF LC? Fair question. I can raise it during IETF LC, sure. Not sure if I'll get a chance to draft proposed text, but if I do, I will;-) Cheers, S. From stpeter@stpeter.im Mon Jul 2 09:20:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7559321F8716 for ; Mon, 2 Jul 2012 09:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxbRvc0ubyCV for ; Mon, 2 Jul 2012 09:20:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E2B4421F870A for ; Mon, 2 Jul 2012 09:20:20 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0BA954005A; Mon, 2 Jul 2012 10:38:38 -0600 (MDT) Message-ID: <4FF1CA48.7090609@stpeter.im> Date: Mon, 02 Jul 2012 10:20:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mike Jones References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> <4E1F6AAD24975D4BA5B168042967394366572961@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FF1C3B5.4090902@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943665729B6@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943665729B6@TK5EX14MBXC283.redmond.corp.microsoft.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 16:20:21 -0000 On 7/2/12 9:54 AM, Mike Jones wrote: > It's done a lot - it's one of the primary applications of the > "localhost" name. I suppose we could define acct:user@localhost, but > that seems like more of a hack than just allowing acct:user. So if you want to access one of these non-Internet-connected hosts using HTTP, you would specify a URI of "http:///"? That's crazy talk. :) I really don't see a good reason to make the hostname optional -- it just introduces unnecessary complexity. Peter -- Peter Saint-Andre https://stpeter.im/ From superuser@gmail.com Mon Jul 2 09:29:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E2E21F861F for ; Mon, 2 Jul 2012 09:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCJjX3MjEroq for ; Mon, 2 Jul 2012 09:29:07 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 627C421F8585 for ; Mon, 2 Jul 2012 09:29:07 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so8524780lbb.31 for ; Mon, 02 Jul 2012 09:29:12 -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=K9mnjWPGRwHHN9k1YspK0dZmChFKb50bh6aOPzD65y0=; b=Sy1zY3+WNeTOv1krqPJlU8D5KB+QVNMb0j72H7TeSEJGAR2nibHVMb+aeiCORnd7JA kmWtY7gWyr1Fb9aa+/AVXIFu00uXuTUkhx4B90sgGaaydWzt2Evd82B6jwdvEMCAEmwn mQJkHymBw6fhSwafwiYHwdkQmaR0bXaP/RmF56fedFXsN89L074h2nmwAGh8R1gzvNiU PpdmQpsyzkpEqBfgeU7im8oyP1kdZVBGoz/NkNKgHPBsgwUcE+lrFQaHF4b1W18ZZs3e zYjGfbn3RrKLjUv+OZnt5SjyHSafFZp6Sh4Scidn0Lg13I+1aI7FTErooY4rC2wyiOGn +fZw== MIME-Version: 1.0 Received: by 10.112.46.9 with SMTP id r9mr6391715lbm.81.1341246552045; Mon, 02 Jul 2012 09:29:12 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 2 Jul 2012 09:29:12 -0700 (PDT) Date: Mon, 2 Jul 2012 09:29:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=f46d0401236f4a79a804c3db4c46 Subject: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 16:29:08 -0000 --f46d0401236f4a79a804c3db4c46 Content-Type: text/plain; charset=ISO-8859-1 Greetings, APPSAWG has now sent three documents, half of its recent docket, to the IESG for IETF Last Call. We have three open documents remaining: draft-ietf-appsawg-malformed-mail draft-ietf-appsawg-json-pointer draft-ietf-appsawg-json-patch These remain in active development. Having cleared those other three documents, we'd like to bring in and begin processing webfinger, which we've been holding outside the WG until we cleared some backlog. I'd like to thank the authors and participants for their patience as we worked through those other projects, and the rest of you for your work in getting the others off to the next steps in their lifecycle. The authors of draft-jones-appsawg-webfinger are invited to submit draft-ietf-appsawg-webfinger-00, and we'll approve it. Now, a question: The "acct:" scheme URI work is an offshoot of webfinger. PSA has recently posted a document that separates that work out. So what is working group consensus: Should these be processed as two documents in parallel (and should APPSAWG take them on), or should they be processed as a single document? -MSK, APPSAWG co-chair --f46d0401236f4a79a804c3db4c46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings,

APPSAWG has now sent three documents, half of its recent = docket, to the IESG for IETF Last Call.=A0 We have three open documents rem= aining:

draft-ietf-appsawg-malformed-mail
draft-ietf-appsawg-json= -pointer
draft-ietf-appsawg-json-patch

These remain in active development.=A0= Having cleared those other three documents, we'd like to bring in and = begin processing webfinger, which we've been holding outside the WG unt= il we cleared some backlog.=A0 I'd like to thank the authors and partic= ipants for their patience as we worked through those other projects, and th= e rest of you for your work in getting the others off to the next steps in = their lifecycle.

The authors of draft-jones-appsawg-webfinger are invited to submit draf= t-ietf-appsawg-webfinger-00, and we'll approve it.

Now, a questi= on: The "acct:" scheme URI work is an offshoot of webfinger.=A0 P= SA has recently posted a document that separates that work out.=A0 So what = is working group consensus: Should these be processed as two documents in p= arallel (and should APPSAWG take them on), or should they be processed as a= single document?

-MSK, APPSAWG co-chair

--f46d0401236f4a79a804c3db4c46-- From ve7jtb@ve7jtb.com Mon Jul 2 09:44:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1E821F870F for ; Mon, 2 Jul 2012 09:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_A_BODY=0.742] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfgG9sfDxRPz for ; Mon, 2 Jul 2012 09:44:37 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD7621F86D7 for ; Mon, 2 Jul 2012 09:44:36 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4803069ghb.31 for ; Mon, 02 Jul 2012 09:44:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=n8+TceIBwI7gWtlfKEoQOQBzVeHY8nXcq2D67tpWH1A=; b=DHlaMTEx4EkCuLzyh8g+I0k5aWfUPK/DCq+8xykqR/G3g9+zOMNc1BWVj9251BB72i sqyTBvu1jFz3hSs0wIeko/e9FO7okrZ2FjX6A7+8LuyvUkvmj/wWxtXrOOt2wOP6uJ9y zDXU1ueba3yer2Y92B+rbTKsT2kIyq3uhqj8eRzxoiCSK9ay+POUQkSJUS2SKvRyRBDC FjcMHycTV+elGRYqprzsQNwiNbY7/x9qnyLepT4YlYQl14VPB/Bjcwth5eIimOh/muHz /20jfvupv9m4rXESnnx4tVEHD1PFFUMUFD23Kkhk19IvXjBvaDwD9S7InAKAL6J7s0uw 4mig== Received: by 10.236.192.162 with SMTP id i22mr16182377yhn.83.1341247482200; Mon, 02 Jul 2012 09:44:42 -0700 (PDT) Received: from [192.168.1.211] (190-20-50-6.baf.movistar.cl. [190.20.50.6]) by mx.google.com with ESMTPS id e19sm11936221ann.10.2012.07.02.09.44.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jul 2012 09:44:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_91F18569-0A34-444F-AB24-4933A69815AC"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4FF1CA48.7090609@stpeter.im> Date: Mon, 2 Jul 2012 12:44:32 -0400 Message-Id: <5EBEB0AD-B7B9-4EF4-B7C2-055679B36705@ve7jtb.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> <4E1F6AAD24975D4BA5B168042967394366572961@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FF1C3B5.4090902@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943665729B6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FF1CA48.7090609@st peter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnlf51QWWxxhM0QurYIvVJO1u1k3RfQuY0F+4Skpt+6cUN56rmS0YWptsRjL5dhRMLKITfC Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 16:44:38 -0000 --Apple-Mail=_91F18569-0A34-444F-AB24-4933A69815AC Content-Type: multipart/alternative; boundary="Apple-Mail=_BE9B9F34-810C-408E-878C-C97B5DCFEC3B" --Apple-Mail=_BE9B9F34-810C-408E-878C-C97B5DCFEC3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Relative URI need to be relative to a base context. They don't contain scheme or host information. I could see having a relative acct: URI of: bob's account That would be assembled by some user agent to "acct:bob@example.com" as = a URI for dereferencing. That is different from throwing around "acct:bob" which is like saying = "http:///bob.html" and not a valid URI as I understand it. This is the good thing about trying to document acct: separately, it = brings out issues that WF might not address. John B. On 2012-07-02, at 12:20 PM, Peter Saint-Andre wrote: > On 7/2/12 9:54 AM, Mike Jones wrote: >> It's done a lot - it's one of the primary applications of the >> "localhost" name. I suppose we could define acct:user@localhost, but >> that seems like more of a hack than just allowing acct:user. >=20 > So if you want to access one of these non-Internet-connected hosts = using > HTTP, you would specify a URI of "http:///"? That's crazy talk. :) >=20 > I really don't see a good reason to make the hostname optional -- it > just introduces unnecessary complexity. >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_BE9B9F34-810C-408E-878C-C97B5DCFEC3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
<HEAD>
   <BASE href=3D"acct://example.com">
 </HEAD>

<BODY>
<A href=3D"bob">bob's =
account</A>
</BODY>
That would be assembled by = some user agent to "acct:bob@example.com" as a URI for = dereferencing.

That is different from throwing = around "acct:bob"  which is like saying "http:///bob.html" and not a valid URI as I = understand it.

This is the good thing about = trying to document acct: separately,  it brings out issues that WF = might not address.

John = B.

On 2012-07-02, at 12:20 PM, Peter = Saint-Andre wrote:

On = 7/2/12 9:54 AM, Mike Jones wrote:
It's done = a lot - it's one of the primary applications of = the
"localhost" name.  I = suppose we could define acct:user@localhost, = but
that seems like more of a = hack than just allowing acct:user.

So if you want to = access one of these non-Internet-connected hosts using
HTTP, you = would specify a URI of "http:///"? That's crazy = talk. :)

I really don't see a good reason to make the hostname = optional -- it
just introduces unnecessary = complexity.

Peter

--
Peter Saint-Andre
https://stpeter.im/




__= _____________________________________________
apps-discuss mailing = list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/app= s-discuss

= --Apple-Mail=_BE9B9F34-810C-408E-878C-C97B5DCFEC3B-- --Apple-Mail=_91F18569-0A34-444F-AB24-4933A69815AC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw MjE2NDQzMlowIwYJKoZIhvcNAQkEMRYEFCwIU4zhLCQYZTSEa0cjsXRuFpctMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AFnggT5rFBOLA7BEC+/b3/oMQ/UxFBqzrNkYB/EW6nnwY7grBOBdrQFxQP21N3dO37iVxxBV0sdU bjkuI5W9GC/BIdssmFuB0kKKpZ/KFlswDLbJDCpUhOZSnSAEyR0kZEaygwQvJyQeycp1PAJG/BPk CT9uEHhZDVuUOp0OxKXxpYt4Pj4g7uKE8atY/2DUqwJLzvrZXmTnAkruRW7xwqInJ0oNdU/KY9y2 Kiwidd3FLWhBvTzWQ4pTGuzko7MEfW0EpCx5EAG2eNyZGAnS2EG3gEf6F3zkibxHp0SxHFlCJM/b rg56BoO8MzI9ruEHPixtSd8/6nKb5/b/8mrScJwAAAAAAAA= --Apple-Mail=_91F18569-0A34-444F-AB24-4933A69815AC-- From stpeter@stpeter.im Mon Jul 2 09:44:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13A921F8734 for ; Mon, 2 Jul 2012 09:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpX26wj1oG-Y for ; Mon, 2 Jul 2012 09:44:44 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 34CF021F8726 for ; Mon, 2 Jul 2012 09:44:44 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C49BE4005A; Mon, 2 Jul 2012 11:03:02 -0600 (MDT) Message-ID: <4FF1D000.8020100@stpeter.im> Date: Mon, 02 Jul 2012 10:44:48 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 16:44:44 -0000 On 7/2/12 10:29 AM, Murray S. Kucherawy wrote: > The authors of draft-jones-appsawg-webfinger are invited to submit > draft-ietf-appsawg-webfinger-00, and we'll approve it. > > Now, a question: The "acct:" scheme URI work is an offshoot of > webfinger. PSA has recently posted a document that separates that work > out. So what is working group consensus: Should these be processed as > two documents in parallel (and should APPSAWG take them on), or should > they be processed as a single document? Clarifying question: since the chairs have invited the authors of the WebFinger I-D to submit it as a WG item, I assume that the question "should APPSAWG take them on" does not apply to the WebFinger I-D, but only to the 'acct' URI I-D. FWIW, I authored a separate spec for the 'acct' URI scheme because I understood from the list discussion that the 'acct' URI *could* be used by protocols other than WebFinger. If that is true, then it seems to me preferable to work on the WebFinger protocol and the 'acct' URI scheme as separate documents. If that is false, then I think they belong in the same specification. Personally I'm unclear as to whether the 'acct' URI scheme is tightly coupled to WebFinger protocol, so I think we need to figure that out first before deciding whether to proceed with two documents or one. Peter -- Peter Saint-Andre https://stpeter.im/ From superuser@gmail.com Mon Jul 2 10:14:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E05421F862A for ; Mon, 2 Jul 2012 10:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhHaFaFdvxcH for ; Mon, 2 Jul 2012 10:14:24 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 74C6221F85FD for ; Mon, 2 Jul 2012 10:14:24 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so8578298lbb.31 for ; Mon, 02 Jul 2012 10:14:29 -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=QiFmQe3XwNTkYXwC1kbzR9Of8gEcr8J2+CZumvDmG2E=; b=CqzzPDyzNZkKqK8ejfSpYSo6OLYIaciBrEl/lH9IFv50G64TnQ9QMwlWnGtkjkzrOj WTdnTouT04/QoYft2N+J866nXLr+tPbYgflEhnnutw1tYG2Mw0okdYW9JBfzKbbr/gk9 txVKdrQAXgYMnwDQmNL3lKxilJMMfBbmZnWOKgkZ9AjpBmY223fHuvDyf1EViIgoJh0c gg6JpelVO9vQrIIyDZUJej7GyihqjNvVicj+SkN3uOZYnKZBYrsA5++YZpK7cbg+YobG e8pucjpXmnQrjis4RPUSPK7Ijm5AaPvyq5+ogSgVKUOM3FbfkPm0Pyl1c7sJGv6bXRGW /Wkw== MIME-Version: 1.0 Received: by 10.112.39.135 with SMTP id p7mr6559085lbk.78.1341249269128; Mon, 02 Jul 2012 10:14:29 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 2 Jul 2012 10:14:29 -0700 (PDT) In-Reply-To: <4FF1D000.8020100@stpeter.im> References: <4FF1D000.8020100@stpeter.im> Date: Mon, 2 Jul 2012 10:14:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=485b390f7a763ddfe104c3dbeee1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 17:14:25 -0000 --485b390f7a763ddfe104c3dbeee1 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 2, 2012 at 9:44 AM, Peter Saint-Andre wrote: > Clarifying question: since the chairs have invited the authors of the > WebFinger I-D to submit it as a WG item, I assume that the question > "should APPSAWG take them on" does not apply to the WebFinger I-D, but > only to the 'acct' URI I-D. > Yes, sorry. > > FWIW, I authored a separate spec for the 'acct' URI scheme because I > understood from the list discussion that the 'acct' URI *could* be used > by protocols other than WebFinger. If that is true, then it seems to me > preferable to work on the WebFinger protocol and the 'acct' URI scheme > as separate documents. If that is false, then I think they belong in the > same specification. Personally I'm unclear as to whether the 'acct' URI > scheme is tightly coupled to WebFinger protocol, so I think we need to > figure that out first before deciding whether to proceed with two > documents or one. > > Right, that's part-and-parcel of the question I'm asking. -MSK --485b390f7a763ddfe104c3dbeee1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 2, 2012 at 9:44 AM, Peter Saint-Andre <stpeter@stpeter.im= > wrote:
Clarifying question: since the chairs have invited the authors of the
WebFinger I-D to submit it as a WG item, I assume that the question
"should APPSAWG take them on" does not apply to the WebFinger I-D= , but
only to the 'acct' URI I-D.

Yes, sorry.=A0

FWIW, I authored a separate spec for the 'acct' URI scheme because = I
understood from the list discussion that the 'acct' URI *could* be = used
by protocols other than WebFinger. If that is true, then it seems to me
preferable to work on the WebFinger protocol and the 'acct' URI sch= eme
as separate documents. If that is false, then I think they belong in the same specification. Personally I'm unclear as to whether the 'acct&= #39; URI
scheme is tightly coupled to WebFinger protocol, so I think we need to
figure that out first before deciding whether to proceed with two
documents or one.


Right, that's part-and-parcel of the question I'm askin= g.

-MSK

--485b390f7a763ddfe104c3dbeee1-- From Michael.Jones@microsoft.com Mon Jul 2 10:15:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D36B21F8617 for ; Mon, 2 Jul 2012 10:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.763 X-Spam-Level: X-Spam-Status: No, score=-3.763 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bahZkGhG+ok2 for ; Mon, 2 Jul 2012 10:15:05 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id DAACA21F8630 for ; Mon, 2 Jul 2012 10:15:04 -0700 (PDT) Received: from mail84-db3-R.bigfish.com (10.3.81.243) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 2 Jul 2012 17:13:12 +0000 Received: from mail84-db3 (localhost [127.0.0.1]) by mail84-db3-R.bigfish.com (Postfix) with ESMTP id 6CEAD3A04E2; Mon, 2 Jul 2012 17:13:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zzbb2dI98dI9371I542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail84-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail84-db3 (localhost.localdomain [127.0.0.1]) by mail84-db3 (MessageSwitch) id 1341249190486098_17122; Mon, 2 Jul 2012 17:13:10 +0000 (UTC) Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.232]) by mail84-db3.bigfish.com (Postfix) with ESMTP id 74C24E0046; Mon, 2 Jul 2012 17:13:10 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 2 Jul 2012 17:13:10 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0309.003; Mon, 2 Jul 2012 17:14:58 +0000 From: Mike Jones To: Peter Saint-Andre , "Murray S. Kucherawy" Thread-Topic: [apps-discuss] The webfinger and the acct: scheme documents Thread-Index: AQHNWG/WQ0eH9e/PpEGLOhYyE4y2G5cWMxwAgAAH46A= Date: Mon, 2 Jul 2012 17:14:56 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366572C13@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4FF1D000.8020100@stpeter.im> In-Reply-To: <4FF1D000.8020100@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 17:15:06 -0000 I would like to add support to submitting your acct: draft as a working gro= up document. While WebFinger will have a normative dependency on it, it's actually indep= endent of WebFinger and so can and should be considered separately. Best wishes, -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Peter Saint-Andre Sent: Monday, July 02, 2012 9:45 AM To: Murray S. Kucherawy Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents On 7/2/12 10:29 AM, Murray S. Kucherawy wrote: > The authors of draft-jones-appsawg-webfinger are invited to submit=20 > draft-ietf-appsawg-webfinger-00, and we'll approve it. >=20 > Now, a question: The "acct:" scheme URI work is an offshoot of=20 > webfinger. PSA has recently posted a document that separates that=20 > work out. So what is working group consensus: Should these be=20 > processed as two documents in parallel (and should APPSAWG take them=20 > on), or should they be processed as a single document? Clarifying question: since the chairs have invited the authors of the WebFi= nger I-D to submit it as a WG item, I assume that the question "should APPS= AWG take them on" does not apply to the WebFinger I-D, but only to the 'acc= t' URI I-D. FWIW, I authored a separate spec for the 'acct' URI scheme because I unders= tood from the list discussion that the 'acct' URI *could* be used by protoc= ols other than WebFinger. If that is true, then it seems to me preferable t= o work on the WebFinger protocol and the 'acct' URI scheme as separate docu= ments. If that is false, then I think they belong in the same specification= . Personally I'm unclear as to whether the 'acct' URI scheme is tightly cou= pled to WebFinger protocol, so I think we need to figure that out first bef= ore deciding whether to proceed with two documents or one. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From martin.thomson@gmail.com Mon Jul 2 10:43:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E6B21F8768 for ; Mon, 2 Jul 2012 10:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umx14Zhw90Az for ; Mon, 2 Jul 2012 10:43:37 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7B121F8767 for ; Mon, 2 Jul 2012 10:43:36 -0700 (PDT) Received: by bkty8 with SMTP id y8so5196535bkt.31 for ; Mon, 02 Jul 2012 10:43: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:date:message-id:subject:from:to :cc:content-type; bh=4/mOH33PAouKv/NqFXVBjq2S7bFK+Ys0mAZBmhG6Oho=; b=FgRFdpmM+wuhSruSI7m6WTd8P0OzHmbfT+EYYNLzVQ70NEXrUm3PYW83pHJZ14iKPS FVKf7/ry+q6XKsNX7yG8joRZOccwuk8ltxmTZ0M4micYDGX6ZXGZhgbmIoE7RXTZdXUD Y7+1//2IgRSCMwbZCX48MI2DL8feWPMEtACfaLqb8XNgucILcYaH3dN6f+CPaYd/Jx8V hmPrBggzapCg6GenXHYPMVqxtHz7a6PF6lIio9gJ2DQu+jnLo8QROmAHG5rK/eTc0ZW3 IRxJTAm+y3o+pJxVh+JoPLYOBCVUTS7NCzgVquenrIgU2/TLMkaVjc3YXpXx5/GvtN+g 2S+A== MIME-Version: 1.0 Received: by 10.205.132.6 with SMTP id hs6mr7835100bkc.26.1341251021855; Mon, 02 Jul 2012 10:43:41 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Mon, 2 Jul 2012 10:43:41 -0700 (PDT) In-Reply-To: <4FF1CA48.7090609@stpeter.im> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> <4E1F6AAD24975D4BA5B168042967394366572961@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FF1C3B5.4090902@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943665729B6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FF1CA48.7090609@stpeter.im> Date: Mon, 2 Jul 2012 10:43:41 -0700 Message-ID: From: Martin Thomson To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 17:43:38 -0000 On 2 July 2012 09:20, Peter Saint-Andre wrote: > I really don't see a good reason to make the hostname optional -- it > just introduces unnecessary complexity. +1 There is always a domain. Relying on implicit contexts just makes the scheme more fragile. If you really don't know the domain, but expect clients to have this information, how about: acct:user@you.know.what.i.mean.but.its.not.my.domain.com From stpeter@stpeter.im Mon Jul 2 10:45:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B05C11E80BC for ; Mon, 2 Jul 2012 10:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEitqPY4i4EL for ; Mon, 2 Jul 2012 10:45:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1F68A11E80B3 for ; Mon, 2 Jul 2012 10:45:37 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D47214005A; Mon, 2 Jul 2012 12:03:55 -0600 (MDT) Message-ID: <4FF1DE45.70801@stpeter.im> Date: Mon, 02 Jul 2012 11:45:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Martin Thomson References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> <4E1F6AAD24975D4BA5B168042967394366572961@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FF1C3B5.4090902@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943665729B6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FF1CA48.7090609@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 17:45:38 -0000 On 7/2/12 11:43 AM, Martin Thomson wrote: > On 2 July 2012 09:20, Peter Saint-Andre wrote: >> I really don't see a good reason to make the hostname optional -- it >> just introduces unnecessary complexity. > > +1 > > There is always a domain. Relying on implicit contexts just makes the > scheme more fragile. Well put. I don't trust this implicit stuff in protocols. :) /psa From bobwyman@gmail.com Mon Jul 2 10:52:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2692D11E80D5 for ; Mon, 2 Jul 2012 10:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOegmPG3HiDV for ; Mon, 2 Jul 2012 10:52:42 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id EB47C11E80C4 for ; Mon, 2 Jul 2012 10:52:41 -0700 (PDT) Received: by yhp26 with SMTP id 26so6092490yhp.26 for ; Mon, 02 Jul 2012 10:52:47 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oDPmy0FIJMuJaV9M/M05YbH///Mb6gA3o7iVnXKnpDo=; b=V+eLJlYbf66MZ3Aiq5Liiq/qP4d685NHgRHxsp8X8ulUx0tNOXzOFYdwz2iiC72shw P7mGHBLehV2LyQNhKsaeIIxRmiBOE/WtjPD4QaUttmGw+58jlzUSWnBAMrGQXS33IiKz 0sWXXQBjSQ6kFP1hXaa7+9S+CthF2QA5vy8Xf4K23fwd52wniwDIzTiAYPjdxkygU1mX RJYUOgV1VhT3GEU35sZ16Fp+LFNxyN9GT0RIH9y5A+uZOhelUz2nlZD9u51hdealbPcA AoW5xEBn45o6Pg89pARlx1PUPESxfcFyYr3Ahx5VZQ8TdoDRxV0QSq048KvpjdVScPgw Zfcw== MIME-Version: 1.0 Received: by 10.236.155.41 with SMTP id i29mr16192204yhk.115.1341251567267; Mon, 02 Jul 2012 10:52:47 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.100.95.20 with HTTP; Mon, 2 Jul 2012 10:52:47 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366572C13@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4FF1D000.8020100@stpeter.im> <4E1F6AAD24975D4BA5B168042967394366572C13@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 2 Jul 2012 13:52:47 -0400 X-Google-Sender-Auth: Wvj0jIfAZ3f1XRQTa0MrUUxGe9Q Message-ID: From: Bob Wyman To: Mike Jones Content-Type: multipart/alternative; boundary=20cf303f6e8238b02104c3dc77b0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 17:52:43 -0000 --20cf303f6e8238b02104c3dc77b0 Content-Type: text/plain; charset=ISO-8859-1 I would appreciate it greatly if someone could suggest a number of useful use-cases for acct: without WebFinger. What use is independence if that independence provides no utility? bob wyman On Mon, Jul 2, 2012 at 1:14 PM, Mike Jones wrote: > I would like to add support to submitting your acct: draft as a working > group document. > > While WebFinger will have a normative dependency on it, it's actually > independent of WebFinger and so can and should be considered separately. > > Best wishes, > -- Mike > > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of Peter Saint-Andre > Sent: Monday, July 02, 2012 9:45 AM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents > > On 7/2/12 10:29 AM, Murray S. Kucherawy wrote: > > > The authors of draft-jones-appsawg-webfinger are invited to submit > > draft-ietf-appsawg-webfinger-00, and we'll approve it. > > > > Now, a question: The "acct:" scheme URI work is an offshoot of > > webfinger. PSA has recently posted a document that separates that > > work out. So what is working group consensus: Should these be > > processed as two documents in parallel (and should APPSAWG take them > > on), or should they be processed as a single document? > > Clarifying question: since the chairs have invited the authors of the > WebFinger I-D to submit it as a WG item, I assume that the question "should > APPSAWG take them on" does not apply to the WebFinger I-D, but only to the > 'acct' URI I-D. > > FWIW, I authored a separate spec for the 'acct' URI scheme because I > understood from the list discussion that the 'acct' URI *could* be used by > protocols other than WebFinger. If that is true, then it seems to me > preferable to work on the WebFinger protocol and the 'acct' URI scheme as > separate documents. If that is false, then I think they belong in the same > specification. Personally I'm unclear as to whether the 'acct' URI scheme > is tightly coupled to WebFinger protocol, so I think we need to figure that > out first before deciding whether to proceed with two documents or one. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > > _______________________________________________ > 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 > --20cf303f6e8238b02104c3dc77b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would appreciate it greatly if someone could suggest a number of useful u= se-cases for acct: without WebFinger.

What use is independence= if that independence provides no utility?

bob wym= an

On Mon, Jul 2, 2012 at 1:14 PM, Mike Jones <= span dir=3D"ltr"><Michael.Jones@microsoft.com> wrote:
I would like to add support to submitting your acct: draft as a working gro= up document.

While WebFinger will have a normative dependency on it, it's actually i= ndependent of WebFinger and so can and should be considered separately.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Best wishes= ,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike

-----Original Message-----
From: apps-discuss-bounces= @ietf.org [mailto:apps= -discuss-bounces@ietf.org] On Behalf Of Peter Saint-Andre
Sent: Monday, July 02, 2012 9:45 AM
To: Murray S. Kucherawy
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents
On 7/2/12 10:29 AM, Murray S. Kucherawy wrote:

> The authors of draft-jones-appsawg-webfinger are invited to submit
> draft-ietf-appsawg-webfinger-00, and we'll approve it.
>
> Now, a question: The "acct:" scheme URI work is an offshoot = of
> webfinger. =A0PSA has recently posted a document that separates that > work out. =A0So what is working group consensus: Should these be
> processed as two documents in parallel (and should APPSAWG take them > on), or should they be processed as a single document?

Clarifying question: since the chairs have invited the authors of the WebFi= nger I-D to submit it as a WG item, I assume that the question "should= APPSAWG take them on" does not apply to the WebFinger I-D, but only t= o the 'acct' URI I-D.

FWIW, I authored a separate spec for the 'acct' URI scheme because = I understood from the list discussion that the 'acct' URI *could* b= e used by protocols other than WebFinger. If that is true, then it seems to= me preferable to work on the WebFinger protocol and the 'acct' URI= scheme as separate documents. If that is false, then I think they belong i= n the same specification. Personally I'm unclear as to whether the '= ;acct' URI scheme is tightly coupled to WebFinger protocol, so I think = we need to figure that out first before deciding whether to proceed with tw= o documents or one.

Peter

--
Peter Saint-Andre
https://stpeter.im/



_______________________________________________
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

--20cf303f6e8238b02104c3dc77b0-- From stpeter@stpeter.im Mon Jul 2 10:53:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD1C21F85F2 for ; Mon, 2 Jul 2012 10:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.469 X-Spam-Level: X-Spam-Status: No, score=-103.469 tagged_above=-999 required=5 tests=[AWL=1.130, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBGuCB2Bb6Ef for ; Mon, 2 Jul 2012 10:52:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2296B21F85F1 for ; Mon, 2 Jul 2012 10:52:59 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 151B34005A for ; Mon, 2 Jul 2012 12:11:18 -0600 (MDT) Message-ID: <4FF1DFFF.4090703@stpeter.im> Date: Mon, 02 Jul 2012 11:53:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <20120702175123.24297.20097.idtracker@ietfa.amsl.com> In-Reply-To: <20120702175123.24297.20097.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: <20120702175123.24297.20097.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: I-D Action: draft-saintandre-acct-uri-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 17:53:00 -0000 FYI. I addressed the issues raised so far. Keep those cards and letters coming! ;-) /psa -------- Original Message -------- Subject: I-D Action: draft-saintandre-acct-uri-01.txt Date: Mon, 02 Jul 2012 10:51:23 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The 'acct' URI Scheme Author(s) : Peter Saint-Andre Filename : draft-saintandre-acct-uri-01.txt Pages : 7 Date : 2012-07-02 Abstract: This document defines the 'acct' URI scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-saintandre-acct-uri There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-acct-uri-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-saintandre-acct-uri-01 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 bobwyman@gmail.com Mon Jul 2 10:57:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9985B11E80D5 for ; Mon, 2 Jul 2012 10:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vai0EC7B7YlD for ; Mon, 2 Jul 2012 10:57:31 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCB311E80CC for ; Mon, 2 Jul 2012 10:57:31 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4892482ghb.31 for ; Mon, 02 Jul 2012 10:57:36 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=m29VSSf7uXygOx2jHQ8/mRwmarqytr3gcLaOI4FdS2Q=; b=JXdhOAw3jXe++LpCSYOUcySerV68njOct61Gjh9uxa5IsuLIFGKgmUEtwlCEXRKqi3 pSsjgzduSQJ8a/hn2Vav3r6du3VDC/sKC26bDVQP7iKX4xFDM59IL2/vbb0VH0LNseBy OtvD9B3cN6pP1/rBdpU1FvU2QvuHXLZnSO+9opOST2xnOC8ytS1WTL3LgfH7lCvM2Bvh tLks75G1yKSFPLV9dm3lEilT4gFy8knSgJ9kDr5xhd8YznTvb3eF5b+UPI5/kkgSs3zt MsXpuO5nRjfIkcVdANAiSMiER5tv6gLcCzYA+eVX5dEebwNmIeXz2uBRI4X7a9rPwcZc MVuA== MIME-Version: 1.0 Received: by 10.236.187.1 with SMTP id x1mr2843017yhm.125.1341251856637; Mon, 02 Jul 2012 10:57:36 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.100.95.20 with HTTP; Mon, 2 Jul 2012 10:57:36 -0700 (PDT) In-Reply-To: References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> Date: Mon, 2 Jul 2012 13:57:36 -0400 X-Google-Sender-Auth: ouSo3uM8sQpIXf6RfYsx2QNXv3c Message-ID: From: Bob Wyman To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=20cf305e2551781dc504c3dc88f2 Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 17:57:32 -0000 --20cf305e2551781dc504c3dc88f2 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 2, 2012 at 11:42 AM, Phillip Hallam-Baker wrote: > I think Tim regrets having been argued out of a lot of positions > relating to naming that he was subsequently proved right on. > > Naming issues are an area where a lot of people have strong opinions > that really turn out to be a matter of taste rather than grounded in > semiotics. > > The whole business of differentiating URLs and URNs as distinct > classes was bogus. Once the locator scheme has caching, a URL becomes > a name. Once an application provides a default action for a name (e.g. > look it up on Amazon) then a name becomes a locator. > > > A URI scheme should simply provide people with a well defined syntax > that allows them to express the concepts that applications that need > to interoperate need to exchange references to. Trying to decide how > people should use the identifiers is counterproductive. Trying to > enforce particular approaches is destructive. > > The vast majority of computer systems that use accounts do not bind > them to domain names. So there is a place in the acct: scheme for > unbound references. It seems to me that an unbound acct: name would be useful only in a "local" case, not generally useful between otherwise inter-working machines. As I understand it, the IETF normally limits its scope to those issues that relate to interworking between systems. Thus, it seems to me that a feature that is purely local and does not, in fact, facilitate inter-working is one that should not appear in an IETF document. This, of course, would not prevent anyone from building a system, or even set of systems, that made private agreements or used private conventions concerning the use of acct: names which were unbound or contained no domain part. But, that is not, I think, a matter which need concern anyone while wearing an IETF standards hat. > I expect that practice to go down over time. I > expect that deployment of technology that uses acct: will encourage > that. But trying to force the issue by excluding unbound accounts is > only going to hurt that transition by making acct: a special case of > account objects rather than a technology that can ease the transition. > > > > On Mon, Jul 2, 2012 at 9:42 AM, Melvin Carvalho > wrote: > > > > > > On 2 July 2012 15:31, Phillip Hallam-Baker wrote: > >> > >> Relative URIs have existed from the start. That is one of the reasons > >> they had to be renamed 'uniform' rather than universal. > >> > >> The idea is to have a uniform means of representing a name. If that > >> name is ambiguous, then the URI form needs to be able to capture that. > >> > >> I don't think it helps in the slightest to argue over whether > >> /fred.html is a URI or a URI fragment. Tim's original proposal is in > >> my view rather better thought out than what others have proposed as > >> 'improvements'. A name is merely a label for a concept and every URI > >> is a name, some happen to be resolvable via a default protocol, others > >> not, thats all. > >> > >> > >> Incompletely specified account names are inevitable. If you want to > >> use SAML or the like in a Windows environment then the Windows domain > >> is not bound to a unique DNS address and picking a random one is only > >> going to confuse matters. > >> > >> An acct: name that does not have a domain name part is going to have > >> to be resolved in the same fashion as relative URIs are - by reference > >> to context and local state. I don't see anything wrong in that. In the > >> context of accounts, a domain name is not completely unambiguous > >> unless you also have time. > >> > >> > >> The real world is a fuzzy place. Trying to cope with the fuzzyness and > >> ambiguity by wishing it away only leads to broken specs. Accounts have > >> only recently come to be understood to have an intrinsic domain > >> component. It is better to accept that fact and to build > >> infrastructure that addresses the need than to pretend that the need > >> can be magicked away. > >> > >> People who don't have a domain are going to drop it in any case. We > >> saw the same thing happen with the news: and nntp: URL. Tim thought > >> that the USENET space was uniform and tried to establish a URL that > >> didn't have the domain name. Engineers trying to solve real world > >> problems then added it back in because there is more to NNTP than > >> USENET. > > > > > > I enjoyed reading this. Just a remark regarding universal vs uniform. > > > > FWIW, Tim is on record saying that he regrets not insisting to the IETF, > > that the original 'Universal' should be used in URI, instead of changed > form > > 'Uniform'. Depending on which circles you're in, I think informally, the > > two terms are used pretty interchangeably, these days. > > > >> > >> > >> > >> > >> On Mon, Jul 2, 2012 at 7:55 AM, Graham Klyne wrote: > >> > On 01/07/2012 23:02, Peter Saint-Andre wrote: > >> >> > >> >> On 7/1/12 9:38 AM, William Mills wrote: > >> >>> > >> >>> Section 4.3: '"@" domainpart' should be optional. It's reasonable > >> >>> to think this might be used with local account identifiers that > >> >>> don/t/need have a domain. > >> >> > >> >> > >> >> Making the domain name of the service provider implicit seems > >> >> ill-advised to me. What's the harm of including the domainpart? > >> > > >> > > >> > +1 > >> > > >> > (URIs are intended to be a global namespace.) > >> > > >> > #g > >> > -- > >> > > >> > _______________________________________________ > >> > apps-discuss mailing list > >> > apps-discuss@ietf.org > >> > https://www.ietf.org/mailman/listinfo/apps-discuss > >> > >> > >> > >> -- > >> Website: http://hallambaker.com/ > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --20cf305e2551781dc504c3dc88f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jul 2, 2012 at 11:42 AM, Phillip= Hallam-Baker <hallam@gmail.com> wrote:
I think Tim regrets having been argued out of a lot of positions
relating to naming that he was subsequently proved right on.

Naming issues are an area where a lot of people have strong opinions
that really turn out to be a matter of taste rather than grounded in
semiotics.

The whole business of differentiating URLs and URNs as distinct
classes was bogus. Once the locator scheme has caching, a URL becomes
a name. Once an application provides a default action for a name (e.g.
look it up on Amazon) then a name becomes a locator.


A URI scheme should simply provide people with a well defined syntax
that allows them to express the concepts that applications that need
to interoperate need to exchange references to. Trying to decide how
people should use the identifiers is counterproductive. Trying to
enforce particular approaches is destructive.

The vast majority of computer systems that use accounts do not bind
them to domain names. So there is a place in the acct: scheme for
unbound references.
It seems to me that an unbound acct: n= ame would be useful only in a "local" case, not generally useful = between otherwise inter-working machines. As I understand it, the IETF norm= ally limits its scope to those issues that relate to interworking between s= ystems. Thus, it seems to me that a feature that is purely local and does n= ot, in fact, facilitate inter-working is one that should not appear in an I= ETF document. This, of course, would not prevent anyone from building a sys= tem, or even set of systems, that made private agreements or used private c= onventions concerning the use of acct: names which were unbound or containe= d no domain part. But, that is not, I think, a matter which need concern an= yone while wearing an IETF standards hat.

=A0
I expect that = practice to go down over time. I
expect that deployment of technology that uses acct: will encourage
that. But trying to force the issue by excluding unbound accounts is
only going to hurt that transition by making acct: a special case of
account objects rather than a technology that can ease the transition.



On Mon, Jul 2, 2012 at 9:42 AM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
>
>
> On 2 July 2012 15:31, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>>
>> Relative URIs have existed from the start. That is one of the reas= ons
>> they had to be renamed 'uniform' rather than universal. >>
>> The idea is to have a uniform means of representing a name. If tha= t
>> name is ambiguous, then the URI form needs to be able to capture t= hat.
>>
>> I don't think it helps in the slightest to argue over whether<= br> >> /fred.html is a URI or a URI fragment. Tim's original proposal= is in
>> my view rather better thought out than what others have proposed a= s
>> 'improvements'. A name is merely a label for a concept and= every URI
>> is a name, some happen to be resolvable via a default protocol, ot= hers
>> not, thats all.
>>
>>
>> Incompletely specified account names are inevitable. If you want t= o
>> use SAML or the like in a Windows environment then the Windows dom= ain
>> is not bound to a unique DNS address and picking a random one is o= nly
>> going to confuse matters.
>>
>> An acct: name that does not have a domain name part is going to ha= ve
>> to be resolved in the same fashion as relative URIs are - by refer= ence
>> to context and local state. I don't see anything wrong in that= . In the
>> context of accounts, a domain name is not completely unambiguous >> unless you also have time.
>>
>>
>> The real world is a fuzzy place. Trying to cope with the fuzzyness= and
>> ambiguity by wishing it away only leads to broken specs. Accounts = have
>> only recently come to be understood to have an intrinsic domain >> component. It is better to accept that fact and to build
>> infrastructure that addresses the need than to pretend that the ne= ed
>> can be magicked away.
>>
>> People who don't have a domain are going to drop it in any cas= e. We
>> saw the same thing happen with the news: and nntp: URL. Tim though= t
>> that the USENET space was uniform and tried to establish a URL tha= t
>> didn't have the domain name. Engineers trying to solve real wo= rld
>> problems then added it back in because there is more to NNTP than<= br> >> USENET.
>
>
> I enjoyed reading this. =A0Just a remark regarding universal vs unifor= m.
>
> FWIW, Tim is on record saying that he regrets not insisting to the IET= F,
> that the original 'Universal' should be used in URI, instead o= f changed form
> 'Uniform'. =A0Depending on which circles you're in, I thin= k informally, the
> two terms are used pretty interchangeably, these days.
>
>>
>>
>>
>>
>> On Mon, Jul 2, 2012 at 7:55 AM, Graham Klyne <GK@ninebynine.org> wrote:
>> > On 01/07/2012 23:02, Peter Saint-Andre wrote:
>> >>
>> >> On 7/1/12 9:38 AM, William Mills wrote:
>> >>>
>> >>> Section 4.3: =A0'"@" domainpart' sh= ould be optional. =A0It's reasonable
>> >>> to think this might be used with local account identi= fiers that
>> >>> don/t/need have a domain.
>> >>
>> >>
>> >> Making the domain name of the service provider implicit s= eems
>> >> ill-advised to me. What's the harm of including the d= omainpart?
>> >
>> >
>> > +1
>> >
>> > (URIs are intended to be a global namespace.)
>> >
>> > #g
>> > --
>> >
>> > _______________________________________________
>> > apps-discuss mailing list
>> > apps-discuss@ietf.or= g
>> > https://www.ietf.org/mailman/listinfo/apps-discuss<= br> >>
>>
>>
>> --
>> Website: htt= p://hallambaker.com/
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org=
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>



--
Website: http://halla= mbaker.com/
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--20cf305e2551781dc504c3dc88f2-- From hallam@gmail.com Mon Jul 2 11:13:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E215521F86F6 for ; Mon, 2 Jul 2012 11:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WdcV3+M8DF5 for ; Mon, 2 Jul 2012 11:13:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 76D9021F85D7 for ; Mon, 2 Jul 2012 11:13:11 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9897700obb.31 for ; Mon, 02 Jul 2012 11:13: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; bh=YTlQ36IaFuz1z52wVp2/GYN0ojgH7W2fTc1IMUzf1j0=; b=lChYi0cgTnsu+UvbcZyV3Lum9utQqVz0l2PKuNsbb/jbHNYymb7xxwje0hRvNwtrNP oug4i7QfJxqzcdZVFuFmwklVTDNYQTBRP4C59mgEftN3QuTgRUYe2iUxX+9AJYHulVvK zA5pEDcEqHudPqZpPfdY01szCoZfsL+CH3thSV1Oi3k/ynDLTDgttT0u6eIXyTM+GUHR M0J+J8j9SJyyNlZhRPTjlHHsajHRV8zlGMl0ETJ31reDJN6l45pNOzoWKpHsSUXfyK3p 50hVqzSaBK5FLyA4k7uz1BTsIn9OWgnbZHhxSGnb3dKm9sKKVduLsSGEZF/eO0Tj5R+L a0dQ== MIME-Version: 1.0 Received: by 10.182.116.2 with SMTP id js2mr9396404obb.38.1341252796773; Mon, 02 Jul 2012 11:13:16 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Mon, 2 Jul 2012 11:13:16 -0700 (PDT) In-Reply-To: References: <4FF1D000.8020100@stpeter.im> <4E1F6AAD24975D4BA5B168042967394366572C13@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 2 Jul 2012 14:13:16 -0400 Message-ID: From: Phillip Hallam-Baker To: Bob Wyman Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 18:13:13 -0000 The main use case I see for acct: is SAML and SAML-like specifications that currently end up using mailto: I don't see WebFinger as being the driver at all. It is not a specification I am very interested in as 'public information about Bob' is a subset of 'information that Alice is permitted to know about Bob.' On Mon, Jul 2, 2012 at 1:52 PM, Bob Wyman wrote: > I would appreciate it greatly if someone could suggest a number of useful > use-cases for acct: without WebFinger. > > What use is independence if that independence provides no utility? > > bob wyman > > > On Mon, Jul 2, 2012 at 1:14 PM, Mike Jones > wrote: >> >> I would like to add support to submitting your acct: draft as a working >> group document. >> >> While WebFinger will have a normative dependency on it, it's actually >> independent of WebFinger and so can and should be considered separately. >> >> Best wishes, >> -- Mike >> >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] >> On Behalf Of Peter Saint-Andre >> Sent: Monday, July 02, 2012 9:45 AM >> To: Murray S. Kucherawy >> Cc: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents >> >> On 7/2/12 10:29 AM, Murray S. Kucherawy wrote: >> >> > The authors of draft-jones-appsawg-webfinger are invited to submit >> > draft-ietf-appsawg-webfinger-00, and we'll approve it. >> > >> > Now, a question: The "acct:" scheme URI work is an offshoot of >> > webfinger. PSA has recently posted a document that separates that >> > work out. So what is working group consensus: Should these be >> > processed as two documents in parallel (and should APPSAWG take them >> > on), or should they be processed as a single document? >> >> Clarifying question: since the chairs have invited the authors of the >> WebFinger I-D to submit it as a WG item, I assume that the question "should >> APPSAWG take them on" does not apply to the WebFinger I-D, but only to the >> 'acct' URI I-D. >> >> FWIW, I authored a separate spec for the 'acct' URI scheme because I >> understood from the list discussion that the 'acct' URI *could* be used by >> protocols other than WebFinger. If that is true, then it seems to me >> preferable to work on the WebFinger protocol and the 'acct' URI scheme as >> separate documents. If that is false, then I think they belong in the same >> specification. Personally I'm unclear as to whether the 'acct' URI scheme is >> tightly coupled to WebFinger protocol, so I think we need to figure that out >> first before deciding whether to proceed with two documents or one. >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> >> >> _______________________________________________ >> 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 > -- Website: http://hallambaker.com/ From perpetual-tripper@wwelves.org Mon Jul 2 13:36:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F5F11E80EB for ; Mon, 2 Jul 2012 13:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37Ybliu4w+iI for ; Mon, 2 Jul 2012 13:36:30 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4E821F861A for ; Mon, 2 Jul 2012 13:36:29 -0700 (PDT) X-Originating-IP: 217.70.178.146 Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 82FA2A80AD; Mon, 2 Jul 2012 22:36:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter18-d.gandi.net (mfilter18-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 6E+IDd6GvPgE; Mon, 2 Jul 2012 22:36:23 +0200 (CEST) X-Originating-IP: 217.11.53.243 Received: from localhost (243.53.11.217.in-addr.arpa.manitu.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 69EC0A80A3; Mon, 2 Jul 2012 22:36:22 +0200 (CEST) Content-Type: text/plain; charset=UTF-8 From: elf Pavlik To: "apps-discuss@ietf.org" In-reply-to: References: <4FF1D000.8020100@stpeter.im> <4E1F6AAD24975D4BA5B168042967394366572C13@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 02 Jul 2012 20:36:21 +0000 Message-Id: <1341257402-sup-9426@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: Henry Story Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 20:36:31 -0000 Excerpts from Bob Wyman's message of 2012-07-02 17:52:47 +0000: > I would appreciate it greatly if someone could suggest a number of usef= ul > use-cases for acct: without WebFinger. >=20 > What use is independence if that independence provides no utility? i wonder if webfinger could specify handling acct: for HTTP, but other = protocols?(SIP, XMPP, PSYC[1], ...) could maybe also use generic acct: with developments like WebID[2] maybe i could use same ss= l cert just with acct: in SAN and authenticate on this account to various= services... ~elf-pavlik~ [1] http://psyced.org/ [2] http://webid.info/ >bob wyman > >On Mon, Jul 2, 2012 at 1:14 PM, Mike Jones = wrote: >> >> I would like to add support to submitting your acct: draft as a workin= g >> group document. >> >> While WebFinger will have a normative dependency on it, it's actually >> independent of WebFinger and so can and should be considered separatel= y. >> >> Best wishes, >> -- Mike >> >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.= org] >> On Behalf Of Peter Saint-Andre >> Sent: Monday, July 02, 2012 9:45 AM >> To: Murray S. Kucherawy >> Cc: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] The webfinger and the acct: scheme documen= ts >> >> On 7/2/12 10:29 AM, Murray S. Kucherawy wrote: >> >> > The authors of draft-jones-appsawg-webfinger are invited to submit >> > draft-ietf-appsawg-webfinger-00, and we'll approve it. >> > >> > Now, a question: The "acct:" scheme URI work is an offshoot of >> > webfinger. PSA has recently posted a document that separates that >> > work out. So what is working group consensus: Should these be >> > processed as two documents in parallel (and should APPSAWG take them >> > on), or should they be processed as a single document? >> >> Clarifying question: since the chairs have invited the authors of the >> WebFinger I-D to submit it as a WG item, I assume that the question "s= hould >> APPSAWG take them on" does not apply to the WebFinger I-D, but only to= the >> 'acct' URI I-D. >> >> FWIW, I authored a separate spec for the 'acct' URI scheme because I >> understood from the list discussion that the 'acct' URI *could* be use= d by >> protocols other than WebFinger. If that is true, then it seems to me >> preferable to work on the WebFinger protocol and the 'acct' URI scheme= as >> separate documents. If that is false, then I think they belong in the = same >> specification. Personally I'm unclear as to whether the 'acct' URI sch= eme >> is tightly coupled to WebFinger protocol, so I think we need to figure= that >> out first before deciding whether to proceed with two documents or one= . >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> >> >> _______________________________________________ >> 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 sm@resistor.net Mon Jul 2 13:55:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE8811E80BA for ; Mon, 2 Jul 2012 13:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iR3yVE8LBKfJ for ; Mon, 2 Jul 2012 13:55:20 -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 F262C21F854F for ; Mon, 2 Jul 2012 13:55:19 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q62KtKct009206 for ; Mon, 2 Jul 2012 13:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341262524; bh=tO+12leRZ0HbhGRU5nVfrxysTjZUkwUyO6ulsWuvFyw=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=Wm6Id7eYLtptM6g2f7M3uCPMzGaJNWupTpH7nOSqzJ9JbBw6HSmS4ZXz1pKhjP5Vb ete01RA38mEUp0+MV3Vwr5B+PPCF5BA18fj/tVA1le20jf0aHR7KtQ7FuIMWCyfP87 bP5FFeRrEpAoRy7V2rq8nTgMx4QkYc5f+tz0bKpo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341262524; i=@resistor.net; bh=tO+12leRZ0HbhGRU5nVfrxysTjZUkwUyO6ulsWuvFyw=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=JKq4V4h/N3oaIO24odFeBvZ9FdFDkI8A3x99gmBbmmAUAKYDcukptY7QCCr8zo5jo BtChZE7NXfLSOjZ+4qm2jaTW6RHjaQMEgGeOmrmba5ObnGFnEiyMf6tCMKEH/HsdiN 2m+5W/32N72sY1uq8TFobbWXWjigsX9xwNMnVbrc= Message-Id: <6.2.5.6.2.20120702133806.0935ba68@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 02 Jul 2012 13:54:38 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: <4FEB2003.9000508@isode.com> References: <4FEB2003.9000508@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 20:55:24 -0000 Hi Alexey, At 08:00 27-06-2012, Alexey Melnikov wrote: >The Working Group Last Call for this document has ended and there >were a couple of updates to it to address issues (-03 and -04). I >believe all issues were addressed, but it would be good for the WG >to check the latest version and confirm that. If one of your issues >is not addressed (and especially if it wasn't replied to), please let me know. I responded to a message from Alissa Cooper ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05908.html ). I should have mentioned that it is a comment about the draft. I don't consider the issue as addressed in draft-ietf-appsawg-http-forwarded-05. If I recall correctly, I did "send text" previously about this. Regards, -sm From hallam@gmail.com Mon Jul 2 14:16:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E49C21F873B for ; Mon, 2 Jul 2012 14:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aitq6ISx0xwA for ; Mon, 2 Jul 2012 14:16:41 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8594721F8628 for ; Mon, 2 Jul 2012 14:16:41 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so10113289obb.31 for ; Mon, 02 Jul 2012 14:16:47 -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=i3O+W7MAzP+pP0/EqOPnTtROSsQ8j8JzE+EX9YZVm4s=; b=iOBsfXwXCK6GxwpG8aP0fxMKW9jz0royN1evnOqhParH6tAnW5HVXU6/vqXFVMJnkT fino6cm6QUr/KMPmjpoNYkvsN+dRA0xqxe36RUvVLqG9VuxNWPS6W1djNBLWBzz2g82G lgk8VS9LZCgIeLyyZwsPiMeWcLMP+VvQaQJd607mR6DMSG/jWY62S7TjVs6S5/GMmaZ1 y7ngsgC3gX5ztv06B5cJTAZWqhI2ZUbHMvFpdV63Hzj2Fj+SP8j5SG5eeJ3ZK9NvIpvE nys7Vnall9S90DbVPHXCnY80p4O8lsZPs2jTQLku2avoR1E/MG3C6GvDy+dnrTTZwQPX a+eg== MIME-Version: 1.0 Received: by 10.182.227.38 with SMTP id rx6mr2638439obc.27.1341263806809; Mon, 02 Jul 2012 14:16:46 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Mon, 2 Jul 2012 14:16:46 -0700 (PDT) In-Reply-To: <1341257402-sup-9426@heahdk.net> References: <4FF1D000.8020100@stpeter.im> <4E1F6AAD24975D4BA5B168042967394366572C13@TK5EX14MBXC283.redmond.corp.microsoft.com> <1341257402-sup-9426@heahdk.net> Date: Mon, 2 Jul 2012 17:16:46 -0400 Message-ID: From: Phillip Hallam-Baker To: elf Pavlik Content-Type: text/plain; charset=ISO-8859-1 Cc: Henry Story , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 21:16:43 -0000 I think it will go a long way to prevent future nonsense like OpenID where we were told that users wanted to use a URL as their account reference (not!) and then that we needed an alias scheme (XRI) to make the URLs palatable. Representing account identifiers as URIs in the protocol makes sense. Expecting users to type them in is stupid on rollerskates. On Mon, Jul 2, 2012 at 4:36 PM, elf Pavlik wrote: > Excerpts from Bob Wyman's message of 2012-07-02 17:52:47 +0000: >> I would appreciate it greatly if someone could suggest a number of useful >> use-cases for acct: without WebFinger. >> >> What use is independence if that independence provides no utility? > > i wonder if webfinger could specify handling acct: for HTTP, but other protocols?(SIP, XMPP, PSYC[1], ...) could maybe also use generic acct: > with developments like WebID[2] maybe i could use same ssl cert just with acct: in SAN and authenticate on this account to various services... > > > ~elf-pavlik~ > > [1] http://psyced.org/ > [2] http://webid.info/ > > >>bob wyman >> >>On Mon, Jul 2, 2012 at 1:14 PM, Mike Jones wrote: >>> >>> I would like to add support to submitting your acct: draft as a working >>> group document. >>> >>> While WebFinger will have a normative dependency on it, it's actually >>> independent of WebFinger and so can and should be considered separately. >>> >>> Best wishes, >>> -- Mike >>> >>> -----Original Message----- >>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] >>> On Behalf Of Peter Saint-Andre >>> Sent: Monday, July 02, 2012 9:45 AM >>> To: Murray S. Kucherawy >>> Cc: apps-discuss@ietf.org >>> Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents >>> >>> On 7/2/12 10:29 AM, Murray S. Kucherawy wrote: >>> >>> > The authors of draft-jones-appsawg-webfinger are invited to submit >>> > draft-ietf-appsawg-webfinger-00, and we'll approve it. >>> > >>> > Now, a question: The "acct:" scheme URI work is an offshoot of >>> > webfinger. PSA has recently posted a document that separates that >>> > work out. So what is working group consensus: Should these be >>> > processed as two documents in parallel (and should APPSAWG take them >>> > on), or should they be processed as a single document? >>> >>> Clarifying question: since the chairs have invited the authors of the >>> WebFinger I-D to submit it as a WG item, I assume that the question "should >>> APPSAWG take them on" does not apply to the WebFinger I-D, but only to the >>> 'acct' URI I-D. >>> >>> FWIW, I authored a separate spec for the 'acct' URI scheme because I >>> understood from the list discussion that the 'acct' URI *could* be used by >>> protocols other than WebFinger. If that is true, then it seems to me >>> preferable to work on the WebFinger protocol and the 'acct' URI scheme as >>> separate documents. If that is false, then I think they belong in the same >>> specification. Personally I'm unclear as to whether the 'acct' URI scheme >>> is tightly coupled to WebFinger protocol, so I think we need to figure that >>> out first before deciding whether to proceed with two documents or one. >>> >>> Peter >>> >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> >>> >>> >>> _______________________________________________ >>> 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 -- Website: http://hallambaker.com/ From wmills@yahoo-inc.com Mon Jul 2 14:45:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352AD11E80F4 for ; Mon, 2 Jul 2012 14:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.547 X-Spam-Level: X-Spam-Status: No, score=-17.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-P08-O1U8Ge for ; Mon, 2 Jul 2012 14:45:52 -0700 (PDT) Received: from nm19.bullet.mail.ac4.yahoo.com (nm19.bullet.mail.ac4.yahoo.com [98.139.52.216]) by ietfa.amsl.com (Postfix) with SMTP id AECD711E80E1 for ; Mon, 2 Jul 2012 14:45:52 -0700 (PDT) Received: from [98.139.52.193] by nm19.bullet.mail.ac4.yahoo.com with NNFMP; 02 Jul 2012 21:45:52 -0000 Received: from [98.139.52.129] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 02 Jul 2012 21:45:52 -0000 Received: from [127.0.0.1] by omp1012.mail.ac4.yahoo.com with NNFMP; 02 Jul 2012 21:45:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 251293.97442.bm@omp1012.mail.ac4.yahoo.com Received: (qmail 47679 invoked by uid 60001); 2 Jul 2012 21:45:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1341265551; bh=yoG97OdxcbBCXd64JAizHtXaMJu2L1EBju58e2gqcUo=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=boGtX9jgIyL+YLes7tsR3Modqv6ebH3UOpqDfaT3OgFx6MSw31ejEAWpq6H17xv9CGW4YOXQKIMIDyQdx2dCatayvNQc59Ka7VLQJpfGtCSIDgX8+ScF3N/UT1MZXyQA/KiT7qa79c4J1to+JNjTiKvWXYn6coAk/oagvtte14o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HjO2F5k3sO2tQdcA8EbgLJJjwRkwEFVExN6foU8FBsH7yIG+EzClKzsQTdI2bZvN7J+QGwQdZuy5WeXXLJoNBewa4M7omrACmeFElBuzEaTWSuGrnpQg58zqLqfpb3BdIUWlAQAFhIkK8VsDXUoE/3m0VpnxaRB3IqcbcMPSBQE=; X-YMail-OSG: gN1CapYVM1nU1G_FQqTnSK.vicVjJa5rAaI2.DbNV_VMvjR R309TzlhVNzVTlkosx.Rt4VOEhhB9I1qbQZ2.bJA_txx2CUiYuk0qUHqKI4i TdLApQdX_TYMJyfxC669Zz64_ZtrAEENeaaDCkrcwAid72VZtn7TBNM_JRXz 7y6hdzQGZzKSgIb_BRJEIQeMKpru.YD4qfUf14YMbzdC34e0xiHTzVvkPlYh naMn72PvFgWeipPWYw93LCXyEob73gN0xp0pJ3HJL35z4lgGiGRUBdnlgkiq Ujle0f4_xpdo79BT9ohVYgd0W6ExFwB75p02rp891d4InUtszTMMyhOSwEMI qo9JDKbGI2qCube2b0X4bFt8lhrIPiJjnYgOYuaoLZT8f5V1BAqX3kMUtWHi 16fzicS5UP_9FFVU7AO0ruZcoAZOsG5Qv7ek2FxnjpHRJ_jP_Ici_AkKcPTo ZiFcdyp6_e74r08q2iaqaNPmVOie1uo2SNW3EFA-- Received: from [209.131.62.115] by web31802.mail.mud.yahoo.com via HTTP; Mon, 02 Jul 2012 14:45:50 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> Message-ID: <1341265550.44719.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Mon, 2 Jul 2012 14:45:50 -0700 (PDT) From: William Mills To: Bob Wyman , Phillip Hallam-Baker MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 21:45:54 -0000 Bob's argument makes sense to me.=A0 I withdraw my own argument for making = domain optional.=0A=0A=0A=0A=0A=0A>________________________________=0A> Fro= m: Bob Wyman =0A>To: Phillip Hallam-Baker = =0A>Cc: Graham Klyne ; "apps-discuss@ietf.org" ; Murray S. Kucherawy =0A>Sent: Monday, J= uly 2, 2012 10:57 AM=0A>Subject: Re: [apps-discuss] The acct: scheme questi= on=0A> =0A>=0A>=0A>=0A>=0A>On Mon, Jul 2, 2012 at 11:42 AM, Phillip Hallam-= Baker wrote:=0A>=0A>I think Tim regrets having been argu= ed out of a lot of positions=0A>>relating to naming that he was subsequentl= y proved right on.=0A>>=0A>>Naming issues are an area where a lot of people= have strong opinions=0A>>that really turn out to be a matter of taste rath= er than grounded in=0A>>semiotics.=0A>>=0A>>The whole business of different= iating URLs and URNs as distinct=0A>>classes was bogus. Once the locator sc= heme has caching, a URL becomes=0A>>a name. Once an application provides a = default action for a name (e.g.=0A>>look it up on Amazon) then a name becom= es a locator.=0A>>=0A>>=0A>>A URI scheme should simply provide people with = a well defined syntax=0A>>that allows them to express the concepts that app= lications that need=0A>>to interoperate need to exchange references to. Try= ing to decide how=0A>>people should use the identifiers is counterproductiv= e. Trying to=0A>>enforce particular approaches is destructive.=0A>>=0A>>The= vast majority of computer systems that use accounts do not bind=0A>>them t= o domain names. So there is a place in the acct: scheme for=0A>>unbound ref= erences.=0A>It seems to me that an unbound acct: name would be useful only = in a "local" case, not generally useful between otherwise inter-working mac= hines. As I understand it, the IETF normally limits its scope to those issu= es that relate to interworking between systems. Thus, it seems to me that a= feature that is purely local and does not, in fact, facilitate inter-worki= ng is one that should not appear in an IETF document. This, of course, woul= d not prevent anyone from building a system, or even set of systems, that m= ade private agreements or used private conventions concerning the use of ac= ct: names which were unbound or contained no domain part. But, that is not,= I think, a matter which need concern anyone while wearing an IETF standard= s hat.=0A>=0A>=0A>=A0=0A>I expect that practice to go down over time. I=0A>= >expect that deployment of technology that uses acct: will encourage=0A>>th= at. But trying to force the issue by excluding unbound accounts is=0A>>only= going to hurt that transition by making acct: a special case of=0A>>accoun= t objects rather than a technology that can ease the transition.=0A>>=0A>>= =0A>>=0A>>=0A>>On Mon, Jul 2, 2012 at 9:42 AM, Melvin Carvalho=0A>> wrote:=0A>>>=0A>>>=0A>>> On 2 July 2012 15:31, Phillip H= allam-Baker wrote:=0A>>>>=0A>>>> Relative URIs have exis= ted from the start. That is one of the reasons=0A>>>> they had to be rename= d 'uniform' rather than universal.=0A>>>>=0A>>>> The idea is to have a unif= orm means of representing a name. If that=0A>>>> name is ambiguous, then th= e URI form needs to be able to capture that.=0A>>>>=0A>>>> I don't think it= helps in the slightest to argue over whether=0A>>>> /fred.html is a URI or= a URI fragment. Tim's original proposal is in=0A>>>> my view rather better= thought out than what others have proposed as=0A>>>> 'improvements'. A nam= e is merely a label for a concept and every URI=0A>>>> is a name, some happ= en to be resolvable via a default protocol, others=0A>>>> not, thats all.= =0A>>>>=0A>>>>=0A>>>> Incompletely specified account names are inevitable. = If you want to=0A>>>> use SAML or the like in a Windows environment then th= e Windows domain=0A>>>> is not bound to a unique DNS address and picking a = random one is only=0A>>>> going to confuse matters.=0A>>>>=0A>>>> An acct: = name that does not have a domain name part is going to have=0A>>>> to be re= solved in the same fashion as relative URIs are - by reference=0A>>>> to co= ntext and local state. I don't see anything wrong in that. In the=0A>>>> co= ntext of accounts, a domain name is not completely unambiguous=0A>>>> unles= s you also have time.=0A>>>>=0A>>>>=0A>>>> The real world is a fuzzy place.= Trying to cope with the fuzzyness and=0A>>>> ambiguity by wishing it away = only leads to broken specs. Accounts have=0A>>>> only recently come to be u= nderstood to have an intrinsic domain=0A>>>> component. It is better to acc= ept that fact and to build=0A>>>> infrastructure that addresses the need th= an to pretend that the need=0A>>>> can be magicked away.=0A>>>>=0A>>>> Peop= le who don't have a domain are going to drop it in any case. We=0A>>>> saw = the same thing happen with the news: and nntp: URL. Tim thought=0A>>>> that= the USENET space was uniform and tried to establish a URL that=0A>>>> didn= 't have the domain name. Engineers trying to solve real world=0A>>>> proble= ms then added it back in because there is more to NNTP than=0A>>>> USENET.= =0A>>>=0A>>>=0A>>> I enjoyed reading this. =A0Just a remark regarding unive= rsal vs uniform.=0A>>>=0A>>> FWIW, Tim is on record saying that he regrets = not insisting to the IETF,=0A>>> that the original 'Universal' should be us= ed in URI, instead of changed form=0A>>> 'Uniform'. =A0Depending on which c= ircles you're in, I think informally, the=0A>>> two terms are used pretty i= nterchangeably, these days.=0A>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>> On Mon= , Jul 2, 2012 at 7:55 AM, Graham Klyne wrote:=0A>>>> > = On 01/07/2012 23:02, Peter Saint-Andre wrote:=0A>>>> >>=0A>>>> >> On 7/1/12= 9:38 AM, William Mills wrote:=0A>>>> >>>=0A>>>> >>> Section 4.3: =A0'"@" d= omainpart' should be optional. =A0It's reasonable=0A>>>> >>> to think this = might be used with local account identifiers that=0A>>>> >>> don/t/need hav= e a domain.=0A>>>> >>=0A>>>> >>=0A>>>> >> Making the domain name of the ser= vice provider implicit seems=0A>>>> >> ill-advised to me. What's the harm o= f including the domainpart?=0A>>>> >=0A>>>> >=0A>>>> > +1=0A>>>> >=0A>>>> >= (URIs are intended to be a global namespace.)=0A>>>> >=0A>>>> > #g=0A>>>> = > --=0A>>>> >=0A>>>> > _______________________________________________=0A>>= >> > apps-discuss mailing list=0A>>>> > apps-discuss@ietf.org=0A>>>> > http= s://www.ietf.org/mailman/listinfo/apps-discuss=0A>>>>=0A>>>>=0A>>>>=0A>>>> = --=0A>>>> Website: http://hallambaker.com/=0A>>>> _________________________= ______________________=0A>>>> apps-discuss mailing list=0A>>>> apps-discuss= @ietf.org=0A>>>> https://www.ietf.org/mailman/listinfo/apps-discuss=0A>>>= =0A>>>=0A>>=0A>>=0A>>=0A>>--=0A>>Website: http://hallambaker.com/=0A>>_____= __________________________________________=0A>>apps-discuss mailing list=0A= >>apps-discuss@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/apps-disc= uss=0A>>=0A>=0A>_______________________________________________=0A>apps-dis= cuss mailing list=0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/= listinfo/apps-discuss=0A>=0A>=0A> From hallam@gmail.com Mon Jul 2 15:53:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A4A21F85A2 for ; Mon, 2 Jul 2012 15:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMVDFuyheW4C for ; Mon, 2 Jul 2012 15:53:18 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB95821F85A1 for ; Mon, 2 Jul 2012 15:53:18 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so10222400obb.31 for ; Mon, 02 Jul 2012 15:53: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=pb5l45uJs0UhHGOwXwL9vfTCBVzZsX3AJ9KeexhYuH8=; b=jfeYrIW7EHHy1bJWYpxt8YRmPLkuesgL2shkXWfEibpo/hwMkzvmy1ahXoJbFxjgoO 8Z7wm0ImhbWymvU2DKwBG2km0184O483CfwiIwtfkPFevxv5izP6YozgK79C3d4SqKi4 3nnCm056QrRsw7MB3ACafSEGOU5ZUOzKt+Oh2UMGiRE1YfpWJLszllYD9qr1I8qF4ZLB 3qqtlbEPW3in1bgEZUB7AijSy1mdIQqbSmy16rcQHbYG55uGL1BrKgK3LKbDPKBG3wZR vhjGkoXuvE+4N6brdH0bRbYQ1ZmjDXArUkqUmgG4Zs2DF4zvCas9ODkUegmmu2wTvCMS T5zg== MIME-Version: 1.0 Received: by 10.182.160.10 with SMTP id xg10mr10086047obb.76.1341269604626; Mon, 02 Jul 2012 15:53:24 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Mon, 2 Jul 2012 15:53:24 -0700 (PDT) In-Reply-To: References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> Date: Mon, 2 Jul 2012 18:53:24 -0400 Message-ID: From: Phillip Hallam-Baker To: Bob Wyman Content-Type: text/plain; charset=ISO-8859-1 Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 22:53:19 -0000 On Mon, Jul 2, 2012 at 1:57 PM, Bob Wyman wrote: > > > On Mon, Jul 2, 2012 at 11:42 AM, Phillip Hallam-Baker > wrote: >> >> I think Tim regrets having been argued out of a lot of positions >> relating to naming that he was subsequently proved right on. >> >> Naming issues are an area where a lot of people have strong opinions >> that really turn out to be a matter of taste rather than grounded in >> semiotics. >> >> The whole business of differentiating URLs and URNs as distinct >> classes was bogus. Once the locator scheme has caching, a URL becomes >> a name. Once an application provides a default action for a name (e.g. >> look it up on Amazon) then a name becomes a locator. >> >> >> A URI scheme should simply provide people with a well defined syntax >> that allows them to express the concepts that applications that need >> to interoperate need to exchange references to. Trying to decide how >> people should use the identifiers is counterproductive. Trying to >> enforce particular approaches is destructive. >> >> The vast majority of computer systems that use accounts do not bind >> them to domain names. So there is a place in the acct: scheme for >> unbound references. > > It seems to me that an unbound acct: name would be useful only in a "local" > case, not generally useful between otherwise inter-working machines. As I > understand it, the IETF normally limits its scope to those issues that > relate to interworking between systems. Thus, it seems to me that a feature > that is purely local and does not, in fact, facilitate inter-working is one > that should not appear in an IETF document. This, of course, would not > prevent anyone from building a system, or even set of systems, that made > private agreements or used private conventions concerning the use of acct: > names which were unbound or contained no domain part. But, that is not, I > think, a matter which need concern anyone while wearing an IETF standards > hat. That is not the case at all. IETF protocols have always been designed to support local use in addition to Internet use where that makes sense. In this case accounts are currently a locally defined resource and the objective is to make them an Internet resource. The transition from one to the other requires a spec that can work equally well in both circumstances. Deployment is something that should always concern us. Scope arguments are only ever relevant to the question of whether the IETF should consider a problem in the first place. Once the problem is accepted the design must address all the use cases and requirements that reasonably apply whether they are deemed to be in IETF scope or not. And in any case I think that you are completely wrong on the question of scope in the first place. Please provide a citation for your claim if you want to continue the argument. -- Website: http://hallambaker.com/ From ve7jtb@ve7jtb.com Mon Jul 2 17:00:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA19111E80DF for ; Mon, 2 Jul 2012 17:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbPK-E4P2Fhd for ; Mon, 2 Jul 2012 17:00:55 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A98611E80BF for ; Mon, 2 Jul 2012 17:00:46 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5209745ggn.31 for ; Mon, 02 Jul 2012 17:00:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=mBI0PH68mvuwhMbXqI4+HeeRXEwC2ndaDXwr/AjqKN0=; b=WzGfwOoKlUBQOyvvWDPxbsO/N8Xrf0QNLfSFZvBvCnKCgEw+wpeIKCtxToQyXbmb6H eYhhP0X+clHpjUSYuEEEYdMdETmrLvz1eCXWwAm6wE6RxqBI8HUbWlQ6AgEwUSJwomKE mxONIlZ+m/pYxVTBHatekGoTEWGc1fA/TX2jqjZT517pUFK7eFIFC2PfacE9efaEQzUX lL6iPAArHVjCNRJ36ESZ3TNvZfEwRmDFSz+3YEQvsHvrFVhnaLrxA3m6RLJe4yKrHuBW P7D6MDdpR9KfPdCi+9wC4mPrsr2CHMAJJnbyy7+AHEzLmVXcJkxhVedndxyhaTkGJatx ca9g== Received: by 10.236.108.195 with SMTP id q43mr17693560yhg.38.1341273652990; Mon, 02 Jul 2012 17:00:52 -0700 (PDT) Received: from [192.168.1.211] (190-20-50-6.baf.movistar.cl. [190.20.50.6]) by mx.google.com with ESMTPS id p16sm13100706ano.19.2012.07.02.17.00.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jul 2012 17:00:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_A2A98896-AA1C-4C56-A40C-ABF3FC006563"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366572C13@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 2 Jul 2012 20:00:44 -0400 Message-Id: <0D9FB40B-6BA6-4D2B-B868-27EAAC6EA01B@ve7jtb.com> References: <4FF1D000.8020100@stpeter.im> <4E1F6AAD24975D4BA5B168042967394366572C13@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQks8nOfYqzWVAWCqQCQWNRfJexKU77UBcqGi2T4IEFaAHgLQU/afLkhEpH0+YTYRyuT0LYc Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 00:00:56 -0000 --Apple-Mail=_A2A98896-AA1C-4C56-A40C-ABF3FC006563 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As I have said several times, having the acct: draft as a working group = document will help clarify the issues and bring this to a resolution. John B. On 2012-07-02, at 1:14 PM, Mike Jones wrote: > I would like to add support to submitting your acct: draft as a = working group document. >=20 > While WebFinger will have a normative dependency on it, it's actually = independent of WebFinger and so can and should be considered separately. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Peter Saint-Andre > Sent: Monday, July 02, 2012 9:45 AM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] The webfinger and the acct: scheme = documents >=20 > On 7/2/12 10:29 AM, Murray S. Kucherawy wrote: >=20 >> The authors of draft-jones-appsawg-webfinger are invited to submit=20 >> draft-ietf-appsawg-webfinger-00, and we'll approve it. >>=20 >> Now, a question: The "acct:" scheme URI work is an offshoot of=20 >> webfinger. PSA has recently posted a document that separates that=20 >> work out. So what is working group consensus: Should these be=20 >> processed as two documents in parallel (and should APPSAWG take them=20= >> on), or should they be processed as a single document? >=20 > Clarifying question: since the chairs have invited the authors of the = WebFinger I-D to submit it as a WG item, I assume that the question = "should APPSAWG take them on" does not apply to the WebFinger I-D, but = only to the 'acct' URI I-D. >=20 > FWIW, I authored a separate spec for the 'acct' URI scheme because I = understood from the list discussion that the 'acct' URI *could* be used = by protocols other than WebFinger. If that is true, then it seems to me = preferable to work on the WebFinger protocol and the 'acct' URI scheme = as separate documents. If that is false, then I think they belong in the = same specification. Personally I'm unclear as to whether the 'acct' URI = scheme is tightly coupled to WebFinger protocol, so I think we need to = figure that out first before deciding whether to proceed with two = documents or one. >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_A2A98896-AA1C-4C56-A40C-ABF3FC006563 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw MzAwMDA0NFowIwYJKoZIhvcNAQkEMRYEFPhaVBAM5hbyMhW5e13pKBCXXHTmMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AEZaFya+Leus73NWhbJeT/VxhTwEDRlshdamWXJbm2ngNxYnSIFP18olfyfJqaCEADWuuad5TDLI 3S9xXMYMpe1JYJzyZPwRjMJeYLyh/5JjzZ3o0aA60XiDiHYH4YuBNwQCet/gbZlbRhnueMPnX+XM iYJFw7DuJ+k9cs0aiXbO/8ysSPwmM/H6kIcdjti8E22IVCY2lbtnJv1rfQ2LGqEuWjGkDLDWSHXu gnBNmq5BlkX5h7IhpyqKNLtDpjXpjE8hx4DYeglt4mb4VW7KLR7C4+365FR1cZXvSc7uPbAxH579 jqK7TDw4RhLtcnlZLOldcWnETTBSDmq0eB3uI2MAAAAAAAA= --Apple-Mail=_A2A98896-AA1C-4C56-A40C-ABF3FC006563-- From mnot@mnot.net Mon Jul 2 17:47:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB29021F84EA for ; Mon, 2 Jul 2012 17:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.513 X-Spam-Level: X-Spam-Status: No, score=-105.513 tagged_above=-999 required=5 tests=[AWL=-2.914, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORPCoCQqoYca for ; Mon, 2 Jul 2012 17:47:51 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D644E21F84F7 for ; Mon, 2 Jul 2012 17:47:50 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BF58E22E1F4; Mon, 2 Jul 2012 20:47:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham Date: Tue, 3 Jul 2012 10:47:47 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <5976E21A-81BC-4576-8609-B2C04C218C10@mnot.net> References: <20120703004409.1599.57166.idtracker@ietfa.amsl.com> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1278) Cc: HTTP Working Group Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-link-template-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Apps Discuss List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 00:47:51 -0000 [Follow-ups set to Apps-discuss] FYI; a few people have asked me about this recently, and URI Template is = final, so it seems like a good time. Cheers, Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-link-template-00.txt > Date: 3 July 2012 10:44:09 AM AEST > To: mnot@mnot.net >=20 >=20 > A new version of I-D, draft-nottingham-link-template-00.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Filename: draft-nottingham-link-template > Revision: 00 > Title: The Link-Template HTTP Header Field > Creation date: 2012-07-03 > WG ID: Individual Submission > Number of pages: 6 > URL: = http://www.ietf.org/internet-drafts/draft-nottingham-link-template-00.txt > Status: = http://datatracker.ietf.org/doc/draft-nottingham-link-template > Htmlized: = http://tools.ietf.org/html/draft-nottingham-link-template-00 >=20 >=20 > Abstract: > This specification defines the Link-Template HTTP header field, > providing a means for describing the structure of a link between two > resources, so that new links can be generated. >=20 >=20 >=20 >=20 > The IETF Secretariat -- Mark Nottingham http://www.mnot.net/ From sakimura@gmail.com Mon Jul 2 17:55:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F86A11E80FA for ; Mon, 2 Jul 2012 17:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.453 X-Spam-Level: X-Spam-Status: No, score=-3.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msti6PeEk2jS for ; Mon, 2 Jul 2012 17:55:46 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id F3BAC11E80F6 for ; Mon, 2 Jul 2012 17:55:45 -0700 (PDT) Received: by bkty8 with SMTP id y8so5421747bkt.31 for ; Mon, 02 Jul 2012 17:55: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=+b4TruuhM4llNBCayJMEUIlYCjQPyDvblw6JXXZhpw8=; b=iVbs+zdsEAOj9WOFLSVLzjP6LO6ogTPi/TKyWw5ZIPDc1b+9UxEXYw3+7fcZ7Nf8xT g3KANyJGBbmIViX1woiAlVTH5FXda4Oomi+FF8yHou5FYj+B7rFaItdank9PQ2olpMQW RDehr2V9Wjx+8KeJLcmpVZrJntHJp57jH7DMFEHHE6gF2h2Q7soBC3+oBuylWnj2WonH lXC1Eq1vWx4Wb1wgN1dSGbcoTna1uPHFxTWoAoIXVroJjQ8YfNdw7FbM9lKBIw+cIA+C +80MXdPF7ZIMyo7MFdSfHrNg6LeFsRslg1kAIuccuXyxoasdE/07pqzbe/VE+A5Abf2t jdhw== MIME-Version: 1.0 Received: by 10.204.151.81 with SMTP id b17mr8651993bkw.52.1341276951376; Mon, 02 Jul 2012 17:55:51 -0700 (PDT) Received: by 10.204.124.13 with HTTP; Mon, 2 Jul 2012 17:55:51 -0700 (PDT) In-Reply-To: References: <4FF1D000.8020100@stpeter.im> <4E1F6AAD24975D4BA5B168042967394366572C13@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 3 Jul 2012 09:55:51 +0900 Message-ID: From: Nat Sakimura To: Murray Kucherawy , Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=0015175cabae3b741704c3e26059 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 00:55:47 -0000 --0015175cabae3b741704c3e26059 Content-Type: text/plain; charset=ISO-8859-1 I think having acct: as a separate documents are going to be cleaner and more accommodating for other specs to make use of it. Nat On Tue, Jul 3, 2012 at 3:13 AM, Phillip Hallam-Baker wrote: > The main use case I see for acct: is SAML and SAML-like specifications > that currently end up using mailto: > > I don't see WebFinger as being the driver at all. It is not a > specification I am very interested in as 'public information about > Bob' is a subset of 'information that Alice is permitted to know about > Bob.' > > > > On Mon, Jul 2, 2012 at 1:52 PM, Bob Wyman wrote: > > I would appreciate it greatly if someone could suggest a number of useful > > use-cases for acct: without WebFinger. > > > > What use is independence if that independence provides no utility? > > > > bob wyman > > > > > > On Mon, Jul 2, 2012 at 1:14 PM, Mike Jones > > wrote: > >> > >> I would like to add support to submitting your acct: draft as a working > >> group document. > >> > >> While WebFinger will have a normative dependency on it, it's actually > >> independent of WebFinger and so can and should be considered separately. > >> > >> Best wishes, > >> -- Mike > >> > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org [mailto: > apps-discuss-bounces@ietf.org] > >> On Behalf Of Peter Saint-Andre > >> Sent: Monday, July 02, 2012 9:45 AM > >> To: Murray S. Kucherawy > >> Cc: apps-discuss@ietf.org > >> Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents > >> > >> On 7/2/12 10:29 AM, Murray S. Kucherawy wrote: > >> > >> > The authors of draft-jones-appsawg-webfinger are invited to submit > >> > draft-ietf-appsawg-webfinger-00, and we'll approve it. > >> > > >> > Now, a question: The "acct:" scheme URI work is an offshoot of > >> > webfinger. PSA has recently posted a document that separates that > >> > work out. So what is working group consensus: Should these be > >> > processed as two documents in parallel (and should APPSAWG take them > >> > on), or should they be processed as a single document? > >> > >> Clarifying question: since the chairs have invited the authors of the > >> WebFinger I-D to submit it as a WG item, I assume that the question > "should > >> APPSAWG take them on" does not apply to the WebFinger I-D, but only to > the > >> 'acct' URI I-D. > >> > >> FWIW, I authored a separate spec for the 'acct' URI scheme because I > >> understood from the list discussion that the 'acct' URI *could* be used > by > >> protocols other than WebFinger. If that is true, then it seems to me > >> preferable to work on the WebFinger protocol and the 'acct' URI scheme > as > >> separate documents. If that is false, then I think they belong in the > same > >> specification. Personally I'm unclear as to whether the 'acct' URI > scheme is > >> tightly coupled to WebFinger protocol, so I think we need to figure > that out > >> first before deciding whether to proceed with two documents or one. > >> > >> Peter > >> > >> -- > >> Peter Saint-Andre > >> https://stpeter.im/ > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --0015175cabae3b741704c3e26059 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think having acct: as a separate documents are going to be cleaner and mo= re accommodating for other specs to make use of it.=A0

N= at

On Tue, Jul 3, 2012 at 3:13 AM, Philli= p Hallam-Baker <hallam@gmail.com> wrote:
The main use case I see for acct: is SAML an= d SAML-like specifications
that currently end up using mailto:

I don't see WebFinger as being the driver at all. It is not a
specification I am very interested in as =A0'public information about Bob' is a subset of 'information that Alice is permitted to know ab= out
Bob.'



On Mon, Jul 2, 2012 at 1:52 PM, Bob Wyman <bob@wyman.us> wrote:
> I would appreciate it greatly if someone could suggest a number of use= ful
> use-cases for acct: without WebFinger.
>
> What use is independence if that independence provides no utility?
>
> bob wyman
>
>
> On Mon, Jul 2, 2012 at 1:14 PM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:
>>
>> I would like to add support to submitting your acct: draft as a wo= rking
>> group document.
>>
>> While WebFinger will have a normative dependency on it, it's a= ctually
>> independent of WebFinger and so can and should be considered separ= ately.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Be= st wishes,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --= Mike
>>
>> -----Original Message-----
>> From: apps-discus= s-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
>> On Behalf Of Peter Saint-Andre
>> Sent: Monday, July 02, 2012 9:45 AM
>> To: Murray S. Kucherawy
>> Cc: apps-discuss@ietf.org=
>> Subject: Re: [apps-discuss] The webfinger and the acct: scheme doc= uments
>>
>> On 7/2/12 10:29 AM, Murray S. Kucherawy wrote:
>>
>> > The authors of draft-jones-appsawg-webfinger are invited to s= ubmit
>> > draft-ietf-appsawg-webfinger-00, and we'll approve it. >> >
>> > Now, a question: The "acct:" scheme URI work is an = offshoot of
>> > webfinger. =A0PSA has recently posted a document that separat= es that
>> > work out. =A0So what is working group consensus: Should these= be
>> > processed as two documents in parallel (and should APPSAWG ta= ke them
>> > on), or should they be processed as a single document?
>>
>> Clarifying question: since the chairs have invited the authors of = the
>> WebFinger I-D to submit it as a WG item, I assume that the questio= n "should
>> APPSAWG take them on" does not apply to the WebFinger I-D, bu= t only to the
>> 'acct' URI I-D.
>>
>> FWIW, I authored a separate spec for the 'acct' URI scheme= because I
>> understood from the list discussion that the 'acct' URI *c= ould* be used by
>> protocols other than WebFinger. If that is true, then it seems to = me
>> preferable to work on the WebFinger protocol and the 'acct'= ; URI scheme as
>> separate documents. If that is false, then I think they belong in = the same
>> specification. Personally I'm unclear as to whether the 'a= cct' URI scheme is
>> tightly coupled to WebFinger protocol, so I think we need to figur= e that out
>> first before deciding whether to proceed with two documents or one= .
>>
>> Peter
>>
>> --
>> Peter Saint-Andre
>> https://stpeter.= im/
>>
>>
>>
>>
>> _______________________________________________
>> 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
>



--
Website: http://halla= mbaker.com/
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en

--0015175cabae3b741704c3e26059-- From dret@berkeley.edu Mon Jul 2 18:48:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B18621F85D7 for ; Mon, 2 Jul 2012 18:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYJoSGKTOjN6 for ; Mon, 2 Jul 2012 18:48:39 -0700 (PDT) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD0221F85D6 for ; Mon, 2 Jul 2012 18:48:32 -0700 (PDT) Received: from [207.239.114.206] (helo=dretpro.local) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1SlsEG-0006ah-4U; Mon, 02 Jul 2012 18:48:38 -0700 Message-ID: <4FF24F6D.7050807@berkeley.edu> Date: Mon, 02 Jul 2012 18:48:29 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Apps Discuss References: <20120703004409.1599.57166.idtracker@ietfa.amsl.com> <5976E21A-81BC-4576-8609-B2C04C218C10@mnot.net> In-Reply-To: <5976E21A-81BC-4576-8609-B2C04C218C10@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-nottingham-link-template-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 01:48:40 -0000 hello mark. On 2012-07-02 17:47 , Mark Nottingham wrote: > FYI; a few people have asked me about this recently, and URI Template is final, so it seems like a good time. > Begin forwarded message: >> URL: http://www.ietf.org/internet-drafts/draft-nottingham-link-template-00.txt this looks like a very useful initiative! however, for more complex templates, it may be too limiting to only allow variables from "one namespace" (i.e., from the one URI prefix you currently allow). for example, we are looking into search services, and it is actually highly likely that different variables in the templates will come from different namespaces, for example for basic search, paging, spatial aspects, and facet information. i don't have an easy answer how to best do it (and think the current design is actually quite elegant), but from the perspective of more complex templates, it seems to me that supporting multiple namespaces would be a requirement. 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 duerst@it.aoyama.ac.jp Mon Jul 2 18:57:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185D311E8104 for ; Mon, 2 Jul 2012 18:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.555 X-Spam-Level: X-Spam-Status: No, score=-99.555 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NB9c7zI9uFNE for ; Mon, 2 Jul 2012 18:57:12 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6DED911E8100 for ; Mon, 2 Jul 2012 18:57:12 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q631vIpF008904 for ; Tue, 3 Jul 2012 10:57:18 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 19ac_76b2_6b50c9fc_c4b2_11e1_a450_001d096c5782; Tue, 03 Jul 2012 10:57:17 +0900 Received: from [IPv6:::1] ([133.2.210.1]:60306) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 3 Jul 2012 10:57:22 +0900 Message-ID: <4FF2517B.8050504@it.aoyama.ac.jp> Date: Tue, 03 Jul 2012 10:57:15 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 01:57:13 -0000 I was leaning towards having only one document for webfinger and acct:, but now that Peter has created a separate one for acct: (which means we have a document author), let's just move ahead with both as WG documents. Regards, Martin. On 2012/07/03 1:29, Murray S. Kucherawy wrote: > Greetings, > > APPSAWG has now sent three documents, half of its recent docket, to the > IESG for IETF Last Call. We have three open documents remaining: > > draft-ietf-appsawg-malformed-mail > draft-ietf-appsawg-json-pointer > draft-ietf-appsawg-json-patch > > These remain in active development. Having cleared those other three > documents, we'd like to bring in and begin processing webfinger, which > we've been holding outside the WG until we cleared some backlog. I'd like > to thank the authors and participants for their patience as we worked > through those other projects, and the rest of you for your work in getting > the others off to the next steps in their lifecycle. > > The authors of draft-jones-appsawg-webfinger are invited to submit > draft-ietf-appsawg-webfinger-00, and we'll approve it. > > Now, a question: The "acct:" scheme URI work is an offshoot of webfinger. > PSA has recently posted a document that separates that work out. So what > is working group consensus: Should these be processed as two documents in > parallel (and should APPSAWG take them on), or should they be processed as > a single document? > > -MSK, APPSAWG co-chair > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From mnot@mnot.net Mon Jul 2 18:58:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4410221F8569 for ; Mon, 2 Jul 2012 18:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.504 X-Spam-Level: X-Spam-Status: No, score=-105.504 tagged_above=-999 required=5 tests=[AWL=-2.905, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdbRZ8gncgPM for ; Mon, 2 Jul 2012 18:58:17 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 48BA821F855E for ; Mon, 2 Jul 2012 18:58:17 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2699C22E257; Mon, 2 Jul 2012 21:58:12 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4FF24F6D.7050807@berkeley.edu> Date: Tue, 3 Jul 2012 11:58:09 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <158A57BD-6421-4587-B90A-F8E1C98FFC5B@mnot.net> References: <20120703004409.1599.57166.idtracker@ietfa.amsl.com> <5976E21A-81BC-4576-8609-B2C04C218C10@mnot.net> <4FF24F6D.7050807@berkeley.edu> To: Erik Wilde X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-nottingham-link-template-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 01:58:18 -0000 On 03/07/2012, at 11:48 AM, Erik Wilde wrote: > hello mark. >=20 > On 2012-07-02 17:47 , Mark Nottingham wrote: >> FYI; a few people have asked me about this recently, and URI Template = is final, so it seems like a good time. >> Begin forwarded message: >>> URL: = http://www.ietf.org/internet-drafts/draft-nottingham-link-template-00.txt >=20 > this looks like a very useful initiative! however, for more complex = templates, it may be too limiting to only allow variables from "one = namespace" (i.e., from the one URI prefix you currently allow). for = example, we are looking into search services, and it is actually highly = likely that different variables in the templates will come from = different namespaces, for example for basic search, paging, spatial = aspects, and facet information. i don't have an easy answer how to best = do it (and think the current design is actually quite elegant), but from = the perspective of more complex templates, it seems to me that = supporting multiple namespaces would be a requirement. Yep, agreed. The syntax of the header is somewhat limiting. Possible = approaches to this that pop into mind: * Define a prefix for variable to uri mappings; e.g.,=20 _foo=3D"http://example.org/vars/foo" ... but that potentially conflicts with other future parameters, and = I'm not a big fan of this approach elsewhere * Define another header, e.g., Link-Template-Vars: foo=3D"http://example.org/vars/foo" ...which is OK but it'll get awfully verbose (maybe defining a base = and some fallback rules? could get complex) and so on. Intuitively, I think we need a simple solution that addresses the common = case (all vars in one namespace) without much fuss/overhead, but enough = flexibility to address the complex case. That might be a combination of = a base URI and another header. I'd love feedback on this. Cheers, -- Mark Nottingham http://www.mnot.net/ From dret@berkeley.edu Mon Jul 2 19:18:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9260D11E8108 for ; Mon, 2 Jul 2012 19:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+gga5TZFzSJ for ; Mon, 2 Jul 2012 19:18:45 -0700 (PDT) Received: from gong.birdhouse.org (gong.birdhouse.org [207.58.180.215]) by ietfa.amsl.com (Postfix) with ESMTP id 6B11821F858D for ; Mon, 2 Jul 2012 19:18:45 -0700 (PDT) Received: from mobile-198-228-215-226.mycingular.net ([198.228.215.226]:35871 helo=[10.172.152.169]) by gong.birdhouse.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SlshW-0008Jp-NR; Mon, 02 Jul 2012 19:18:51 -0700 References: <20120703004409.1599.57166.idtracker@ietfa.amsl.com> <5976E21A-81BC-4576-8609-B2C04C218C10@mnot.net> <4FF24F6D.7050807@berkeley.edu> <158A57BD-6421-4587-B90A-F8E1C98FFC5B@mnot.net> In-Reply-To: <158A57BD-6421-4587-B90A-F8E1C98FFC5B@mnot.net> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9B206) From: Erik Wilde Date: Mon, 2 Jul 2012 19:18:39 -0700 To: Mark Nottingham X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gong.birdhouse.org X-AntiAbuse: Original Domain - apps.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - berkeley.edu Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-nottingham-link-template-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 02:18:46 -0000 hello mark. On Jul 2, 2012, at 18:58, Mark Nottingham wrote: > Intuitively, I think we need a simple solution that addresses the common c= ase (all vars in one namespace) without much fuss/overhead, but enough flexi= bility to address the complex case. That might be a combination of a base UR= I and another header. agreed that it should be simple to use for non- or one-namespace users. but w= e definitely need the multi-namespace case, so i'll think a little about how= that could be accomplished. (we could invent a general "xmlns"-like header f= or all-header-scoped URI/prefix bindings, but i am sure a lot of people woul= d not want to see xmlns mirrored so closely in HTTP.) cheers, dret.= From mnot@mnot.net Mon Jul 2 19:25:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794D121F85C6 for ; Mon, 2 Jul 2012 19:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.508 X-Spam-Level: X-Spam-Status: No, score=-105.508 tagged_above=-999 required=5 tests=[AWL=-2.909, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofYgFVjIvLRD for ; Mon, 2 Jul 2012 19:25:42 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id DCE8D21F85C3 for ; Mon, 2 Jul 2012 19:25:41 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3B82122E1F4; Mon, 2 Jul 2012 22:25:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Tue, 3 Jul 2012 12:25:44 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120703004409.1599.57166.idtracker@ietfa.amsl.com> <5976E21A-81BC-4576-8609-B2C04C218C10@mnot.net> <4FF24F6D.7050807@berkeley.edu> <158A57BD-6421-4587-B90A-F8E1C98FFC5B@mnot.net> To: Erik Wilde X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-nottingham-link-template-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 02:25:42 -0000 On 03/07/2012, at 12:18 PM, Erik Wilde wrote: > hello mark. >=20 > On Jul 2, 2012, at 18:58, Mark Nottingham wrote: >> Intuitively, I think we need a simple solution that addresses the = common case (all vars in one namespace) without much fuss/overhead, but = enough flexibility to address the complex case. That might be a = combination of a base URI and another header. >=20 > agreed that it should be simple to use for non- or one-namespace = users. but we definitely need the multi-namespace case, so i'll think a = little about how that could be accomplished. (we could invent a general = "xmlns"-like header for all-header-scoped URI/prefix bindings, but i am = sure a lot of people would not want to see xmlns mirrored so closely in = HTTP.) Yes. Also, I think the *really* common case is going to be for the = variables to be defined by the link relation itself.... Cheers, -- Mark Nottingham http://www.mnot.net/ From duerst@it.aoyama.ac.jp Mon Jul 2 20:50:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F28E21F8601 for ; Mon, 2 Jul 2012 20:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.563 X-Spam-Level: X-Spam-Status: No, score=-99.563 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYoklXC5zdYF for ; Mon, 2 Jul 2012 20:50:04 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5F99A21F85D1 for ; Mon, 2 Jul 2012 20:50:04 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q633o53F000355 for ; Tue, 3 Jul 2012 12:50:05 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 19ac_994c_2d1e89b6_c4c2_11e1_a450_001d096c5782; Tue, 03 Jul 2012 12:50:05 +0900 Received: from [IPv6:::1] ([133.2.210.1]:44694) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 3 Jul 2012 12:50:09 +0900 Message-ID: <4FF26BEA.4000909@it.aoyama.ac.jp> Date: Tue, 03 Jul 2012 12:50:02 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Graham Klyne References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <4FF18B9C.4010102@ninebynine.org> In-Reply-To: <4FF18B9C.4010102@ninebynine.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 03:50:05 -0000 On 2012/07/02 20:53, Graham Klyne wrote: > Some comments: > == Section 4.4 == > > My understanding is that an acct: URI is intended to be dereferenced > using the WebFinger protocol. I'm not sure about associated MIME types: > does WebFinger define any such? How's that relevant to the acct: scheme? It will be defined in the WebFinger spec, and that's good enough, isn't it? > == Section 4.6 == > > I'm a little unsure about the phrasing "only the WebFinger protocol uses > the 'acct' URI scheme", but I can't put my finger on any problem or > offer better phrasing at this time. The main problem is that it may be totally wrong in a month, or in 10 years. At the minimum, change it to "at the time of writing of this specification, only ...". Regards, Martin. From duerst@it.aoyama.ac.jp Mon Jul 2 20:53:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568E511E8118 for ; Mon, 2 Jul 2012 20:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.57 X-Spam-Level: X-Spam-Status: No, score=-99.57 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w3DMbVQM-Pn for ; Mon, 2 Jul 2012 20:53:21 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9173011E80EC for ; Mon, 2 Jul 2012 20:53:21 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q633rRPw022888 for ; Tue, 3 Jul 2012 12:53:27 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2a82_6376_a59d36b2_c4c2_11e1_a7b1_001d096c566a; Tue, 03 Jul 2012 12:53:27 +0900 Received: from [IPv6:::1] ([133.2.210.1]:44717) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 3 Jul 2012 12:53:31 +0900 Message-ID: <4FF26CB4.4080203@it.aoyama.ac.jp> Date: Tue, 03 Jul 2012 12:53:24 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 03:53:22 -0000 After reading Phillip's mails, I agree with him that it makes sense to allow an account id without a domain name. The document should be clear that such use won't work internet-wide, and should be avoided wherever possible. It should also be clear that relative resolution won't work, because it's the wrong syntax. Regards, Martin. On 2012/07/03 7:53, Phillip Hallam-Baker wrote: > On Mon, Jul 2, 2012 at 1:57 PM, Bob Wyman wrote: >> >> >> On Mon, Jul 2, 2012 at 11:42 AM, Phillip Hallam-Baker >> wrote: >>> >>> I think Tim regrets having been argued out of a lot of positions >>> relating to naming that he was subsequently proved right on. >>> >>> Naming issues are an area where a lot of people have strong opinions >>> that really turn out to be a matter of taste rather than grounded in >>> semiotics. >>> >>> The whole business of differentiating URLs and URNs as distinct >>> classes was bogus. Once the locator scheme has caching, a URL becomes >>> a name. Once an application provides a default action for a name (e.g. >>> look it up on Amazon) then a name becomes a locator. >>> >>> >>> A URI scheme should simply provide people with a well defined syntax >>> that allows them to express the concepts that applications that need >>> to interoperate need to exchange references to. Trying to decide how >>> people should use the identifiers is counterproductive. Trying to >>> enforce particular approaches is destructive. >>> >>> The vast majority of computer systems that use accounts do not bind >>> them to domain names. So there is a place in the acct: scheme for >>> unbound references. >> >> It seems to me that an unbound acct: name would be useful only in a "local" >> case, not generally useful between otherwise inter-working machines. As I >> understand it, the IETF normally limits its scope to those issues that >> relate to interworking between systems. Thus, it seems to me that a feature >> that is purely local and does not, in fact, facilitate inter-working is one >> that should not appear in an IETF document. This, of course, would not >> prevent anyone from building a system, or even set of systems, that made >> private agreements or used private conventions concerning the use of acct: >> names which were unbound or contained no domain part. But, that is not, I >> think, a matter which need concern anyone while wearing an IETF standards >> hat. > > That is not the case at all. IETF protocols have always been designed > to support local use in addition to Internet use where that makes > sense. > > In this case accounts are currently a locally defined resource and the > objective is to make them an Internet resource. The transition from > one to the other requires a spec that can work equally well in both > circumstances. > > Deployment is something that should always concern us. Scope arguments > are only ever relevant to the question of whether the IETF should > consider a problem in the first place. Once the problem is accepted > the design must address all the use cases and requirements that > reasonably apply whether they are deemed to be in IETF scope or not. > > And in any case I think that you are completely wrong on the question > of scope in the first place. Please provide a citation for your claim > if you want to continue the argument. > From duerst@it.aoyama.ac.jp Mon Jul 2 20:55:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B96311E80EC for ; Mon, 2 Jul 2012 20:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.206 X-Spam-Level: X-Spam-Status: No, score=-99.206 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, SARE_HTML_A_BODY=0.742, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aS3g70hfUge for ; Mon, 2 Jul 2012 20:55:57 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id BFC6511E8108 for ; Mon, 2 Jul 2012 20:55:56 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q633u31t005154 for ; Tue, 3 Jul 2012 12:56:03 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 19a8_aab6_0211dc86_c4c3_11e1_b41d_001d096c5782; Tue, 03 Jul 2012 12:56:02 +0900 Received: from [IPv6:::1] ([133.2.210.1]:40281) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 3 Jul 2012 12:56:06 +0900 Message-ID: <4FF26D4F.3070908@it.aoyama.ac.jp> Date: Tue, 03 Jul 2012 12:55:59 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John Bradley References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> <4E1F6AAD24975D4BA5B168042967394366572961@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FF1C3B5.4090902@stpeter.im> <4E1F6AAD24975D4BA5B1680429673943665729B6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FF1CA48.7090609@st peter.im> <5EBEB0AD-B7B9-4EF4-B7C2-055679B36705@ve7jtb.com> In-Reply-To: <5EBEB0AD-B7B9-4EF4-B7C2-055679B36705@ve7jtb.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 03:55:57 -0000 On 2012/07/03 1:44, John Bradley wrote: > Relative URI need to be relative to a base context. > > They don't contain scheme or host information. > > I could see having a relative acct: URI of: > > > > > > bob's account > > That would be assembled by some user agent to "acct:bob@example.com" as a URI for dereferencing. It would be assembled into "acct://example.com/bob". See RFC 3986, Section 5 (http://tools.ietf.org/html/rfc3986#section-5). Regards, Martin. > That is different from throwing around "acct:bob" which is like saying "http:///bob.html" and not a valid URI as I understand it. > > This is the good thing about trying to document acct: separately, it brings out issues that WF might not address. From duerst@it.aoyama.ac.jp Mon Jul 2 20:57:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364D311E8108 for ; Mon, 2 Jul 2012 20:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.972 X-Spam-Level: X-Spam-Status: No, score=-97.972 tagged_above=-999 required=5 tests=[AWL=-1.382, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwssVzDwjqFS for ; Mon, 2 Jul 2012 20:57:51 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFE311E80EC for ; Mon, 2 Jul 2012 20:57:51 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q633vrek026001 for ; Tue, 3 Jul 2012 12:57:53 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 19ac_9b62_43bc0a80_c4c3_11e1_a450_001d096c5782; Tue, 03 Jul 2012 12:57:52 +0900 Received: from [IPv6:::1] ([133.2.210.1]:40288) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 3 Jul 2012 12:57:57 +0900 Message-ID: <4FF26DBD.1060201@it.aoyama.ac.jp> Date: Tue, 03 Jul 2012 12:57:49 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <4FF1C968.3070802@stpeter.im> In-Reply-To: <4FF1C968.3070802@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Barry Leiba , Graham Klyne , apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme definition -- draft-saintandre-acct-uri X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 03:57:52 -0000 On 2012/07/03 1:16, Peter Saint-Andre wrote: > I would prefer to borrow the definition from RFC 3986 here, not tie this > spec to SMTP or mailto definitions. > > Thus: > > The 'acct' URI syntax is defined here in Augmented Backus-Naur Form > (ABNF) [RFC5234], borrowing the 'unreserved' and 'pct-encoded' rules > from that specification and the 'host' rule from [RFC3986]: > > acctURI = "acct:" userpart "@" host > userpart = 1*( unreserved / pct-encoded ) > > We could even borrow the 'userinfo' rule from RFC 3986: > > userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) > > I think there's good reason to exclude the user:password format in > userinfo, as mentioned in RFC 3986. But what about sub-delims? Perhaps > this is more appropriate: > > userpart = 1*( unreserved / pct-encoded / sub-delims ) Fully agreed. Regards, Martin. From mnot@mnot.net Mon Jul 2 20:59:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6686711E811C for ; Mon, 2 Jul 2012 20:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.499 X-Spam-Level: X-Spam-Status: No, score=-105.499 tagged_above=-999 required=5 tests=[AWL=-2.900, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8TKbQ1GPJSa for ; Mon, 2 Jul 2012 20:59:51 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id AF50111E8116 for ; Mon, 2 Jul 2012 20:59:44 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B915522E257; Mon, 2 Jul 2012 23:59:43 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Jul 2012 13:59:40 +1000 Message-Id: To: "Paul C. Bryan" , Salvatore Loreto , Alexey Melnikov , "Murray S. Kucherawy" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss Subject: [apps-discuss] json-pointer status X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 03:59:52 -0000 This is where I understand we're at with the json-pointer issues = : #1: already in draft; can be closed #2: hasn't been much discussion, think it can be discussed in Vancouver, = then revived on list, then closed. #3: proposal to move to ~ encoding in SVN; needs discussion #4: NUL text in SVN; need to discuss frag id impact in Vancouver #5: text in SVN; can be closed #6: examples in SVN; can be closed So, I think we should publish the draft as -02 so we can discuss in = Vancouver. Make sense? Cheers, -- Mark Nottingham http://www.mnot.net/ From wmills@yahoo-inc.com Mon Jul 2 21:02:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE45B11E811C for ; Mon, 2 Jul 2012 21:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.398 X-Spam-Level: X-Spam-Status: No, score=-17.398 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p6a7MXXSzsO for ; Mon, 2 Jul 2012 21:02:03 -0700 (PDT) Received: from nm31-vm4.bullet.mail.bf1.yahoo.com (nm31-vm4.bullet.mail.bf1.yahoo.com [72.30.239.12]) by ietfa.amsl.com (Postfix) with SMTP id 6982611E80EC for ; Mon, 2 Jul 2012 21:02:03 -0700 (PDT) Received: from [98.139.215.141] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2012 04:02:09 -0000 Received: from [98.139.212.199] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2012 04:02:09 -0000 Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 03 Jul 2012 04:02:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 687393.92950.bm@omp1008.mail.bf1.yahoo.com Received: (qmail 58357 invoked by uid 60001); 3 Jul 2012 04:02:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1341288128; bh=z8I+nIVxoYcQkH8EhijHtjVWvh2AT+JIrGBhuZYDunE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=V6ny+FjHKZ7YgMlVQmNohK2xNqIC4g6tbr3l2PY5dyo0JgYBy4xBPoK5xe6h1qg0gVA3Yv0jdy2JQjyiSU9MFDi0FTmTGNBxPy0OuRj2NWfUF763jZmc2Q/JcpRK+kF7BeIYeq9PqeXp7A2Y9qgtg94wSUN+1KGrFYz5sBrnacQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dUslfSS/kfh5envH8AZVoY5oDWjAMIkArlQnlAIKxTsS8JUQPFI9xYbDiY8tpwc6wxZytHMvjlTwKSDCFM9U5Cc51rLsOMlIfIGXqnSpoDdCw/x9HsBgkiMIH3o6YS2DA0b1cR0WYcGSXksrEnydHVYL/AIbdWZ/5y4gm66cVo8=; X-YMail-OSG: z6z2L0oVM1mFBJhvjm8G4uMP9tKf.q3WYKbhZ_63vjwhZiL DHtr.NNTAEJnsOvlgFp4O6w6CZvsmtRX5ZsNGHZrxUmmGcudkChswqDFPcVJ isPJBvCV5SDbVkgBCdTnZRE_dj.i6sriIa3mpxWTVcDDnERIp9dbMyykeQms TIJAaBoIy9Z8AimtW5pUdrTZvy2wDtMuYGY_wHhGD1G3c22Y2a6DJVVdY4RL pkwFLC6R0qCQBHIDLiQrheeEAjRfxQ_mTtw353C8EbEljsykJWsu6RlMbmLb gTWGpSYDORRAsXMoA5xQ0X2LiosLh_GwhamKXXEr0gu8JKQDdAu4YovfjRi. T1_1VZ6dohQBTMHaw6.Zxcm2FYRXgIApfzUbEHpmL.g9.clVrqwbjIaRRk4g w8c7Gm0Kbz.APjsit5RE_4CNM8kbRhyulh7yq4RiPagy275o6lpoSd6by Received: from [209.131.62.115] by web31802.mail.mud.yahoo.com via HTTP; Mon, 02 Jul 2012 21:02:08 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <1341157111.65669.YahooMailNeo@web31805.mail.mud.yahoo.com> <4FF0C90D.2060207@stpeter.im> <4FF18C30.2040902@ninebynine.org> <4FF26CB4.4080203@it.aoyama.ac.jp> Message-ID: <1341288128.53630.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Mon, 2 Jul 2012 21:02:08 -0700 (PDT) From: William Mills To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , Phillip Hallam-Baker In-Reply-To: <4FF26CB4.4080203@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-1144451342-1341288128=:53630" Cc: Graham Klyne , "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 04:02:04 -0000 ---1036955950-1144451342-1341288128=:53630 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Peter's point about complexity for parsing is significant if we don't have = a good reason to need it.=A0 The logic for optional is something like:=0A= =0A-=A0=A0=A0 is there an @ sign?=0A=A0=A0=A0 -=A0=A0=A0 no: the whole thin= g is a local user identifier=0A=A0=A0=A0 -=A0=A0=A0 yes: does the domain pa= rt parse correctly as a domain?=0A=A0=A0=A0 =A0=A0=A0 -=A0=A0=A0 no: the wh= ole thing is a local user id=0A=A0=A0=A0 =A0=A0=A0 -=A0=A0=A0 yes: this is = a proper compound identifier=0A=0AWhich is kind of a PITA if you don't need= it.=A0 If we do feel like we want purely local identifiers we could let th= e domainpart be empty, with an @ at the end.=A0 That would fix the parsing,= but probably make people cringe.=0A=0A=0A=0A=0A>__________________________= ______=0A> From: ""Martin J. D=FCrst"" =0A>To: Phil= lip Hallam-Baker =0A>Cc: Graham Klyne ; "apps-discuss@ietf.org" ; Murray S. Kucherawy =0A>Sent: Monday, July 2, 2012 8:53 PM=0A>Subject: Re: [ap= ps-discuss] The acct: scheme question=0A> =0A>After reading Phillip's mails= , I agree with him that it makes sense to =0A>allow an account id without a= domain name. The document should be clear =0A>that such use won't work int= ernet-wide, and should be avoided wherever =0A>possible. It should also be = clear that relative resolution won't work, =0A>because it's the wrong synta= x.=0A>=0A>Regards,=A0 =A0 Martin.=0A>=0A>On 2012/07/03 7:53, Phillip Hallam= -Baker wrote:=0A>> On Mon, Jul 2, 2012 at 1:57 PM, Bob Wyman= =A0 wrote:=0A>>>=0A>>>=0A>>> On Mon, Jul 2, 2012 at 11:42 AM, Phillip Halla= m-Baker=0A>>> wrote:=0A>>>>=0A>>>> I think Tim regrets ha= ving been argued out of a lot of positions=0A>>>> relating to naming that h= e was subsequently proved right on.=0A>>>>=0A>>>> Naming issues are an area= where a lot of people have strong opinions=0A>>>> that really turn out to = be a matter of taste rather than grounded in=0A>>>> semiotics.=0A>>>>=0A>>>= > The whole business of differentiating URLs and URNs as distinct=0A>>>> cl= asses was bogus. Once the locator scheme has caching, a URL becomes=0A>>>> = a name. Once an application provides a default action for a name (e.g.=0A>>= >> look it up on Amazon) then a name becomes a locator.=0A>>>>=0A>>>>=0A>>>= > A URI scheme should simply provide people with a well defined syntax=0A>>= >> that allows them to express the concepts that applications that need=0A>= >>> to interoperate need to exchange references to. Trying to decide how=0A= >>>> people should use the identifiers is counterproductive. Trying to=0A>>= >> enforce particular approaches is destructive.=0A>>>>=0A>>>> The vast maj= ority of computer systems that use accounts do not bind=0A>>>> them to doma= in names. So there is a place in the acct: scheme for=0A>>>> unbound refere= nces.=0A>>>=0A>>> It seems to me that an unbound acct: name would be useful= only in a "local"=0A>>> case, not generally useful between otherwise inter= -working machines. As I=0A>>> understand it, the IETF normally limits its s= cope to those issues that=0A>>> relate to interworking between systems. Thu= s, it seems to me that a feature=0A>>> that is purely local and does not, i= n fact, facilitate inter-working is one=0A>>> that should not appear in an = IETF document. This, of course, would not=0A>>> prevent anyone from buildin= g a system, or even set of systems, that made=0A>>> private agreements or u= sed private conventions concerning the use of acct:=0A>>> names which were = unbound or contained no domain part. But, that is not, I=0A>>> think, a mat= ter which need concern anyone while wearing an IETF standards=0A>>> hat.=0A= >>=0A>> That is not the case at all. IETF protocols have always been design= ed=0A>> to support local use in addition to Internet use where that makes= =0A>> sense.=0A>>=0A>> In this case accounts are currently a locally define= d resource and the=0A>> objective is to make them an Internet resource. The= transition from=0A>> one to the other requires a spec that can work equall= y well in both=0A>> circumstances.=0A>>=0A>> Deployment is something that s= hould always concern us. Scope arguments=0A>> are only ever relevant to the= question of whether the IETF should=0A>> consider a problem in the first p= lace. Once the problem is accepted=0A>> the design must address all the use= cases and requirements that=0A>> reasonably apply whether they are deemed = to be in IETF scope or not.=0A>>=0A>> And in any case I think that you are = completely wrong on the question=0A>> of scope in the first place. Please p= rovide a citation for your claim=0A>> if you want to continue the argument.= =0A>>=0A>_______________________________________________=0A>apps-discuss ma= iling list=0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/listinf= o/apps-discuss=0A>=0A>=0A> ---1036955950-1144451342-1341288128=:53630 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Peter's point about complexity for parsing is significant if we don't hav= e a good reason to need it.  The logic for optional is something like:=

-    is there an @ sign?
    -    no:= the whole thing is a local user identifier
    -    yes= : does the domain part parse correctly as a domain?
      &nb= sp; -    no: the whole thing is a= local user id
        -  &= nbsp; yes: this is a proper compound identifier

Which is kind of a PITA= if you don't need it.  If we do feel like we want purely local identi= fiers we could let the domainpart be empty, with an @ at the end.  Tha= t would fix the parsing, but probably make people cringe.
<= div>
=
From: ""Martin J. D= =FCrst"" <duerst@it.aoyama.ac.jp>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: Graham Klyne <GK@ninebynine.org>; "apps-= discuss@ietf.org" <apps-discuss@ietf.org>; Murray S. Kucherawy <ms= k@cloudmark.com>
Sent:= Monday, July 2, 2012 8:53 PM
Subject: Re: [apps-discuss] The acct: scheme question

=0AAfter reading Phillip's mails, I agree with him that it ma= kes sense to
allow an account id without a domain name. The document sh= ould be clear
that such use won't work internet-wide, and should be avo= ided wherever
possible. It should also be clear that relative resolutio= n won't work,
because it's the wrong syntax.

Regards,  &nbs= p; Martin.

On 2012/07/03 7:53, Phillip Hallam-Baker wrote:
> O= n Mon, Jul 2, 2012 at 1:57 PM, Bob Wyman<bob@wyman.us>  wrote:
>&= gt;
>>
>> On Mon, Jul 2, 2012 at 11:42 AM, Phillip Hallam= -Baker<hallam@gmail.com>
>> wrote:
>>>
>&= gt;> I think Tim regrets having been argued out of a lot of positions>>> relating to naming that he was subsequently proved right on.
>>>
>>> Naming issues are an area where a lot = of people have strong opinions
>>> that really turn out to be a= matter of taste rather than grounded in
>>> semiotics.
>= >>
>>> The whole business of differentiating URLs and URN= s as distinct
>>> classes was bogus. Once the locator scheme ha= s caching, a URL becomes
>>> a name. Once an application provid= es a default action for a name (e.g.
>>> look it up on Amazon) = then a name becomes a locator.
>>>
>>>
>>&= gt; A URI scheme should simply provide people with a well defined syntax>>> that allows them to express the concepts that applications th= at need
>>> to interoperate need to exchange references to. Try= ing to decide how
>>> people should use the identifiers is coun= terproductive. Trying to
>>> enforce particular approaches is destructive.
>>>
>>> The vast majori= ty of computer systems that use accounts do not bind
>>> them t= o domain names. So there is a place in the acct: scheme for
>>>= unbound references.
>>
>> It seems to me that an unbound= acct: name would be useful only in a "local"
>> case, not general= ly useful between otherwise inter-working machines. As I
>> unders= tand it, the IETF normally limits its scope to those issues that
>>= ; relate to interworking between systems. Thus, it seems to me that a featu= re
>> that is purely local and does not, in fact, facilitate inter= -working is one
>> that should not appear in an IETF document. Thi= s, of course, would not
>> prevent anyone from building a system, = or even set of systems, that made
>> private agreements or used pr= ivate conventions concerning the use of acct:
>> names which were unbound or contained no domain part. But, that is not, I
>= ;> think, a matter which need concern anyone while wearing an IETF stand= ards
>> hat.
>
> That is not the case at all. IETF pro= tocols have always been designed
> to support local use in addition t= o Internet use where that makes
> sense.
>
> In this case= accounts are currently a locally defined resource and the
> objectiv= e is to make them an Internet resource. The transition from
> one to = the other requires a spec that can work equally well in both
> circum= stances.
>
> Deployment is something that should always concern= us. Scope arguments
> are only ever relevant to the question of whet= her the IETF should
> consider a problem in the first place. Once the= problem is accepted
> the design must address all the use cases and = requirements that
> reasonably apply whether they are deemed to be in IETF scope or not.
>
> And in any case I think that y= ou are completely wrong on the question
> of scope in the first place= . Please provide a citation for your claim
> if you want to continue = the argument.
>
_______________________________________________apps-discuss mailing list
apps-discuss@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/apps-discuss


---1036955950-1144451342-1341288128=:53630-- From mnot@mnot.net Mon Jul 2 21:13:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B595211E812D for ; Mon, 2 Jul 2012 21:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.467 X-Spam-Level: X-Spam-Status: No, score=-105.467 tagged_above=-999 required=5 tests=[AWL=-2.868, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PwA9SbA5mBH for ; Mon, 2 Jul 2012 21:13:50 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0A711E811D for ; Mon, 2 Jul 2012 21:13:49 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EBD6722E253; Tue, 3 Jul 2012 00:13:48 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Jul 2012 14:13:45 +1000 Message-Id: <161A64AC-4F0C-4E68-8B2F-0FE1684BFADB@mnot.net> To: "Paul C. Bryan" , "Murray S. Kucherawy" , Alexey Melnikov , Salvatore Loreto Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: [apps-discuss] json-patch status X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 04:13:50 -0000 .. and this is where I understand we're at with the json-pointer issues = : #7: back-and-forth on whether we need a test operation; needs discussion = / consensus judging. #8: proposal in SVN. #9: fix in SVN; can be closed. #10: frag id needs discussion in Vancouver (just as for pointer). Same question; ready for -02 and discussion in Vancouver? -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Mon Jul 2 21:21:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2B711E812C for ; Mon, 2 Jul 2012 21:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.435 X-Spam-Level: X-Spam-Status: No, score=-105.435 tagged_above=-999 required=5 tests=[AWL=-2.836, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8XagRk++dWu for ; Mon, 2 Jul 2012 21:21:54 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 039BA11E80EC for ; Mon, 2 Jul 2012 21:21:54 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E0BA722E257; Tue, 3 Jul 2012 00:21:58 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Jul 2012 14:21:58 +1000 Message-Id: To: "Paul C. Bryan" , Salvatore Loreto , Alexey Melnikov , "Murray S. Kucherawy" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: [apps-discuss] json-pointer status X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 04:21:55 -0000 [ re-sending because of borked MUA ] This is where I understand we're at with the json-pointer issues = : #1: already in draft; can be closed #2: hasn't been much discussion, think it can be discussed in Vancouver, = then revived on list, then closed. #3: proposal to move to ~ encoding in SVN; needs discussion #4: NUL text in SVN; need to discuss frag id impact in Vancouver #5: text in SVN; can be closed #6: examples in SVN; can be closed So, I think we should publish the draft as -02 so we can discuss in = Vancouver. Make sense? Cheers, -- Mark Nottingham http://www.mnot.net/ From internet-drafts@ietf.org Mon Jul 2 22:31:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5A121F86E3; Mon, 2 Jul 2012 22:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42mCilkf3vcq; Mon, 2 Jul 2012 22:31:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29A021F84FA; Mon, 2 Jul 2012 22:31:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120703053130.19197.7591.idtracker@ietfa.amsl.com> Date: Mon, 02 Jul 2012 22:31:30 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 05:31:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-ietf-appsawg-webfinger-00.txt Pages : 21 Date : 2012-07-02 Abstract: This specification defines the WebFinger protocol. WebFinger may be used to discover information about people on the Internet, such as a person's personal profile address, identity service, telephone number, or preferred avatar. WebFinger may also be used to learn information about objects on the network, such as the amount of toner in a printer or the physical location of a server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paulej@packetizer.com Mon Jul 2 22:34:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDAF11E811C for ; Mon, 2 Jul 2012 22:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdMa5DKQGcPF for ; Mon, 2 Jul 2012 22:34:43 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD1921F86F3 for ; Mon, 2 Jul 2012 22:34:43 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q635YmFe032742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jul 2012 01:34:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341293689; bh=y1lIu7848vJuM3vf7JHctsd2H/0NZpwvDSzqKFRf300=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=TxNTtDKS5k9FvEoAFw5c3W4bgEzK3fRmU2o+7RD57WWXc1/GLIcOgbZ7VvdkLJV3S foZIg6V4uvCXeUJWQTuQBE8mcM/6NRRteaBzFnQ27WDJLKOvAbppJ0P6mn4F6ajyM1 SaTBaqsHbO1pFlPlnILvk8/5N/jFUuAdzSqXdvME= From: "Paul E. Jones" To: "'Murray S. Kucherawy'" , References: In-Reply-To: Date: Tue, 3 Jul 2012 01:34:52 -0400 Message-ID: <03dd01cd58dd$926f5940$b74e0bc0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03DE_01CD58BC.0B5E5580" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXGLam4ZcEXYuhqWsvp7tdeX9aLpaDhtWQ Content-Language: en-us Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 05:34:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03DE_01CD58BC.0B5E5580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Murray, Thanks for the invitation. I prepared a revised version of the text as -00. This version contains text changes discussed on the list and, most importantly, removal of the 'acct' URI scheme definition and a reference to Peter's document. Paul From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Monday, July 02, 2012 12:29 PM To: apps-discuss@ietf.org Subject: [apps-discuss] The webfinger and the acct: scheme documents Greetings, APPSAWG has now sent three documents, half of its recent docket, to the IESG for IETF Last Call. We have three open documents remaining: draft-ietf-appsawg-malformed-mail draft-ietf-appsawg-json-pointer draft-ietf-appsawg-json-patch These remain in active development. Having cleared those other three documents, we'd like to bring in and begin processing webfinger, which we've been holding outside the WG until we cleared some backlog. I'd like to thank the authors and participants for their patience as we worked through those other projects, and the rest of you for your work in getting the others off to the next steps in their lifecycle. The authors of draft-jones-appsawg-webfinger are invited to submit draft-ietf-appsawg-webfinger-00, and we'll approve it. Now, a question: The "acct:" scheme URI work is an offshoot of webfinger. PSA has recently posted a document that separates that work out. So what is working group consensus: Should these be processed as two documents in parallel (and should APPSAWG take them on), or should they be processed as a single document? -MSK, APPSAWG co-chair ------=_NextPart_000_03DE_01CD58BC.0B5E5580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Murray,

 

Thanks for the invitation.  I prepared a revised version of the = text as -00.  This version contains text changes discussed on the = list and, most importantly, removal of the ‘acct’ URI scheme = definition and a reference to Peter’s = document.

 

Paul

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy
Sent: Monday, July 02, = 2012 12:29 PM
To: apps-discuss@ietf.org
Subject: = [apps-discuss] The webfinger and the acct: scheme = documents

 

Greetings,

APPSAWG has now sent = three documents, half of its recent docket, to the IESG for IETF Last = Call.  We have three open documents = remaining:

draft-ietf-appsawg-malformed-mail
draft-ietf-appsawg= -json-pointer
draft-ietf-appsawg-json-patch

These remain in = active development.  Having cleared those other three documents, = we'd like to bring in and begin processing webfinger, which we've been = holding outside the WG until we cleared some backlog.  I'd like to = thank the authors and participants for their patience as we worked = through those other projects, and the rest of you for your work in = getting the others off to the next steps in their lifecycle.

The = authors of draft-jones-appsawg-webfinger are invited to submit = draft-ietf-appsawg-webfinger-00, and we'll approve it.

Now, a = question: The "acct:" scheme URI work is an offshoot of = webfinger.  PSA has recently posted a document that separates that = work out.  So what is working group consensus: Should these be = processed as two documents in parallel (and should APPSAWG take them = on), or should they be processed as a single document?

-MSK, = APPSAWG co-chair

------=_NextPart_000_03DE_01CD58BC.0B5E5580-- From superuser@gmail.com Mon Jul 2 22:37:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD2721F871C for ; Mon, 2 Jul 2012 22:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.505 X-Spam-Level: X-Spam-Status: No, score=-4.505 tagged_above=-999 required=5 tests=[AWL=1.093, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CjG2wlS7sUg for ; Mon, 2 Jul 2012 22:37:22 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E9F8D21F8713 for ; Mon, 2 Jul 2012 22:37:21 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so9288337lbb.31 for ; Mon, 02 Jul 2012 22:37:28 -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=eOLAWaxkMSDif6IFL8SWj5GyCGlWCWvOuBE+OVnw/BA=; b=1A6358OTVpkcnkDkNNKqhrCq4r+9AA/YFScupdNDneNACg1j7Z//dxXxd0eMlStWqj Wt1YJRGQcnKG/1pljvKIgppqZzYm0whzTujDYfwxqCc0qf9YeZZi+WcoQdbK7e8usX+N E7opYe5fgccrY27PRkOaAxiHmd27xSatU3ZldbnH6Hbg/5BmkCqIbnIReIGdaalWZmra 7/oqs+Ek5NiLFwiGbhOhvYwpsFJlwqkcyLi63bGs98ZCC6+Kb38/WOx1mEML/OsIlF+D AWzonYcejIU8Vg36cMZwIi4Cyc5p2Z+BDt6BEQJg1kqPBQFjwSkesWNGFPAF3LRE+Diy gnkg== MIME-Version: 1.0 Received: by 10.152.104.171 with SMTP id gf11mr7214006lab.5.1341293848139; Mon, 02 Jul 2012 22:37:28 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 2 Jul 2012 22:37:28 -0700 (PDT) In-Reply-To: <03dd01cd58dd$926f5940$b74e0bc0$@packetizer.com> References: <03dd01cd58dd$926f5940$b74e0bc0$@packetizer.com> Date: Mon, 2 Jul 2012 22:37:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d04083de75b988d04c3e64f7b Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 05:37:22 -0000 --f46d04083de75b988d04c3e64f7b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jul 2, 2012 at 10:34 PM, Paul E. Jones wrote= : > Thanks for the invitation. I prepared a revised version of the text as > -00. This version contains text changes discussed on the list and, most > importantly, removal of the =91acct=92 URI scheme definition and a refere= nce to > Peter=92s document. > > > It's been approved. I've also emailed the secretariat to ask them to show the older document as replaced by this one. -MSK --f46d04083de75b988d04c3e64f7b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jul 2, 2012 at 10:34 PM, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:
Thanks for the invitation.=A0 I prepared a revised version of the t= ext as -00.=A0 This version contains text changes discussed on the list and= , most importantly, removal of the =91acct=92 URI scheme definition and a r= eference to Peter=92s document.



It's been approved.=A0 I've also = emailed the secretariat to ask them to show the older document as replaced = by this one.

-MSK

--f46d04083de75b988d04c3e64f7b-- From mnot@mnot.net Mon Jul 2 22:47:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7CA21F8771 for ; Mon, 2 Jul 2012 22:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.404 X-Spam-Level: X-Spam-Status: No, score=-105.404 tagged_above=-999 required=5 tests=[AWL=-2.805, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR9vTgiHmuPg for ; Mon, 2 Jul 2012 22:47:10 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCB121F8768 for ; Mon, 2 Jul 2012 22:47:10 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0D2C622E1F4 for ; Tue, 3 Jul 2012 01:47:10 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Jul 2012 15:47:07 +1000 Message-Id: To: IETF Apps Discuss Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 05:47:11 -0000 I've pretty much ignored the whole webfinger / acct: / SWD discussion = (too much!). However, since it's apparent it may soon become Real, I had = a look. In a nutshell, my initial reaction is "It's Not Nearly As Bad As I = Thought It Would Be." :) With that in mind, a few questions / comments (I'll resist going into = editorial matters, for the time being): * First and foremost, why use host-meta? What value does adding this = extra step to the dance bring, beyond "We've defined it, therefore we = must use it?" As I think I've said many times before, the whole point of a .well-known = URI is to group like uses together, to avoid having a "dictionary" = resource that gets bloated with many application's unrelated data, = thereby overburdening clients with too much information (especially when = they're constrained, e.g., mobile). As such, host-meta is a spectacularly bad example of a well-known URI. = Defining a end-all-be-all well-known-URI kind of removes the point of = having a registry, after all... Instead, why not just define a NEW well-known URI for user data? That = has a more constrained scope, and saves one round trip (or more). E.g., GET /.well-known/webfinger?user=3Dbob%40example.com HTTP/1.0 Host: example.com I.e., let webfinger define the URI template to use. Yes, some = implementations might want to come up with crazy URIs, but is that = really a problem we want to solve? Astute observers will notice that this approach removes the need for an = ACCT URI scheme (at least here). =20 * What's the fascination with XRD and JRD? These specifications seem to = be creeping into IETF architecture; first it was in a pure security = context, but now folks are talking about using them in a much more = generic way, as a cornerstone of what we do. As such, I think they = deserve a MUCH closer look, especially since we're defining things with = "Web" in their name when the W3C has already defined solutions in this = space. Thanks, -- Mark Nottingham http://www.mnot.net/ From superuser@gmail.com Mon Jul 2 22:59:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED3F21F8715 for ; Mon, 2 Jul 2012 22:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAK6ez4kq8jd for ; Mon, 2 Jul 2012 22:59:20 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80AD721F86D6 for ; Mon, 2 Jul 2012 22:59:20 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so9309793lbb.31 for ; Mon, 02 Jul 2012 22:59:26 -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=9NfnNwksWiwzlHfdeU+bFTcbF0qp7CmM5HWCX6AjitU=; b=FjjpE7M3ZDvixf5ELq/NerXTdGSFEkdvqHOuqCpLMK7stIRowT1BZy9IVOLZy9uK+t 12soGixRoSPgGKBW6dUr7yzV7vglAKdKIeuR2g0tdjGLvebToPdTJFdkqqHzf6B5VdIQ HdIwjQ8kDyXiGB6Z8K1rLlWHZZwg+GgTfpZRyIGs7EmXOq6fStjYOrSeJX4NR/OwJL5t Jf/hgJ/xYj+WHagHcTe9VMfJSf4dASsEIARtclQuFLKjeufonfhY2iZS6sV8yhDEC1ju Ck3pDVj2NNvTvM+OWzMdKXvytUovlxtpnca9nX9YmlDRMCpcFIpk8hsenYmvW5r0sFex 6NSw== MIME-Version: 1.0 Received: by 10.112.84.168 with SMTP id a8mr7409466lbz.92.1341295166729; Mon, 02 Jul 2012 22:59:26 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 2 Jul 2012 22:59:26 -0700 (PDT) Date: Mon, 2 Jul 2012 22:59:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=f46d04016cadf3afee04c3e69de4 Subject: [apps-discuss] REMINDER: Agenda items for Vancouver X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 05:59:21 -0000 --f46d04016cadf3afee04c3e69de4 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 10, 2012 at 2:11 PM, Murray S. Kucherawy wrote: > If anyone would like to request time on the APPSAWG/APPAREA agenda for the > Vancouver meeting, please send your request to > appsawg-chairs@tools.ietf.org. We have one request in-hand already. > > The deadline for submitting a draft agenda is July 18th, so please get > your requests in well ahead of that date. > > We still have only two requests for time on our agenda. Please don't wait for the last minute to submit your request. -MSK, APPSAWG co-chair --f46d04016cadf3afee04c3e69de4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Jun 10, 2012 at 2:11 PM, Murray S. Kucherawy <= superuser@gmail.co= m> wrote:
If anyone would like to request time on the APPSAWG/APPAREA agenda for the = Vancouver meeting, please send your request to appsawg-chairs@tools.ietf.org.= =A0 We have one request in-hand already.

The deadline for submitting a draft agenda is July 18th, so please get = your requests in well ahead of that date.


We s= till have only two requests for time on our agenda.=A0 Please don't wai= t for the last minute to submit your request.

-MSK, APPSAWG co-chair

--f46d04016cadf3afee04c3e69de4-- From Michael.Jones@microsoft.com Tue Jul 3 00:24:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044B111E8141 for ; Tue, 3 Jul 2012 00:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.777 X-Spam-Level: X-Spam-Status: No, score=-3.777 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz9m00Lo+N+C for ; Tue, 3 Jul 2012 00:24:30 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id C1B3011E8147 for ; Tue, 3 Jul 2012 00:24:29 -0700 (PDT) Received: from mail52-db3-R.bigfish.com (10.3.81.236) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 3 Jul 2012 07:22:37 +0000 Received: from mail52-db3 (localhost [127.0.0.1]) by mail52-db3-R.bigfish.com (Postfix) with ESMTP id 1C9063A0405; Tue, 3 Jul 2012 07:22:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371I542M4015Izz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail52-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail52-db3 (localhost.localdomain [127.0.0.1]) by mail52-db3 (MessageSwitch) id 1341300156192910_30034; Tue, 3 Jul 2012 07:22:36 +0000 (UTC) Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.240]) by mail52-db3.bigfish.com (Postfix) with ESMTP id 233A04A0052; Tue, 3 Jul 2012 07:22:36 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 3 Jul 2012 07:22:35 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0309.003; Tue, 3 Jul 2012 07:24:12 +0000 From: Mike Jones To: Mark Nottingham , IETF Apps Discuss Thread-Topic: [apps-discuss] Looking at Webfinger Thread-Index: AQHNWN9R3JMvULc1OkWqOfej7pUMPpcXJjbA Date: Tue, 3 Jul 2012 07:24:11 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 07:24:34 -0000 You've essentially described Simple Web Discovery! It avoids the complicat= ions introduced by host-meta exactly by using its own .well-known value. T= he basic example is: GET /.well-known/simple-web-discovery?principal=3Dmailto:joe@example.com= &service=3Durn:example.org:service:calendar HTTP/1.1 Host: example.com HTTP/1.1 200 OK Content-Type: application/json { "locations": ["http://calendars.example.net/calendars/joseph"] } See http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 for more= details. By design, there aren't many... -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Mark Nottingham Sent: Monday, July 02, 2012 10:47 PM To: IETF Apps Discuss Subject: [apps-discuss] Looking at Webfinger I've pretty much ignored the whole webfinger / acct: / SWD discussion (too = much!). However, since it's apparent it may soon become Real, I had a look. In a nutshell, my initial reaction is "It's Not Nearly As Bad As I Thought = It Would Be." :) With that in mind, a few questions / comments (I'll resist going into edito= rial matters, for the time being): * First and foremost, why use host-meta? What value does adding this extra = step to the dance bring, beyond "We've defined it, therefore we must use it= ?" As I think I've said many times before, the whole point of a .well-known UR= I is to group like uses together, to avoid having a "dictionary" resource t= hat gets bloated with many application's unrelated data, thereby overburden= ing clients with too much information (especially when they're constrained,= e.g., mobile). As such, host-meta is a spectacularly bad example of a well-known URI. Defi= ning a end-all-be-all well-known-URI kind of removes the point of having a = registry, after all... Instead, why not just define a NEW well-known URI for user data? That has a= more constrained scope, and saves one round trip (or more). E.g., GET /.well-known/webfinger?user=3Dbob%40example.com HTTP/1.0 Host: example.com I.e., let webfinger define the URI template to use. Yes, some implementatio= ns might want to come up with crazy URIs, but is that really a problem we w= ant to solve? Astute observers will notice that this approach removes the need for an ACC= T URI scheme (at least here). =20 * What's the fascination with XRD and JRD? These specifications seem to be = creeping into IETF architecture; first it was in a pure security context, b= ut now folks are talking about using them in a much more generic way, as a = cornerstone of what we do. As such, I think they deserve a MUCH closer look= , especially since we're defining things with "Web" in their name when the = W3C has already defined solutions in this space. Thanks, -- Mark Nottingham http://www.mnot.net/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From mnot@mnot.net Tue Jul 3 00:26:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2F011E8141 for ; Tue, 3 Jul 2012 00:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.354 X-Spam-Level: X-Spam-Status: No, score=-105.354 tagged_above=-999 required=5 tests=[AWL=-2.755, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2eu72m0VhPR for ; Tue, 3 Jul 2012 00:26:34 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFAE11E814F for ; Tue, 3 Jul 2012 00:26:34 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0ADAB22E253; Tue, 3 Jul 2012 03:26:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 3 Jul 2012 17:26:31 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 07:26:35 -0000 On 03/07/2012, at 5:24 PM, Mike Jones wrote: > You've essentially described Simple Web Discovery! It avoids the = complications introduced by host-meta exactly by using its own = .well-known value. This makes me happy. :) So, what's the current state of SWF vs. webfinger? I thought I'd see an = announcement go by that webfinger was going to become a WG draft. Sorry for not keeping up, but I can only digest so much e-mail at = once... Thanks, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Jul 3 00:29:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B8A21F86A4 for ; Tue, 3 Jul 2012 00:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.325 X-Spam-Level: X-Spam-Status: No, score=-105.325 tagged_above=-999 required=5 tests=[AWL=-2.726, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+6owcTEgRZk for ; Tue, 3 Jul 2012 00:29:30 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BFF1C21F86A0 for ; Tue, 3 Jul 2012 00:29:30 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4A57B22E253 for ; Tue, 3 Jul 2012 03:29:37 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Jul 2012 17:29:34 +1000 Message-Id: <2818721F-C276-42D6-9BE5-193A13521FF4@mnot.net> To: IETF Apps Discuss Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [apps-discuss] #10: json-pointer fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 07:29:31 -0000 This is actually about pointer; there isn't any reference to fragment = identifers in json-patch any more. I think there are three ways we could go here: 1) Make json-pointer the fragment identifier syntax for = application/json. This would require updating the media type = registration. 2) Explain how json-pointer could be made the fragment identifier syntax = for *your* media type, upon specification. This would require a small = amount of editorial work. 3) Remove any reference to use of json-pointer as a fragment identifier = syntax. This would require a bit of editorial work. Thoughts? FWIW, my .02 is that #2 seems eminently reasonable. Cheers, -- Mark Nottingham http://www.mnot.net/ From wmills@yahoo-inc.com Tue Jul 3 00:31:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE5411E8152 for ; Tue, 3 Jul 2012 00:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.545 X-Spam-Level: X-Spam-Status: No, score=-17.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu9B3bYLjb6k for ; Tue, 3 Jul 2012 00:31:06 -0700 (PDT) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) by ietfa.amsl.com (Postfix) with SMTP id D908C11E8140 for ; Tue, 3 Jul 2012 00:31:05 -0700 (PDT) Received: from [98.139.212.151] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2012 07:31:12 -0000 Received: from [98.139.215.248] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jul 2012 07:31:12 -0000 Received: from [127.0.0.1] by omp1061.mail.bf1.yahoo.com with NNFMP; 03 Jul 2012 07:31:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 613944.78404.bm@omp1061.mail.bf1.yahoo.com Received: (qmail 8547 invoked by uid 60001); 3 Jul 2012 07:31:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1341300671; bh=MmXnYzw64xkCQxLu9RX0E/gvweXzQe/f1EaLynkQTvQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jHqGKtJmdIypikGhYfq9/mD0+A/pVdT0bMUbh55iUWtLpDrhPAAWqTbUGKVzZO9UJyp9sVbMpe/md+jTmYbdv3StkBqGr1FKimicJMBd3+u7o8NaTckjlvSGxqffhSyH4DYjzMM9PcKK4eqXkw6keD476vPMY1FPGvDzUTCWOIw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lBJ1bqXnaRRu5cd7D3JkO31aQ7JrAhs22haFsddVhyYZvPpoL1kavN/ghGs7F2DmPouZ2nuIUKfyRi8J2Bz0+EeDDTV6HyfXwoMoRdlz6IgbJVWkE14qA1fNQgvwPfB4u+WoO01EzdHBtD0gexiBOvbTLMwzXkpzcNdUSsYnmII=; X-YMail-OSG: qhHLvT8VM1khsU5htRy8eNFdDhZACD9tSriYWDatqGCp0s9 WPaKo.EO1eLAtc9b2Vbmr8209nPUv83PiuIGhm3mIlUcTwAB320UK2rn.idB 5UFZ2ppBgG.HUT1kULdzx6TZqvQrMsvbExbyfkGMTTOWlV2D4luG.DA4Bu2t HeoijqX8sB3o4hJxZopDkLptAAnmin_JVQXcKDOY1Zl3HBlFfagK6t0g1V1t TyD2TUtQLJr_1NR4.JfbQswwx2NY7gYa75Gr0McUYwUTLYkFLfFzsoz0pvwC F4YLwrBYwi_nNdi2ZBeJOafOFMe31Orrz.KzHIoxkwqUw.mxltLjWaes6_Vn .BJvYP5XH_NkVcW6aiElVURWQasPjkiRy69IS_FZYyIJUvxa4WopixUTWlSu 4ScWEyewH9cVippFlQ7UxmfQsk5QSp6V2k_N80B1EYSS5eNdxlw-- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Tue, 03 Jul 2012 00:31:11 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-ID: <1341300671.52855.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Tue, 3 Jul 2012 00:31:11 -0700 (PDT) From: William Mills To: Mark Nottingham , Mike Jones In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-2031056166-1341300671=:52855" Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 07:31:07 -0000 --767760015-2031056166-1341300671=:52855 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The answer is that they are close enough that having two drafts for very si= milar things seemed wrong.=A0 WF is being updated with the incremental chan= ges (small) to get the same functionality.=0A=0A=0A=0A=0A>_________________= _______________=0A> From: Mark Nottingham =0A>To: Mike Jones= =0A>Cc: IETF Apps Discuss =0A>Sent: Tuesday, July 3, 2012 12:26 AM=0A>Subject: Re: [apps-discus= s] Looking at Webfinger=0A> =0A>=0A>On 03/07/2012, at 5:24 PM, Mike Jones w= rote:=0A>=0A>> You've essentially described Simple Web Discovery!=A0 It avo= ids the complications introduced by host-meta exactly by using its own .wel= l-known value.=0A>=0A>This makes me happy. :)=0A>=0A>So, what's the current= state of SWF vs. webfinger? I thought I'd see an announcement go by that w= ebfinger was going to become a WG draft.=0A>=0A>Sorry for not keeping up, b= ut I can only digest so much e-mail at once...=0A>=0A>Thanks,=0A>=0A>--=0A>= Mark Nottingham=A0 http://www.mnot.net/=0A>=0A>=0A>=0A>___________________= ____________________________=0A>apps-discuss mailing list=0A>apps-discuss@i= etf.org=0A>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A> --767760015-2031056166-1341300671=:52855 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The answer is that they are close enough that having two drafts for very = similar things seemed wrong.  WF is being updated with the incremental= changes (small) to get the same functionality.

<= span style=3D"font-weight:bold;">From: Mark Nottingham <mnot@= mnot.net>
To: Mike = Jones <Michael.Jones@microsoft.com>
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
= Sent: Tuesday, July 3, 20= 12 12:26 AM
Subject: R= e: [apps-discuss] Looking at Webfinger

=0A
On 03/= 07/2012, at 5:24 PM, Mike Jones wrote:

> You've essentially descr= ibed Simple Web Discovery!  It avoids the complications introduced by = host-meta exactly by using its own .well-known value.

This makes me = happy. :)

So, what's the current state of SWF vs. webfinger? I thoug= ht I'd see an announcement go by that webfinger was going to become a WG dr= aft.

Sorry for not keeping up, but I can only digest so much e-mail = at once...

Thanks,

--
Mark Nottingham  http://www.mn= ot.net/



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


=
--767760015-2031056166-1341300671=:52855-- From melvincarvalho@gmail.com Tue Jul 3 00:33:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4477521F8606 for ; Tue, 3 Jul 2012 00:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VcR+G27vpiH for ; Tue, 3 Jul 2012 00:33:24 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92C0D21F858F for ; Tue, 3 Jul 2012 00:33:23 -0700 (PDT) Received: by vcqp1 with SMTP id p1so4406387vcq.31 for ; Tue, 03 Jul 2012 00:33:30 -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=m9meeU1YQvAsIhUUmYiRu3fwsqtpRrUCWffzURyW5uI=; b=A5rb7gcCQ/bUmozMhT9/iNUBOPh3oBTSNI414TUE39gpzvPTB3Um1mplunnARc8gra 5dpp2fTJjRpo760r+Sz8q2rMfK3hFG4HS94tCbW7i4jZYA0osAHHQvpLsp4leAzBmpM7 X/yo/ribszZCEOxJqBR/yULXnYJwWJK8dPVurZ32wTphNfR/kLgo+xxeHsq9exBvqh9H RiUx+C+czJgLBsyrcpL5phvwBVp1Hg2S/Laxhfsr49KNg7Ip67ApbOsdSfCSOivga1IS S0cgQmqKjGo0ZcCasLStnztkNHU97HHl8peNsGVVMsdIzsCoMWEpsTVpcJkSCO2JgNEW aVpA== MIME-Version: 1.0 Received: by 10.52.97.41 with SMTP id dx9mr6242932vdb.89.1341300810427; Tue, 03 Jul 2012 00:33:30 -0700 (PDT) Received: by 10.52.166.102 with HTTP; Tue, 3 Jul 2012 00:33:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Jul 2012 09:33:30 +0200 Message-ID: From: Melvin Carvalho To: Mark Nottingham Content-Type: multipart/alternative; boundary=20cf307f380657ac8004c3e7eec4 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 07:33:25 -0000 --20cf307f380657ac8004c3e7eec4 Content-Type: text/plain; charset=ISO-8859-1 On 3 July 2012 07:47, Mark Nottingham wrote: > I've pretty much ignored the whole webfinger / acct: / SWD discussion (too > much!). However, since it's apparent it may soon become Real, I had a look. > > In a nutshell, my initial reaction is "It's Not Nearly As Bad As I Thought > It Would Be." :) > > With that in mind, a few questions / comments (I'll resist going into > editorial matters, for the time being): > > * First and foremost, why use host-meta? What value does adding this extra > step to the dance bring, beyond "We've defined it, therefore we must use > it?" > > As I think I've said many times before, the whole point of a .well-known > URI is to group like uses together, to avoid having a "dictionary" resource > that gets bloated with many application's unrelated data, thereby > overburdening clients with too much information (especially when they're > constrained, e.g., mobile). > > As such, host-meta is a spectacularly bad example of a well-known URI. > Defining a end-all-be-all well-known-URI kind of removes the point of > having a registry, after all... > > Instead, why not just define a NEW well-known URI for user data? That has > a more constrained scope, and saves one round trip (or more). E.g., > > GET /.well-known/webfinger?user=bob%40example.com HTTP/1.0 > Host: example.com > Seems very sensible. To keep with the current naming it may need to be: GET /.well-known/webfinger?acct=bob%40example.com ( ) acct, rather than, user. Tho RFC6068 does in places include the term "user". There is an argument to say that user: is a more natural URI scheme than acct:. Leads to some interesting questions: Should user: be registered as well as acct: ? Should user: be registered instead of acct: ? Does acct: being registered mean user: should NOT be registered. ? In general +1 for this conceptually. Note that a very similar idea was suggested when this thread came up on the TAG list. [1] https://gmail.com/.well-known/host-meta?acct=joe@gmail.com http://lists.w3.org/Archives/Public/www-tag/2012Jun/0110.html > > I.e., let webfinger define the URI template to use. Yes, some > implementations might want to come up with crazy URIs, but is that really a > problem we want to solve? > > Astute observers will notice that this approach removes the need for an > ACCT URI scheme (at least here). > > > * What's the fascination with XRD and JRD? These specifications seem to be > creeping into IETF architecture; first it was in a pure security context, > but now folks are talking about using them in a much more generic way, as a > cornerstone of what we do. As such, I think they deserve a MUCH closer > look, especially since we're defining things with "Web" in their name when > the W3C has already defined solutions in this space. > > Thanks, > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --20cf307f380657ac8004c3e7eec4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 3 July 2012 07:47, Mark Nottingham <mnot= @mnot.net> wrote:
I've pretty much ignored the whole webfinger / acct: / SWD discussion (= too much!). However, since it's apparent it may soon become Real, I had= a look.

In a nutshell, my initial reaction is "It's Not Nearly As Bad As I= Thought It Would Be." :)

With that in mind, a few questions / comments (I'll resist going into e= ditorial matters, for the time being):

* First and foremost, why use host-meta? What value does adding this extra = step to the dance bring, beyond "We've defined it, therefore we mu= st use it?"

As I think I've said many times before, the whole point of a .well-know= n URI is to group like uses together, to avoid having a "dictionary&qu= ot; resource that gets bloated with many application's unrelated data, = thereby overburdening clients with too much information (especially when th= ey're constrained, e.g., mobile).

As such, host-meta is a spectacularly bad example of a well-known URI. Defi= ning a end-all-be-all well-known-URI kind of removes the point of having a = registry, after all...

Instead, why not just define a NEW well-known URI for user data? That has a= more constrained scope, and saves one round trip (or more). E.g.,

GET /.well-known/webfinger?user=3Dbob%40example.com HTTP/1.0
Host: example.com
<= /blockquote>

Seems very sensible.=A0 To keep with the current namin= g it may need to be:

GET /.well-known/webfinger?acct=3Dbob%40example.com (=A0 )

acct, rather than, user.

Tho RFC6068 does in places include the = term "user".=A0 There is an argument to say that user: is a more = natural URI scheme than acct:.=A0 Leads to some interesting questions:
<= br> Should user: be registered as well as acct: ?
Should user: be registered= instead of acct: ?
Does acct: being registered mean user: should NOT be= registered. ?

In general +1 for this conceptually.=A0 Note that a v= ery similar idea was suggested when this thread came up on the TAG list. [1= ]

https://gmail.com/.well-known/host-meta?acct=3Djoe@gmail.com

<= a href=3D"http://lists.w3.org/Archives/Public/www-tag/2012Jun/0110.html">ht= tp://lists.w3.org/Archives/Public/www-tag/2012Jun/0110.html
=A0

I.e., let webfinger define the URI template to use. Yes, some implementatio= ns might want to come up with crazy URIs, but is that really a problem we w= ant to solve?

Astute observers will notice that this approach removes the need for an ACC= T URI scheme (at least here).


* What's the fascination with XRD and JRD? These specifications seem to= be creeping into IETF architecture; first it was in a pure security contex= t, but now folks are talking about using them in a much more generic way, a= s a cornerstone of what we do. As such, I think they deserve a MUCH closer = look, especially since we're defining things with "Web" in th= eir name when the W3C has already defined solutions in this space.

Thanks,


--
Mark Nottingham =A0 http= ://www.mnot.net/



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

--20cf307f380657ac8004c3e7eec4-- From James.H.Manger@team.telstra.com Tue Jul 3 00:40:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD0321F86FE for ; Tue, 3 Jul 2012 00:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI328bZBeQSo for ; Tue, 3 Jul 2012 00:40:53 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id D185121F8704 for ; Tue, 3 Jul 2012 00:40:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,515,1336312800"; d="scan'208";a="79248549" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipobni.tcif.telstra.com.au with ESMTP; 03 Jul 2012 17:40:59 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6760"; a="69425662" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdni.tcif.telstra.com.au with ESMTP; 03 Jul 2012 17:40:58 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Tue, 3 Jul 2012 17:40:58 +1000 From: "Manger, James H" To: Mark Nottingham , IETF Apps Discuss Date: Tue, 3 Jul 2012 17:40:57 +1000 Thread-Topic: [apps-discuss] #10: json-pointer fragment identifiers Thread-Index: Ac1Y7Z1TnoNSaAeCSP+LDIQKc7Js3AAAPMLg Message-ID: <255B9BB34FB7D647A506DC292726F6E114F7600A7B@WSMSG3153V.srv.dir.telstra.com> References: <2818721F-C276-42D6-9BE5-193A13521FF4@mnot.net> In-Reply-To: <2818721F-C276-42D6-9BE5-193A13521FF4@mnot.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] #10: json-pointer fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 07:40:53 -0000 PiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvYXBwc2F3Zy90cmFjL3RpY2tldC8xMD4N Cj4gDQo+IFRoaXMgaXMgYWN0dWFsbHkgYWJvdXQgcG9pbnRlcjsgdGhlcmUgaXNuJ3QgYW55IHJl ZmVyZW5jZSB0byBmcmFnbWVudA0KPiBpZGVudGlmZXJzIGluIGpzb24tcGF0Y2ggYW55IG1vcmUu DQo+IA0KPiBJIHRoaW5rIHRoZXJlIGFyZSB0aHJlZSB3YXlzIHdlIGNvdWxkIGdvIGhlcmU6DQo+ IA0KPiAxKSBNYWtlIGpzb24tcG9pbnRlciB0aGUgZnJhZ21lbnQgaWRlbnRpZmllciBzeW50YXgg Zm9yDQo+IGFwcGxpY2F0aW9uL2pzb24uIFRoaXMgd291bGQgcmVxdWlyZSB1cGRhdGluZyB0aGUg bWVkaWEgdHlwZQ0KPiByZWdpc3RyYXRpb24uDQo+IA0KPiAyKSBFeHBsYWluIGhvdyBqc29uLXBv aW50ZXIgY291bGQgYmUgbWFkZSB0aGUgZnJhZ21lbnQgaWRlbnRpZmllcg0KPiBzeW50YXggZm9y ICp5b3VyKiBtZWRpYSB0eXBlLCB1cG9uIHNwZWNpZmljYXRpb24uIFRoaXMgd291bGQgcmVxdWly ZSBhDQo+IHNtYWxsIGFtb3VudCBvZiBlZGl0b3JpYWwgd29yay4NCj4gDQo+IDMpIFJlbW92ZSBh bnkgcmVmZXJlbmNlIHRvIHVzZSBvZiBqc29uLXBvaW50ZXIgYXMgYSBmcmFnbWVudCBpZGVudGlm aWVyDQo+IHN5bnRheC4gVGhpcyB3b3VsZCByZXF1aXJlIGEgYml0IG9mIGVkaXRvcmlhbCB3b3Jr Lg0KPiANCj4gDQo+IFRob3VnaHRzPyBGV0lXLCBteSAuMDIgaXMgdGhhdCAjMiBzZWVtcyBlbWlu ZW50bHkgcmVhc29uYWJsZS4NCg0KIzEgJiAjMg0KVGhlcmUgd2FzIHNvbWUgY29uY2VybiB0aGF0 IG1ha2luZyBKU09OIHBvaW50ZXIgVEhFIGZyYWdtZW50IGlkIGZvciBhcHBsaWNhdGlvbi9qc29u IHByZXZlbnRlZCBtb3JlIHNvcGhpc3RpY2F0ZWQgc3R1ZmYgbGF0ZXIuIEhvd2V2ZXIsIGEgSlNP TiBwb2ludGVyIGNhbiBvbmx5IHN0YXJ0IHdpdGggIi8iIHNvIHRoZXJlIHNob3VsZCBiZSByb29t IHRvIGFkZCBzZW1hbnRpY3MgdG8gb3RoZXIgZnJhZ21lbnRzIGxhdGVyLg0KDQotLQ0KSmFtZXMg TWFuZ2VyDQo= From julian.reschke@gmx.de Tue Jul 3 00:43:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0BC21F8734 for ; Tue, 3 Jul 2012 00:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[AWL=-3.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWZcuWJVTjaO for ; Tue, 3 Jul 2012 00:43:16 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 912FA21F8732 for ; Tue, 3 Jul 2012 00:43:15 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 07:43:21 -0000 Received: from p5DD95BE7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.91.231] by mail.gmx.net (mp010) with SMTP; 03 Jul 2012 09:43:21 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+uCQwzDHquQbS0Nx6Arp4VSeQIOwdf0wMPpEm4mW iLbqbdF5L9IRHk Message-ID: <4FF2A298.5030601@gmx.de> Date: Tue, 03 Jul 2012 09:43:20 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Nottingham References: <2818721F-C276-42D6-9BE5-193A13521FF4@mnot.net> In-Reply-To: <2818721F-C276-42D6-9BE5-193A13521FF4@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] #10: json-pointer fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 07:43:17 -0000 On 2012-07-03 09:29, Mark Nottingham wrote: > > > This is actually about pointer; there isn't any reference to fragment identifers in json-patch any more. > > I think there are three ways we could go here: > > 1) Make json-pointer the fragment identifier syntax for application/json. This would require updating the media type registration. I'd be unhappy about that, because so far we don't have a solid use case; and the syntax leaves no extension points. > 2) Explain how json-pointer could be made the fragment identifier syntax for *your* media type, upon specification. This would require a small amount of editorial work. That would work for me, as long as it's phrased in a way that makes it totally clear that it doesn't apply to application/json. > 3) Remove any reference to use of json-pointer as a fragment identifier syntax. This would require a bit of editorial work. That would be my preference. Best regards, Julian From salvatore.loreto@ericsson.com Tue Jul 3 00:45:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DEF21F85D3 for ; Tue, 3 Jul 2012 00:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZ0mXJOR0NtV for ; Tue, 3 Jul 2012 00:45:55 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8DC21F8734 for ; Tue, 3 Jul 2012 00:45:55 -0700 (PDT) X-AuditID: c1b4fb30-b7fb46d0000064f2-92-4ff2a339e0cd Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7D.8E.25842.933A2FF4; Tue, 3 Jul 2012 09:46:01 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Tue, 3 Jul 2012 09:46:00 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 570BD2541; Tue, 3 Jul 2012 10:46:00 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 61569531D2; Tue, 3 Jul 2012 10:46:01 +0300 (EEST) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 17CB651BC7; Tue, 3 Jul 2012 10:46:01 +0300 (EEST) Message-ID: <4FF2A337.4050701@ericsson.com> Date: Tue, 3 Jul 2012 10:45:59 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , draft-ietf-xrblock-rtcp-xr-meas-identity@tools.ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvra7l4k/+BjPPGlmsfrmCzWLB5UQH Jo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK2Pd3s+MBZfYK9qu/GZrYOxm62Lk5JAQMJGY vKEVyhaTuHBvPZDNxSEkcIpR4vXmfnYIZz2jxJJlHUwQzm5GibkLpkNl1jFK/Fg+mRWkX0hg OaPEphupIDavgLbEyiWfweIsAioSf+4fALPZBMwknj/cwtzFyMEhKpAs8fd/OkS5oMTJmU9Y QGwRgXyJFxs7GUFsYQE3iTNHLoLFmQVsJS7MuQ5ly0tsfzuHGeJsNYmr5zYxQ5ygJdF7tpNp AqPQLCRjZyFpn4WkfQEj8ypG4dzEzJz0cnO91KLM5OLi/Dy94tRNjMAgPrjlt8EOxk33xQ4x SnOwKInz6qnu9xcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAmJo+X3OSytQbJ+KM7mofYTa8 PHfBrvopN0Svz9XjD9O7/PDNyc6mGXtFctYcfLtkK5OqxZS5sx9sO2zS9OTgyn1zrLgXlDu3 6xs9MLi3VOud5S327erLfz1W/Kzps2/xM6kTUUbX+FgvP2crV9l9p+D6K94luWfEHOTMTmYm Lnp5rDzP/JlRUasSS3FGoqEWc1FxIgCo0xT+MAIAAA== Subject: [apps-discuss] APPSDIR review of draft-ietf-xrblock-rtcp-xr-meas-identity-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 07:45:57 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-xrblock-rtcp-xr-meas-identity-07 Title: Measurement Identity and information Reporting using SDES item and XR Block Reviewer: Salvatore Loreto Review Date: 2012-07-03 IESG Telechat Date: 2012-07-05 Summary: I have read and reviewed this draft. The draft is ready for publication, no issues from an application point of view, Major issues: 0 Minor issues: 0 Nits issues: 0 Major Issues: ----------- Minor Issues: ----------- Nits: ---- best regards /Sal -- Salvatore Loreto, PhD www.sloreto.com From julian.reschke@gmx.de Tue Jul 3 00:46:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C9C21F8749 for ; Tue, 3 Jul 2012 00:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.575 X-Spam-Level: X-Spam-Status: No, score=-105.575 tagged_above=-999 required=5 tests=[AWL=-2.976, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ak4GgSIkfRfl for ; Tue, 3 Jul 2012 00:46:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2995221F85D3 for ; Tue, 3 Jul 2012 00:46:51 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 07:46:57 -0000 Received: from p5DD95BE7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.91.231] by mail.gmx.net (mp033) with SMTP; 03 Jul 2012 09:46:57 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/F1yAoxLLFq+TVRx8uCLfE8JkxKwvT+iJw2Z4QgB NO3QJG1jbhUNAU Message-ID: <4FF2A36B.3030101@gmx.de> Date: Tue, 03 Jul 2012 09:46:51 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <2818721F-C276-42D6-9BE5-193A13521FF4@mnot.net> <255B9BB34FB7D647A506DC292726F6E114F7600A7B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F7600A7B@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] #10: json-pointer fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 07:46:52 -0000 On 2012-07-03 09:40, Manger, James H wrote: >> >> >> This is actually about pointer; there isn't any reference to fragment >> identifers in json-patch any more. >> >> I think there are three ways we could go here: >> >> 1) Make json-pointer the fragment identifier syntax for >> application/json. This would require updating the media type >> registration. >> >> 2) Explain how json-pointer could be made the fragment identifier >> syntax for *your* media type, upon specification. This would require a >> small amount of editorial work. >> >> 3) Remove any reference to use of json-pointer as a fragment identifier >> syntax. This would require a bit of editorial work. >> >> >> Thoughts? FWIW, my .02 is that #2 seems eminently reasonable. > > #1 & #2 > There was some concern that making JSON pointer THE fragment id for application/json prevented more sophisticated stuff later. However, a JSON pointer can only start with "/" so there should be room to add semantics to other fragments later. Good point, except for the "empty pointer" case... May I ask about what use case you are considering? Given the fact that JSON-Pointer is bleeding edge and escaping remains to be ugly I'm really reluctant to bake that into the "application/json" media type until it's clear why. Best regards, Julian From mnot@mnot.net Tue Jul 3 00:55:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BF121F8711 for ; Tue, 3 Jul 2012 00:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.31 X-Spam-Level: X-Spam-Status: No, score=-105.31 tagged_above=-999 required=5 tests=[AWL=-2.711, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVzPz0ifRacS for ; Tue, 3 Jul 2012 00:55:17 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 865B621F84D8 for ; Tue, 3 Jul 2012 00:55:17 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C55D322E253; Tue, 3 Jul 2012 03:55:23 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: <4FF2A298.5030601@gmx.de> Date: Tue, 3 Jul 2012 17:55:20 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2818721F-C276-42D6-9BE5-193A13521FF4@mnot.net> <4FF2A298.5030601@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] #10: json-pointer fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 07:55:18 -0000 One other option -- we can decouple the decision and add json-pointer as = a fragid syntax for application/json later. Cheers, On 03/07/2012, at 5:43 PM, Julian Reschke wrote: > On 2012-07-03 09:29, Mark Nottingham wrote: >> >>=20 >> This is actually about pointer; there isn't any reference to fragment = identifers in json-patch any more. >>=20 >> I think there are three ways we could go here: >>=20 >> 1) Make json-pointer the fragment identifier syntax for = application/json. This would require updating the media type = registration. >=20 > I'd be unhappy about that, because so far we don't have a solid use = case; and the syntax leaves no extension points. >=20 >> 2) Explain how json-pointer could be made the fragment identifier = syntax for *your* media type, upon specification. This would require a = small amount of editorial work. >=20 > That would work for me, as long as it's phrased in a way that makes it = totally clear that it doesn't apply to application/json. >=20 >> 3) Remove any reference to use of json-pointer as a fragment = identifier syntax. This would require a bit of editorial work. >=20 > That would be my preference. >=20 > Best regards, Julian -- Mark Nottingham http://www.mnot.net/ From James.H.Manger@team.telstra.com Tue Jul 3 01:06:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6022721F878A for ; Tue, 3 Jul 2012 01:06:37 -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=[AWL=-0.142, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkUCJQP1LV21 for ; Tue, 3 Jul 2012 01:06:36 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id C4E2221F875E for ; Tue, 3 Jul 2012 01:06:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,515,1336312800"; d="scan'208";a="79449806" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 03 Jul 2012 18:06:42 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6760"; a="69432914" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcdni.tcif.telstra.com.au with ESMTP; 03 Jul 2012 18:06:41 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Tue, 3 Jul 2012 18:06:41 +1000 From: "Manger, James H" To: Julian Reschke Date: Tue, 3 Jul 2012 18:06:40 +1000 Thread-Topic: [apps-discuss] #10: json-pointer fragment identifiers Thread-Index: Ac1Y8Ao5FC/djH4ORDyTVRmFBJ225AAAITBA Message-ID: <255B9BB34FB7D647A506DC292726F6E114F7600AA5@WSMSG3153V.srv.dir.telstra.com> References: <2818721F-C276-42D6-9BE5-193A13521FF4@mnot.net> <255B9BB34FB7D647A506DC292726F6E114F7600A7B@WSMSG3153V.srv.dir.telstra.com> <4FF2A36B.3030101@gmx.de> In-Reply-To: <4FF2A36B.3030101@gmx.de> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] #10: json-pointer fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 08:06:38 -0000 PiA+PiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvYXBwc2F3Zy90cmFjL3RpY2tldC8x MD4NCj4gPj4NCj4gPj4gVGhpcyBpcyBhY3R1YWxseSBhYm91dCBwb2ludGVyOyB0aGVyZSBpc24n dCBhbnkgcmVmZXJlbmNlIHRvDQo+IGZyYWdtZW50DQo+ID4+IGlkZW50aWZlcnMgaW4ganNvbi1w YXRjaCBhbnkgbW9yZS4NCj4gPj4NCj4gPj4gSSB0aGluayB0aGVyZSBhcmUgdGhyZWUgd2F5cyB3 ZSBjb3VsZCBnbyBoZXJlOg0KPiA+Pg0KPiA+PiAxKSBNYWtlIGpzb24tcG9pbnRlciB0aGUgZnJh Z21lbnQgaWRlbnRpZmllciBzeW50YXggZm9yDQo+ID4+IGFwcGxpY2F0aW9uL2pzb24uIFRoaXMg d291bGQgcmVxdWlyZSB1cGRhdGluZyB0aGUgbWVkaWEgdHlwZQ0KPiA+PiByZWdpc3RyYXRpb24u DQo+ID4+DQo+ID4+IDIpIEV4cGxhaW4gaG93IGpzb24tcG9pbnRlciBjb3VsZCBiZSBtYWRlIHRo ZSBmcmFnbWVudCBpZGVudGlmaWVyDQo+ID4+IHN5bnRheCBmb3IgKnlvdXIqIG1lZGlhIHR5cGUs IHVwb24gc3BlY2lmaWNhdGlvbi4gVGhpcyB3b3VsZCByZXF1aXJlDQo+IGENCj4gPj4gc21hbGwg YW1vdW50IG9mIGVkaXRvcmlhbCB3b3JrLg0KPiA+Pg0KPiA+PiAzKSBSZW1vdmUgYW55IHJlZmVy ZW5jZSB0byB1c2Ugb2YganNvbi1wb2ludGVyIGFzIGEgZnJhZ21lbnQNCj4gaWRlbnRpZmllcg0K PiA+PiBzeW50YXguIFRoaXMgd291bGQgcmVxdWlyZSBhIGJpdCBvZiBlZGl0b3JpYWwgd29yay4N Cj4gPj4NCj4gPj4NCj4gPj4gVGhvdWdodHM/IEZXSVcsIG15IC4wMiBpcyB0aGF0ICMyIHNlZW1z IGVtaW5lbnRseSByZWFzb25hYmxlLg0KPiA+DQo+ID4gIzEgJiAjMg0KPiA+IFRoZXJlIHdhcyBz b21lIGNvbmNlcm4gdGhhdCBtYWtpbmcgSlNPTiBwb2ludGVyIFRIRSBmcmFnbWVudCBpZCBmb3IN Cj4gYXBwbGljYXRpb24vanNvbiBwcmV2ZW50ZWQgbW9yZSBzb3BoaXN0aWNhdGVkIHN0dWZmIGxh dGVyLiBIb3dldmVyLCBhDQo+IEpTT04gcG9pbnRlciBjYW4gb25seSBzdGFydCB3aXRoICIvIiBz byB0aGVyZSBzaG91bGQgYmUgcm9vbSB0byBhZGQNCj4gc2VtYW50aWNzIHRvIG90aGVyIGZyYWdt ZW50cyBsYXRlci4NCj4gDQo+IEdvb2QgcG9pbnQsIGV4Y2VwdCBmb3IgdGhlICJlbXB0eSBwb2lu dGVyIiBjYXNlLi4uDQo+IA0KPiBNYXkgSSBhc2sgYWJvdXQgd2hhdCB1c2UgY2FzZSB5b3UgYXJl IGNvbnNpZGVyaW5nPw0KDQoNCk5vIGNydWNpYWwgdXNlIGNhc2VzIHlldC4gUGlja2luZyB0aGUg cmlnaHQga2V5IGZyb20gYSBKU09OIFdlYiBLZXkgdmFsdWUgaXMgYSBwb3NzaWJsZSB1c2UgW2Ry YWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXldLg0KDQoNCj4gR2l2ZW4gdGhlIGZhY3QgdGhhdCBK U09OLVBvaW50ZXIgaXMgYmxlZWRpbmcgZWRnZSBhbmQgZXNjYXBpbmcgcmVtYWlucw0KPiB0byBi ZSB1Z2x5IEknbSByZWFsbHkgcmVsdWN0YW50IHRvIGJha2UgdGhhdCBpbnRvIHRoZQ0KPiAiYXBw bGljYXRpb24vanNvbiINCj4gbWVkaWEgdHlwZSB1bnRpbCBpdCdzIGNsZWFyIHdoeS4NCg0KDQpB IGhhc3NsZSB3aXRoICMyIGlzIHRoYXQgbW9zdC9tYW55IEpTT04gZm9ybWF0cyB1c2UgYXBwbGlj YXRpb24vanNvbiBldmVuIHRob3VnaCBkZWZpbmluZyBhIG1vcmUgc3BlY2lmaWMgbWVkaWEgdHlw ZSBtaWdodCBiZSBiZXR0ZXIuIElmIGFueSBvZiB0aG9zZSB3YW50IHRvIHVzZSBKU09OIHBvaW50 ZXIgZm9yIHRoZWlyIFVSSXMgJiBkb2N1bWVudHMgKG9yIHRoZXkganVzdCBnbyBhaGVhZCBhbmQg dXNlIGl0KSBpdCBhbHJlYWR5IHN0YXJ0cyBwb2xsdXRpbmcgYW55IGZ1dHVyZSBvZmZpY2lhbCBm cmFnbWVudCBmb3JtYXQuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From julian.reschke@gmx.de Tue Jul 3 01:07:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A4821F8790 for ; Tue, 3 Jul 2012 01:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.503 X-Spam-Level: X-Spam-Status: No, score=-105.503 tagged_above=-999 required=5 tests=[AWL=-2.904, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cIPmiBWh9Ph for ; Tue, 3 Jul 2012 01:07:31 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id CA22F21F875E for ; Tue, 3 Jul 2012 01:07:30 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 08:07:37 -0000 Received: from p5DD95BE7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.91.231] by mail.gmx.net (mp031) with SMTP; 03 Jul 2012 10:07:37 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/PRO8wfL/PDCzWKMlhOdGiIJVloN1V+rqIz15bEi Y7n+6XzuM3Gel4 Message-ID: <4FF2A847.7090108@gmx.de> Date: Tue, 03 Jul 2012 10:07:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Nottingham References: <2818721F-C276-42D6-9BE5-193A13521FF4@mnot.net> <4FF2A298.5030601@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] #10: json-pointer fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 08:07:32 -0000 On 2012-07-03 09:55, Mark Nottingham wrote: > One other option -- we can decouple the decision and add json-pointer as a fragid syntax for application/json later. > > Cheers, > ... Of course. My main concern is about doing it as a "side effect" instead of clearly updating RFC 4627. Best regards, Julian From julian.reschke@gmx.de Tue Jul 3 01:17:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26A021F87C9 for ; Tue, 3 Jul 2012 01:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[AWL=-2.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMrJK0pzXBc7 for ; Tue, 3 Jul 2012 01:17:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7CD2921F86EF for ; Tue, 3 Jul 2012 01:17:16 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 08:17:22 -0000 Received: from p5DD95BE7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.91.231] by mail.gmx.net (mp030) with SMTP; 03 Jul 2012 10:17:22 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18jjHUTGfkjrC9/6d889sjLsbA+JClDusbWiCJArC R3VNKEkJuFLWxY Message-ID: <4FF2AA8F.3000203@gmx.de> Date: Tue, 03 Jul 2012 10:17:19 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <2818721F-C276-42D6-9BE5-193A13521FF4@mnot.net> <255B9BB34FB7D647A506DC292726F6E114F7600A7B@WSMSG3153V.srv.dir.telstra.com> <4FF2A36B.3030101@gmx.de> <255B9BB34FB7D647A506DC292726F6E114F7600AA5@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F7600AA5@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] #10: json-pointer fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 08:17:24 -0000 On 2012-07-03 10:06, Manger, James H wrote: >>>> >>>> >>>> This is actually about pointer; there isn't any reference to >> fragment >>>> identifers in json-patch any more. >>>> >>>> I think there are three ways we could go here: >>>> >>>> 1) Make json-pointer the fragment identifier syntax for >>>> application/json. This would require updating the media type >>>> registration. >>>> >>>> 2) Explain how json-pointer could be made the fragment identifier >>>> syntax for *your* media type, upon specification. This would require >> a >>>> small amount of editorial work. >>>> >>>> 3) Remove any reference to use of json-pointer as a fragment >> identifier >>>> syntax. This would require a bit of editorial work. >>>> >>>> >>>> Thoughts? FWIW, my .02 is that #2 seems eminently reasonable. >>> >>> #1 & #2 >>> There was some concern that making JSON pointer THE fragment id for >> application/json prevented more sophisticated stuff later. However, a >> JSON pointer can only start with "/" so there should be room to add >> semantics to other fragments later. >> >> Good point, except for the "empty pointer" case... >> >> May I ask about what use case you are considering? > > > No crucial use cases yet. Picking the right key from a JSON Web Key value is a possible use [draft-ietf-jose-json-web-key]. It seems that you then would have to rely on array indices, right? > ... Best regards, Julian From James.H.Manger@team.telstra.com Tue Jul 3 01:56:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA6B21F87C8 for ; Tue, 3 Jul 2012 01:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6Eg-rr9lDm3 for ; Tue, 3 Jul 2012 01:56:27 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6844A21F87D5 for ; Tue, 3 Jul 2012 01:56:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,515,1336312800"; d="scan'208";a="80682951" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 03 Jul 2012 18:56:22 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6760"; a="73684372" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbvi.tcif.telstra.com.au with ESMTP; 03 Jul 2012 18:56:21 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Tue, 3 Jul 2012 18:56:20 +1000 From: "Manger, James H" To: "apps-discuss@ietf.org" Date: Tue, 3 Jul 2012 18:56:19 +1000 Thread-Topic: [apps-discuss] #10: json-pointer fragment identifiers Thread-Index: Ac1Y+bag86SBjaPHQzin3DRYoC09Dg== Message-ID: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [apps-discuss] #10: json-pointer fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 08:56:28 -0000 Pj4gUGlja2luZyB0aGUgcmlnaHQga2V5IGZyb20gYSBKU09OIFdlYiBLZXkgdmFsdWUgaXMgYSBw b3NzaWJsZSB1c2UgW2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXldLg0KDQo+IEl0IHNlZW1z IHRoYXQgeW91IHRoZW4gd291bGQgaGF2ZSB0byByZWx5IG9uIGFycmF5IGluZGljZXMsIHJpZ2h0 Pw0KDQpZZXMsIHdpdGggdGhlIGN1cnJlbnQgSldLIHN5bnRheC4gaHR0cDovL2V4YW1wbGUub3Jn L2ppbS5qc29uIy9rZXlzLzEgdG8gcGljayB0aGUgMm5kIGtleS4NCg0KLS0NCkphbWVzIE1hbmdl cg0K From julian.reschke@gmx.de Tue Jul 3 02:19:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53C421F86B1 for ; Tue, 3 Jul 2012 02:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.302 X-Spam-Level: X-Spam-Status: No, score=-105.302 tagged_above=-999 required=5 tests=[AWL=-2.703, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPASZGs6BsPB for ; Tue, 3 Jul 2012 02:19:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7B9B021F8592 for ; Tue, 3 Jul 2012 02:19:04 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 09:19:10 -0000 Received: from p5DD95BE7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.91.231] by mail.gmx.net (mp016) with SMTP; 03 Jul 2012 11:19:10 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19dYfJYxUZdyQh5rO1CDtDv2TOfopYV/CETnHaAnk fJtEuGBMUoVJtx Message-ID: <4FF2B90B.3050408@gmx.de> Date: Tue, 03 Jul 2012 11:19:07 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Manger, James H" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] #10: json-pointer fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 09:19:06 -0000 On 2012-07-03 10:56, Manger, James H wrote: >>> Picking the right key from a JSON Web Key value is a possible use [draft-ietf-jose-json-web-key]. > >> It seems that you then would have to rely on array indices, right? > > Yes, with the current JWK syntax. http://example.org/jim.json#/keys/1 to pick the 2nd key. > ... And relying on a specific order is not a problem? (Asking because this seems to be a nice example for a case where a more expressive pointer syntax could be useful). Best regards, Julian From michiel@unhosted.org Tue Jul 3 02:44:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22E521F873D for ; Tue, 3 Jul 2012 02:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0P2ZsFL8TsP for ; Tue, 3 Jul 2012 02:44:04 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 96B8421F87DC for ; Tue, 3 Jul 2012 02:44:04 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so9266240pbc.31 for ; Tue, 03 Jul 2012 02:44:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=S4/JspNfiUR1EZWN+Oyqp/akYbi/5bdQablz+5Q4tSA=; b=fr1eCQn4nkYMSQcTJnmlfsQbbnMwdvFVCE+sAuZp6wzNSO/ZFnP2HXrIT5HzK9EfSq 25nyr5YAsUkfa3Vx4o5ih9BEPbNCGeRQlllpzvLkv1sI9QUlBtOfrA5PY0uRHyh2Sl8Q Twu1uzlZDc6FU/AeX0cb7VzVtUbuw2aMt0N+emLIxX8hgHnP+ka9s3pqoA+AWColwuLW cccIuPa705gcYGimHEQuLOsc31FFA/QQDpZeXfgX0nNmldOTEosCdNDO2KuZehxiEEsE Ii74CD3iYUOGJ1gThz5QYxWqcjV0GXKOYfvHRoBrUOZTIZtqUCnU2cMR1WXcIwHRwD87 If1w== MIME-Version: 1.0 Received: by 10.68.223.34 with SMTP id qr2mr5646439pbc.10.1341308651974; Tue, 03 Jul 2012 02:44:11 -0700 (PDT) Received: by 10.142.10.4 with HTTP; Tue, 3 Jul 2012 02:44:11 -0700 (PDT) X-Originating-IP: [195.251.28.194] In-Reply-To: References: Date: Tue, 3 Jul 2012 12:44:11 +0300 Message-ID: From: Michiel de Jong To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnhJVJzzwwy5aGBSkowFxLwOxE/5Sk1PYHrJbERHwwspOZD/VUHa2XbAXoswDEoeQnNGHV4 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 09:44:06 -0000 A brilliant and convincing post, IMO! My remarks, fwiw: - it should be clear to implementers that they are allowed to use http 3** responses to redirect to some other place where running the actual webfinger service might be easier to organize. it should be clear to clients that they should follow such redirects. afaik, the ability to redirect to some other place was an argument for using host-meta as a first hop: first discover where the host-meta server is, and then do the actual work there. - changing existing implementations costs money and goodwill in the short term (but so do prolonged discussions, so a change like this could actually improve adoption if it's done right). - the reason host-meta and also simple-web-discovery use URIs to describe resources is that the architecture of the web says that if you point to something of any importance, then the pointing should be done with a URI. In this case i think it's fair to say we are not really pointing to a resource, but rather just passing a string as a query parameter. So i'm all in favour of ?user=user@host or ?acct=user@host, i'm just saying that i think that was the reasoning at the time. - if we give various applications all their own well-known URI, then there might at some point a need to get an aggregated list of which things are discoverable. Aggregated discovery has been discussed in a separate thread already, and i think making it optional is good. Otherwise, unless i overlooked some other point, I think it's hard to deny that registering a well-known URI instead of a full URI scheme would basically solve everything instantly and be preferable. My 2ct, -- Michiel de Jong http://unhosted.org/ From duerst@it.aoyama.ac.jp Tue Jul 3 03:36:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08A621F8808 for ; Tue, 3 Jul 2012 03:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.532 X-Spam-Level: X-Spam-Status: No, score=-99.532 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBdQ4r6UWW1n for ; Tue, 3 Jul 2012 03:36:34 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 597C521F8807 for ; Tue, 3 Jul 2012 03:36:33 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q63AaUSu029336 for ; Tue, 3 Jul 2012 19:36:30 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 19ac_1d90_f35a3af2_c4fa_11e1_a450_001d096c5782; Tue, 03 Jul 2012 19:36:29 +0900 Received: from [IPv6:::1] ([133.2.210.1]:34271) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 3 Jul 2012 19:36:34 +0900 Message-ID: <4FF2CB2A.5090004@it.aoyama.ac.jp> Date: Tue, 03 Jul 2012 19:36:26 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <2818721F-C276-42D6-9BE5-193A13521FF4@mnot.net> <4FF2A298.5030601@gmx.de> <4FF2A847.7090108@gmx.de> In-Reply-To: <4FF2A847.7090108@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] #10: json-pointer fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 10:36:34 -0000 On 2012/07/03 17:07, Julian Reschke wrote: > On 2012-07-03 09:55, Mark Nottingham wrote: >> One other option -- we can decouple the decision and add json-pointer >> as a fragid syntax for application/json later. > Of course. My main concern is about doing it as a "side effect" instead > of clearly updating RFC 4627. Of course the draft would say "updates RFC 4627". Or is that not what you mean? If the escaping syntax is ugly, but we tried very hard and didn't find anything better, then the chance that somebody else will find something better is low. And "waiting for later" often means "waiting for never". So I think we should just go ahead and define it. Regards, Martin. From GK@ninebynine.org Tue Jul 3 04:04:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659F821F8800 for ; Tue, 3 Jul 2012 04:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.718 X-Spam-Level: X-Spam-Status: No, score=-6.718 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNSIvKEMoBt2 for ; Tue, 3 Jul 2012 04:04:37 -0700 (PDT) Received: from relay3.mail.ox.ac.uk (relay3.mail.ox.ac.uk [163.1.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 682CD21F8639 for ; Tue, 3 Jul 2012 04:04:37 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay3.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1Sm0uQ-00048e-Cn; Tue, 03 Jul 2012 12:04:42 +0100 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Sm0uQ-0004eu-63; Tue, 03 Jul 2012 12:04:42 +0100 Message-ID: <4FF2B820.5040301@ninebynine.org> Date: Tue, 03 Jul 2012 10:15:12 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <4FF18B9C.4010102@ninebynine.org> <4FF1C243.2000008@stpeter.im> In-Reply-To: <4FF1C243.2000008@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 11:04:38 -0000 On 02/07/2012 16:46, Peter Saint-Andre wrote: >> > == Section 4.4 == >> > >> > My understanding is that an acct: URI is intended to be dereferenced >> > using the WebFinger protocol. > My understanding is that the WebFinger protocol defines one way for > 'acct' URIs to be dereferenced, but that other protocols might also > define such ways in the future. If I am wrong about that and 'acct' is > tightly coupled with WebFinger, then we need to make that clear in the > 'acct' URI spec. If it's not the case, then I think a key reason for acct: being useful as a distinct URI scheme is scuppered. #g -- From GK-lists@ninebynine.org Tue Jul 3 04:04:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D031F21F8639 for ; Tue, 3 Jul 2012 04:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xg-sir5GTJRL for ; Tue, 3 Jul 2012 04:04:37 -0700 (PDT) Received: from relay3.mail.ox.ac.uk (relay3.mail.ox.ac.uk [163.1.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 681C821F859A for ; Tue, 3 Jul 2012 04:04:37 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay3.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1Sm0uR-00048n-BH; Tue, 03 Jul 2012 12:04:43 +0100 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Sm0uR-0004f0-4Q; Tue, 03 Jul 2012 12:04:43 +0100 Message-ID: <4FF2BABF.8090003@ninebynine.org> Date: Tue, 03 Jul 2012 10:26:23 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Mark Nottingham References: <20120703004409.1599.57166.idtracker@ietfa.amsl.com> <5976E21A-81BC-4576-8609-B2C04C218C10@mnot.net> <4FF24F6D.7050807@berkeley.edu> <158A57BD-6421-4587-B90A-F8E1C98FFC5B@mnot.net> In-Reply-To: <158A57BD-6421-4587-B90A-F8E1C98FFC5B@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-nottingham-link-template-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 11:04:39 -0000 On 03/07/2012 02:58, Mark Nottingham wrote: > > On 03/07/2012, at 11:48 AM, Erik Wilde wrote: > >> hello mark. >> >> On 2012-07-02 17:47 , Mark Nottingham wrote: >>> FYI; a few people have asked me about this recently, and URI Template is final, so it seems like a good time. >>> Begin forwarded message: >>>> URL: http://www.ietf.org/internet-drafts/draft-nottingham-link-template-00.txt >> >> this looks like a very useful initiative! however, for more complex templates, it may be too limiting to only allow variables from "one namespace" (i.e., from the one URI prefix you currently allow). for example, we are looking into search services, and it is actually highly likely that different variables in the templates will come from different namespaces, for example for basic search, paging, spatial aspects, and facet information. i don't have an easy answer how to best do it (and think the current design is actually quite elegant), but from the perspective of more complex templates, it seems to me that supporting multiple namespaces would be a requirement. > > > Yep, agreed. The syntax of the header is somewhat limiting. Possible approaches to this that pop into mind: > > * Define a prefix for variable to uri mappings; e.g., > _foo="http://example.org/vars/foo" > ... but that potentially conflicts with other future parameters, and I'm not a big fan of this approach elsewhere > > * Define another header, e.g., > Link-Template-Vars: foo="http://example.org/vars/foo" > ...which is OK but it'll get awfully verbose (maybe defining a base and some fallback rules? could get complex) > > and so on. > > Intuitively, I think we need a simple solution that addresses the common case (all vars in one namespace) without much fuss/overhead, but enough flexibility to address the complex case. That might be a combination of a base URI and another header. > > I'd love feedback on this. The use-cases I have for this don't depend on the variable names being URIs. My own take is that it was up to the defining application/API to explain how the variable names are related to known values, and then use the Link-template header to allow a service to describe how to map that information to a related URI. So I'd be happy to see this aspect of the spec dropped if it's likely to lead to complications (and delay). But, of course, others may have burning use-cases of which I'm unaware, so this is clearly just one voice among many of what is actually useful to define here. #g -- From gffletch@aol.com Tue Jul 3 07:11:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C99821F8823 for ; Tue, 3 Jul 2012 07:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.299, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWfqblEqpeg0 for ; Tue, 3 Jul 2012 07:11:51 -0700 (PDT) Received: from imr-ma04.mx.aol.com (imr-ma04.mx.aol.com [64.12.206.42]) by ietfa.amsl.com (Postfix) with ESMTP id E017521F8816 for ; Tue, 3 Jul 2012 07:11:50 -0700 (PDT) Received: from mtaout-ma06.r1000.mx.aol.com (mtaout-ma06.r1000.mx.aol.com [172.29.41.6]) by imr-ma04.mx.aol.com (8.14.1/8.14.1) with ESMTP id q63EBmS1030587; Tue, 3 Jul 2012 10:11:48 -0400 Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id BF90DE0000B1; Tue, 3 Jul 2012 10:11:47 -0400 (EDT) Message-ID: <4FF2FDA1.3020507@aol.com> Date: Tue, 03 Jul 2012 10:11:45 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: IETF Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1341324707; bh=XQjigaFiEvpGAKVoK+JeLs6YlbpjikS9oZA7UQQE2ss=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=Brf92Oq27q38vKo/k2j3MxD0vsJt7eoQGw5kE79WHR8Pj61B127UmUg6GIaTqJPtM tKqb6F9gmsflZVTRPCp9s5inHGD81UD22BrB+nfdKiXrxuIy6HblHwhWmdOHwT5G2J sPT0mpKFrxuRrPPs+QGnr2WOfZVVpOA6s/7Mn70U= X-AOL-SCOLL-SCORE: 0:2:409777920:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29064ff2fda33baf X-AOL-IP: 10.181.186.254 Cc: Mark Nottingham Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 14:11:52 -0000 +1 for supporting redirects From a pure deployment perspective, managing multiple .well-known/ endpoints can be difficult is the group that "owns" the web domain is substantially different/separated from the group that wants to put "files" in the .well-known directory. In addition, a single organization supporting multiple domains that all use the same "identifier" strings can also add complications. Not unsolvable, but it creates a more brittle deployment. Managing these endpoints as a set of fixed 3XX redirects is much simpler than having to deploy the actual functionality at the endpoint. Even easier (for my environment) is to only deploy one endpoint... but I get the rationale behind having multiple. Thanks, George On 7/3/12 5:44 AM, Michiel de Jong wrote: > - it should be clear to implementers that they are allowed to use http > 3** responses to redirect to some other place where running the actual > webfinger service might be easier to organize. it should be clear to > clients that they should follow such redirects. afaik, the ability to > redirect to some other place was an argument for using host-meta as a > first hop: first discover where the host-meta server is, and then do > the actual work there. From hallam@gmail.com Tue Jul 3 07:52:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B6111E8111 for ; Tue, 3 Jul 2012 07:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTDJF5y7mWyq for ; Tue, 3 Jul 2012 07:52:47 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 72F9F21F8631 for ; Tue, 3 Jul 2012 07:52:46 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so11489164obb.31 for ; Tue, 03 Jul 2012 07:52:54 -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=3xwvzGgo85Ttrw81f5krs4MsBk5v6HGgAY3oB0agqps=; b=nFJZ7ZWhR6gsSBH2hVt6vBPK0r0W7DyLOtGFleGFzR14aigQiI1cyYWSE/xgrjbZGJ vBQwkdMIQlQSH8Qbylh0XN1Tb3zWID88X8kzs4bg39rY8yfMLTS2hTYtcxDhuki/TQxM DiljtxFG8auR1enJH9mLsdW61WTthzGcd+KhfSMz1PHzg34Z5LjJdDUh5KmxxJIMcILq YKSCY8uRtmiE8IyTI+33FIbYb/Tfd2g3UdNtq4RYd7KS8FJxMXa5wGKeKQJPKPa6LF1v WdkHnobTwU34DL/m5pvcvLNlUR7CMhtMpkg4lCh9CxwCD+9lhyOxGFKoZso2D/UAa2Dk XL6w== MIME-Version: 1.0 Received: by 10.182.160.10 with SMTP id xg10mr13009096obb.76.1341327174173; Tue, 03 Jul 2012 07:52:54 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Tue, 3 Jul 2012 07:52:54 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Jul 2012 10:52:54 -0400 Message-ID: From: Phillip Hallam-Baker To: Michiel de Jong Content-Type: text/plain; charset=ISO-8859-1 Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 14:52:50 -0000 I am not clear what the proposal is that is being referred to though. There is a very clear rationale for having an acct: scheme as far as I am concerned that is independent of WebFinger. Accounts are a specific type of resource that we refer to repeatedly in protocols, a URI is appropriate. Web Finger looks to me like something that is eminently suitable for implementation as a .well-known lookup returning some chunk of data in response. The place where I would see acct: being used in WebFinger is actually more the data structures being returned. So for example if I am looking up my friends profile, I would probably want to see their battle.net accounts listed there along with their other stuff. WebFinger would still be a way to resolve acct: URIs, but only one way and the http: transport might only be one option. If I click on an acct: link in a browser I would have a range of possible options: * Grab the public WebFinger data * Grab the profile data exposed to me by virtue of me being a friend. * Attempt to connect on chat * Attempt to send an email I would expect there to be a default action but that choice is something the user would probably make. The place I would be using acct: identifiers is in the authentication and authorization layer. And no, I don't get the XRD thing either except that it seems that they painted the bus a color other people liked. On Tue, Jul 3, 2012 at 5:44 AM, Michiel de Jong wrote: > A brilliant and convincing post, IMO! My remarks, fwiw: > > - it should be clear to implementers that they are allowed to use http > 3** responses to redirect to some other place where running the actual > webfinger service might be easier to organize. it should be clear to > clients that they should follow such redirects. afaik, the ability to > redirect to some other place was an argument for using host-meta as a > first hop: first discover where the host-meta server is, and then do > the actual work there. > > - changing existing implementations costs money and goodwill in the > short term (but so do prolonged discussions, so a change like this > could actually improve adoption if it's done right). > > - the reason host-meta and also simple-web-discovery use URIs to > describe resources is that the architecture of the web says that if > you point to something of any importance, then the pointing should be > done with a URI. In this case i think it's fair to say we are not > really pointing to a resource, but rather just passing a string as a > query parameter. So i'm all in favour of ?user=user@host or > ?acct=user@host, i'm just saying that i think that was the reasoning > at the time. > > - if we give various applications all their own well-known URI, then > there might at some point a need to get an aggregated list of which > things are discoverable. Aggregated discovery has been discussed in a > separate thread already, and i think making it optional is good. > > Otherwise, unless i overlooked some other point, I think it's hard to > deny that registering a well-known URI instead of a full URI scheme > would basically solve everything instantly and be preferable. > > > My 2ct, > > > -- > Michiel de Jong http://unhosted.org/ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Website: http://hallambaker.com/ From henry.story@bblfish.net Mon Jul 2 14:41:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B49421F850B for ; Mon, 2 Jul 2012 14:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7GALoR0syI2 for ; Mon, 2 Jul 2012 14:41:50 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 56D3821F85C2 for ; Mon, 2 Jul 2012 14:41:50 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so2948260wib.13 for ; Mon, 02 Jul 2012 14:41:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=8E6S9x0JTySIE/qV/MZ6mpD6gpp4kiAX0z2PQ3+uo4I=; b=DoPRGH3Ct+hhLPjH9zuo8np6EyS9FvvlVCl0FCNmomfYa2IdqFK5TZ8H4dI3TXa5J/ who/1ysXvxHKa/4IbYdZMOxyVXJA3mEEx3ivTWkks80+xN3E8uBVQZVamR9zLjNmwnFI DfVdD2ezjU1MH/utHLg+NLzRl0W6fzchQk+u/l4HJHk+BS7voRDzE03lLsnbV7ZmbMt0 txyaSZTg+F4SuVjT3QW/SdZ+lcA/YBWjA0O7++RwNeNtnM0KYZvvYsvErN3cHSjPQhxX njetwwGTswgi0cspUPVg7WsfNsKIdcLe74LGqfGUVmhm5mw9JzritaIQ+OyLB1Hm5NVS hEpw== Received: by 10.180.97.33 with SMTP id dx1mr26260662wib.18.1341265315104; Mon, 02 Jul 2012 14:41:55 -0700 (PDT) Received: from [192.168.1.10] (AAubervilliers-651-1-127-44.w86-198.abo.wanadoo.fr. [86.198.94.44]) by mx.google.com with ESMTPS id n6sm48926727wie.7.2012.07.02.14.41.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jul 2012 14:41:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Henry Story In-Reply-To: Date: Mon, 2 Jul 2012 23:41:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <549FFD78-912F-475A-B49F-B309760E3562@bblfish.net> References: <4FF1D000.8020100@stpeter.im> <4E1F6AAD24975D4BA5B168042967394366572C13@TK5EX14MBXC283.redmond.corp.microsoft.com> <1341257402-sup-9426@heahdk.net> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmqDml4bXDuhCsiARmpPZ3+H2sO7CeekGrCMubEECS36wlo0eQSVP+Th8vlMrBrbiYO+MOR X-Mailman-Approved-At: Tue, 03 Jul 2012 08:07:34 -0700 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jul 2012 21:41:52 -0000 On 2 Jul 2012, at 23:16, Phillip Hallam-Baker wrote: > I think it will go a long way to prevent future nonsense like OpenID > where we were told that users wanted to use a URL as their account > reference (not!) and then that we needed an alias scheme (XRI) to make > the URLs palatable. >=20 > Representing account identifiers as URIs in the protocol makes sense. > Expecting users to type them in is stupid on roller-skates. With WebID over TLS the user does not need to type his identifier, just = a point and click will do, as shown clearly in the video on http://webid.info/ WebID can also work with acct: url schemes, as a few people on the WebID = community group have shown. http://www.w3.org/community/webid/ IT's just that when you don't need to type the account URL, then there = is no issue anymore=20 passing in a URL for the account home page directly into the X509 = certificate, which can be however complicated you wish it to be - since it will never get = typed.=20 The spec is on http://webid.info/spec/ and we have a nice implementation = at=20 http://my-profile.eu/ . Looking forward to many more implementations... Henry >=20 >=20 >=20 > On Mon, Jul 2, 2012 at 4:36 PM, elf Pavlik > wrote: >> Excerpts from Bob Wyman's message of 2012-07-02 17:52:47 +0000: >>> I would appreciate it greatly if someone could suggest a number of = useful >>> use-cases for acct: without WebFinger. >>>=20 >>> What use is independence if that independence provides no utility? >> >> i wonder if webfinger could specify handling acct: for HTTP, but = other protocols?(SIP, XMPP, PSYC[1], ...) could maybe also use generic = acct: >> with developments like WebID[2] maybe i could use same = ssl cert just with acct: in SAN and authenticate on this account to = various services... >> >>=20 >> ~elf-pavlik~ >>=20 >> [1] http://psyced.org/ >> [2] http://webid.info/ >>=20 >>=20 >>> bob wyman >>>=20 >>> On Mon, Jul 2, 2012 at 1:14 PM, Mike Jones = wrote: >>>>=20 >>>> I would like to add support to submitting your acct: draft as a = working >>>> group document. >>>>=20 >>>> While WebFinger will have a normative dependency on it, it's = actually >>>> independent of WebFinger and so can and should be considered = separately. >>>>=20 >>>> Best wishes, >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] >>>> On Behalf Of Peter Saint-Andre >>>> Sent: Monday, July 02, 2012 9:45 AM >>>> To: Murray S. Kucherawy >>>> Cc: apps-discuss@ietf.org >>>> Subject: Re: [apps-discuss] The webfinger and the acct: scheme = documents >>>>=20 >>>> On 7/2/12 10:29 AM, Murray S. Kucherawy wrote: >>>>=20 >>>>> The authors of draft-jones-appsawg-webfinger are invited to submit >>>>> draft-ietf-appsawg-webfinger-00, and we'll approve it. >>>>>=20 >>>>> Now, a question: The "acct:" scheme URI work is an offshoot of >>>>> webfinger. PSA has recently posted a document that separates that >>>>> work out. So what is working group consensus: Should these be >>>>> processed as two documents in parallel (and should APPSAWG take = them >>>>> on), or should they be processed as a single document? >>>>=20 >>>> Clarifying question: since the chairs have invited the authors of = the >>>> WebFinger I-D to submit it as a WG item, I assume that the question = "should >>>> APPSAWG take them on" does not apply to the WebFinger I-D, but only = to the >>>> 'acct' URI I-D. >>>>=20 >>>> FWIW, I authored a separate spec for the 'acct' URI scheme because = I >>>> understood from the list discussion that the 'acct' URI *could* be = used by >>>> protocols other than WebFinger. If that is true, then it seems to = me >>>> preferable to work on the WebFinger protocol and the 'acct' URI = scheme as >>>> separate documents. If that is false, then I think they belong in = the same >>>> specification. Personally I'm unclear as to whether the 'acct' URI = scheme >>>> is tightly coupled to WebFinger protocol, so I think we need to = figure that >>>> out first before deciding whether to proceed with two documents or = one. >>>>=20 >>>> Peter >>>>=20 >>>> -- >>>> Peter Saint-Andre >>>> https://stpeter.im/ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>=20 >>>>=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 >=20 >=20 > --=20 > Website: http://hallambaker.com/ Social Web Architect http://bblfish.net/ From barryleiba.mailing.lists@gmail.com Tue Jul 3 08:19:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D0D11E8156 for ; Tue, 3 Jul 2012 08:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.788 X-Spam-Level: X-Spam-Status: No, score=-102.788 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqlPTBFaCGWM for ; Tue, 3 Jul 2012 08:19:06 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 75CEC11E8111 for ; Tue, 3 Jul 2012 08:19:06 -0700 (PDT) Received: by eekd4 with SMTP id d4so2772061eek.31 for ; Tue, 03 Jul 2012 08:19:14 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LeGna87KD5BTuSbBX2NKQbY5/xOLRnES79YAbKOrTss=; b=q+UCDR9tWqDcewxaoS9rtDBWPERpne21RYTNuNZFC3FJJSZ+x+X+wiMRMN2R4bJ7PG ImPRlRmzURz//dUkFMT30y/j2RZeCoCSmlYc1yUYDq05bi6e/ko4W0qNdaaMGAnzbbJK qN1rnlK2PIfOnMB7nXvY3DqqQFoymSJZ+9LZNEmBnXBoJiypCLOlhM2OEVlEs9bc6yR8 LyFEXb577DmNyle2C7TEfLozHlTLB8apH9/EL6oF5QzAosAioySv1oEKPz+GlN2V9eLM Ql/F3fwPHTF+VhwA35m8rvR8YWA9EKVLLDslbRKsufkk+p6l0U40leRnA5bXFcY12ymt 8yaw== MIME-Version: 1.0 Received: by 10.152.136.18 with SMTP id pw18mr17882237lab.17.1341328753773; Tue, 03 Jul 2012 08:19:13 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Tue, 3 Jul 2012 08:19:13 -0700 (PDT) In-Reply-To: <4FF1D000.8020100@stpeter.im> References: <4FF1D000.8020100@stpeter.im> Date: Tue, 3 Jul 2012 11:19:13 -0400 X-Google-Sender-Auth: aX68whPOjMLLknPAodYWQi38pes Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The webfinger and the acct: scheme documents X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 15:19:15 -0000 > FWIW, I authored a separate spec for the 'acct' URI scheme because I > understood from the list discussion that the 'acct' URI *could* be used > by protocols other than WebFinger. If that is true, then it seems to me > preferable to work on the WebFinger protocol and the 'acct' URI scheme > as separate documents. If that is false, then I think they belong in the > same specification. Personally I'm unclear as to whether the 'acct' URI > scheme is tightly coupled to WebFinger protocol, so I think we need to > figure that out first before deciding whether to proceed with two > documents or one. I think it's important to keep the "acct" definition, if we retain it, as a separate document. As Nat points out, it's useful for referencing the URI scheme separately. We've had problems in the past where something that we thought to be part of a protocol wound up, a few years later, as having other uses. It meant that other protocol had a normative reference to a protocol they had nothing to do with, only for the purpose of referring to that one useful feature. Separating it into its own document has also focused discussion on issues specific to the URI scheme, rather than diluting things by putting it in as a short section in another document. As the AD who will be responsible for these documents, I strongly urge y'all to leave the "acct" specification as a separate document. Barry From stpeter@stpeter.im Tue Jul 3 08:19:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D02511E8154 for ; Tue, 3 Jul 2012 08:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI-A+zhZ8s3Z for ; Tue, 3 Jul 2012 08:19:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 81A7D11E8085 for ; Tue, 3 Jul 2012 08:19:21 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8E2484005A; Tue, 3 Jul 2012 09:37:45 -0600 (MDT) Message-ID: <4FF30D80.6010208@stpeter.im> Date: Tue, 03 Jul 2012 09:19:28 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Graham Klyne References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> <4FF18B9C.4010102@ninebynine.org> <4FF1C243.2000008@stpeter.im> <4FF2B820.5040301@ninebynine.org> In-Reply-To: <4FF2B820.5040301@ninebynine.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 15:19:22 -0000 On 7/3/12 3:15 AM, Graham Klyne wrote: > On 02/07/2012 16:46, Peter Saint-Andre wrote: >>> > == Section 4.4 == >>> > >>> > My understanding is that an acct: URI is intended to be dereferenced >>> > using the WebFinger protocol. >> My understanding is that the WebFinger protocol defines one way for >> 'acct' URIs to be dereferenced, but that other protocols might also >> define such ways in the future. If I am wrong about that and 'acct' is >> tightly coupled with WebFinger, then we need to make that clear in the >> 'acct' URI spec. > > If it's not the case, then I think a key reason for acct: being useful > as a distinct URI scheme is scuppered. Precisely why I asked the question. :) Peter -- Peter Saint-Andre https://stpeter.im/ From ve7jtb@ve7jtb.com Tue Jul 3 08:24:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19C121F85E5 for ; Tue, 3 Jul 2012 08:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9baUopXksYQ for ; Tue, 3 Jul 2012 08:24:22 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A863421F873D for ; Tue, 3 Jul 2012 08:24:21 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5973450ggn.31 for ; Tue, 03 Jul 2012 08:24:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=NnJPU7hRercS2zvebxFFCWPQ8tWXgTni38XWNyUZCrs=; b=NEOvWEXfG2mxxmowstVG36ZzQ5z632V8f1M9xjge/0elbOhuk2h//As6LjhGx6K6PA e6QZrfI7YZevY6oDRv4v9anAjBmWM+LINKTHMVhtF71CSz+Au6QynNUt0FqS7T1nfyPa Zb6XEYkbeKYOBgrLaAh46ONCEVxpHUUyOskpERTacBWVaBjdt/7sGu4cQA4dVGrw47Yd rcPaoLi8uk6XAACEO18VowBp5DXMremPk7+H7X7rCkhkGz04wQ3moa/MgXmKvwh27TQ3 ZyrJNKFC2kvWYrb8YtRp6gC3ct7HaPYioBk9KX8VPehspDOspYwZkWBK4gP+fS5fgOjk Z7uA== Received: by 10.100.238.19 with SMTP id l19mr6282565anh.31.1341329069241; Tue, 03 Jul 2012 08:24:29 -0700 (PDT) Received: from [192.168.1.211] (190-20-40-193.baf.movistar.cl. [190.20.40.193]) by mx.google.com with ESMTPS id k67sm32314110yhj.18.2012.07.03.08.24.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jul 2012 08:24:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_A90B337A-B47B-4D5C-9FFA-159577094ADE"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Tue, 3 Jul 2012 11:24:19 -0400 Message-Id: <1A87B9DE-ECEC-4F07-8734-131D4BB564EB@ve7jtb.com> References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mark Nottingham X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlU6zKAYrzscEaWuRXYtX65wb3bB69puo11XKfR4iAuWIXYki/2yhrVY3yPqr+a0SkbRMJ3 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 15:24:23 -0000 --Apple-Mail=_A90B337A-B47B-4D5C-9FFA-159577094ADE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We took SWD form openID Connect to the OAuth WG. The decision was made to send it to Apps as it was seen as similar to = WF. Ironically a number of the XRD authors Nat Sakimura, myself and others = were involved in SWD and not WF. While some of us argued for SWDs simpler features and independence from = any particular URI scheme, the consensus of the WG has been to = basically stick with WF. Overloading host-meta to take a parameter in WF was one feature that was = added to WF to reduce the number of calls. By building on host-metta there is a perceived requirement that the = template pass a URI and hence one of the requirements to register acct: Now that WF has been accepted by the chairs as a WG draft it gets harder = to make breaking changes. WF was improved by the discussions. It might have been improved more = if more people had engaged in the conversation earlier. Though sometimes it takes something moving to completion before people = start to pay attention. We have a relatively short deadline for completing openID connect, and = still must make a decision on if we keep SWD or move to WF if there is = sufficient stability and consensus around it. Regards John B. On 2012-07-03, at 3:26 AM, Mark Nottingham wrote: >=20 > On 03/07/2012, at 5:24 PM, Mike Jones wrote: >=20 >> You've essentially described Simple Web Discovery! It avoids the = complications introduced by host-meta exactly by using its own = .well-known value. >=20 > This makes me happy. :) >=20 > So, what's the current state of SWF vs. webfinger? I thought I'd see = an announcement go by that webfinger was going to become a WG draft. >=20 > Sorry for not keeping up, but I can only digest so much e-mail at = once... >=20 > Thanks, >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_A90B337A-B47B-4D5C-9FFA-159577094ADE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw MzE1MjQyMFowIwYJKoZIhvcNAQkEMRYEFL/3t99QCZXS+9xAzgg5b8/2G8NgMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AC2UP9dokfySwm1dALBSWjMnV0/zSduqLG/ePLddSQ8ss/cZv0UnGs8XilX8jo1N+0rkeEQ2YDTJ XJM/3z/Q3QKB+AIv/eOD4SgOjgMGfWP+FTBV+XXm8w+hqtcbPlaLg4YRoqC52HGzoYK398VAHus5 y2g1hUJMdTV2KjvEbpF6PiOZFagB3mfixrHiEsGQlCbqYQ98Ru4weyRXJBaTPldrF/5QjDt6kvJ1 LKJEaZmIYTSyy+Msm0QvxrWAG0YTDQ+gQSjicXngoLk6N8/wuLcffHGtdrJCDYW6nWP0D34Lldh0 ohLsj2exYmBpnUvMo30Hrtdslp8PazRWgjBdOgUAAAAAAAA= --Apple-Mail=_A90B337A-B47B-4D5C-9FFA-159577094ADE-- From stpeter@stpeter.im Tue Jul 3 08:58:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E53E21F86F1 for ; Tue, 3 Jul 2012 08:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMmInP2cUHjk for ; Tue, 3 Jul 2012 08:58:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFDB21F86DD for ; Tue, 3 Jul 2012 08:58:42 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 47A434005A; Tue, 3 Jul 2012 10:17:02 -0600 (MDT) Message-ID: <4FF316B4.10002@stpeter.im> Date: Tue, 03 Jul 2012 09:58:44 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Nottingham References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 15:58:45 -0000 On 7/2/12 11:47 PM, Mark Nottingham wrote: > * First and foremost, why use host-meta? What value does adding this > extra step to the dance bring, beyond "We've defined it, therefore we > must use it?" > > As I think I've said many times before, the whole point of a > .well-known URI is to group like uses together, to avoid having a > "dictionary" resource that gets bloated with many application's > unrelated data, thereby overburdening clients with too much > information (especially when they're constrained, e.g., mobile). > > As such, host-meta is a spectacularly bad example of a well-known > URI. Defining a end-all-be-all well-known-URI kind of removes the > point of having a registry, after all... > > Instead, why not just define a NEW well-known URI for user data? That > has a more constrained scope, and saves one round trip (or more). > E.g., > > GET /.well-known/webfinger?user=bob%40example.com HTTP/1.0 Host: > example.com > > I.e., let webfinger define the URI template to use. Yes, some > implementations might want to come up with crazy URIs, but is that > really a problem we want to solve? > > Astute observers will notice that this approach removes the need for > an ACCT URI scheme (at least here). Mark, that seems like a reasonable approach. I have no strong attachment to 'acct' URIs, and removing one step in the dance makes some sense. In particular, I echo your question: is host-meta doing something special for us here that we can't do with a well-known URI for webfinger? Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jul 3 09:05:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAFB11E8179 for ; Tue, 3 Jul 2012 09:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xehsYZTvXsOT for ; Tue, 3 Jul 2012 09:05:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2A18411E8167 for ; Tue, 3 Jul 2012 09:05:23 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4F0DB4005A; Tue, 3 Jul 2012 10:23:47 -0600 (MDT) Message-ID: <4FF31849.6040504@stpeter.im> Date: Tue, 03 Jul 2012 10:05:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , IETF Apps Discuss Subject: [apps-discuss] the need for acct (was: Re: Looking at Webfinger) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 16:05:24 -0000 On 7/3/12 8:52 AM, Phillip Hallam-Baker wrote: > The place where I would see acct: being used in WebFinger is actually > more the data structures being returned. So for example if I am > looking up my friends profile, I would probably want to see their > battle.net accounts listed there along with their other stuff. > > WebFinger would still be a way to resolve acct: URIs, but only one way > and the http: transport might only be one option. > > If I click on an acct: link in a browser I would have a range of > possible options: > * Grab the public WebFinger data > * Grab the profile data exposed to me by virtue of me being a friend. > * Attempt to connect on chat Don't we have xmpp: for that? > * Attempt to send an email Don't we have mailto: for that? You're saying that acct: would be a general identifier and that applications could attempt many different kinds of interactions with that account, using specific protocols like SMTP or XMPP. But deciding whether to attempt such interactions would depend on knowing if the service provider actually offers email service, IM service, public profiles, microblogging, etc. Presumably that information could be discovered via WebFinger (for a particular account), but I wouldn't assume that one can send email to an account simply because an acct: URI exists. > I would expect there to be a default action but that choice is > something the user would probably make. It seems that the default action would be discovery. > The place I would be using acct: identifiers is in the authentication > and authorization layer. Describing those use cases more completely would help us decide whether we really need the 'acct' URI scheme. Peter -- Peter Saint-Andre https://stpeter.im/ From julian.reschke@gmx.de Tue Jul 3 09:17:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B4021F8566 for ; Tue, 3 Jul 2012 09:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.83 X-Spam-Level: X-Spam-Status: No, score=-104.83 tagged_above=-999 required=5 tests=[AWL=-2.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu93uzOkpfuq for ; Tue, 3 Jul 2012 09:17:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4B5EC21F853B for ; Tue, 3 Jul 2012 09:17:51 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 16:17:58 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp002) with SMTP; 03 Jul 2012 18:17:58 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19AcxRpDQ1A/6RVgSYuRYbhkv1Ae4yaFE8wZbp7qS OFnIzwedKoOKcK Message-ID: <4FF31B35.8010403@gmx.de> Date: Tue, 03 Jul 2012 18:17:57 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Nottingham References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 16:17:52 -0000 On 2012-07-03 07:47, Mark Nottingham wrote: > I've pretty much ignored the whole webfinger / acct: / SWD discussion (too much!). However, since it's apparent it may soon become Real, I had a look. > > In a nutshell, my initial reaction is "It's Not Nearly As Bad As I Thought It Would Be." :) > > With that in mind, a few questions / comments (I'll resist going into editorial matters, for the time being): > > * First and foremost, why use host-meta? What value does adding this extra step to the dance bring, beyond "We've defined it, therefore we must use it?" > > As I think I've said many times before, the whole point of a .well-known URI is to group like uses together, to avoid having a "dictionary" resource that gets bloated with many application's unrelated data, thereby overburdening clients with too much information (especially when they're constrained, e.g., mobile). > > As such, host-meta is a spectacularly bad example of a well-known URI. Defining a end-all-be-all well-known-URI kind of removes the point of having a registry, after all... > > Instead, why not just define a NEW well-known URI for user data? That has a more constrained scope, and saves one round trip (or more). E.g., > > GET /.well-known/webfinger?user=bob%40example.com HTTP/1.0 > Host: example.com > ... Or even /.well-known/webfinger/bob@example.com ? Best regards, Julian From pbryan@anode.ca Tue Jul 3 09:49:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9349B11E8166 for ; Tue, 3 Jul 2012 09:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZL3+ymXXc0L for ; Tue, 3 Jul 2012 09:49:47 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBEB11E8162 for ; Tue, 3 Jul 2012 09:49:47 -0700 (PDT) Received: from [10.126.22.47] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id C2990614C; Tue, 3 Jul 2012 16:49:54 +0000 (UTC) From: "Paul C. Bryan" To: Mark Nottingham In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> <1340897879.2393.9.camel@pbryan-wsl.internal.salesforce.com> <1340922969.2393.13.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114F730FACE@WSMSG3153V.srv.dir.telstra.com> <1340984775.31848.2.camel@pbryan-wsl.internal.salesforce.com> Content-Type: multipart/alternative; boundary="=-q/iwmrLW07GipczTkjGE" Date: Tue, 03 Jul 2012 09:49:51 -0700 Message-ID: <1341334191.2442.0.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: IETF Apps Discuss , Joe Hildebrand Subject: Re: [apps-discuss] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 16:49:48 -0000 --=-q/iwmrLW07GipczTkjGE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Looks good to me. Paul On Mon, 2012-07-02 at 10:01 +1000, Mark Nottingham wrote: > I've started to go in this direction in ; feedback appreciated. > > I think we'll need a few examples to show that the ordering of decoding matters. > > Also, anyone interesting in starting to collect test cases, as we've done for URI Templates ? > > Cheers, > > > On 30/06/2012, at 1:46 AM, Paul C. Bryan wrote: > > > I'll concede that ~0 is easier for humans and regular expression parsers to process than ~~, so I'll retract any suggestion that it should be so. > > > > On Fri, 2012-06-29 at 10:19 +1000, Manger, James H wrote: > >> > >> >> As a quoting character, ~ is a good choice. I might offer that 0 and > >> >> 1 are strange choices for the next character, but I wont offer an > >> >> alternative except to note that double-escape is the more commonly > >> >> used method for escaping the escape character. > >> > >> > True, ~~ would just as good to escape ~ instead of ~0... > >> > >> No. > >> > >> Using "~~" to escape "~" means a "~" in a pointer can be > >> either an escaper or an escapee -- and you have to count > >> a potentially indefinite number of preceding "~"'s to > >> determine the answer. That just makes parsing and matching > >> with a regex harder. > >> > >> The names in the following 2 pointers end in "1" or "/". > >> Which is which? > >> > >> /~~~~~~~~~~~~~~~~~~~~1 > >> /~~~~~~~~~~~~~~~~~~~1 > >> > >> It is much more obvious if we use "~0" as the escape for "~". > >> > >> /~0~0~0~0~0~0~0~0~0~01 > >> /~0~0~0~0~0~0~0~0~0~1 > >> > >> -- > >> James Manger > >> > > > > -- > Mark Nottingham http://www.mnot.net/ > > > --=-q/iwmrLW07GipczTkjGE Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Looks good to me.

Paul

On Mon, 2012-07-02 at 10:01 +1000, Mark Nottingham wrote: 
I've started to go in this direction in <http://trac.tools.ietf.org/wg/appsawg/trac/changeset/85>; feedback appreciated.

I think we'll need a few examples to show that the ordering of decoding matters.

Also, anyone interesting in starting to collect test cases, as we've done for URI Templates <https://github.com/uri-templates/uritemplate-test>?

Cheers,


On 30/06/2012, at 1:46 AM, Paul C. Bryan wrote:

> I'll concede that ~0 is easier for humans and regular expression parsers to process than ~~, so I'll retract any suggestion that it should be so.
> 
> On Fri, 2012-06-29 at 10:19 +1000, Manger, James H wrote:
>> 
>> >> As a quoting character, ~ is a good choice.  I might offer that 0 and
>> >> 1 are strange choices for the next character, but I wont offer an
>> >> alternative except to note that double-escape is the more commonly
>> >> used method for escaping the escape character.
>> 
>> > True, ~~ would just as good to escape ~ instead of ~0...
>> 
>> No.
>> 
>> Using "~~" to escape "~" means a "~" in a pointer can be
>> either an escaper or an escapee -- and you have to count
>> a potentially indefinite number of preceding "~"'s to
>> determine the answer. That just makes parsing and matching
>> with a regex harder.
>> 
>> The names in the following 2 pointers end in "1" or "/".
>> Which is which?
>> 
>>  /~~~~~~~~~~~~~~~~~~~~1
>>  /~~~~~~~~~~~~~~~~~~~1
>> 
>> It is much more obvious if we use "~0" as the escape for "~".
>> 
>>  /~0~0~0~0~0~0~0~0~0~01
>>  /~0~0~0~0~0~0~0~0~0~1
>> 
>> --
>> James Manger
>> 
> 

--
Mark Nottingham   http://www.mnot.net/

--=-q/iwmrLW07GipczTkjGE-- From hallam@gmail.com Tue Jul 3 09:51:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F3211E8162 for ; Tue, 3 Jul 2012 09:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vFQ0ErvM9RM for ; Tue, 3 Jul 2012 09:51:30 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A538A21F86C7 for ; Tue, 3 Jul 2012 09:51:30 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so11638302obb.31 for ; Tue, 03 Jul 2012 09:51:38 -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=s6uLRCzpdVSp2MjeQTg2u92h2Jm++hCATeesKUXDtgk=; b=Sk7uf3oYjwuL9rDos4ryiJ2jKVyEvFoZUTJKvXfdaoGXq4fS7DJbjl+c+52GX73pwB BdYxit4lQoJDQvmJ2VXWyGEQyX7QBhUs+exNUCyFV+yz2XmzOV7cFD1wjAPqGHWi5KNA qXtqXvWI4VM+URX1EXPcdetO+vmUKykn0dsUm077kOdDghh26uaTpdS4HS7izkfJ77R2 GeX+w7vSdTL/vJ2z5i89p3oSpvbGZTyDewiQwQq2BoDOmrbwa+Mi6HgMK7A3FnsDO7VZ KBNeOUFaIF/pKV38mgl54J5lawMI5VjvZJcIpyACd4OWEeh/oGRHiR3aFiOZemGEu/1t GcVA== MIME-Version: 1.0 Received: by 10.182.227.38 with SMTP id rx6mr6365911obc.27.1341334298657; Tue, 03 Jul 2012 09:51:38 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Tue, 3 Jul 2012 09:51:38 -0700 (PDT) In-Reply-To: <4FF31849.6040504@stpeter.im> References: <4FF31849.6040504@stpeter.im> Date: Tue, 3 Jul 2012 12:51:38 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] the need for acct (was: Re: Looking at Webfinger) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 16:51:32 -0000 Yes we do have mailto and xmpp but they conflate a resource with the action on that resource. We keep on having to develop all these new identifiers because the old ones have that conflation. Unfortunately I couldn't get people to change into at the time it appeared. Having acct: in there allows the client to offer the default action that makes sense in the context of that client. For example, a chat client is probably going to default to trying to set up chat. On Tue, Jul 3, 2012 at 12:05 PM, Peter Saint-Andre wrote: > On 7/3/12 8:52 AM, Phillip Hallam-Baker wrote: > >> The place where I would see acct: being used in WebFinger is actually >> more the data structures being returned. So for example if I am >> looking up my friends profile, I would probably want to see their >> battle.net accounts listed there along with their other stuff. >> >> WebFinger would still be a way to resolve acct: URIs, but only one way >> and the http: transport might only be one option. >> >> If I click on an acct: link in a browser I would have a range of >> possible options: >> * Grab the public WebFinger data >> * Grab the profile data exposed to me by virtue of me being a friend. >> * Attempt to connect on chat > > Don't we have xmpp: for that? > >> * Attempt to send an email > > Don't we have mailto: for that? > > You're saying that acct: would be a general identifier and that > applications could attempt many different kinds of interactions with > that account, using specific protocols like SMTP or XMPP. But deciding > whether to attempt such interactions would depend on knowing if the > service provider actually offers email service, IM service, public > profiles, microblogging, etc. Presumably that information could be > discovered via WebFinger (for a particular account), but I wouldn't > assume that one can send email to an account simply because an acct: URI > exists. > >> I would expect there to be a default action but that choice is >> something the user would probably make. > > It seems that the default action would be discovery. > >> The place I would be using acct: identifiers is in the authentication >> and authorization layer. > > Describing those use cases more completely would help us decide whether > we really need the 'acct' URI scheme. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > -- Website: http://hallambaker.com/ From ve7jtb@ve7jtb.com Tue Jul 3 09:57:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7739711E8163 for ; Tue, 3 Jul 2012 09:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDukMUMmiACN for ; Tue, 3 Jul 2012 09:56:59 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF0911E815C for ; Tue, 3 Jul 2012 09:56:59 -0700 (PDT) Received: by yenq13 with SMTP id q13so6083988yen.31 for ; Tue, 03 Jul 2012 09:57:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=7RPL2sOutldJDiaIkrVYrldV7wJaNRHqDpU6oR/uRzY=; b=NF4lpUPAOohC3HGRmjXf7UELWmafuhINDnRRH7N0wHnb3jLpwGckdJ1PD/CX9rQfr0 6PKoRCdc6Vaz6nywMd2ArgwzgXc+mIJCzbYbHuExv74oYalv9Ml1UYADOzKK0P04zIF6 EwHEUuapjczP7ePNuR+DYManDLs4kNU5hBUzmYjx2YxPJMwXk8vYlak+9wcvNYRq7DV2 0bZgSjPRBV3jQnLVGtMdfJW1IAUjUvFWoojexXvDYA3fdRA0DMtoewu17VWtyw/Ztnq5 Iv0uTNPGsEsFhzLOKXjiqpkY6z2O7ULqvHHsu/0WATYE+JTcH1PPesCo2OXRdISc6HqN t3Dg== Received: by 10.236.108.234 with SMTP id q70mr3038536yhg.4.1341334627198; Tue, 03 Jul 2012 09:57:07 -0700 (PDT) Received: from [192.168.1.211] (190-20-40-193.baf.movistar.cl. [190.20.40.193]) by mx.google.com with ESMTPS id k67sm32700354yhj.18.2012.07.03.09.57.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jul 2012 09:57:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_E1820285-B557-4E4C-9D7D-7E541D20B2F2"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4FF31B35.8010403@gmx.de> Date: Tue, 3 Jul 2012 12:56:58 -0400 Message-Id: References: <4FF31B35.8010403@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkWpWLOE16vg41s6vOdOoFgSiOqn4ktGcq7+AfdZXQul1IkAM4sbKs5teYXL7Z51S1jt/K3 Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 16:57:00 -0000 --Apple-Mail=_E1820285-B557-4E4C-9D7D-7E541D20B2F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In SWD we had a second parameter for the link relation you are looking = for. =20 That make processing on the client simpler if it can ask for the IMAP = link relation and get back a simple document with just the relevant = links. That is similar to the WF resource and rel parameters, though rel is = somewhat limited in WF due to it only having a single template = parameter. I don't personally care if the resource being retrieved is part of the = path or a query parameter. This also cases the question of what is the thing de-refrenced. Is it a = abstract concept of the account or a concrete resource that is a file. I think we are creating a new URI name using acct: for what is = essentially a document, that also has a http: scheme uri for = de-refrencing it. So I am still unclear on if acct: really has some unique meaning as a = identifier that can be defined. John B. On 2012-07-03, at 12:17 PM, Julian Reschke wrote: > On 2012-07-03 07:47, Mark Nottingham wrote: >> I've pretty much ignored the whole webfinger / acct: / SWD discussion = (too much!). However, since it's apparent it may soon become Real, I had = a look. >>=20 >> In a nutshell, my initial reaction is "It's Not Nearly As Bad As I = Thought It Would Be." :) >>=20 >> With that in mind, a few questions / comments (I'll resist going into = editorial matters, for the time being): >>=20 >> * First and foremost, why use host-meta? What value does adding this = extra step to the dance bring, beyond "We've defined it, therefore we = must use it?" >>=20 >> As I think I've said many times before, the whole point of a = .well-known URI is to group like uses together, to avoid having a = "dictionary" resource that gets bloated with many application's = unrelated data, thereby overburdening clients with too much information = (especially when they're constrained, e.g., mobile). >>=20 >> As such, host-meta is a spectacularly bad example of a well-known = URI. Defining a end-all-be-all well-known-URI kind of removes the point = of having a registry, after all... >>=20 >> Instead, why not just define a NEW well-known URI for user data? That = has a more constrained scope, and saves one round trip (or more). E.g., >>=20 >> GET /.well-known/webfinger?user=3Dbob%40example.com HTTP/1.0 >> Host: example.com >> ... >=20 > Or even >=20 > /.well-known/webfinger/bob@example.com >=20 > ? >=20 > Best regards, Julian > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_E1820285-B557-4E4C-9D7D-7E541D20B2F2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw MzE2NTY1OVowIwYJKoZIhvcNAQkEMRYEFN+SslyC+Pubh2HZH0Ikv7nXqthGMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AB26atrmhywdStHRuiBx9Kb4OxG3HpM3w18uwt7fNg7/5LShMDpaUKzLE4er+mzjgwRFXs3tBH50 q0BO+BZMLEhsrNTo5NltE2nkTBb5bumleDRg/x6IFgk82h0++NmBJe9I0yxYqxY/eH6+L8SZ0ntL e8JmhmzPSL/wl217j9krTu9zmDJY/KhgGymePVPBdXWcTGfGtrWU610OkmUOr4gwU60QDwiKeZN6 w3GEQ7OziVCPQJKgFFK+pSwAeE01ryBq7EaVFtZf9DMvJWltYz96weLuCzG8ZxPqti36TS/eWTCO C13shxGU+xJde3xvp5MPvjcyd494TPAjAuMZuNgAAAAAAAA= --Apple-Mail=_E1820285-B557-4E4C-9D7D-7E541D20B2F2-- From wmills@yahoo-inc.com Tue Jul 3 10:29:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A0921F85A7 for ; Tue, 3 Jul 2012 10:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.546 X-Spam-Level: X-Spam-Status: No, score=-17.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ba-BsnGAeBOZ for ; Tue, 3 Jul 2012 10:29:05 -0700 (PDT) Received: from nm5.bullet.mail.sp2.yahoo.com (nm5.bullet.mail.sp2.yahoo.com [98.139.91.75]) by ietfa.amsl.com (Postfix) with SMTP id 4133721F85A5 for ; Tue, 3 Jul 2012 10:29:04 -0700 (PDT) Received: from [72.30.22.93] by nm5.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jul 2012 17:29:10 -0000 Received: from [98.139.91.43] by tm15.bullet.mail.sp2.yahoo.com with NNFMP; 03 Jul 2012 17:29:10 -0000 Received: from [127.0.0.1] by omp1043.mail.sp2.yahoo.com with NNFMP; 03 Jul 2012 17:29:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 319289.39517.bm@omp1043.mail.sp2.yahoo.com Received: (qmail 84529 invoked by uid 60001); 3 Jul 2012 17:29:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1341336549; bh=BPcRrdRvTFvosHMvNsK+A80uLSfAtQRNkjol5PWzvko=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WQFot06v/ih2nlb3dIX/QHKhZFlnV9NnVcqC4gNjxOkY9JpW99ko/4LAOyqVR6g/g461PTlYLBP0k80wl8yi0AbPbsHqVjA3w+00oaAv+NNvnzKKTcBV5YWIIzZyPI7a6XiSJD3WKPzFPqSeY4nXvNvQ7Que6dEno2dV63t+G1g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=V82ys1enrHddpoQ3ITrubOAe8a8cXEk1+e4XeRGFef/fs4lr2RsDx8UNIUe2ahWfMVwcrft5mq1pDMhXf7SfH405+tT82nzL2lioyc5AugnZINFZg4nkyfH3ksSwEj7uFFeQvlgEyvnJ8n2gGkifUVcZAi7rAOkJFul2bo1V3so=; X-YMail-OSG: P884UtoVM1kPypSzIsTa0yVZq5ZwYlQPH5UWzLPVDEukV2Q 8nGFPb1VDFscrZC93Vp2CtzeSp1kp_KZ7KX_Yp7PfQK6cJifSXPAUqG6xTuC 38vFATi7g9j_YSrpuidXvJc2BUr6OA923KgvuXCLECF09kA9_oeXcErVMmzG kT6Xc794JP9K96yUx91FmmWrzFowmG0UMTufw91I5xbdPFQuToPut1G5Vuu7 DI_kIqHQHegYTbXN8_kcETn23myUIHGXUus6GT.qoBwHsEdF_Yoz6faFyiFz 3DjurP5Qca0v.2nxYQZgHyWQGJBLLOSNmiBqDHwadmP4EbaxIuaNQDWC61Ub m66X_.BX1iC8IZoyqMKw9uCg_bq8YJUDq_K5RQgysShv61yDLnmCf1WIh484 KRFc.rI4ZOe_Xf0Wy12B90oFi.mny7jgFvEo9MgAPvCznNvRw0FhD2MHeo24 97HKWQVUWYBZ1rqKoyW2L9kSNJ3wRpVKHF.PRwwlYKVrgGirI_MoMiSmQRWe qKrQSsCsGNMBsC8VgPjhb8FwUqOdVS4cZTGyaKQ-- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Tue, 03 Jul 2012 10:29:09 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <4FF31849.6040504@stpeter.im> Message-ID: <1341336549.84355.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Tue, 3 Jul 2012 10:29:09 -0700 (PDT) From: William Mills To: Peter Saint-Andre , Phillip Hallam-Baker In-Reply-To: <4FF31849.6040504@stpeter.im> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-1304175061-1341336549=:84355" Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] the need for acct (was: Re: Looking at Webfinger) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 17:29:06 -0000 --1458549034-1304175061-1341336549=:84355 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable For describing why we need acct: I come back to the previous discussion whe= re the point was made almost exactly that xmpp:, mailto: and others have sp= ecific contexts and in the context of Webfinger are appropriate for discove= ring information about that specific context.=A0 The acct: scheme satisfies= the need for "I need information about this user" when it's not in the con= text of a specific applicaiton protocol.=0A=0A=0A=0A=0A>___________________= _____________=0A> From: Peter Saint-Andre =0A>To: Phill= ip Hallam-Baker =0A>Cc: Mark Nottingham ;= IETF Apps Discuss =0A>Sent: Tuesday, July 3, 2012 = 9:05 AM=0A>Subject: [apps-discuss] the need for acct (was: Re: Looking at = Webfinger)=0A> =0A>On 7/3/12 8:52 AM, Phillip Hallam-Baker wrote:=0A>=0A>> = The place where I would see acct: being used in WebFinger is actually=0A>> = more the data structures being returned. So for example if I am=0A>> lookin= g up my friends profile, I would probably want to see their=0A>> battle.net= accounts listed there along with their other stuff.=0A>> =0A>> WebFinger w= ould still be a way to resolve acct: URIs, but only one way=0A>> and the ht= tp: transport might only be one option.=0A>> =0A>> If I click on an acct: l= ink in a browser I would have a range of=0A>> possible options:=0A>>=A0 =A0= * Grab the public WebFinger data=0A>>=A0 =A0 * Grab the profile data expos= ed to me by virtue of me being a friend.=0A>>=A0 =A0 * Attempt to connect o= n chat=0A>=0A>Don't we have xmpp: for that?=0A>=0A>>=A0 =A0 * Attempt to se= nd an email=0A>=0A>Don't we have mailto: for that?=0A>=0A>You're saying tha= t acct: would be a general identifier and that=0A>applications could attemp= t many different kinds of interactions with=0A>that account, using specific= protocols like SMTP or XMPP. But deciding=0A>whether to attempt such inter= actions would depend on knowing if the=0A>service provider actually offers = email service, IM service, public=0A>profiles, microblogging, etc. Presumab= ly that information could be=0A>discovered via WebFinger (for a particular = account), but I wouldn't=0A>assume that one can send email to an account si= mply because an acct: URI=0A>exists.=0A>=0A>> I would expect there to be a = default action but that choice is=0A>> something the user would probably ma= ke.=0A>=0A>It seems that the default action would be discovery.=0A>=0A>> Th= e place I would be using acct: identifiers is in the authentication=0A>> an= d authorization layer.=0A>=0A>Describing those use cases more completely wo= uld help us decide whether=0A>we really need the 'acct' URI scheme.=0A>=0A>= Peter=0A>=0A>-- =0A>Peter Saint-Andre=0A>https://stpeter.im/=0A>=0A>=0A>=0A= >=0A>_______________________________________________=0A>apps-discuss mailin= g list=0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/listinfo/ap= ps-discuss=0A>=0A>=0A> --1458549034-1304175061-1341336549=:84355 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
For describing why we need acct: I come back to the previous discussion w= here the point was made almost exactly that xmpp:, mailto: and others have = specific contexts and in the context of Webfinger are appropriate for disco= vering information about that specific context.  The acct: scheme sati= sfies the need for "I need information about this user" when it's not in th= e context of a specific applicaiton protocol.

From: Peter Saint-Andre <stpeter= @stpeter.im>
To: Ph= illip Hallam-Baker <hallam@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>; IETF Apps = Discuss <apps-discuss@ietf.org>
Sent: Tuesday, July 3, 2012 9:05 AM
Subject: [apps-discuss] the need for acct (w= as: Re: Looking at Webfinger)

=0AOn 7/3/12 8:52 AM,= Phillip Hallam-Baker wrote:

> The place where I would see acct: = being used in WebFinger is actually
> more the data structures being = returned. So for example if I am
> looking up my friends profile, I w= ould probably want to see their
> battle.net accounts listed there al= ong with their other stuff.
>
> WebFinger would still be a way= to resolve acct: URIs, but only one way
> and the http: transport mi= ght only be one option.
>
> If I click on an acct: link in a b= rowser I would have a range of
> possible options:
>  &nbs= p; * Grab the public WebFinger data
>    * Grab the profile= data exposed to me by virtue of me being a friend.
>    * = Attempt to connect on chat

Don't we have xmpp: for that?

>=     * Attempt to send an email

Don't we have mailto: for t= hat?

You're saying that acct: would be a general identifier and that
applications could attempt many different k= inds of interactions with
that account, using specific protocols like SM= TP or XMPP. But deciding
whether to attempt such interactions would depe= nd on knowing if the
service provider actually offers email service, IM = service, public
profiles, microblogging, etc. Presumably that informatio= n could be
discovered via WebFinger (for a particular account), but I wo= uldn't
assume that one can send email to an account simply because an ac= ct: URI
exists.

> I would expect there to be a default action = but that choice is
> something the user would probably make.

I= t seems that the default action would be discovery.

> The place I= would be using acct: identifiers is in the authentication
> and auth= orization layer.

Describing those use cases more completely would he= lp us decide whether
we really need the 'acct' URI scheme.

Peter

--
Peter Saint-Andre
https://stpeter.im/




= _______________________________________________
apps-discuss mailing lis= t
apps-discuss@ietf.org
https://www.ietf.org/mailman= /listinfo/apps-discuss


=
--1458549034-1304175061-1341336549=:84355-- From barryleiba@gmail.com Tue Jul 3 11:33:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F289021F8700 for ; Tue, 3 Jul 2012 11:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.788 X-Spam-Level: X-Spam-Status: No, score=-102.788 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8M+4AvEof1EA for ; Tue, 3 Jul 2012 11:33:03 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E64A321F8703 for ; Tue, 3 Jul 2012 11:33:02 -0700 (PDT) Received: by qcac10 with SMTP id c10so3192382qca.31 for ; Tue, 03 Jul 2012 11:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=v4Jof8rZBkSYYcVSqZzB21V9MgtpV0wogaGvJsogvVo=; b=M8o85RbLRivekfz/2g8lQVNDSaSBRj9A14ls+AbKiOEZDpPRtUMsMGO67ufL0OfazU fKLHmCg9Wnq49iPxAFitd40l/GSmTh1uc9SiHIPcYUBB/m92INZtPF1pzwj4/rWL4Oy6 cCKdUjFBjhCZYjg2OCIy+xJRO++UEID3O7dVTtcHkMNkwIIR1QMtV5aUA7RxiquWG5wp Pi86w2lle55kfy+4M2gkdFGDQnYK/OhdppfTxTXR7qIPo7RdfsQdtbRwyZKxCMHbXpB5 vyH6B209AXlGNMTeUfo11hQ4cnxNBuOkbNFRZKRN+AoAIJfbktK/zYhs4S11Ru6qrLVa LZWQ== MIME-Version: 1.0 Received: by 10.229.137.72 with SMTP id v8mr9230679qct.79.1341340391034; Tue, 03 Jul 2012 11:33:11 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Tue, 3 Jul 2012 11:33:11 -0700 (PDT) Date: Tue, 3 Jul 2012 14:33:11 -0400 X-Google-Sender-Auth: TaW4xa1L8PE-MKU4gs-0Oga9nqo Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 18:33:28 -0000 In my AD review of draft-ietf-appsawg-http-forwarded-05 I found myself significantly bothered by the fact that there are multiple ways to represent the same thing, that proxies are giving the choice of how to add their information (and delete older, inappropriate information), and, therefore, that consumers of the information have to cope with it in multiple ways. Here's a re-edit of my comment to the document editors: Last paragraph of Section 4: > Given that a proxy wishes to add a Forwarded header field to the > outgoing request, if the incoming request has no such header field, > the proxy simply adds the header field with the list of parameters > desired. If, on the other hand, the incoming request has such a > header field, the proxy can either add a comma and the list of > parameters, or add a new instance of the header field. A proxy MAY > remove all Forwarded header fields from a request. It MUST, however, > ensure that the correct header field is updated in case of multiple Forwarded header fields. I find this confusing, and I question the value of having more than one way of representing things. Why would a proxy want to add a comma and a list, rather than adding a new instance? If a proxy later wants to selectively remove earlier information, how would it safely do it when some had been added as list items into another header field? Doesn't it complicate things to have to support various combinations? How would I choose between these?: Forwarded: for=192.0.2.43,for=198.51.100.17 Forwarded: for=192.0.2.43 Forwarded: for=198.51.100.17 You either need to explain the pros and cons, or just provide one way to do it. I guess I'd want to see a good reason for not just having one header field per proxy. I realize that existing fields use this mechanism, but we have a chance to be specific in a new specification. Is there a good reason not to be? It's also very awkward to have punctuation precedence that's backward from how it works in English (and again, I know this is used elsewhere). Here, commas are more powerful than semicolons, so you might have something like this: Forwarded: for=192.0.2.43;proto=http,for=198.51.100.17;proto=https As someone who reads English, I find the way that gets grouped to be surprising and unsettling, because I expect the break between "43" and "proto=http" to be *stronger* than the break after "proto=http", and it's not. I think this point is significant enough that I really need to bring it up on the mailing list and get the working group's opinion. Barry From w@1wt.eu Tue Jul 3 11:37:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7DA11E81B5 for ; Tue, 3 Jul 2012 11:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.085 X-Spam-Level: X-Spam-Status: No, score=-6.085 tagged_above=-999 required=5 tests=[AWL=-4.042, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btuiClAx9bsn for ; Tue, 3 Jul 2012 11:37:29 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id D2BCF11E81B2 for ; Tue, 3 Jul 2012 11:37:28 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q63IbU8O017671; Tue, 3 Jul 2012 20:37:30 +0200 Date: Tue, 3 Jul 2012 20:37:30 +0200 From: Willy Tarreau To: Barry Leiba Message-ID: <20120703183730.GH17454@1wt.eu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 18:37:29 -0000 Hi Barry, On Tue, Jul 03, 2012 at 02:33:11PM -0400, Barry Leiba wrote: > In my AD review of draft-ietf-appsawg-http-forwarded-05 I found myself > significantly bothered by the fact that there are multiple ways to > represent the same thing, that proxies are giving the choice of how to > add their information (and delete older, inappropriate information), > and, therefore, that consumers of the information have to cope with it > in multiple ways. > > Here's a re-edit of my comment to the document editors: > > Last paragraph of Section 4: > > Given that a proxy wishes to add a Forwarded header field to the > > outgoing request, if the incoming request has no such header field, > > the proxy simply adds the header field with the list of parameters > > desired. If, on the other hand, the incoming request has such a > > header field, the proxy can either add a comma and the list of > > parameters, or add a new instance of the header field. A proxy MAY > > remove all Forwarded header fields from a request. It MUST, however, > > ensure that the correct header field is updated in case of multiple > Forwarded header fields. > > I find this confusing, and I question the value of having more than > one way of representing things. Why would a proxy want to add a comma > and a list, rather than adding a new instance? If a proxy later wants > to selectively remove earlier information, how would it safely do it when > some had been added as list items into another header field? Doesn't it > complicate things to have to support various combinations? How would I > choose between these?: > > Forwarded: for=192.0.2.43,for=198.51.100.17 > > Forwarded: for=192.0.2.43 > Forwarded: for=198.51.100.17 I agree with you on this point. Both forms are valid once received, and parsers MUST be able to parse both forms. So it's certain that some senders will do the later because it's easier and is valid HTTP-wise. For instance, in haproxy, we never update the existing header, which requires complicated memmove() and header re-indexation, we always append at the end. Regards, Willy From julian.reschke@gmx.de Tue Jul 3 11:38:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047D711E81B2 for ; Tue, 3 Jul 2012 11:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.375 X-Spam-Level: X-Spam-Status: No, score=-105.375 tagged_above=-999 required=5 tests=[AWL=-2.776, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LA+EwhW2AZGV for ; Tue, 3 Jul 2012 11:38:04 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4EA8311E8162 for ; Tue, 3 Jul 2012 11:38:04 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 18:38:11 -0000 Received: from p5DD96484.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.100.132] by mail.gmx.net (mp019) with SMTP; 03 Jul 2012 20:38:11 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19iJwsJTpVio9jUa1Ofnx/tskT37drpfmCSoNoh2o ME8hR7tgm8gnk4 Message-ID: <4FF33C11.6040300@gmx.de> Date: Tue, 03 Jul 2012 20:38:09 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 18:38:06 -0000 On 2012-07-03 20:33, Barry Leiba wrote: > In my AD review of draft-ietf-appsawg-http-forwarded-05 I found myself > significantly bothered by the fact that there are multiple ways to > represent the same thing, that proxies are giving the choice of how to > add their information (and delete older, inappropriate information), > and, therefore, that consumers of the information have to cope with it > in multiple ways. > > Here's a re-edit of my comment to the document editors: > > Last paragraph of Section 4: >> Given that a proxy wishes to add a Forwarded header field to the >> outgoing request, if the incoming request has no such header field, >> the proxy simply adds the header field with the list of parameters >> desired. If, on the other hand, the incoming request has such a >> header field, the proxy can either add a comma and the list of >> parameters, or add a new instance of the header field. A proxy MAY >> remove all Forwarded header fields from a request. It MUST, however, >> ensure that the correct header field is updated in case of multiple > Forwarded header fields. > > I find this confusing, and I question the value of having more than > one way of representing things. Why would a proxy want to add a comma > and a list, rather than adding a new instance? If a proxy later wants > to selectively remove earlier information, how would it safely do it when > some had been added as list items into another header field? Doesn't it > complicate things to have to support various combinations? How would I > choose between these?: > > Forwarded: for=192.0.2.43,for=198.51.100.17 > > Forwarded: for=192.0.2.43 > Forwarded: for=198.51.100.17 > > You either need to explain the pros and cons, or just provide one way > to do it. I guess I'd want to see a good reason for not just having one > header field per proxy. I realize that existing fields use this > mechanism, but we have a chance to be specific in a new specification. > Is there a good reason not to be? Yes. Consistency in header parsing. No new special cases, please. > It's also very awkward to have punctuation precedence that's backward > from how it works in English (and again, I know this is used elsewhere). > Here, commas are more powerful than semicolons, so you might have > something like this: > > Forwarded: for=192.0.2.43;proto=http,for=198.51.100.17;proto=https > > As someone who reads English, I find the way that gets grouped to be > surprising and unsettling, because I expect the break between "43" and > "proto=http" to be *stronger* than the break after "proto=http", and > it's not. > > I think this point is significant enough that I really need to bring it up on > the mailing list and get the working group's opinion. Again, this is consistent with other HTTP header fields. Best regards, Julian From barryleiba.mailing.lists@gmail.com Tue Jul 3 11:40:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A10B11E81BB for ; Tue, 3 Jul 2012 11:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.883 X-Spam-Level: X-Spam-Status: No, score=-102.883 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xK9j7TcsHA9L for ; Tue, 3 Jul 2012 11:40:53 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D24A11E81BE for ; Tue, 3 Jul 2012 11:40:52 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so10254580lbb.31 for ; Tue, 03 Jul 2012 11:41:00 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ussXbjotYUEzQFqQSKf4VbRFXiPSN7X//EAmLAmkcZw=; b=yrVDkCDZb+xF3oNXPqlz59LM9APRKajzObxSypTbCZZMURAPqGW28PzMmJ3rtiZ3w5 9qrzl83xwo4r+LGpziH1+qRehoAuIAIfApcmW/jnobKMhhD8QyhStV9dDGxzpwq21e7L JUxUlbRxa0gUnqrGSTylfaTyXYze5PvN74d1GXKalcWN6QGphJ0EckxXmoxZjPaDihUA xZcpuJSnqsbamxhWqoA0i8yB+DMdWmm7zM1ZvQPSWEjbY01MtcbF38l+pOVGc3Wi4xFQ fRAMmNK2R+znmVm9d1ylrAwY1b3ntjjx8jpot4dk9FaLzx/6BEjkkjEb2Z/tH0YbInya 1vgQ== MIME-Version: 1.0 Received: by 10.152.111.200 with SMTP id ik8mr18550187lab.15.1341340860716; Tue, 03 Jul 2012 11:41:00 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Tue, 3 Jul 2012 11:41:00 -0700 (PDT) In-Reply-To: <1A87B9DE-ECEC-4F07-8734-131D4BB564EB@ve7jtb.com> References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <1A87B9DE-ECEC-4F07-8734-131D4BB564EB@ve7jtb.com> Date: Tue, 3 Jul 2012 14:41:00 -0400 X-Google-Sender-Auth: ib3ciW6g5SepDDO2E9iCtuqZQZc Message-ID: From: Barry Leiba To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 18:40:54 -0000 > Now that WF has been accepted by the chairs as a WG draft it gets harder to > make breaking changes. I'm not sure what you mean by "breaking changes", but I don't see that having the document be a working group product undermines the ability to suggest any change for which there has not already been a decision against. If your suggestion develops rough consensus, then it will be included. If not, then it won't. To avoid the flogging of dead horses, the chairs may declare some topics out of scope if those topics have already been firmly decided. But that, too, is standard procedure. Barry From barryleiba.mailing.lists@gmail.com Tue Jul 3 11:44:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95ACC21F85FD for ; Tue, 3 Jul 2012 11:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.914 X-Spam-Level: X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjKN-wnk0Ek0 for ; Tue, 3 Jul 2012 11:44:32 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9318821F85F1 for ; Tue, 3 Jul 2012 11:44:31 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so10258490lbb.31 for ; Tue, 03 Jul 2012 11:44:39 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k+e9wJageAD6VQ5+8sfXLRrV3cUMYXJAieajer0DXg8=; b=kAIFK7COWant7hqd07RCYujBRW1xd5LWTW6+A+WUfirjwzfVXbz6blwcg/2qbiQSLS 7yiESd5HkCAyPlGIxCS969ewPyBYuUQHNyK3XA677nkxmkUIIxYj95r/IgzmSLt8TRcC A5iJ73WkaMsysxHbOz9gZYt+XjHouxL/VbeDa63DesENAfwAdafqrMoYONG6hnyGwMlN NT5DQ+clCPorWl+epkTbhP8HGIor8xey5SBbTBXfGtRHqRoQvjDZbw2CYdWb6z8nilqM HZloIHcydflcnl5Gx+I4E7hYg2qbd4YQeZkVHVozTxblVG3h9nAcgTb6vuZOd+En4Mup kqgA== MIME-Version: 1.0 Received: by 10.112.10.198 with SMTP id k6mr8728537lbb.83.1341341079298; Tue, 03 Jul 2012 11:44:39 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Tue, 3 Jul 2012 11:44:39 -0700 (PDT) In-Reply-To: <4FF33C11.6040300@gmx.de> References: <4FF33C11.6040300@gmx.de> Date: Tue, 3 Jul 2012 14:44:39 -0400 X-Google-Sender-Auth: GiViREJ7HvqnoW8KA9KHcP4y18w Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 18:44:33 -0000 >> You either need to explain the pros and cons, or just provide one way >> to do it. =A0I guess I'd want to see a good reason for not just having o= ne >> header field per proxy. =A0I realize that existing fields use this >> mechanism, but we have a chance to be specific in a new specification. >> Is there a good reason not to be? > > Yes. Consistency in header parsing. No new special cases, please. How is there any inconsistency? Anyone receiving the fields already needs to know how to parse both forms. Why is there a specific problem with requiring those who create the fields to create one field per proxy? Barry From julian.reschke@gmx.de Tue Jul 3 11:51:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FB511E815E for ; Tue, 3 Jul 2012 11:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.296 X-Spam-Level: X-Spam-Status: No, score=-105.296 tagged_above=-999 required=5 tests=[AWL=-2.697, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+f1SV3JXYnr for ; Tue, 3 Jul 2012 11:51:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 77B0211E80C1 for ; Tue, 3 Jul 2012 11:51:44 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 18:51:51 -0000 Received: from p5DD96484.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.100.132] by mail.gmx.net (mp016) with SMTP; 03 Jul 2012 20:51:51 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18jfj58EgkjNtf0l/qb9L7N+wxYbfaozUvSAhGhKx R5Lg7ivJkOGpmy Message-ID: <4FF33F45.90307@gmx.de> Date: Tue, 03 Jul 2012 20:51:49 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Barry Leiba References: <4FF33C11.6040300@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 18:51:46 -0000 On 2012-07-03 20:44, Barry Leiba wrote: >>> You either need to explain the pros and cons, or just provide one way >>> to do it. I guess I'd want to see a good reason for not just having one >>> header field per proxy. I realize that existing fields use this >>> mechanism, but we have a chance to be specific in a new specification. >>> Is there a good reason not to be? >> >> Yes. Consistency in header parsing. No new special cases, please. > > How is there any inconsistency? Anyone receiving the fields already > needs to know how to parse both forms. Why is there a specific > problem with requiring those who create the fields to create one field > per proxy? If all recipients need to understand both forms (per HTTP/1.1), what's the point in requiring one of these for senders? Best regards, Julian From barryleiba@gmail.com Tue Jul 3 12:01:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9040511E8114 for ; Tue, 3 Jul 2012 12:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.93 X-Spam-Level: X-Spam-Status: No, score=-102.93 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjjJ6C1vbhGH for ; Tue, 3 Jul 2012 12:01:59 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D584211E80C1 for ; Tue, 3 Jul 2012 12:01:58 -0700 (PDT) Received: by qcac10 with SMTP id c10so3211703qca.31 for ; Tue, 03 Jul 2012 12:02: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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0uwSQn0+zbVuq0F15tIWErrA0q4VDNchdZbpCbApnzU=; b=jDMxyoPQ3N7pMdjO3Fjr4Juk6VauXCqjewAY08cHIRksKB3VPWgLCwG3CIQ8yKehWp 1ZsuCue1gs+ihRfcGZ4KxFL+wc1POl0FdoZ6e3Sf1MhcLE1X0csANriw+AgfJdc/u7V8 d+VTk924QQnMrFxJ5MVd3Njew2oDN7HHPta+RFibahGx+Ww7cLOZC3960hGp9CAYieEp BxAsrmhhPJo8d97QdcgBCmro+ufuoLSF/Pnpu7dBF7eqB0zfKIjdrYFVmNTL0aQdxkSP 8BPxGCrcwTPmQMAwZmWpVZuVZ+VIXQ2y0sYj+hbrkcyJ0oGD/xLCJslP8b2PMgGffmGl UIEg== MIME-Version: 1.0 Received: by 10.229.136.142 with SMTP id r14mr9587504qct.70.1341342127083; Tue, 03 Jul 2012 12:02:07 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Tue, 3 Jul 2012 12:02:07 -0700 (PDT) In-Reply-To: <4FF33F45.90307@gmx.de> References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> Date: Tue, 3 Jul 2012 15:02:07 -0400 X-Google-Sender-Auth: SvJIPw79RVVMqYyXx3WzolV7ois Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 19:01:59 -0000 >>>> You either need to explain the pros and cons, or just provide one way >>>> to do it. I guess I'd want to see a good reason for not just having one >>>> header field per proxy. I realize that existing fields use this >>>> mechanism, but we have a chance to be specific in a new specification. >>>> Is there a good reason not to be? >>> >>> Yes. Consistency in header parsing. No new special cases, please. >> >> How is there any inconsistency? Anyone receiving the fields already >> needs to know how to parse both forms. Why is there a specific >> problem with requiring those who create the fields to create one field >> per proxy? > > If all recipients need to understand both forms (per HTTP/1.1), what's the > point in requiring one of these for senders? Consistency. THAT is where the consistency comes in. Barry From w@1wt.eu Tue Jul 3 12:04:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382A011E80D1 for ; Tue, 3 Jul 2012 12:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=-3.675, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+YxoYZ3uZaf for ; Tue, 3 Jul 2012 12:04:00 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 2532B11E80B8 for ; Tue, 3 Jul 2012 12:03:59 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q63J41hs017832; Tue, 3 Jul 2012 21:04:01 +0200 Date: Tue, 3 Jul 2012 21:04:01 +0200 From: Willy Tarreau To: Barry Leiba Message-ID: <20120703190401.GL17454@1wt.eu> References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Julian Reschke , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 19:04:01 -0000 On Tue, Jul 03, 2012 at 03:02:07PM -0400, Barry Leiba wrote: > >>>> You either need to explain the pros and cons, or just provide one way > >>>> to do it. I guess I'd want to see a good reason for not just having one > >>>> header field per proxy. I realize that existing fields use this > >>>> mechanism, but we have a chance to be specific in a new specification. > >>>> Is there a good reason not to be? > >>> > >>> Yes. Consistency in header parsing. No new special cases, please. > >> > >> How is there any inconsistency? Anyone receiving the fields already > >> needs to know how to parse both forms. Why is there a specific > >> problem with requiring those who create the fields to create one field > >> per proxy? > > > > If all recipients need to understand both forms (per HTTP/1.1), what's the > > point in requiring one of these for senders? > > Consistency. THAT is where the consistency comes in. Barry, the consistency comes from the reuse of existing parsers and the syntax already in use with other header fields. Or maybe we're all discussing different things ? Regards, Willy From julian.reschke@gmx.de Tue Jul 3 12:06:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC47411E8192 for ; Tue, 3 Jul 2012 12:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.221 X-Spam-Level: X-Spam-Status: No, score=-105.221 tagged_above=-999 required=5 tests=[AWL=-2.622, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JLGJSrz17X4 for ; Tue, 3 Jul 2012 12:06:12 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 45A7B11E80C1 for ; Tue, 3 Jul 2012 12:06:12 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 19:06:20 -0000 Received: from p5DD96484.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.100.132] by mail.gmx.net (mp031) with SMTP; 03 Jul 2012 21:06:20 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/0VLZee5v0YJ7tpbbf5PhFceQ7jPNwtbJv5Fu1QZ dDlc0NF/MahTA/ Message-ID: <4FF342AA.90905@gmx.de> Date: Tue, 03 Jul 2012 21:06:18 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Barry Leiba References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 19:06:14 -0000 On 2012-07-03 21:02, Barry Leiba wrote: >>>>> You either need to explain the pros and cons, or just provide one way >>>>> to do it. I guess I'd want to see a good reason for not just having one >>>>> header field per proxy. I realize that existing fields use this >>>>> mechanism, but we have a chance to be specific in a new specification. >>>>> Is there a good reason not to be? >>>> >>>> Yes. Consistency in header parsing. No new special cases, please. >>> >>> How is there any inconsistency? Anyone receiving the fields already >>> needs to know how to parse both forms. Why is there a specific >>> problem with requiring those who create the fields to create one field >>> per proxy? >> >> If all recipients need to understand both forms (per HTTP/1.1), what's the >> point in requiring one of these for senders? > > Consistency. THAT is where the consistency comes in. > ... A big -1 on that. We have a syntax that allows two forms. Disallowing or discouraging one of these for just *one* header field will either be (rightfully) ignored, or lead to completely unneeded special-casing in libraries. Best regards, Julian From barryleiba@gmail.com Tue Jul 3 12:08:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4160111E80B8 for ; Tue, 3 Jul 2012 12:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.529 X-Spam-Level: X-Spam-Status: No, score=-103.529 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qxu1iiKYLuST for ; Tue, 3 Jul 2012 12:08:33 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18B0711E80C1 for ; Tue, 3 Jul 2012 12:08:32 -0700 (PDT) Received: by qcac10 with SMTP id c10so3216571qca.31 for ; Tue, 03 Jul 2012 12:08:40 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Qsqj9GgMd5ZTjmTYZuFlhl6SS4fcecQYcGZrlN+Qm4E=; b=oQe1FoTh7CDwNovqflDyfarV/60Xqa0yxbsiUTTUGS6DK1+elGmvbrakqzAaXSiV3p L4Qk977z1cEjubCRInw4aIYJk6kT6D8zMz6aLEEvPKbZIo7dZXil60azVctn4H10pleW DBuENgJglAOdirMw+azWUy2JMKfW4dnQBaHReRJkpZkq+9hycIVWarq7e4AzB2HQ+Hg5 wPO1Rs4bVThrRI5gWCibyHqjbGbNLnjuus8tppI/kcQX8J3dXgLe6LgRdG6hXbzY7Bt3 tJFCfPM6tdksAn7MryzIprLBYybNlRhu5th+TISBQMRiTpxAtermj5LZb4wC/Wl3ECTy XoUA== MIME-Version: 1.0 Received: by 10.224.213.4 with SMTP id gu4mr32689560qab.0.1341342520763; Tue, 03 Jul 2012 12:08:40 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Tue, 3 Jul 2012 12:08:40 -0700 (PDT) In-Reply-To: <20120703190401.GL17454@1wt.eu> References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> <20120703190401.GL17454@1wt.eu> Date: Tue, 3 Jul 2012 15:08:40 -0400 X-Google-Sender-Auth: ZClZkvLU5KG10KMlKH_8J-T5Tms Message-ID: From: Barry Leiba To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Cc: Julian Reschke , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 19:08:34 -0000 >> Consistency. THAT is where the consistency comes in. > > Barry, the consistency comes from the reuse of existing parsers and the > syntax already in use with other header fields. Or maybe we're all discussing > different things ? You and Julian appear to be arguing that because existing parsers can handle both forms, there's no problem with allowing generators to generate both forms. I am arguing that simplicity says that we should tell generators to only generate one form. The fact that parsers can already handle this is a good thing. In addition, this spec suggests that proxies might want to selectively *remove* stuff that had been added by earlier proxies. Is that already done for other header fields? Isn't it simpler to explain the removal process if there's only one way for the information to appear? Barry From julian.reschke@gmx.de Tue Jul 3 12:15:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A0B11E8195 for ; Tue, 3 Jul 2012 12:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.15 X-Spam-Level: X-Spam-Status: No, score=-105.15 tagged_above=-999 required=5 tests=[AWL=-2.551, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAmP0V9aN-60 for ; Tue, 3 Jul 2012 12:15:13 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id AA58211E8186 for ; Tue, 3 Jul 2012 12:15:12 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 19:15:19 -0000 Received: from p5DD96484.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.100.132] by mail.gmx.net (mp016) with SMTP; 03 Jul 2012 21:15:19 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+wxTcnkuyw6XMF883K47VZoR+YlsQoJ6OZ3ALogj iBXc7JGMjCFWfB Message-ID: <4FF344C5.6000105@gmx.de> Date: Tue, 03 Jul 2012 21:15:17 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Barry Leiba References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> <20120703190401.GL17454@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 19:15:14 -0000 On 2012-07-03 21:08, Barry Leiba wrote: >>> Consistency. THAT is where the consistency comes in. >> >> Barry, the consistency comes from the reuse of existing parsers and the >> syntax already in use with other header fields. Or maybe we're all discussing >> different things ? > > You and Julian appear to be arguing that because existing parsers can > handle both forms, there's no problem with allowing generators to > generate both forms. That's only part of the argument. > I am arguing that simplicity says that we should tell generators to > only generate one form. The fact that parsers can already handle this > is a good thing. Telling generators to produce only one form requires them to either special case the new header field (bad), or change their habits for all existing header fields as well (even worse). Also, I think we have seen that there are reasons for both formats; sometimes it's easier to insert a new header field instance, sometimes it's easier to append to a field value. There's really no reason to require a specific format. > In addition, this spec suggests that proxies might want to selectively > *remove* stuff that had been added by earlier proxies. Is that > already done for other header fields? Isn't it simpler to explain the > removal process if there's only one way for the information to appear? Removing things is specific to this header field; so I don't have a "consistency" argument here. Yes, it probably would be easier to explain, but no, as the proxy as recipient needs to understand both forms anyway that's a complication the spec needs to deal with. Best regards, Julian From barryleiba@gmail.com Tue Jul 3 12:18:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6126211E8195 for ; Tue, 3 Jul 2012 12:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.45 X-Spam-Level: X-Spam-Status: No, score=-103.45 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGmN9zkXqjSM for ; Tue, 3 Jul 2012 12:18:34 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF1911E81AC for ; Tue, 3 Jul 2012 12:18:34 -0700 (PDT) Received: by qadz3 with SMTP id z3so2844288qad.10 for ; Tue, 03 Jul 2012 12:18:43 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0NwRe/f7taF5zXyT3lub/X0TpE/IrL1YyB44RhenBcU=; b=mWENNcFibvBVZ3utfIDyyF15TpdQYo0RHye93QsqfXDneBsUrEAoydn7gcUpBF8KnU P6Ef9+9R20n2swTLXu0lE6hH+uVIZ4RlLPPYPPZ/0D5Z4s4S+HHkiKNDVJgf3hqnluWL zTyfsMQSmZsEHA/VpuFgnCxixkAHLDfmeHC2o1UIySa4Hyn7CdSFDI8pZOkYgZ/nbbLx WhYrRXzrDpnkK7ch9SAnWIFaqrl/Y1JrcyWHZHtV2SwJzviu9iLWGZFaluFHrmIc5ElX FRtyUcwXVEekU+rDZNkEXm0aAKHTBprim9tVl5gxA9BgcqXJ7FxIXiq72yN7powj8eBF +ifA== MIME-Version: 1.0 Received: by 10.224.40.2 with SMTP id i2mr32571202qae.62.1341343122943; Tue, 03 Jul 2012 12:18:42 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Tue, 3 Jul 2012 12:18:42 -0700 (PDT) In-Reply-To: <4FF344C5.6000105@gmx.de> References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> <20120703190401.GL17454@1wt.eu> <4FF344C5.6000105@gmx.de> Date: Tue, 3 Jul 2012 15:18:42 -0400 X-Google-Sender-Auth: G8Y9r2PTG62DY23OLI2mg9nODMg Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 19:18:35 -0000 > Telling generators to produce only one form requires them to either special > case the new header field (bad), Ack. This makes sense. > or change their habits for all existing header fields as well (even worse). Well, I hardly see how that's bad at all, much less worse. Still... > Also, I think we have seen that there are reasons for both formats; > sometimes it's easier to insert a new header field instance, sometimes it's > easier to append to a field value. "Easier"? Easier how? > Removing things is specific to this header field; so I don't have a > "consistency" argument here. Yes, it probably would be easier to explain, > but no, as the proxy as recipient needs to understand both forms anyway > that's a complication the spec needs to deal with. I completely disagree here. The proxy needs to understand how to parse both types of fields, but does NOT already need to know how to delete information from an existing field. It's much easier both to understand and to code the removal of a header field than to deal with the selective deletion of information from a field. Barry From w@1wt.eu Tue Jul 3 12:18:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1848411E81AF for ; Tue, 3 Jul 2012 12:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.412 X-Spam-Level: X-Spam-Status: No, score=-5.412 tagged_above=-999 required=5 tests=[AWL=-3.369, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox6dU4p9iSAS for ; Tue, 3 Jul 2012 12:18:56 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 1148111E80F2 for ; Tue, 3 Jul 2012 12:18:55 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q63JIwMX017973; Tue, 3 Jul 2012 21:18:58 +0200 Date: Tue, 3 Jul 2012 21:18:58 +0200 From: Willy Tarreau To: Julian Reschke Message-ID: <20120703191858.GM17454@1wt.eu> References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> <20120703190401.GL17454@1wt.eu> <4FF344C5.6000105@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FF344C5.6000105@gmx.de> User-Agent: Mutt/1.4.2.3i Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 19:18:57 -0000 On Tue, Jul 03, 2012 at 09:15:17PM +0200, Julian Reschke wrote: > On 2012-07-03 21:08, Barry Leiba wrote: > >>>Consistency. THAT is where the consistency comes in. > >> > >>Barry, the consistency comes from the reuse of existing parsers and the > >>syntax already in use with other header fields. Or maybe we're all > >>discussing > >>different things ? > > > >You and Julian appear to be arguing that because existing parsers can > >handle both forms, there's no problem with allowing generators to > >generate both forms. > > That's only part of the argument. > > >I am arguing that simplicity says that we should tell generators to > >only generate one form. The fact that parsers can already handle this > >is a good thing. > > Telling generators to produce only one form requires them to either > special case the new header field (bad), or change their habits for all > existing header fields as well (even worse). Exactly. And it does not tell what an intermediary which receives both forms despite the spec should do with it ! We already have this issue with the non-foldable Set-Cookie header which is handled as an exception in every parser, please do not add a second one ! Regards, Willy From w@1wt.eu Tue Jul 3 12:22:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A3B11E81C1 for ; Tue, 3 Jul 2012 12:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.152 X-Spam-Level: X-Spam-Status: No, score=-5.152 tagged_above=-999 required=5 tests=[AWL=-3.109, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUxvSYMIzFdl for ; Tue, 3 Jul 2012 12:21:56 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id EEF2611E81B6 for ; Tue, 3 Jul 2012 12:21:55 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q63JM1KC018027; Tue, 3 Jul 2012 21:22:01 +0200 Date: Tue, 3 Jul 2012 21:22:01 +0200 From: Willy Tarreau To: Barry Leiba Message-ID: <20120703192201.GN17454@1wt.eu> References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> <20120703190401.GL17454@1wt.eu> <4FF344C5.6000105@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Julian Reschke , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 19:22:03 -0000 On Tue, Jul 03, 2012 at 03:18:42PM -0400, Barry Leiba wrote: > > Also, I think we have seen that there are reasons for both formats; > > sometimes it's easier to insert a new header field instance, sometimes it's > > easier to append to a field value. > > "Easier"? Easier how? Some do simply append a header field. Other ones would rather apply a regex to an existing header. It all depends on the proxy's abilities after all. > > Removing things is specific to this header field; so I don't have a > > "consistency" argument here. Yes, it probably would be easier to explain, > > but no, as the proxy as recipient needs to understand both forms anyway > > that's a complication the spec needs to deal with. > > I completely disagree here. The proxy needs to understand how to > parse both types of fields, but does NOT already need to know how to > delete information from an existing field. It's much easier both to > understand and to code the removal of a header field than to deal with > the selective deletion of information from a field. Depends. I'm used to see people process headers with regex that are declared in their configurations. You need not to stick to code, config is a large part of header handling. Regards, Willy From barryleiba@gmail.com Tue Jul 3 12:23:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FFB21F871D for ; Tue, 3 Jul 2012 12:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.391 X-Spam-Level: X-Spam-Status: No, score=-103.391 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDYUzAtDpnEe for ; Tue, 3 Jul 2012 12:23:47 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B23A421F8718 for ; Tue, 3 Jul 2012 12:23:46 -0700 (PDT) Received: by qcac10 with SMTP id c10so3227563qca.31 for ; Tue, 03 Jul 2012 12:23:55 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Z0AqDFwZh8mx2WkKftQFDEXedbFvGiOWzXCbgOPf0FE=; b=GdAyl9ILg4147b4gTh/DXvdgDfkU3iII0UsA9xTr/dXX/5aYGxLkQGDt6uVFNGxxLb RWhcsnWRx0MjKmPIGWkaMd3xERyQ7WcGQYJTtmi0ud/wii5uzs499PXfcprVU/Z3mGfX 4HGj60pngTslDprhg893U/yV955MPjZv1UFBDeMYmbTYvVoqiS+vIQpQHOlfe7utcoHW HNU6tTZL2RK6AIp7fHusnZnXJtRkJwat0xuiR65JDnckmGNLoePUo4oFhO5VZRtbfGV6 ofNERpMIhimQ4UZw3VMCdHuBro6Lro5CDjEwWFGiJYPHssMv5E2RyO3faFcYIuC5ZTZD JsfA== MIME-Version: 1.0 Received: by 10.224.187.11 with SMTP id cu11mr32668465qab.24.1341343434838; Tue, 03 Jul 2012 12:23:54 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Tue, 3 Jul 2012 12:23:54 -0700 (PDT) In-Reply-To: <20120703191858.GM17454@1wt.eu> References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> <20120703190401.GL17454@1wt.eu> <4FF344C5.6000105@gmx.de> <20120703191858.GM17454@1wt.eu> Date: Tue, 3 Jul 2012 15:23:54 -0400 X-Google-Sender-Auth: dysskOR-kgMcLUlcOUClwhATAgc Message-ID: From: Barry Leiba To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Cc: Julian Reschke , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 19:23:48 -0000 > Exactly. And it does not tell what an intermediary which receives both > forms despite the spec should do with it ! We already have this issue > with the non-foldable Set-Cookie header which is handled as an exception > in every parser, please do not add a second one ! Ack. I want to say that we can't design protocols based on the expectation of faulty implementations, but I've been in the email world too long to be that casual about it. This makes sense. Barry From julian.reschke@gmx.de Tue Jul 3 12:28:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B69611E81C0 for ; Tue, 3 Jul 2012 12:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.02 X-Spam-Level: X-Spam-Status: No, score=-105.02 tagged_above=-999 required=5 tests=[AWL=-2.421, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZtCtORPCbkc for ; Tue, 3 Jul 2012 12:28:16 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D84FA11E8170 for ; Tue, 3 Jul 2012 12:28:14 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 19:28:22 -0000 Received: from p5DD96484.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.100.132] by mail.gmx.net (mp041) with SMTP; 03 Jul 2012 21:28:22 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19FHsV/LRpF6nFyCp9hUQBJAtlLHEn2h/fjMsHZ/y aVmOGFsMgDv3Wl Message-ID: <4FF347D3.7000905@gmx.de> Date: Tue, 03 Jul 2012 21:28:19 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Barry Leiba References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> <20120703190401.GL17454@1wt.eu> <4FF344C5.6000105@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 19:28:16 -0000 On 2012-07-03 21:18, Barry Leiba wrote: >> Telling generators to produce only one form requires them to either special >> case the new header field (bad), > > Ack. This makes sense. > >> or change their habits for all existing header fields as well (even worse). > > Well, I hardly see how that's bad at all, much less worse. Still... Do you believe people will change existing HTTP header field libraries just to accommodate a new requirement in this spec? >> Also, I think we have seen that there are reasons for both formats; >> sometimes it's easier to insert a new header field instance, sometimes it's >> easier to append to a field value. > > "Easier"? Easier how? It depends on the implementation. >> Removing things is specific to this header field; so I don't have a >> "consistency" argument here. Yes, it probably would be easier to explain, >> but no, as the proxy as recipient needs to understand both forms anyway >> that's a complication the spec needs to deal with. > > I completely disagree here. The proxy needs to understand how to > parse both types of fields, but does NOT already need to know how to > delete information from an existing field. It's much easier both to > understand and to code the removal of a header field than to deal with > the selective deletion of information from a field. Conceptually, the proxy needs to parse the header field instances into an ordered list of forwarded-element, remove what it wants to remove, add what it wants to add, then reserialize. This is all the spec needs to say. Best regards, Julian From barryleiba@gmail.com Tue Jul 3 12:32:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC68411E81D7 for ; Tue, 3 Jul 2012 12:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.345 X-Spam-Level: X-Spam-Status: No, score=-103.345 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSe9OuBIFvrL for ; Tue, 3 Jul 2012 12:32:33 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5834211E81BE for ; Tue, 3 Jul 2012 12:32:33 -0700 (PDT) Received: by qadz3 with SMTP id z3so2851870qad.10 for ; Tue, 03 Jul 2012 12:32:41 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=D8uadfSlZ+M/0lKVjPbN8N+/EN2im2cPInoxGwVXyh8=; b=N1kbs66pH2YZZkQh8I7mgqpy8PpnILguFQ8wFKa6iv77vZZDVEm8JZBgZbbeylElNo Wa5mzQENJ1OPu2Pz5bbGMtsX60Exoursk8eTyIYtDME3Qb4I/KSjDM9OILb4eqcwRS/1 kYNNVi3oCfQq4M+qVQHR6tld15HV2jHGo3rCRgY2xk1bR0Sa3uggB7kIb1jjFmkuR+ds GxNxEXcWtrcQY7GTNN6RH1HB/MHJAtfPyQODalIAhYwcEsrB3IcBsjN3ucK35hmoRri+ ksa2IXVQOyb+nvZgTY/0zZ+q0p9f7KNj0NO+Cj5nyRbxdbXciT62m1fcbgTId/AVaJXc iQkw== MIME-Version: 1.0 Received: by 10.229.137.9 with SMTP id u9mr9583654qct.107.1341343961543; Tue, 03 Jul 2012 12:32:41 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Tue, 3 Jul 2012 12:32:41 -0700 (PDT) In-Reply-To: <4FF347D3.7000905@gmx.de> References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> <20120703190401.GL17454@1wt.eu> <4FF344C5.6000105@gmx.de> <4FF347D3.7000905@gmx.de> Date: Tue, 3 Jul 2012 15:32:41 -0400 X-Google-Sender-Auth: IEZkKqcFpIsukUBFdGLyA7avM3k Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 19:32:34 -0000 >>> or change their habits for all existing header fields as well (even >>> worse). >> >> Well, I hardly see how that's bad at all, much less worse. Still... > > Do you believe people will change existing HTTP header field libraries just > to accommodate a new requirement in this spec? That's not the point: you're saying it would be *bad* if they did; I don't see how. >>> Also, I think we have seen that there are reasons for both formats; >>> sometimes it's easier to insert a new header field instance, sometimes >>> it's easier to append to a field value. >> >> "Easier"? Easier how? > > It depends on the implementation. That is not an answer. >>> Removing things is specific to this header field; so I don't have a >>> "consistency" argument here. Yes, it probably would be easier to explain, >>> but no, as the proxy as recipient needs to understand both forms anyway >>> that's a complication the spec needs to deal with. >> >> I completely disagree here. The proxy needs to understand how to >> parse both types of fields, but does NOT already need to know how to >> delete information from an existing field. It's much easier both to >> understand and to code the removal of a header field than to deal with >> the selective deletion of information from a field. > > Conceptually, the proxy needs to parse the header field instances into an > ordered list of forwarded-element, remove what it wants to remove, add what > it wants to add, then reserialize. This is all the spec needs to say. I understand how I would implement it. But you can't really argue that it's easier to code that (and test it and debug it) than it is to simple remove an entire header field, can you? Barry From julian.reschke@gmx.de Tue Jul 3 12:48:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D4921F8762 for ; Tue, 3 Jul 2012 12:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.901 X-Spam-Level: X-Spam-Status: No, score=-104.901 tagged_above=-999 required=5 tests=[AWL=-2.302, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo7IFUk6i1B3 for ; Tue, 3 Jul 2012 12:48:58 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E8CB821F8759 for ; Tue, 3 Jul 2012 12:48:57 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2012 19:49:04 -0000 Received: from p5DD96484.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.100.132] by mail.gmx.net (mp027) with SMTP; 03 Jul 2012 21:49:04 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19KoFhBT6BKTCzUiqcVcI1o6UcSoXBaLEhiYXdyLL mEgWclqQyPJDxB Message-ID: <4FF34CAE.5020302@gmx.de> Date: Tue, 03 Jul 2012 21:49:02 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Barry Leiba References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> <20120703190401.GL17454@1wt.eu> <4FF344C5.6000105@gmx.de> <4FF347D3.7000905@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 19:48:59 -0000 On 2012-07-03 21:32, Barry Leiba wrote: >>>> or change their habits for all existing header fields as well (even >>>> worse). >>> >>> Well, I hardly see how that's bad at all, much less worse. Still... >> >> Do you believe people will change existing HTTP header field libraries just >> to accommodate a new requirement in this spec? > > That's not the point: you're saying it would be *bad* if they did; I > don't see how. What if another header field definition prefers the other notation? >>>> Also, I think we have seen that there are reasons for both formats; >>>> sometimes it's easier to insert a new header field instance, sometimes >>>> it's easier to append to a field value. >>> >>> "Easier"? Easier how? >> >> It depends on the implementation. > > That is not an answer. Sorry, I don't know how to explain it better. It simply depends on the way an implementation represents header data. >>>> Removing things is specific to this header field; so I don't have a >>>> "consistency" argument here. Yes, it probably would be easier to explain, >>>> but no, as the proxy as recipient needs to understand both forms anyway >>>> that's a complication the spec needs to deal with. >>> >>> I completely disagree here. The proxy needs to understand how to >>> parse both types of fields, but does NOT already need to know how to >>> delete information from an existing field. It's much easier both to >>> understand and to code the removal of a header field than to deal with >>> the selective deletion of information from a field. >> >> Conceptually, the proxy needs to parse the header field instances into an >> ordered list of forwarded-element, remove what it wants to remove, add what >> it wants to add, then reserialize. This is all the spec needs to say. > > I understand how I would implement it. But you can't really argue > that it's easier to code that (and test it and debug it) than it is to > simple remove an entire header field, can you? If the recipient uses a proper header field parser, it doesn't matter, because it will execute exactly the same methods to remove an entry. If it does not, it's *probably* easier to drop a header field instance. That being said, a proxy is a recipient as well, so it can't *rely* on the format, so I'm not sure how this helps. Manipulating HTTP messages *properly* is non-trivial; I don't believe that trying to add more special cases will do anything except making things worse. Best regards, Julian From barryleiba@gmail.com Tue Jul 3 13:09:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB17E11E80CC for ; Tue, 3 Jul 2012 13:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.308 X-Spam-Level: X-Spam-Status: No, score=-103.308 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-tgZC6seNFM for ; Tue, 3 Jul 2012 13:09:59 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE3C11E80CA for ; Tue, 3 Jul 2012 13:09:58 -0700 (PDT) Received: by qaea16 with SMTP id a16so2872629qae.10 for ; Tue, 03 Jul 2012 13:10: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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8/RQX3mb4nY8RtkbPHrH1+vp3I28yPaNO4jNeec0D7s=; b=aPh0mYVFA4RMR5xTU82Vjk8IfyAe6M9qjVKIR7fslwmOUw0B4x1f0b7uswqcUHKcPo qDUqkJlWy8q2cYxyV2TitnBRQRzAp06QOaWeLssAj6R1P56Gov25rU4Aae4hOJAyZw3l +boU0DTZe+7wNgofBB7dnLInBQaUhnsqCFBD0gvcjFT/vPfL0/8L9jElyFyNSkY3DExx 4NN1n4OEpei5G1rMgbIh1ueeLYq8UTE9KDJqnKWClyYffOmnZW2C8wDXTVD0JDfdRwUs NsvuxNTQJQmduYz5HtAaEfdYZgoj3KdAOgPDDOGjhFKrmCQj6B+vc2/yJiivSnHzUXuh Mo9g== MIME-Version: 1.0 Received: by 10.224.187.11 with SMTP id cu11mr32972590qab.24.1341346207240; Tue, 03 Jul 2012 13:10:07 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Tue, 3 Jul 2012 13:10:07 -0700 (PDT) In-Reply-To: <4FF34CAE.5020302@gmx.de> References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> <20120703190401.GL17454@1wt.eu> <4FF344C5.6000105@gmx.de> <4FF347D3.7000905@gmx.de> <4FF34CAE.5020302@gmx.de> Date: Tue, 3 Jul 2012 16:10:07 -0400 X-Google-Sender-Auth: tE1IXn7gGhnLhUbkbLbIW2Kms6k Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 20:10:00 -0000 > Manipulating HTTP messages *properly* is non-trivial; I don't believe that > trying to add more special cases will do anything except making things > worse. Ack. OK, I think Julian, Willy, and I have exhausted ourselves on this. :-) Any comments from others? Barry From ve7jtb@ve7jtb.com Tue Jul 3 13:18:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE7521F85D2 for ; Tue, 3 Jul 2012 13:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAtO-XhPZnql for ; Tue, 3 Jul 2012 13:18:00 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 598BD21F85D0 for ; Tue, 3 Jul 2012 13:18:00 -0700 (PDT) Received: by yenq13 with SMTP id q13so6332373yen.31 for ; Tue, 03 Jul 2012 13:18:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=OUKH/bcFCNQsSO16MtrTyro5tVcC9rGPPl0tYZFdTAM=; b=D/fvUzcmhjuysxZcR7HMq1dWV0oinSU86O8IieBhQW2zucbx6fOLf5G2OE3aiiEKQV mDrhuojRwLXCLOofLsVFXLDkdSTJ4nXdPtWVVN7PhQE/OwFVhEcGUNOwg0wExIzFgVSz diw1M+wX8fKSSzNu6mhwsmmtyniFgJLXoVu2pWSObBr/meiDgkRjN3+sh3pS9KnLamdE QRzgauqPHK6rdHLWSG95F0xl1mzVl5Oa4tSu7sK920wXqBjaNqnfwHpYclCdm2W7BsYq hD1W44irnFiBTX1u5q7gmCZLUdDq+wyjVTyUh/y9tp8PNC7cwCWr2x3SYBTVu/i6y+pi YRJw== Received: by 10.236.46.195 with SMTP id r43mr22187993yhb.86.1341346688757; Tue, 03 Jul 2012 13:18:08 -0700 (PDT) Received: from [192.168.1.211] (190-20-40-193.baf.movistar.cl. [190.20.40.193]) by mx.google.com with ESMTPS id p29sm33542074yhl.19.2012.07.03.13.17.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jul 2012 13:18:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_2F55BA95-3CED-4265-9C6E-27BCE2E6FC16"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Tue, 3 Jul 2012 16:17:32 -0400 Message-Id: <911C1091-6D88-4937-BF4C-0FCB264B6AEF@ve7jtb.com> References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <1A87B9DE-ECEC-4F07-8734-131D4BB564EB@ve7jtb.com> To: Barry Leiba X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlSBbkZQz7xfJK5lqGbvqGkX/M7BVYi6A9JkNBzWGOwniBDOpzBcP6Tc/OZjUiZfgzuQveQ Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 20:18:01 -0000 --Apple-Mail=_2F55BA95-3CED-4265-9C6E-27BCE2E6FC16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 There are existing deployments of WF. Changes that lead to something = incompatible with what is deployed=20 are likely to receive more resistance, now that we have a WG draft. Not that changes can't be made with rough consensus.. =20 It may have been easier though to have had Mark and others comments = before the WG draft. That might have made it easier to have included some more of the SWD = design. That is however water under the bridge, and we have an initial document = that is backwards compatible with WF as deployed. John B. On 2012-07-03, at 2:41 PM, Barry Leiba wrote: >> Now that WF has been accepted by the chairs as a WG draft it gets = harder to >> make breaking changes. >=20 > I'm not sure what you mean by "breaking changes", but I don't see that > having the document be a working group product undermines the ability > to suggest any change for which there has not already been a decision > against. If your suggestion develops rough consensus, then it will be > included. If not, then it won't. >=20 > To avoid the flogging of dead horses, the chairs may declare some > topics out of scope if those topics have already been firmly decided. > But that, too, is standard procedure. >=20 > Barry --Apple-Mail=_2F55BA95-3CED-4265-9C6E-27BCE2E6FC16 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw MzIwMTczMlowIwYJKoZIhvcNAQkEMRYEFM1OAoD98LM3u8IaiidtMG5K60IkMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AFwAU041ebJQ7S1KXUIhcUs45+xv2St8+wzRQzlYpSvs81FFJvbxq8S27nrtahDPc/Z4MOZh6JTS eXkEodrb3yOtBfhotlxGFL/+hI20l2YVwjwGO4IOp+wTXYDoBqljAi++984JjEQ01ES0sru3EE9C hi2Y76I6dJPZtAM8eTD5t7fwE1woome5u1vF92QnNLE31JLqlzovclwCUrrjqM1oB7jq8wvO+4fg SzmOSuvU81tTOsJCuUVeVk+luF/T5fd0c2ZZrkkMJw0WGivE/DTkIqqNxKUfte3lt6JYjbwK5nwJ NY2kAvwaSq5WFacnv1cRuBNeFj7YiaIQ4WMSkEEAAAAAAAA= --Apple-Mail=_2F55BA95-3CED-4265-9C6E-27BCE2E6FC16-- From internet-drafts@ietf.org Tue Jul 3 13:28:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04AE11E8118; Tue, 3 Jul 2012 13:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+ZBWmLBgdYi; Tue, 3 Jul 2012 13:28:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F5411E80BC; Tue, 3 Jul 2012 13:28:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30 Message-ID: <20120703202842.10788.44079.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2012 13:28:42 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 20:28:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : JSON Pointer Author(s) : Paul C. Bryan Kris Zyp Mark Nottingham Filename : draft-ietf-appsawg-json-pointer-02.txt Pages : 7 Date : 2012-07-03 Abstract: JSON Pointer defines a string syntax for identifying a specific value within a JSON document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-pointer-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Jul 3 13:29:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BED11E8138; Tue, 3 Jul 2012 13:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhobQTVsaBbt; Tue, 3 Jul 2012 13:29:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B368211E80E8; Tue, 3 Jul 2012 13:29:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30 Message-ID: <20120703202915.9701.38875.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2012 13:29:15 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 20:29:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : JSON Patch Author(s) : Paul C. Bryan Mark Nottingham Filename : draft-ietf-appsawg-json-patch-02.txt Pages : 13 Date : 2012-07-03 Abstract: JSON Patch defines the media type "application/json-patch", a JSON document structure for expressing a sequence of operations to apply to a JSON document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-patch-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jasnell@gmail.com Tue Jul 3 14:27:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9983811E809C for ; Tue, 3 Jul 2012 14:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=-2.692, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAU7wHmrRf9S for ; Tue, 3 Jul 2012 14:27:35 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C23F321F87A8 for ; Tue, 3 Jul 2012 14:27:34 -0700 (PDT) Received: by werp11 with SMTP id p11so1901691wer.31 for ; Tue, 03 Jul 2012 14: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=yOkzOik1ySCIKiedDzUrIg+mjFfV9yt6NHdlMrhXTGE=; b=REu5UgDz2do08N8xzB/aD2qL9gtt25lwKLcn+/YlO/ivAtXEgA+t66bxQGMEqnfsr7 E8zL9l34OBc53cauNlTrN/lSG9ctRRvG6Qlps2NZWeWFQ4AkHVY+zD/kei4cZyqOWKib w2VIP7VywHQXfbTMIFB12B/LK/Yovzn74FpNs86/KHPWWQdnfEk3TLsTCol8wY8eT5mg TKqb5EowQvjICZrVwy2v9xUX9L/JwzxM02FLn6IBIGjgauN06MwV+g1uDizeE0zqH0cY hsUOTr3v+CGd45Qd00EDeKylNv4ILJM9gT+6/tQtaxUHzpHz+SFwqfwe9MtB/IEv2L4j D/2Q== Received: by 10.216.209.95 with SMTP id r73mr5126889weo.157.1341350862813; Tue, 03 Jul 2012 14:27:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.67 with HTTP; Tue, 3 Jul 2012 14:27:22 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> From: James M Snell Date: Tue, 3 Jul 2012 14:27:22 -0700 Message-ID: To: Mike Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 21:27:36 -0000 Great to see this conversation coming up... A couple of months ago I posted a few thoughts on WebFinger on my personal blog [1]... I've copied the relevant bits here for discussion. The short summary: WebFinger is ok but can be made so much simpler. [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html ... Ok... so [WebFinger] seems simple enough, but can we make it even simpler? I think we definitely can. Let's start by eliminating the requirement to use XRD. Look at the first response... what is the XRD document giving us? A Link. One Link. Ok, not really a Link, but a URI Template. Wait, so that's two things we I actually need to process before I can actually look up information about the user "bob"... let's eliminate both of those things and simply provide a means of looking up information about the user directly.. for instance: GET /.well-known/finger/acct%3Abob%40example.org HTTP/1.1 Host: example.org If we still need to know things about the domain, then we can finger that domain... GET /.well-known/finger/example.org HTTP/1.1 Host: example.org But looking up basic information about the user should not be predicated on first looking up basic information about the domain. Those can, and should, be two completely separate tasks. There is a problem here, however. A big problem actually. Many enterprises frown on putting things that look like email addresses into URLs because of fairly significant privacy concerns. So let's change that, instead of passing the acct: ID directly, we'll pass a hash of the acct id.. much more secure and private that way... GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 Host: example.org Ah, that's better... and in the process I managed to eliminate about a third of what the WebFinger draft currently requires. It boils down to nothing more than this: If I want to know something about user "bob@example.org", I sent a GET request to http://example.org/.well-known/finger/{md5("bob@example.org")} and see what I get back. No absolute need to parse any XML. No need to process any URI Templates. No need to define special query string parameters. Keep it very simple and we're essentially done. Ok, so what about the response from the server? What would that look like? Currently, WebFinger requires that the response has to either be XRD or this other thing called JRD. While I don't have any problem with using either of those particular formats, I do not believe that the WebFinger spec needs to declare that any format MUST be supported. It should be up to the server to provide whatever format it wishes. The client can determine if it's able to get what it's needs from the provided format or not. If the response is HTML and includes Link or Anchor elements that use appropriately labelled rel attribute values, then the client should be able to get the information it needs; if the response is JSON and includes appropriately labeled information in a way the client can understand, then great. That's what we have things like the Accept request header for... GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 Host: example.org Accept: application/xrd+xml, text/html, application/atom+xml The client can tell the server what format it would like and the server can respond appropriately. These mechanism are widely used and the abstract notion of a Link is fairly universal now and easily represented in multiple formats. The response to the above request could very well be as simple as: HTTP/1.1 204 No Content Link: ; rel=3D"blog", ; rel=3D"profile", ; rel=3D"avatar" Sure, this hypothetical type of response may be impractical if a particular user has a significantly large number of links associated with it, but (a) realistically most users won't have that many at any single service and (b) this is just an example, I did say that I have no problem with XRD/JRD being used... it just shouldn't be required. Another possibility. Just to stretch the imagination a bit more. Suppose I want to know the location of the user's blog and I send this for a request: GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1.1 Host: example.org Note the addition of the "/blog" at the end of the request URI. Let's just say that the last little bit there is a rel value. If the user has only a single rel=3D"blog" Link, then the server can tell me where it is with a simple redirect: HTTP/1.1 302 Found Location: http://blogs.example.org/bob If there happen to be multiple "blog" links associated with that particular user, then the server can tell me about all of them... HTTP/1.1 300 Multiple Choices Location: http://blogs.example.org/bobs_default_blog Link: ; rel=3D"blog", ; rel=3D"blog" What if I want to know about some other kind of Link associated with the user... well, I simply replace "/blog" with the other rel attribute value... GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard HTTP/1.1 Host: example.org GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar HTTP/1.= 1 Host: example.org GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/ http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fprovider HTTP/1.1 Host: example.org Whatever specific link rel I want to know about, I just append that to the end. If I need to know about more than one, separate them by a comma: GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard,avatar HTTP/1.1 Host: example.org Which could return something along the lines of... HTTP/1.1 300 Multiple Choices Link: ; rel=3D"vcard", ; rel=3D"avatar" Or it could return an XRD or JRD... either way, it works just fine. The point is that it's MUCH simpler than what WebFinger defines and requires fewer moving parts (no required XML parsing, no required URI Template processing, no required querystring parameters, etc). With regards to security considerations, the original Finger protocol was quite problematic because of the potential for inappropriate disclosure of sensitive information about an account. The same basic concern would be applicable to WebFinger depending on what information was being made available for discovery. I've already dealt with one particular concern -- the use of an email-like identifier within the discovery URI... requiring a hash is a simple fix there. But what else can be done? Well, obviously, we're talking about a HTTP request here. When a requester sends an unauthenticated HTTP request to discover information about a user, the server can choose to respond with only the most basic generic and public information about the user and possibly some links to that user's public facing services (their blog, their avatar, etc). Mechanisms such as OAuth 2 can be employed, however, to support much more interesting scenarios. For instance, a trusted third party could acquire an OAuth 2 access token to request additional, more detailed information about a user... GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1.1 Host: example.org Authentication: Bearer {my_access_token} Such requests can be easily tracked, rate-limited, etc, making the protocol generally much more reliable and secure than the original finger protocol. Unfortunately, the current WebFinger specification does not adequately address this particular concern. .... - James On Tue, Jul 3, 2012 at 12:24 AM, Mike Jones w= rote: > You've essentially described Simple Web Discovery! It avoids the complic= ations introduced by host-meta exactly by using its own .well-known value. = The basic example is: > > GET /.well-known/simple-web-discovery?principal=3Dmailto:joe@example.c= om&service=3Durn:example.org:service:calendar HTTP/1.1 > Host: example.com > > HTTP/1.1 200 OK > Content-Type: application/json > > { > "locations": ["http://calendars.example.net/calendars/joseph"] > } > > See http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 for mo= re details. By design, there aren't many... > > -- Mike > > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Mark Nottingham > Sent: Monday, July 02, 2012 10:47 PM > To: IETF Apps Discuss > Subject: [apps-discuss] Looking at Webfinger > > I've pretty much ignored the whole webfinger / acct: / SWD discussion (to= o much!). However, since it's apparent it may soon become Real, I had a loo= k. > > In a nutshell, my initial reaction is "It's Not Nearly As Bad As I Though= t It Would Be." :) > > With that in mind, a few questions / comments (I'll resist going into edi= torial matters, for the time being): > > * First and foremost, why use host-meta? What value does adding this extr= a step to the dance bring, beyond "We've defined it, therefore we must use = it?" > > As I think I've said many times before, the whole point of a .well-known = URI is to group like uses together, to avoid having a "dictionary" resource= that gets bloated with many application's unrelated data, thereby overburd= ening clients with too much information (especially when they're constraine= d, e.g., mobile). > > As such, host-meta is a spectacularly bad example of a well-known URI. De= fining a end-all-be-all well-known-URI kind of removes the point of having = a registry, after all... > > Instead, why not just define a NEW well-known URI for user data? That has= a more constrained scope, and saves one round trip (or more). E.g., > > GET /.well-known/webfinger?user=3Dbob%40example.com HTTP/1.0 > Host: example.com > > I.e., let webfinger define the URI template to use. Yes, some implementat= ions might want to come up with crazy URIs, but is that really a problem we= want to solve? > > Astute observers will notice that this approach removes the need for an A= CCT URI scheme (at least here). > > > * What's the fascination with XRD and JRD? These specifications seem to b= e creeping into IETF architecture; first it was in a pure security context,= but now folks are talking about using them in a much more generic way, as = a cornerstone of what we do. As such, I think they deserve a MUCH closer lo= ok, especially since we're defining things with "Web" in their name when th= e W3C has already defined solutions in this space. > > Thanks, > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > 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 hallam@gmail.com Tue Jul 3 15:29:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588C111E80D3 for ; Tue, 3 Jul 2012 15:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieI17mrZlHSB for ; Tue, 3 Jul 2012 15:29:02 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6C211E8098 for ; Tue, 3 Jul 2012 15:28:58 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12032937obb.31 for ; Tue, 03 Jul 2012 15:29:07 -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=aZzHGKRQc/j/dm/u/VYvfAETyxMZ5sau37hQP3c8m28=; b=BKeinndylY7SpW5i2PNNWuyPAvo//F7encINGOTfPArXsjYL6WFw6E1sbMKTaDFboF toed5LaCEJsgiDPTJgLkaIKjnwc7cjuPEU4Sw+96z9i627Xk29j1qhJE7z5T0SHAW1be OrZiU6v8At9u4cJ3BtI4Vu+7S+Dshgwe4CdGwzi3QUQM5tFYzKytpr9IX5E+bBwinBV/ ymYTAdc3Cikvz7RSEQmyqy1iecMtGANIYr2SaQZoveCQC05c5YpLM+VLABw/ekCV3y0O 9zvpYKL+iu9g9kUft1lhRrD4veczKKs1QmWCDPkjM+A1C5zVlIZjlRXhERYUL0iNjPzY 8PSQ== MIME-Version: 1.0 Received: by 10.182.74.68 with SMTP id r4mr14895245obv.31.1341354547730; Tue, 03 Jul 2012 15:29:07 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Tue, 3 Jul 2012 15:29:07 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 3 Jul 2012 18:29:07 -0400 Message-ID: From: Phillip Hallam-Baker To: James M Snell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 22:29:04 -0000 What are the PR encumbrances of XRD? The XRI folk never gave me a straight answer, it is all tainted until there is an explicit statement AFIK. On Tue, Jul 3, 2012 at 5:27 PM, James M Snell wrote: > Great to see this conversation coming up... A couple of months ago I > posted a few thoughts on WebFinger on my personal blog [1]... I've > copied the relevant bits here for discussion. The short summary: > WebFinger is ok but can be made so much simpler. > > [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html > > ... > Ok... so [WebFinger] seems simple enough, but can we make it even > simpler? I think we definitely can. Let's start by eliminating the > requirement to use XRD. Look at the first response... what is the XRD > document giving us? A Link. One Link. Ok, not really a Link, but a URI > Template. Wait, so that's two things we I actually need to process > before I can actually look up information about the user "bob"... > let's eliminate both of those things and simply provide a means of > looking up information about the user directly.. for instance: > > GET /.well-known/finger/acct%3Abob%40example.org HTTP/1.1 > Host: example.org > > If we still need to know things about the domain, then we can finger > that domain... > > GET /.well-known/finger/example.org HTTP/1.1 > Host: example.org > > But looking up basic information about the user should not be > predicated on first looking up basic information about the domain. > Those can, and should, be two completely separate tasks. > > There is a problem here, however. A big problem actually. Many > enterprises frown on putting things that look like email addresses > into URLs because of fairly significant privacy concerns. So let's > change that, instead of passing the acct: ID directly, we'll pass a > hash of the acct id.. much more secure and private that way... > > GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 > Host: example.org > > Ah, that's better... and in the process I managed to eliminate about a > third of what the WebFinger draft currently requires. > > It boils down to nothing more than this: > If I want to know something about user "bob@example.org", I sent a GET > request to http://example.org/.well-known/finger/{md5("bob@example.org")} > and see what I get back. No absolute need to parse any XML. No need to > process any URI Templates. No need to define special query string > parameters. Keep it very simple and we're essentially done. > > Ok, so what about the response from the server? What would that look > like? Currently, WebFinger requires that the response has to either be > XRD or this other thing called JRD. While I don't have any problem > with using either of those particular formats, I do not believe that > the WebFinger spec needs to declare that any format MUST be supported. > It should be up to the server to provide whatever format it wishes. > The client can determine if it's able to get what it's needs from the > provided format or not. If the response is HTML and includes Link or > Anchor elements that use appropriately labelled rel attribute values, > then the client should be able to get the information it needs; if the > response is JSON and includes appropriately labeled information in a > way the client can understand, then great. That's what we have things > like the Accept request header for... > > GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 > Host: example.org > Accept: application/xrd+xml, text/html, application/atom+xml > > The client can tell the server what format it would like and the > server can respond appropriately. These mechanism are widely used and > the abstract notion of a Link is fairly universal now and easily > represented in multiple formats. > > The response to the above request could very well be as simple as: > > HTTP/1.1 204 No Content > Link: ; rel=3D"blog", > ; rel=3D"profile", > ; rel=3D"avatar" > > Sure, this hypothetical type of response may be impractical if a > particular user has a significantly large number of links associated > with it, but (a) realistically most users won't have that many at any > single service and (b) this is just an example, I did say that I have > no problem with XRD/JRD being used... it just shouldn't be required. > > Another possibility. Just to stretch the imagination a bit more. > Suppose I want to know the location of the user's blog and I send this > for a request: > > GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1.1 > Host: example.org > > Note the addition of the "/blog" at the end of the request URI. Let's > just say that the last little bit there is a rel value. If the user > has only a single rel=3D"blog" Link, then the server can tell me where > it is with a simple redirect: > > HTTP/1.1 302 Found > Location: http://blogs.example.org/bob > > If there happen to be multiple "blog" links associated with that > particular user, then the server can tell me about all of them... > > HTTP/1.1 300 Multiple Choices > Location: http://blogs.example.org/bobs_default_blog > Link: ; rel=3D"blog", > ; rel=3D"blog" > > What if I want to know about some other kind of Link associated with > the user... well, I simply replace "/blog" with the other rel > attribute value... > > GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard HTTP/1= .1 > Host: example.org > > GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar HTTP/= 1.1 > Host: example.org > > GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/ > http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fprovider HTTP/1.1 > Host: example.org > > Whatever specific link rel I want to know about, I just append that to > the end. If I need to know about more than one, separate them by a > comma: > > GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard,avatar > HTTP/1.1 > Host: example.org > > Which could return something along the lines of... > > HTTP/1.1 300 Multiple Choices > Link: ; rel=3D"vcard", > ; rel=3D"avatar" > > Or it could return an XRD or JRD... either way, it works just fine. > The point is that it's MUCH simpler than what WebFinger defines and > requires fewer moving parts (no required XML parsing, no required URI > Template processing, no required querystring parameters, etc). > > With regards to security considerations, the original Finger protocol > was quite problematic because of the potential for inappropriate > disclosure of sensitive information about an account. The same basic > concern would be applicable to WebFinger depending on what information > was being made available for discovery. I've already dealt with one > particular concern -- the use of an email-like identifier within the > discovery URI... requiring a hash is a simple fix there. But what else > can be done? > > Well, obviously, we're talking about a HTTP request here. When a > requester sends an unauthenticated HTTP request to discover > information about a user, the server can choose to respond with only > the most basic generic and public information about the user and > possibly some links to that user's public facing services (their blog, > their avatar, etc). Mechanisms such as OAuth 2 can be employed, > however, to support much more interesting scenarios. For instance, a > trusted third party could acquire an OAuth 2 access token to request > additional, more detailed information about a user... > > GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1.1 > Host: example.org > Authentication: Bearer {my_access_token} > > Such requests can be easily tracked, rate-limited, etc, making the > protocol generally much more reliable and secure than the original > finger protocol. Unfortunately, the current WebFinger specification > does not adequately address this particular concern. > .... > > - James > > On Tue, Jul 3, 2012 at 12:24 AM, Mike Jones = wrote: >> You've essentially described Simple Web Discovery! It avoids the compli= cations introduced by host-meta exactly by using its own .well-known value.= The basic example is: >> >> GET /.well-known/simple-web-discovery?principal=3Dmailto:joe@example.= com&service=3Durn:example.org:service:calendar HTTP/1.1 >> Host: example.com >> >> HTTP/1.1 200 OK >> Content-Type: application/json >> >> { >> "locations": ["http://calendars.example.net/calendars/joseph"] >> } >> >> See http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 for m= ore details. By design, there aren't many... >> >> -- Mike >> >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.or= g] On Behalf Of Mark Nottingham >> Sent: Monday, July 02, 2012 10:47 PM >> To: IETF Apps Discuss >> Subject: [apps-discuss] Looking at Webfinger >> >> I've pretty much ignored the whole webfinger / acct: / SWD discussion (t= oo much!). However, since it's apparent it may soon become Real, I had a lo= ok. >> >> In a nutshell, my initial reaction is "It's Not Nearly As Bad As I Thoug= ht It Would Be." :) >> >> With that in mind, a few questions / comments (I'll resist going into ed= itorial matters, for the time being): >> >> * First and foremost, why use host-meta? What value does adding this ext= ra step to the dance bring, beyond "We've defined it, therefore we must use= it?" >> >> As I think I've said many times before, the whole point of a .well-known= URI is to group like uses together, to avoid having a "dictionary" resourc= e that gets bloated with many application's unrelated data, thereby overbur= dening clients with too much information (especially when they're constrain= ed, e.g., mobile). >> >> As such, host-meta is a spectacularly bad example of a well-known URI. D= efining a end-all-be-all well-known-URI kind of removes the point of having= a registry, after all... >> >> Instead, why not just define a NEW well-known URI for user data? That ha= s a more constrained scope, and saves one round trip (or more). E.g., >> >> GET /.well-known/webfinger?user=3Dbob%40example.com HTTP/1.0 >> Host: example.com >> >> I.e., let webfinger define the URI template to use. Yes, some implementa= tions might want to come up with crazy URIs, but is that really a problem w= e want to solve? >> >> Astute observers will notice that this approach removes the need for an = ACCT URI scheme (at least here). >> >> >> * What's the fascination with XRD and JRD? These specifications seem to = be creeping into IETF architecture; first it was in a pure security context= , but now folks are talking about using them in a much more generic way, as= a cornerstone of what we do. As such, I think they deserve a MUCH closer l= ook, especially since we're defining things with "Web" in their name when t= he W3C has already defined solutions in this space. >> >> Thanks, >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> _______________________________________________ >> 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 --=20 Website: http://hallambaker.com/ From James.H.Manger@team.telstra.com Tue Jul 3 16:35:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41F311E80CE for ; Tue, 3 Jul 2012 16:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTN-DD9eARNm for ; Tue, 3 Jul 2012 16:35:59 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0520311E8083 for ; Tue, 3 Jul 2012 16:35:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,519,1336312800"; d="scan'208";a="85599666" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 04 Jul 2012 09:36:08 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6761"; a="75163647" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcbni.tcif.telstra.com.au with ESMTP; 04 Jul 2012 09:36:06 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Wed, 4 Jul 2012 09:36:05 +1000 From: "Manger, James H" To: Julian Reschke Date: Wed, 4 Jul 2012 09:36:04 +1000 Thread-Topic: [apps-discuss] #10: json-pointer fragment identifiers Thread-Index: Ac1Y/OsTxKLsa+NxSIC09ITMB/8nSAAdiJMw Message-ID: <255B9BB34FB7D647A506DC292726F6E114F7600D61@WSMSG3153V.srv.dir.telstra.com> References: <4FF2B90B.3050408@gmx.de> In-Reply-To: <4FF2B90B.3050408@gmx.de> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] #10: json-pointer fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 23:35:59 -0000 PiA+Pj4gUGlja2luZyB0aGUgcmlnaHQga2V5IGZyb20gYSBKU09OIFdlYiBLZXkgdmFsdWUgaXMg YSBwb3NzaWJsZSB1c2UNCj4gW2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXldLg0KPiA+DQo+ ID4+IEl0IHNlZW1zIHRoYXQgeW91IHRoZW4gd291bGQgaGF2ZSB0byByZWx5IG9uIGFycmF5IGlu ZGljZXMsIHJpZ2h0Pw0KPiA+DQo+ID4gWWVzLCB3aXRoIHRoZSBjdXJyZW50IEpXSyBzeW50YXgu IGh0dHA6Ly9leGFtcGxlLm9yZy9qaW0uanNvbiMva2V5cy8xDQo+IHRvIHBpY2sgdGhlIDJuZCBr ZXkuDQo+ID4gLi4uDQo+IA0KPiBBbmQgcmVseWluZyBvbiBhIHNwZWNpZmljIG9yZGVyIGlzIG5v dCBhIHByb2JsZW0/IChBc2tpbmcgYmVjYXVzZSB0aGlzDQo+IHNlZW1zIHRvIGJlIGEgbmljZSBl eGFtcGxlIGZvciBhIGNhc2Ugd2hlcmUgYSBtb3JlIGV4cHJlc3NpdmUgcG9pbnRlcg0KPiBzeW50 YXggY291bGQgYmUgdXNlZnVsKS4NCg0KUmVseWluZyBvbiB0aGUgb3JkZXIgaW4gYW4gYXJyYXkg c2hvdWxkbid0IGJlIGEgcHJvYmxlbS4NCg0KRWFjaCBrZXkgY2FuIGhhdmUgYSBrZXkgaWQsIHdo aWNoIGlzIHByb2JhYmx5IGEgYmV0dGVyIHdheSB0byByZWZlciB0byBhIHBhcnRpY3VsYXIga2V5 LiBBIG1vcmUgc29waGlzdGljYXRlZCBwb2ludGVyL2ZyYWdtZW50IHN5bnRheCBjb3VsZCBhZGRy ZXNzIHRoYXQsIGJ1dCBhIGJldHRlciBhcHByb2FjaCBpcyB0byByZWRlc2lnbiB0aGUgSldLIEpT T04gc3ludGF4IHNvIHRoZSBrZXkgaWQgaXMgdXNlZCBhcyB0aGUgZWxlbWVudCBuYW1lICh0aGVu IGEgSlNPTiBwb2ludGVyIHdvdWxkIGJlIGEgcGVyZmVjdCBmcmFnbWVudCB2YWx1ZSkuDQoNCi0t DQpKYW1lcyBNYW5nZXINCg== From ve7jtb@ve7jtb.com Tue Jul 3 16:53:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681C411E8072 for ; Tue, 3 Jul 2012 16:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.404 X-Spam-Level: X-Spam-Status: No, score=-3.404 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrjYt3OiNFMZ for ; Tue, 3 Jul 2012 16:53:40 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 212BC11E8083 for ; Tue, 3 Jul 2012 16:53:40 -0700 (PDT) Received: by yenq13 with SMTP id q13so6509570yen.31 for ; Tue, 03 Jul 2012 16:53:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=YfEnkoU7l9TTtu7HY35GIGV7YG6LbcpzWvws5hHPQ50=; b=TGg/g4Pq1wHXXy6eNtiCMRy9b8iOtzqqvMNurqfOmBSDtDrL5cwPzZu3I1AVabt+3q s/7IvH+5e5iZ91W4/+eAYAKruiUusZ5mngGvQ/p1uE51+ftQkDiQdV1ScVRmqorvPGx1 5tv9j3sG+TlGqd5G5Ar6dHB4gtcyVEsuJbTuVG2KzjR7QmliMCJCw5NmAMylsKP7S8Mv H50iZTtxMhViMGBPwvr7cOsiQzNPsIOYgKn/redyK8fYpekQyJOZ1/nac9u+NDdnUy7X MVnzSpM3Z1jGHiL4Tbs94mrOi3dK1T831ujByjUcbejfxVIh0RCoN+FctDkXnS5pAMnd QARA== Received: by 10.236.108.196 with SMTP id q44mr13605723yhg.68.1341359628600; Tue, 03 Jul 2012 16:53:48 -0700 (PDT) Received: from [192.168.1.211] (190-20-40-193.baf.movistar.cl. [190.20.40.193]) by mx.google.com with ESMTPS id a79sm3944765yhk.16.2012.07.03.16.53.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jul 2012 16:53:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_8E773533-D66E-4705-BC74-40921D1FC52A"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Tue, 3 Jul 2012 19:53:36 -0400 Message-Id: <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlglzDBeKMU7wtJr3632MWyVjMSY0qbR8Bw6Gh/hw+n9t3V8l9LE2HtlJcK7o9XUiteR6St Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2012 23:53:45 -0000 --Apple-Mail=_8E773533-D66E-4705-BC74-40921D1FC52A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I recall that there were strait answers and a meeting with the OASIS = lawyer on the topic back in the day. Not everyone trusted the answers apparently, but you can't make = everyone happy. The IPR you are concerned about related to XRI resolution and not the = XRDS or XRD XML document formats. There should be no more IPR concern than there is with other OASIS specs = like SAML. That said I am not advocating the use of XRD, SWD used a simple link = data type JSON format. The XRD and JRD format are heavily influenced by the link data format if = you look at it closely. Regards John B. On 2012-07-03, at 6:29 PM, Phillip Hallam-Baker wrote: > What are the PR encumbrances of XRD? >=20 > The XRI folk never gave me a straight answer, it is all tainted until > there is an explicit statement AFIK. >=20 > On Tue, Jul 3, 2012 at 5:27 PM, James M Snell = wrote: >> Great to see this conversation coming up... A couple of months ago I >> posted a few thoughts on WebFinger on my personal blog [1]... I've >> copied the relevant bits here for discussion. The short summary: >> WebFinger is ok but can be made so much simpler. >>=20 >> [1] = http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html >>=20 >> ... >> Ok... so [WebFinger] seems simple enough, but can we make it even >> simpler? I think we definitely can. Let's start by eliminating the >> requirement to use XRD. Look at the first response... what is the XRD >> document giving us? A Link. One Link. Ok, not really a Link, but a = URI >> Template. Wait, so that's two things we I actually need to process >> before I can actually look up information about the user "bob"... >> let's eliminate both of those things and simply provide a means of >> looking up information about the user directly.. for instance: >>=20 >> GET /.well-known/finger/acct%3Abob%40example.org HTTP/1.1 >> Host: example.org >>=20 >> If we still need to know things about the domain, then we can finger >> that domain... >>=20 >> GET /.well-known/finger/example.org HTTP/1.1 >> Host: example.org >>=20 >> But looking up basic information about the user should not be >> predicated on first looking up basic information about the domain. >> Those can, and should, be two completely separate tasks. >>=20 >> There is a problem here, however. A big problem actually. Many >> enterprises frown on putting things that look like email addresses >> into URLs because of fairly significant privacy concerns. So let's >> change that, instead of passing the acct: ID directly, we'll pass a >> hash of the acct id.. much more secure and private that way... >>=20 >> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 >> Host: example.org >>=20 >> Ah, that's better... and in the process I managed to eliminate about = a >> third of what the WebFinger draft currently requires. >>=20 >> It boils down to nothing more than this: >> If I want to know something about user "bob@example.org", I sent a = GET >> request to = http://example.org/.well-known/finger/{md5("bob@example.org")} >> and see what I get back. No absolute need to parse any XML. No need = to >> process any URI Templates. No need to define special query string >> parameters. Keep it very simple and we're essentially done. >>=20 >> Ok, so what about the response from the server? What would that look >> like? Currently, WebFinger requires that the response has to either = be >> XRD or this other thing called JRD. While I don't have any problem >> with using either of those particular formats, I do not believe that >> the WebFinger spec needs to declare that any format MUST be = supported. >> It should be up to the server to provide whatever format it wishes. >> The client can determine if it's able to get what it's needs from the >> provided format or not. If the response is HTML and includes Link or >> Anchor elements that use appropriately labelled rel attribute values, >> then the client should be able to get the information it needs; if = the >> response is JSON and includes appropriately labeled information in a >> way the client can understand, then great. That's what we have things >> like the Accept request header for... >>=20 >> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 >> Host: example.org >> Accept: application/xrd+xml, text/html, application/atom+xml >>=20 >> The client can tell the server what format it would like and the >> server can respond appropriately. These mechanism are widely used and >> the abstract notion of a Link is fairly universal now and easily >> represented in multiple formats. >>=20 >> The response to the above request could very well be as simple as: >>=20 >> HTTP/1.1 204 No Content >> Link: ; rel=3D"blog", >> ; rel=3D"profile", >> ; rel=3D"avatar" >>=20 >> Sure, this hypothetical type of response may be impractical if a >> particular user has a significantly large number of links associated >> with it, but (a) realistically most users won't have that many at any >> single service and (b) this is just an example, I did say that I have >> no problem with XRD/JRD being used... it just shouldn't be required. >>=20 >> Another possibility. Just to stretch the imagination a bit more. >> Suppose I want to know the location of the user's blog and I send = this >> for a request: >>=20 >> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog = HTTP/1.1 >> Host: example.org >>=20 >> Note the addition of the "/blog" at the end of the request URI. Let's >> just say that the last little bit there is a rel value. If the user >> has only a single rel=3D"blog" Link, then the server can tell me = where >> it is with a simple redirect: >>=20 >> HTTP/1.1 302 Found >> Location: http://blogs.example.org/bob >>=20 >> If there happen to be multiple "blog" links associated with that >> particular user, then the server can tell me about all of them... >>=20 >> HTTP/1.1 300 Multiple Choices >> Location: http://blogs.example.org/bobs_default_blog >> Link: ; rel=3D"blog", >> ; rel=3D"blog" >>=20 >> What if I want to know about some other kind of Link associated with >> the user... well, I simply replace "/blog" with the other rel >> attribute value... >>=20 >> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard = HTTP/1.1 >> Host: example.org >>=20 >> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar = HTTP/1.1 >> Host: example.org >>=20 >> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/ >> http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fprovider HTTP/1.1 >> Host: example.org >>=20 >> Whatever specific link rel I want to know about, I just append that = to >> the end. If I need to know about more than one, separate them by a >> comma: >>=20 >> GET = /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard,avatar >> HTTP/1.1 >> Host: example.org >>=20 >> Which could return something along the lines of... >>=20 >> HTTP/1.1 300 Multiple Choices >> Link: ; rel=3D"vcard", >> ; rel=3D"avatar" >>=20 >> Or it could return an XRD or JRD... either way, it works just fine. >> The point is that it's MUCH simpler than what WebFinger defines and >> requires fewer moving parts (no required XML parsing, no required URI >> Template processing, no required querystring parameters, etc). >>=20 >> With regards to security considerations, the original Finger protocol >> was quite problematic because of the potential for inappropriate >> disclosure of sensitive information about an account. The same basic >> concern would be applicable to WebFinger depending on what = information >> was being made available for discovery. I've already dealt with one >> particular concern -- the use of an email-like identifier within the >> discovery URI... requiring a hash is a simple fix there. But what = else >> can be done? >>=20 >> Well, obviously, we're talking about a HTTP request here. When a >> requester sends an unauthenticated HTTP request to discover >> information about a user, the server can choose to respond with only >> the most basic generic and public information about the user and >> possibly some links to that user's public facing services (their = blog, >> their avatar, etc). Mechanisms such as OAuth 2 can be employed, >> however, to support much more interesting scenarios. For instance, a >> trusted third party could acquire an OAuth 2 access token to request >> additional, more detailed information about a user... >>=20 >> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog = HTTP/1.1 >> Host: example.org >> Authentication: Bearer {my_access_token} >>=20 >> Such requests can be easily tracked, rate-limited, etc, making the >> protocol generally much more reliable and secure than the original >> finger protocol. Unfortunately, the current WebFinger specification >> does not adequately address this particular concern. >> .... >>=20 >> - James >>=20 >> On Tue, Jul 3, 2012 at 12:24 AM, Mike Jones = wrote: >>> You've essentially described Simple Web Discovery! It avoids the = complications introduced by host-meta exactly by using its own = .well-known value. The basic example is: >>>=20 >>> GET = /.well-known/simple-web-discovery?principal=3Dmailto:joe@example.com&servi= ce=3Durn:example.org:service:calendar HTTP/1.1 >>> Host: example.com >>>=20 >>> HTTP/1.1 200 OK >>> Content-Type: application/json >>>=20 >>> { >>> "locations": ["http://calendars.example.net/calendars/joseph"] >>> } >>>=20 >>> See http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 = for more details. By design, there aren't many... >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mark Nottingham >>> Sent: Monday, July 02, 2012 10:47 PM >>> To: IETF Apps Discuss >>> Subject: [apps-discuss] Looking at Webfinger >>>=20 >>> I've pretty much ignored the whole webfinger / acct: / SWD = discussion (too much!). However, since it's apparent it may soon become = Real, I had a look. >>>=20 >>> In a nutshell, my initial reaction is "It's Not Nearly As Bad As I = Thought It Would Be." :) >>>=20 >>> With that in mind, a few questions / comments (I'll resist going = into editorial matters, for the time being): >>>=20 >>> * First and foremost, why use host-meta? What value does adding this = extra step to the dance bring, beyond "We've defined it, therefore we = must use it?" >>>=20 >>> As I think I've said many times before, the whole point of a = .well-known URI is to group like uses together, to avoid having a = "dictionary" resource that gets bloated with many application's = unrelated data, thereby overburdening clients with too much information = (especially when they're constrained, e.g., mobile). >>>=20 >>> As such, host-meta is a spectacularly bad example of a well-known = URI. Defining a end-all-be-all well-known-URI kind of removes the point = of having a registry, after all... >>>=20 >>> Instead, why not just define a NEW well-known URI for user data? = That has a more constrained scope, and saves one round trip (or more). = E.g., >>>=20 >>> GET /.well-known/webfinger?user=3Dbob%40example.com HTTP/1.0 >>> Host: example.com >>>=20 >>> I.e., let webfinger define the URI template to use. Yes, some = implementations might want to come up with crazy URIs, but is that = really a problem we want to solve? >>>=20 >>> Astute observers will notice that this approach removes the need for = an ACCT URI scheme (at least here). >>>=20 >>>=20 >>> * What's the fascination with XRD and JRD? These specifications seem = to be creeping into IETF architecture; first it was in a pure security = context, but now folks are talking about using them in a much more = generic way, as a cornerstone of what we do. As such, I think they = deserve a MUCH closer look, especially since we're defining things with = "Web" in their name when the W3C has already defined solutions in this = space. >>>=20 >>> Thanks, >>>=20 >>>=20 >>> -- >>> Mark Nottingham http://www.mnot.net/ >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_8E773533-D66E-4705-BC74-40921D1FC52A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw MzIzNTMzN1owIwYJKoZIhvcNAQkEMRYEFIATKF8lNZivDEqJY3sfaEm/TqS+MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AIOyXOlENGgQbjIUQN74GT5bd9cUbJnSlxz7rA2C+ox5dm14DFn2L04OiJaTmk3JEmY1FA96sFsw IyRiW2j6rqZNe85w7uEnVJReTokiXJWJYcUcPBYOA/Stc+kyqzw3WTL3H9kMZdBEQqFAYlM0w7CT UR7ACbF8gcNPzmVSYC4UJxpZYAVuP5RPQd3TTYwbtFEa8W2AP2S5VAD3ELGiyt0lwilMJK4MiTZ5 8WUsvT7k/P1biCBCXSoDTEVq4Z0YAD+zuePDyZx1o8UlFtexll5QNA0UbRwjWZQ7S0GJjdkGz4JY 8TjmVX9OnIq9jlzZp8zf7rhqoC0x39nFPZNrPi4AAAAAAAA= --Apple-Mail=_8E773533-D66E-4705-BC74-40921D1FC52A-- From mnot@mnot.net Tue Jul 3 17:48:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C2811E80BF for ; Tue, 3 Jul 2012 17:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.341 X-Spam-Level: X-Spam-Status: No, score=-105.341 tagged_above=-999 required=5 tests=[AWL=-2.742, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXoKpw2yNs5w for ; Tue, 3 Jul 2012 17:48:43 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3839A11E80AE for ; Tue, 3 Jul 2012 17:48:43 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2E27822E257 for ; Tue, 3 Jul 2012 20:48:45 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Jul 2012 10:48:43 +1000 References: <20120704002826.31184.30649.idtracker@ietfa.amsl.com> To: IETF Apps Discuss Message-Id: Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-http-problem-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 00:48:44 -0000 FYI. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-http-problem-00.txt > Date: 4 July 2012 10:28:26 AM AEST > To: mnot@mnot.net >=20 >=20 > A new version of I-D, draft-nottingham-http-problem-00.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Filename: draft-nottingham-http-problem > Revision: 00 > Title: Indicating Details of Problems to Machines in = HTTP > Creation date: 2012-07-04 > WG ID: Individual Submission > Number of pages: 9 > URL: = http://www.ietf.org/internet-drafts/draft-nottingham-http-problem-00.txt > Status: = http://datatracker.ietf.org/doc/draft-nottingham-http-problem > Htmlized: = http://tools.ietf.org/html/draft-nottingham-http-problem-00 >=20 >=20 > Abstract: > This specification proposes a "Problem Detail" as an extensible way > to carry machine-readable details of HTTP errors in a response, to > avoid the need to invent new response formats for non-human > consumers. >=20 >=20 >=20 >=20 > The IETF Secretariat -- Mark Nottingham http://www.mnot.net/ From hallam@gmail.com Tue Jul 3 18:59:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB70C11E80AE for ; Tue, 3 Jul 2012 18:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gByfomvNrSOm for ; Tue, 3 Jul 2012 18:59:26 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2158721F8692 for ; Tue, 3 Jul 2012 18:59:26 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12274518obb.31 for ; Tue, 03 Jul 2012 18:59: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:content-transfer-encoding; bh=ccdglvrsNSoKDWw3Ii3oAPyuKNDSc3tfxFJ5puWjii0=; b=smRdLI2Ha64DGx24Zk4D72t/quy7GCZJq0GH7rL3tmkjIC2Rndyv5PCaapf04oERUH 7kW2VWtD39YSHFA8Flq/XHUPVlIq4ENra4JQVXbxHbc89Lcp2WvbmUP8zlpATPtiu82f Hiv09GWBu9KW9B1MN1cRfJEDqIcA9L7lbB7dZwH/JMhxUUfU63GWSB0fYK6oQjQ9Vi+5 Fvc9gpUzRjBi0egMtxiW4KoYhZI7kpjyA8cTXPIXxQx8QLqULjU1NKFqlA1ow1UUWD9n MMoVvJlXVdvnp0YTKKcVzcMvfctwWTUYpKLNdqD/Y6annW5UqqMafEcVh9RWUvRe1Fgr QZXw== MIME-Version: 1.0 Received: by 10.60.18.114 with SMTP id v18mr20833626oed.34.1341367175074; Tue, 03 Jul 2012 18:59:35 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Tue, 3 Jul 2012 18:59:34 -0700 (PDT) In-Reply-To: <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> Date: Tue, 3 Jul 2012 21:59:34 -0400 Message-ID: From: Phillip Hallam-Baker To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 01:59:28 -0000 I recall something rather different. I recall a claim that the IPR was open when in fact the registry was to be operated on a commercial basis. This technology keeps appearing in specs without any apparent requirement to motivate it. In OpenID the only reason for =3DPhill being required was that user@domain was not supported as we were told that people wanted to use the URL of their blog. On Tue, Jul 3, 2012 at 7:53 PM, John Bradley wrote: > I recall that there were strait answers and a meeting with the OASIS lawy= er on the topic back in the day. > > Not everyone trusted the answers apparently, but you can't make everyone= happy. > > The IPR you are concerned about related to XRI resolution and not the XRD= S or XRD XML document formats. > > There should be no more IPR concern than there is with other OASIS specs = like SAML. > > That said I am not advocating the use of XRD, SWD used a simple link dat= a type JSON format. > > The XRD and JRD format are heavily influenced by the link data format if = you look at it closely. > > Regards > John B. > > > > On 2012-07-03, at 6:29 PM, Phillip Hallam-Baker wrote: > >> What are the PR encumbrances of XRD? >> >> The XRI folk never gave me a straight answer, it is all tainted until >> there is an explicit statement AFIK. >> >> On Tue, Jul 3, 2012 at 5:27 PM, James M Snell wrote: >>> Great to see this conversation coming up... A couple of months ago I >>> posted a few thoughts on WebFinger on my personal blog [1]... I've >>> copied the relevant bits here for discussion. The short summary: >>> WebFinger is ok but can be made so much simpler. >>> >>> [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html >>> >>> ... >>> Ok... so [WebFinger] seems simple enough, but can we make it even >>> simpler? I think we definitely can. Let's start by eliminating the >>> requirement to use XRD. Look at the first response... what is the XRD >>> document giving us? A Link. One Link. Ok, not really a Link, but a URI >>> Template. Wait, so that's two things we I actually need to process >>> before I can actually look up information about the user "bob"... >>> let's eliminate both of those things and simply provide a means of >>> looking up information about the user directly.. for instance: >>> >>> GET /.well-known/finger/acct%3Abob%40example.org HTTP/1.1 >>> Host: example.org >>> >>> If we still need to know things about the domain, then we can finger >>> that domain... >>> >>> GET /.well-known/finger/example.org HTTP/1.1 >>> Host: example.org >>> >>> But looking up basic information about the user should not be >>> predicated on first looking up basic information about the domain. >>> Those can, and should, be two completely separate tasks. >>> >>> There is a problem here, however. A big problem actually. Many >>> enterprises frown on putting things that look like email addresses >>> into URLs because of fairly significant privacy concerns. So let's >>> change that, instead of passing the acct: ID directly, we'll pass a >>> hash of the acct id.. much more secure and private that way... >>> >>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 >>> Host: example.org >>> >>> Ah, that's better... and in the process I managed to eliminate about a >>> third of what the WebFinger draft currently requires. >>> >>> It boils down to nothing more than this: >>> If I want to know something about user "bob@example.org", I sent a GET >>> request to http://example.org/.well-known/finger/{md5("bob@example.org"= )} >>> and see what I get back. No absolute need to parse any XML. No need to >>> process any URI Templates. No need to define special query string >>> parameters. Keep it very simple and we're essentially done. >>> >>> Ok, so what about the response from the server? What would that look >>> like? Currently, WebFinger requires that the response has to either be >>> XRD or this other thing called JRD. While I don't have any problem >>> with using either of those particular formats, I do not believe that >>> the WebFinger spec needs to declare that any format MUST be supported. >>> It should be up to the server to provide whatever format it wishes. >>> The client can determine if it's able to get what it's needs from the >>> provided format or not. If the response is HTML and includes Link or >>> Anchor elements that use appropriately labelled rel attribute values, >>> then the client should be able to get the information it needs; if the >>> response is JSON and includes appropriately labeled information in a >>> way the client can understand, then great. That's what we have things >>> like the Accept request header for... >>> >>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 >>> Host: example.org >>> Accept: application/xrd+xml, text/html, application/atom+xml >>> >>> The client can tell the server what format it would like and the >>> server can respond appropriately. These mechanism are widely used and >>> the abstract notion of a Link is fairly universal now and easily >>> represented in multiple formats. >>> >>> The response to the above request could very well be as simple as: >>> >>> HTTP/1.1 204 No Content >>> Link: ; rel=3D"blog", >>> ; rel=3D"profile", >>> ; rel=3D"avatar" >>> >>> Sure, this hypothetical type of response may be impractical if a >>> particular user has a significantly large number of links associated >>> with it, but (a) realistically most users won't have that many at any >>> single service and (b) this is just an example, I did say that I have >>> no problem with XRD/JRD being used... it just shouldn't be required. >>> >>> Another possibility. Just to stretch the imagination a bit more. >>> Suppose I want to know the location of the user's blog and I send this >>> for a request: >>> >>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1.1 >>> Host: example.org >>> >>> Note the addition of the "/blog" at the end of the request URI. Let's >>> just say that the last little bit there is a rel value. If the user >>> has only a single rel=3D"blog" Link, then the server can tell me where >>> it is with a simple redirect: >>> >>> HTTP/1.1 302 Found >>> Location: http://blogs.example.org/bob >>> >>> If there happen to be multiple "blog" links associated with that >>> particular user, then the server can tell me about all of them... >>> >>> HTTP/1.1 300 Multiple Choices >>> Location: http://blogs.example.org/bobs_default_blog >>> Link: ; rel=3D"blog", >>> ; rel=3D"blog" >>> >>> What if I want to know about some other kind of Link associated with >>> the user... well, I simply replace "/blog" with the other rel >>> attribute value... >>> >>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard HTTP/= 1.1 >>> Host: example.org >>> >>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar HTTP= /1.1 >>> Host: example.org >>> >>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/ >>> http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fprovider HTTP/1.1 >>> Host: example.org >>> >>> Whatever specific link rel I want to know about, I just append that to >>> the end. If I need to know about more than one, separate them by a >>> comma: >>> >>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard,avata= r >>> HTTP/1.1 >>> Host: example.org >>> >>> Which could return something along the lines of... >>> >>> HTTP/1.1 300 Multiple Choices >>> Link: ; rel=3D"vcard", >>> ; rel=3D"avatar" >>> >>> Or it could return an XRD or JRD... either way, it works just fine. >>> The point is that it's MUCH simpler than what WebFinger defines and >>> requires fewer moving parts (no required XML parsing, no required URI >>> Template processing, no required querystring parameters, etc). >>> >>> With regards to security considerations, the original Finger protocol >>> was quite problematic because of the potential for inappropriate >>> disclosure of sensitive information about an account. The same basic >>> concern would be applicable to WebFinger depending on what information >>> was being made available for discovery. I've already dealt with one >>> particular concern -- the use of an email-like identifier within the >>> discovery URI... requiring a hash is a simple fix there. But what else >>> can be done? >>> >>> Well, obviously, we're talking about a HTTP request here. When a >>> requester sends an unauthenticated HTTP request to discover >>> information about a user, the server can choose to respond with only >>> the most basic generic and public information about the user and >>> possibly some links to that user's public facing services (their blog, >>> their avatar, etc). Mechanisms such as OAuth 2 can be employed, >>> however, to support much more interesting scenarios. For instance, a >>> trusted third party could acquire an OAuth 2 access token to request >>> additional, more detailed information about a user... >>> >>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1.1 >>> Host: example.org >>> Authentication: Bearer {my_access_token} >>> >>> Such requests can be easily tracked, rate-limited, etc, making the >>> protocol generally much more reliable and secure than the original >>> finger protocol. Unfortunately, the current WebFinger specification >>> does not adequately address this particular concern. >>> .... >>> >>> - James >>> >>> On Tue, Jul 3, 2012 at 12:24 AM, Mike Jones wrote: >>>> You've essentially described Simple Web Discovery! It avoids the comp= lications introduced by host-meta exactly by using its own .well-known valu= e. The basic example is: >>>> >>>> GET /.well-known/simple-web-discovery?principal=3Dmailto:joe@example= .com&service=3Durn:example.org:service:calendar HTTP/1.1 >>>> Host: example.com >>>> >>>> HTTP/1.1 200 OK >>>> Content-Type: application/json >>>> >>>> { >>>> "locations": ["http://calendars.example.net/calendars/joseph"] >>>> } >>>> >>>> See http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 for= more details. By design, there aren't many... >>>> >>>> -- Mike >>>> >>>> -----Original Message----- >>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.= org] On Behalf Of Mark Nottingham >>>> Sent: Monday, July 02, 2012 10:47 PM >>>> To: IETF Apps Discuss >>>> Subject: [apps-discuss] Looking at Webfinger >>>> >>>> I've pretty much ignored the whole webfinger / acct: / SWD discussion = (too much!). However, since it's apparent it may soon become Real, I had a = look. >>>> >>>> In a nutshell, my initial reaction is "It's Not Nearly As Bad As I Tho= ught It Would Be." :) >>>> >>>> With that in mind, a few questions / comments (I'll resist going into = editorial matters, for the time being): >>>> >>>> * First and foremost, why use host-meta? What value does adding this e= xtra step to the dance bring, beyond "We've defined it, therefore we must u= se it?" >>>> >>>> As I think I've said many times before, the whole point of a .well-kno= wn URI is to group like uses together, to avoid having a "dictionary" resou= rce that gets bloated with many application's unrelated data, thereby overb= urdening clients with too much information (especially when they're constra= ined, e.g., mobile). >>>> >>>> As such, host-meta is a spectacularly bad example of a well-known URI.= Defining a end-all-be-all well-known-URI kind of removes the point of havi= ng a registry, after all... >>>> >>>> Instead, why not just define a NEW well-known URI for user data? That = has a more constrained scope, and saves one round trip (or more). E.g., >>>> >>>> GET /.well-known/webfinger?user=3Dbob%40example.com HTTP/1.0 >>>> Host: example.com >>>> >>>> I.e., let webfinger define the URI template to use. Yes, some implemen= tations might want to come up with crazy URIs, but is that really a problem= we want to solve? >>>> >>>> Astute observers will notice that this approach removes the need for a= n ACCT URI scheme (at least here). >>>> >>>> >>>> * What's the fascination with XRD and JRD? These specifications seem t= o be creeping into IETF architecture; first it was in a pure security conte= xt, but now folks are talking about using them in a much more generic way, = as a cornerstone of what we do. As such, I think they deserve a MUCH closer= look, especially since we're defining things with "Web" in their name when= the W3C has already defined solutions in this space. >>>> >>>> Thanks, >>>> >>>> >>>> -- >>>> Mark Nottingham http://www.mnot.net/ >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 Website: http://hallambaker.com/ From mca@amundsen.com Tue Jul 3 19:41:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492D721F86C3 for ; Tue, 3 Jul 2012 19:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.596 X-Spam-Level: X-Spam-Status: No, score=-3.596 tagged_above=-999 required=5 tests=[AWL=-2.917, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaIxKS8GGhMk for ; Tue, 3 Jul 2012 19:41:13 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27D6021F86C1 for ; Tue, 3 Jul 2012 19:41:13 -0700 (PDT) Received: by yhq56 with SMTP id 56so8177150yhq.31 for ; Tue, 03 Jul 2012 19:41:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=YGbGR12/DHZ5Ip2dBJr+Bkk1W+NLsYttqhGIhtoPW+g=; b=O2ryOmX39DPsYisrwaAEBfhKBACiva1NFAV/ja/2WajIXMabhs1XaX1X07DPXa6LfW MuwB9jaERDLpD2i2Kj6E9RUAC8tx4hf+jYNpj292Ne5o90DvD/Q9gNjX3gs626jPZAYt GOmWjsNG3CDZ23qtd8yruNW0XRwMaGoHvVFcTcqNYmdvQpW++xvpvoenMSKASTluZc3n FJg+7PPKBNYd6yzoh/SCNhSyV9FLs67D23UEFJ/mz52ZP5E6PQYXVQ6VFsMCaQGOTSI+ vuDGupHBrdHEWHFJ6g2ubo24W53j4UEOSfIEcF1V4mhPG4sPgv0umH4hr84BiLqbIHHy Z39Q== MIME-Version: 1.0 Received: by 10.236.175.106 with SMTP id y70mr7877073yhl.110.1341369682007; Tue, 03 Jul 2012 19:41:22 -0700 (PDT) Sender: mca@amundsen.com Received: by 10.147.79.17 with HTTP; Tue, 3 Jul 2012 19:41:21 -0700 (PDT) In-Reply-To: References: <20120704002826.31184.30649.idtracker@ietfa.amsl.com> Date: Tue, 3 Jul 2012 22:41:21 -0400 X-Google-Sender-Auth: Uci8WsTre7_5bBUhcoi646o7qCU Message-ID: From: mike amundsen To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=20cf305e288368969004c3f7f771 X-Gm-Message-State: ALoCoQlBgb4RKGxCsAGLLFoMMo5E2Ia8SFmRsr/TPQ66Olz78G6T5lcaR1E0+KHrDr3tPzsf8MTk Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-nottingham-http-problem-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 02:41:14 -0000 --20cf305e288368969004c3f7f771 Content-Type: text/plain; charset=ISO-8859-1 Mark: Good to see this I-D. This has come up a handful of times recently in my online/IRL convos. I've been contemplating "solving" this problem (ha!) w/ a link-rel value of "error" that could be used for both link headers and in negotiable bodies: HTTP/1.1 400 Bad Request Link: ; rel="error" Content-type: text/html
Invalid hat size, please try again! BAD-HAT-01 Details... A registered value of "error" might be preferable to using "describedby"; esp for machine clients that might encounter "describedby" in other contexts. Also, I've found using a "code" property has been helpful for machine clients as this will be static no matter the language used to express the title text. mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me On Tue, Jul 3, 2012 at 8:48 PM, Mark Nottingham wrote: > FYI. > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > draft-nottingham-http-problem-00.txt > > Date: 4 July 2012 10:28:26 AM AEST > > To: mnot@mnot.net > > > > > > A new version of I-D, draft-nottingham-http-problem-00.txt > > has been successfully submitted by Mark Nottingham and posted to the > > IETF repository. > > > > Filename: draft-nottingham-http-problem > > Revision: 00 > > Title: Indicating Details of Problems to Machines in HTTP > > Creation date: 2012-07-04 > > WG ID: Individual Submission > > Number of pages: 9 > > URL: > http://www.ietf.org/internet-drafts/draft-nottingham-http-problem-00.txt > > Status: > http://datatracker.ietf.org/doc/draft-nottingham-http-problem > > Htmlized: > http://tools.ietf.org/html/draft-nottingham-http-problem-00 > > > > > > Abstract: > > This specification proposes a "Problem Detail" as an extensible way > > to carry machine-readable details of HTTP errors in a response, to > > avoid the need to invent new response formats for non-human > > consumers. > > > > > > > > > > The IETF Secretariat > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --20cf305e288368969004c3f7f771 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark:

Good to see= this I-D. This has come up a handful of times recently in my online/IRL co= nvos.

I've been contemplating "solving" this problem (ha!) w/ a=A0l= ink-rel value of "error" that could be used for both link headers= and=A0in negotiable bodies:

HTTP/1.1 400 Bad Request
Link: <http:= //example.org/logs/errors/aqswdefrgt>; rel=3D"error"
Co= ntent-type: text/html

<div class=3D"error">
=A0 <span class=3D"tex= t">Invalid hat size, please try again!</span>
=A0 <span= class=3D"code">BAD-HAT-01</span>
=A0 <a href=3D&q= uot;http://example.org/logs/errors/aqswdefrgt" rel=3D"error">Details...</a>
</link>=A0



mca
http://amundsen.com/blog/=
http://twitter.com= @mamund
http://mamund.c= om/foaf.rdf#me




On Tue, Jul 3, 2012 at 8:48 PM, Mark Not= tingham <mnot@mnot.net> wrote:
FYI.

Begin forwarded message:

> From: internet-drafts@ietf= .org
> Subject: New Version Notification for draft-nottingham-http-problem-00= .txt
> Date: 4 July 2012 10:28:26 AM AEST
> To: mnot@mnot.net
>
>
> A new version of I-D, draft-nottingham-http-problem-00.txt
> has been successfully submitted by Mark Nottingham and posted to the > IETF repository.
>
> Filename: =A0 =A0 =A0draft-nottingham-http-problem
> Revision: =A0 =A0 =A000
> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Indicating Details of Problems = to Machines in HTTP
> Creation date: =A0 =A0 =A0 =A0 2012-07-04
> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 9
> URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ie= tf.org/internet-drafts/draft-nottingham-http-problem-00.txt
> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.or= g/doc/draft-nottingham-http-problem
> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/dra= ft-nottingham-http-problem-00
>
>
> Abstract:
> =A0 This specification proposes a "Problem Detail" as an ext= ensible way
> =A0 to carry machine-readable details of HTTP errors in a response, to=
> =A0 avoid the need to invent new response formats for non-human
> =A0 consumers.
>
>
>
>
> The IETF Secretariat

--
Mark Nottingham =A0 http= ://www.mnot.net/



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

--20cf305e288368969004c3f7f771-- From superuser@gmail.com Tue Jul 3 20:46:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820D711E80FA for ; Tue, 3 Jul 2012 20:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzL8tH4qOSnI for ; Tue, 3 Jul 2012 20:46:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 345B911E80F5 for ; Tue, 3 Jul 2012 20:46:03 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12404066obb.31 for ; Tue, 03 Jul 2012 20:46: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=FHlNtCGrWFhzS4ZGtCeM69DnvWT7MhG0lx0ies4Fy4Y=; b=qHtc2yVi8xkCQtdli9420aXZ/MaSGcyRcOjPiMIEOp5UNNAa/qXaCvXmHtdHro1Jad rvBuKSyFhjBjhx3L5bpAzh+RfSB0SLIwVBsh0yLXGcvwI6lNopNvDhUdO3F14xqTJ2dI YraAtZvxyDqof9mUIa6ExW4ZrJztwgsADmiPRwpLXJcsqbin5aZpSpr9RxjA+/p2ifVv TBYx+cpfZCtdiZkLBJe3M9yTuidZSrUHU2YUoO0YJQDa+OKKyp63s6c6EcGM7WzZK0o2 oRqrMCUxs9K3AhTd2ynwFxLigzZBlFQkLda8m8qyVyYkHp44M0aycT5o3QKWLw8X838S 0gbw== MIME-Version: 1.0 Received: by 10.60.169.134 with SMTP id ae6mr20932878oec.55.1341373571286; Tue, 03 Jul 2012 20:46:11 -0700 (PDT) Received: by 10.182.28.65 with HTTP; Tue, 3 Jul 2012 20:46:11 -0700 (PDT) In-Reply-To: <911C1091-6D88-4937-BF4C-0FCB264B6AEF@ve7jtb.com> References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <1A87B9DE-ECEC-4F07-8734-131D4BB564EB@ve7jtb.com> <911C1091-6D88-4937-BF4C-0FCB264B6AEF@ve7jtb.com> Date: Tue, 3 Jul 2012 20:46:11 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Bradley Content-Type: multipart/alternative; boundary=bcaec550b36c3a480004c3f8dfbe Cc: Mark Nottingham , Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 03:46:04 -0000 --bcaec550b36c3a480004c3f8dfbe Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 3, 2012 at 1:17 PM, John Bradley wrote: > There are existing deployments of WF. Changes that lead to something > incompatible with what is deployed > are likely to receive more resistance, now that we have a WG draft. > > Not that changes can't be made with rough consensus.. > > It may have been easier though to have had Mark and others comments before > the WG draft. That might have made it easier to have included some more of the SWD design. > > The fact that there's a WG draft now doesn't change what's been deployed. These are two orthogonal points. I (predictably) concur with Barry's statements about document evolution. The working group could conceivably completely rewrite Webfinger at this point if it so chooses, as driven by consensus. That includes applying all, some, or none of Mark's comments, for example. If you have some changes you'd like to have the working group consider, the floor is open. -MSK --bcaec550b36c3a480004c3f8dfbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 3, 2012 at 1:17 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
There are existing deployments of WF. =A0 Changes that lead to something in= compatible with what is deployed
are likely to receive more resistance, now that we have a WG draft.

Not that changes can't be made with rough consensus..

It may have been easier though to have had Mark and others comments before = the WG draft.=A0
That might have made it easier to have included some more of the SWD design= .


The fact that there's a WG draft now doesn= 9;t change what's been deployed.=A0 These are two orthogonal points.
I (predictably) concur with Barry's statements about document=20 evolution.=A0 The working group could conceivably completely rewrite=20 Webfinger at this point if it so chooses, as driven by consensus.=A0 That i= ncludes applying all, some, or none of Mark's comments, for example.
If you have some changes you'd like to have the working group cons= ider, the floor is open.

-MSK
--bcaec550b36c3a480004c3f8dfbe-- From mnot@mnot.net Tue Jul 3 22:31:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A058921F87B2 for ; Tue, 3 Jul 2012 22:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.327 X-Spam-Level: X-Spam-Status: No, score=-105.327 tagged_above=-999 required=5 tests=[AWL=-2.728, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bDOH6n1KA7y for ; Tue, 3 Jul 2012 22:31:23 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id CA2C221F87B4 for ; Tue, 3 Jul 2012 22:31:23 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A0B7422E253; Wed, 4 Jul 2012 01:31:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: Date: Wed, 4 Jul 2012 15:31:23 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <647904D2-D497-4E54-9CBB-7E636F2E9F7D@mnot.net> References: <20120704002826.31184.30649.idtracker@ietfa.amsl.com> To: mike amundsen X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 05:31:24 -0000 On 04/07/2012, at 12:41 PM, mike amundsen wrote: > Mark: >=20 > Good to see this I-D. This has come up a handful of times recently in = my online/IRL convos. Thanks.=20 > I've been contemplating "solving" this problem (ha!) w/ a link-rel = value of "error" that could be used for both link headers and in = negotiable bodies: >=20 > HTTP/1.1 400 Bad Request > Link: ; rel=3D"error" > Content-type: text/html >=20 >
> Invalid hat size, please try again! > BAD-HAT-01 > Details... > =20 >=20 > A registered value of "error" might be preferable to using = "describedby"; esp for machine clients that might encounter = "describedby" in other contexts. That was some of the feedback I got pre-draft, and I agree that a = different relation might be better. I'm not sure about "error" because = it might be misinterpreted; was maybe thinking about a simple = "problem-detail" or "problem-type" (because the detail is the *whole* = set of details about the type *and* instance of the problem). > Also, I've found using a "code" property has been helpful for machine = clients as this will be static no matter the language used to express = the title text That's the function that the URI has in mine.=20 Cheers, -- Mark Nottingham http://www.mnot.net/ From mca@amundsen.com Tue Jul 3 22:54:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD9E11E8101 for ; Tue, 3 Jul 2012 22:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuXjhKE9aZD7 for ; Tue, 3 Jul 2012 22:54:38 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0B96811E810A for ; Tue, 3 Jul 2012 22:54:37 -0700 (PDT) Received: by yenq13 with SMTP id q13so6698065yen.31 for ; Tue, 03 Jul 2012 22:54:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=/RSbvD6DOoHCwEyhYjVjuHAvULVjvMaEY6EXiBbGr3Y=; b=T9P9q7t8YpDOt04KFaMCrUIQgp5PpJTpjuD+ngsPy+3DJmlyzWsb53iFaFkaWo4RYN KX45s/OZFDVAIxK2UvgtRyeCxnfCCIeHH4mZxh8HUMEDRV+pXw6SQ29jy4226PU5Jgk0 28GPEkRg8LkLGxreEgNeta2y8AEd4MBGBHNLXjdptBVWvDpWA8EdEJpesDtu0ObMC+Qy 0TNW59m8+cCqF1o7ckDt+YoJThqFm3gsyRIMK7xYuOKL0DqGuJsWmQ0oaPDwaxu2wDTO YYphRbcHNxL4r7gpJQWrHkUGsC6yk028+NUwVZbCsb9a6Jc5O/ClQg3xjj2FIP9O9EuL Saag== MIME-Version: 1.0 Received: by 10.236.193.67 with SMTP id j43mr23981667yhn.17.1341381287446; Tue, 03 Jul 2012 22:54:47 -0700 (PDT) Sender: mca@amundsen.com Received: by 10.147.79.17 with HTTP; Tue, 3 Jul 2012 22:54:47 -0700 (PDT) In-Reply-To: <647904D2-D497-4E54-9CBB-7E636F2E9F7D@mnot.net> References: <20120704002826.31184.30649.idtracker@ietfa.amsl.com> <647904D2-D497-4E54-9CBB-7E636F2E9F7D@mnot.net> Date: Wed, 4 Jul 2012 01:54:47 -0400 X-Google-Sender-Auth: VziH8EyuyJwa2esQxOi1rKiNo_8 Message-ID: From: mike amundsen To: Mark Nottingham Content-Type: multipart/alternative; boundary=20cf305b0c1a258a5a04c3faab7c X-Gm-Message-State: ALoCoQlqWTgZNX/k0dsqC3kinoSZa7mRjtSYlcmPGfsxY8EwLEoFrdpcm/cZr9xvauVLp2DuwhKE Cc: IETF Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 05:54:40 -0000 --20cf305b0c1a258a5a04c3faab7c Content-Type: text/plain; charset=ISO-8859-1 > A registered value of "error" might be preferable to using "describedby"; esp for machine clients that might encounter "describedby" in other contexts. That was some of the feedback I got pre-draft, and I agree that a different relation might be better. I'm not sure about "error" because it might be misinterpreted; was maybe thinking about a simple "problem-detail" or "problem-type" (because the detail is the *whole* set of details about the type *and* instance of the problem). What misinterpretation of "error" do you foresee? Can you help me get a better handle on the difference you have in mind between "detail" and "type" and/or "type" and" instance" here? > Also, I've found using a "code" property has been helpful for machine clients as this will be static no matter the language used to express the title text That's the function that the URI has in mine. So the content at the other end of URI "z" will always be the same content, no matter the app using this URI, or the specifics that _caused_ the "problem", right? FWIW, in my current usage, the href points to a record that is specific to the immediate problem. This means it is possible that the server will create and collect error logging information at these URIs. I assume that possibility is not accounted for in your baseline design. mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me --20cf305b0c1a258a5a04c3faab7c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> A re= gistered value of "error" might be preferable to using "desc= ribedby"; esp for machine clients that might encounter "described= by" in other contexts.

That was s= ome of the feedback I got pre-draft, and I agree that a different relation = might be better. I'm not sure about "error" because it might = be misinterpreted; was maybe thinking about a simple "problem-detail&q= uot; or "problem-type" (because the detail is the *whole* set of = details about the type *and* instance of the problem).

What misinterpretation of "error" do you foresee?=A0
Can you help me = get a better handle on the difference you have in mind between "detail= " and "type" and/or "type" and" instance"= ; here?


&= gt; Also, I've found using a "code" property has been helpful= for machine clients as this will be static no matter the language used to = express the title text

That's= the function that the URI has in mine.

So the content at the other end of URI "z" will always b= e the same content, no matter the app using this URI, or the specifics that= _caused_ the "problem", right?

FWIW, in= my current usage, the href points to a record that is specific to the imme= diate problem. This means it is possible that the server will create and co= llect error logging information at these URIs.

I assume that possibility is not accounted for in your = baseline design.
--20cf305b0c1a258a5a04c3faab7c-- From dret@berkeley.edu Wed Jul 4 00:20:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E266211E8129 for ; Wed, 4 Jul 2012 00:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fabmAzZthkzr for ; Wed, 4 Jul 2012 00:20:21 -0700 (PDT) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 148BF21F859B for ; Wed, 4 Jul 2012 00:20:20 -0700 (PDT) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretair.local) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1SmJsu-0001tC-Gd; Wed, 04 Jul 2012 00:20:29 -0700 Message-ID: <4FF3EEB2.2000607@berkeley.edu> Date: Wed, 04 Jul 2012 09:20:18 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: IETF Apps Discuss References: <20120704002826.31184.30649.idtracker@ietfa.amsl.com> <647904D2-D497-4E54-9CBB-7E636F2E9F7D@mnot.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 07:20:22 -0000 hello all. thanks, mark, for the initiative! On 2012-07-04 07:54 , mike amundsen wrote: > So the content at the other end of URI "z" will always be the same > content, no matter the app using this URI, or the specifics that > _caused_ the "problem", right? > FWIW, in my current usage, the href points to a record that is specific > to the immediate problem. This means it is possible that the server will > create and collect error logging information at these URIs. > I assume that possibility is not accounted for in your baseline design. it seems to me there's value in having the ability to express both concepts: an "error type" that indicates the type of problem encountered (and i think mark's idea of using a URI for this is better than using a non-URI identifier), as well as an "error instance" that indicates specific information about the occurrence of the error in that particular case. both could probably be optional, and for the type link i'd suggest to treat this as an identifier only (clients should not dereference the URI, the only meaningful operation would be to compare it to known error identifiers), whereas the error instance would be expected to return a representation of the specific error instance. 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 dret@berkeley.edu Wed Jul 4 01:00:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF6221F8704 for ; Wed, 4 Jul 2012 01:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnQSijsu2R3H for ; Wed, 4 Jul 2012 01:00:07 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 17CC121F880F for ; Wed, 4 Jul 2012 01:00:06 -0700 (PDT) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretair.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1SmKVS-0005s6-D8; Wed, 04 Jul 2012 01:00:15 -0700 Message-ID: <4FF3F807.8080508@berkeley.edu> Date: Wed, 04 Jul 2012 10:00:07 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Graham Klyne References: <20120703004409.1599.57166.idtracker@ietfa.amsl.com> <5976E21A-81BC-4576-8609-B2C04C218C10@mnot.net> <4FF24F6D.7050807@berkeley.edu> <158A57BD-6421-4587-B90A-F8E1C98FFC5B@mnot.net> <4FF2BABF.8090003@ninebynine.org> In-Reply-To: <4FF2BABF.8090003@ninebynine.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Mark Nottingham Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-nottingham-link-template-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 08:00:08 -0000 hello all. On 2012-07-03 11:26 , Graham Klyne wrote: > The use-cases I have for this don't depend on the variable names being > URIs. My own take is that it was up to the defining application/API to > explain how the variable names are related to known values, and then use > the Link-template header to allow a service to describe how to map that > information to a related URI. i think that's the use case that mark serves well in the current approach (mapping to URIs is optional). > But, of course, others may have burning use-cases of which I'm unaware, > so this is clearly just one voice among many of what is actually useful > to define here. the question is whether you're interested in scenarios where you make parameters reusable across link templates and relations. currently, there is no standardized way how to "register URI parameters", and maybe that's something worth looking into. our scenarios are something along those lines: - we have paged feed scenarios with random access, where we have well-defined parameters that allow clients to construct URIs of result sets, based on page sizes and a page index. - we want to reuse these concepts in a variety of cases where the actual results mix in other parameters, such as for spatial search, and faceted search. a template should be able to mix-and-match parameters and do that in a way that uses the globally unique URI parameter identifiers. so a question i am interested in looking at would be the following: would it make sense to consider a "URI parameter registry", so that syntax and semantics of URI template parameters could be made reusable across media types and/or link relations? 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 derhoermi@gmx.net Wed Jul 4 01:07:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853F321F87E0 for ; Wed, 4 Jul 2012 01:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnnL6JsGHOw5 for ; Wed, 4 Jul 2012 01:07:41 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 272CB21F8811 for ; Wed, 4 Jul 2012 01:07:40 -0700 (PDT) Received: (qmail invoked by alias); 04 Jul 2012 08:07:49 -0000 Received: from dslb-094-223-211-169.pools.arcor-ip.net (EHLO netb) [94.223.211.169] by mail.gmx.net (mp001) with SMTP; 04 Jul 2012 10:07:49 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/9BugLeDf91nRygpEVD0Q6iDGF2CIrdyFI55+sKf j9W8CTdAcjLCEG From: Bjoern Hoehrmann To: Barry Leiba Date: Wed, 04 Jul 2012 10:07:48 +0200 Message-ID: References: <4FF33F45.90307@gmx.de> <20120703190401.GL17454@1wt.eu> <4FF344C5.6000105@gmx.de> <4FF347D3.7000905@gmx.de> <4FF34CAE.5020302@gmx.de> In-Reply-To: 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-Y-GMX-Trusted: 0 Cc: Julian Reschke , Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 08:07:42 -0000 * Barry Leiba wrote: >OK, I think Julian, Willy, and I have exhausted ourselves on this. >:-) Any comments from others? HTTP does not allow specifications for individual headers to re-define the semantics of multiple instances of the same list-valued header in a message; if X is a list-valued header, then X: 1,2 and X: 1 X: 2 are equivalent; there is no option for the specification of X to say one conforms to the X header specification while the other does not; they're the same by definition for the purpose of finding the header value, see http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-19#section-3.2 -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From andreas@sbin.se Wed Jul 4 05:01:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214A921F87A4 for ; Wed, 4 Jul 2012 05:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekerddKOd2Y6 for ; Wed, 4 Jul 2012 05:01:24 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2E75621F87B2 for ; Wed, 4 Jul 2012 05:01:23 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q64C1Stk000941; Wed, 4 Jul 2012 12:01:28 GMT Date: Wed, 4 Jul 2012 14:01:26 +0200 From: Andreas Petersson To: Stephen Farrell Message-ID: <20120704140126.794bf4e2@hetzer> In-Reply-To: <4FF05306.2010301@cs.tcd.ie> References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 12:01:25 -0000 On Sun, 01 Jul 2012 14:39:18 +0100 Stephen Farrell wrote: > One argument given is that a direct connection would expose the > client IP anyway, but that's not comparing this proposal against > today's reality, which ought to be the point. If you, as a user, bother to find out whether the proxy is anonymizing or not, you can not know that now either. A proxy that is appending "Forwarded" do that because it do not want to anonymize user. If that is the desire, the proxy may already append X-Forwarded-For, which is really widespread. Also, if the intention of the proxy isn't to anonymize, the owner may also give out logfiles to untrusted parties as well. Do you believe that "todays reality" is that you can go and seek up a proxy, that you know nothing about, browse through it, and trust that it will anonymize your requests? Even if the proxy owner doesn't call the proxy "anonymizing"? As said, X-Forwarded-For does already exists and is implemented in all large proxy-servers, so this is nothing new, it is only a standardization of that. I don't think this document is the place for guidelines, neither for how to set up an anonymizing proxy, nor how to browse the web in an anonymous way. > I also think the text in that section seems to be trying to sell > this as having no privacy impact, and I just don't think that is > the case. I do not see what that impact would be really. Please explain when this specification have an impact, compared to todays reality. Do you suggest that we should advise people not use this at all? It may be a nice thought, but I think it is far to idealistic. Unfortunately, such a proxy-service would be abused for a lot of things. So most people do not want to run such a service, and lots of network owners wouldn't like to host it, etc. > I've only looked at 8.3, but I believe the privacy considerations > section is wrong when it says that standardising this has no new > privacy impact. I do not entirely agree with you here. But I notice that there are more support for this opinion, so lets try to come up with something. This is the text SM sent: ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05774.html SM, correct me if I'm wrong). In recent years, there has been growing concerns about privacy. There is a tradeoff between ensuring privacy for users versus disclosing information which is useful for debugging. The Forwarded HTTP header field, by design, exposes information which affects the privacy of users. This header field should not be used if the proxy is being operated as a privacy service. This header field is not only for debugging, so that should probably be expanded. Something else that should be added? I do think that the text should say something about the current use of similar header fields though, otherwise it may look like everything is fine unless you don't use this, which is not true. Users should also be aware of all other different headers and cookies that their browsers sends out, so they can be identified by those too, but mentioning that here seems out of scope to me. Best regards, Andreas From stephen.farrell@cs.tcd.ie Wed Jul 4 06:37:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F061321F87A8 for ; Wed, 4 Jul 2012 06:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxJT+5QoEGEb for ; Wed, 4 Jul 2012 06:37:06 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id BC8CE21F87A2 for ; Wed, 4 Jul 2012 06:37:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E29ED171819; Wed, 4 Jul 2012 14:37:12 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341409031; bh=9cCUEjkRzYf/Uh SGb96+pvH57x4bpoOhb3Msk27HxRE=; b=vMtBbdch47JyE/jBGTw58m29xvvNn4 WcAk5GBjS+pPuNgC+XZxqCP/SmQmTHGAjt2aWs+xe1lc37UcW7NDuVkJ2Z/04zsf 7vkjOAMcQsNOqd/+9WpjqbdFmytpXGHf9K3EQbRpOcC8tB5s/ZcFPOSPnma/O+we fgakCcyR7y9lZUdJmusx+REhyW5YXrLgwzVEUNE4vUqDIsKcMdNWvaFkWVYF6oGh NkRHTxXKsKKtXDpPvcZ/+Z9tcFRiCSrUqsr7qGARhgwDyad7oVkCNuFvCUx9ODah f31suEIl50dAzwrIQsObNwqU5UEAgzPNFwxCRXdDAsO8a9YnmKTJhI8Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id qA7M1mHbi2Ws; Wed, 4 Jul 2012 14:37:11 +0100 (IST) Received: from [IPv6:2001:770:10:203:55ef:e8f4:bac2:5d52] (unknown [IPv6:2001:770:10:203:55ef:e8f4:bac2:5d52]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 85FF617147F; Wed, 4 Jul 2012 14:37:08 +0100 (IST) Message-ID: <4FF44705.2000707@cs.tcd.ie> Date: Wed, 04 Jul 2012 14:37:09 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andreas Petersson References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> In-Reply-To: <20120704140126.794bf4e2@hetzer> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 13:37:07 -0000 Hi Andreas, On 07/04/2012 01:01 PM, Andreas Petersson wrote: > On Sun, 01 Jul 2012 14:39:18 +0100 > Stephen Farrell wrote: >> One argument given is that a direct connection would expose the >> client IP anyway, but that's not comparing this proposal against >> today's reality, which ought to be the point. > > If you, as a user, bother to find out whether the proxy is anonymizing > or not, you can not know that now either. I can't really parse the above sorry. > A proxy that is appending "Forwarded" do that because it do not want to > anonymize user. If that is the desire, the proxy may already append > X-Forwarded-For, which is really widespread. I think that needs to be clear in 8.3. > Also, if the intention of the proxy isn't to anonymize, the owner may > also give out logfiles to untrusted parties as well. > > Do you believe that "todays reality" is that you can go and seek up a > proxy, that you know nothing about, browse through it, and trust that > it will anonymize your requests? Even if the proxy owner doesn't call > the proxy "anonymizing"? No I don't. But direct connections are not today's reality which is what's implied by the current 8.3. > As said, X-Forwarded-For does already exists and is implemented in > all large proxy-servers, so this is nothing new, it is only a > standardization of that. > > I don't think this document is the place for guidelines, neither for > how to set up an anonymizing proxy, nor how to browse the web in an > anonymous way. > > >> I also think the text in that section seems to be trying to sell >> this as having no privacy impact, and I just don't think that is >> the case. > > I do not see what that impact would be really. Please explain when this > specification have an impact, compared to todays reality. Presumably the reason to standardise this is so that more proxies will do it this way. That reduces privacy to some extent unless nobody adopts this. > Do you suggest that we should advise people not use this at all? It may > be a nice thought, but I think it is far to idealistic. Unfortunately, > such a proxy-service would be abused for a lot of things. So most > people do not want to run such a service, and lots of network owners > wouldn't like to host it, etc. I didn't suggest that. I'm asking for truth in advertising. >> I've only looked at 8.3, but I believe the privacy considerations >> section is wrong when it says that standardising this has no new >> privacy impact. > > I do not entirely agree with you here. But I notice that there are more > support for this opinion, so lets try to come up with something. > > This is the text SM sent: > ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05774.html > SM, correct me if I'm wrong). > > In recent years, there has been growing concerns about privacy. > There is a tradeoff between ensuring privacy for users versus > disclosing information which is useful for debugging. The Forwarded > HTTP header field, by design, exposes information which affects the > privacy of users. This header field should not be used if the proxy > is being operated as a privacy service. > > This header field is not only for debugging, so that should > probably be expanded. Something else that should be added? Depends on what else its used for I guess. If there are other (non-obvious uses) with privacy implications then those should I guess be mentioned. Not sure myself. (I'm assuming this information is mostly fed into the marketing machine.) > I do think that the text should say something about the current use of > similar header fields though, otherwise it may look like everything is > fine unless you don't use this, which is not true. Right. > Users should also be aware of all other different headers and cookies > that their browsers sends out, so they can be identified by those too, > but mentioning that here seems out of scope to me. I agree that such things are out of scope. Ok, Alexey asked for text, how about something like this for 8.3: "The existing X-Forwarded-* headers expose information that some users (or regulators) consider privacy sensitive. This header field standardises that practice and so decreases user privacy. However, with the current widespread use of X-Forwarded-*, that impact is considered acceptable as it improves interoperability, which might also allow for better privacy controls in future. Implementers and operators deploying this header (or X-Forwarded-* equivalents) need to consider whether and how doing so impacts on user privacy and for example whether relevant regulations such as cross-border controls might come into play. See [ref] for additional guidance." I don't have a good reference to hand, but referring to something that tells implementers and/or operators how to play nice would be useful I think, since it seems that many don't know (or don't care, and claim not to know;-) BTW - I still haven't had a chance to read the whole thing, though, so might have more comments when I do. Cheers, S. > > Best regards, > Andreas > > From andreas@sbin.se Wed Jul 4 07:56:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2396B21F87D6 for ; Wed, 4 Jul 2012 07:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJRLZR09ukUN for ; Wed, 4 Jul 2012 07:56:02 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 32F9621F87D3 for ; Wed, 4 Jul 2012 07:56:01 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q64Eu3tU020227; Wed, 4 Jul 2012 14:56:07 GMT Date: Wed, 4 Jul 2012 16:56:02 +0200 From: Andreas Petersson To: Stephen Farrell Message-ID: <20120704165602.61d722a9@hetzer> In-Reply-To: <4FF44705.2000707@cs.tcd.ie> References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 14:56:06 -0000 On Wed, 04 Jul 2012 14:37:09 +0100 Stephen Farrell wrote: > > Hi Andreas, > > On 07/04/2012 01:01 PM, Andreas Petersson wrote: > > On Sun, 01 Jul 2012 14:39:18 +0100 > > Stephen Farrell wrote: > >> One argument given is that a direct connection would expose the > >> client IP anyway, but that's not comparing this proposal against > >> today's reality, which ought to be the point. > > > > If you, as a user, bother to find out whether the proxy is anonymizing > > or not, you can not know that now either. > > I can't really parse the above sorry. Sorry, it should read: "If you, as a user, don't bother to find out whether the proxy is anonymizing or not, you can not know that* now either." *) That the proxy is not giving away your IP-address. > > > A proxy that is appending "Forwarded" do that because it do not want to > > anonymize user. If that is the desire, the proxy may already append > > X-Forwarded-For, which is really widespread. > > I think that needs to be clear in 8.3. > > > Also, if the intention of the proxy isn't to anonymize, the owner may > > also give out logfiles to untrusted parties as well. > > > > Do you believe that "todays reality" is that you can go and seek up a > > proxy, that you know nothing about, browse through it, and trust that > > it will anonymize your requests? Even if the proxy owner doesn't call > > the proxy "anonymizing"? > > No I don't. But direct connections are not today's reality > which is what's implied by the current 8.3. Well, they do exist of course. But also non-direct connections are discussed in the current version of 8.3. > > > As said, X-Forwarded-For does already exists and is implemented in > > all large proxy-servers, so this is nothing new, it is only a > > standardization of that. > > > > I don't think this document is the place for guidelines, neither for > > how to set up an anonymizing proxy, nor how to browse the web in an > > anonymous way. > > > > > >> I also think the text in that section seems to be trying to sell > >> this as having no privacy impact, and I just don't think that is > >> the case. > > > > I do not see what that impact would be really. Please explain when this > > specification have an impact, compared to todays reality. > > Presumably the reason to standardise this is so that more proxies > will do it this way. That reduces privacy to some extent unless > nobody adopts this. The reason to standardize this is so that more proxies will do this instead of X-Forwarded-* (e.g. For). I do not expect people to start using this, who currently do not use X-Forwarded-For. XFF is so widely spread so those who wants to disclose this information does it already. If your concern is that more people will start using this just because it exists, well, yes, that may have a privacy impact. If this is you concern, I start to understand your point. I don't share your concern but we can surely mention that this header field should not be used for people that do not see an actual need for it. > > > Do you suggest that we should advise people not use this at all? It may > > be a nice thought, but I think it is far to idealistic. Unfortunately, > > such a proxy-service would be abused for a lot of things. So most > > people do not want to run such a service, and lots of network owners > > wouldn't like to host it, etc. > > I didn't suggest that. I'm asking for truth in advertising. Ok, just asking. > > >> I've only looked at 8.3, but I believe the privacy considerations > >> section is wrong when it says that standardising this has no new > >> privacy impact. > > > > I do not entirely agree with you here. But I notice that there are more > > support for this opinion, so lets try to come up with something. > > > > This is the text SM sent: > > ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05774.html > > SM, correct me if I'm wrong). > > > > In recent years, there has been growing concerns about privacy. > > There is a tradeoff between ensuring privacy for users versus > > disclosing information which is useful for debugging. The Forwarded > > HTTP header field, by design, exposes information which affects the > > privacy of users. This header field should not be used if the proxy > > is being operated as a privacy service. > > > > This header field is not only for debugging, so that should > > probably be expanded. Something else that should be added? > > Depends on what else its used for I guess. If there are other > (non-obvious uses) with privacy implications then those should > I guess be mentioned. Not sure myself. (I'm assuming this > information is mostly fed into the marketing machine.) One use case which I believe is pretty big is to geo-locate the users to localize the content in various ways. I don't think that is an elegant solution, but it is part of the reality. If this use is intrusive on privacy is probably a matter of taste. > > I do think that the text should say something about the current use of > > similar header fields though, otherwise it may look like everything is > > fine unless you don't use this, which is not true. > > Right. > > > Users should also be aware of all other different headers and cookies > > that their browsers sends out, so they can be identified by those too, > > but mentioning that here seems out of scope to me. > > I agree that such things are out of scope. > > Ok, Alexey asked for text, how about something like this > for 8.3: It's a start, but I have some concerns (see below). > "The existing X-Forwarded-* headers expose information that > some users (or regulators) consider privacy sensitive. This > header field standardises that practice and so decreases user > privacy. "... and so decreases ..." I don't see how it decreases if people are following an RFC-specification of the format, or just the de facto format that everyone already uses. > However, with the current widespread use of > X-Forwarded-*, that impact is considered acceptable as it > improves interoperability, which might also allow for > better privacy controls in future. Implementers and operators > deploying this header (or X-Forwarded-* equivalents) need to > consider whether and how doing so impacts on user privacy and > for example whether relevant regulations such as cross-border > controls might come into play. See [ref] for additional > guidance." What regulations and cross-border controls are you talking about here? Can you elaborate? > I don't have a good reference to hand, but referring to > something that tells implementers and/or operators how to > play nice would be useful I think, since it seems that > many don't know (or don't care, and claim not to know;-) Anyone else who can point to some relevant document for this matter? I would think that most parties to follow the laws in their respective country, which may be part of the problem, of course, but also quite expected. > BTW - I still haven't had a chance to read the whole thing, > though, so might have more comments when I do. Well, the document is current under AD review. It would have been better if you raised your comments during the WGLC. If you find new issues, I guess the time to raise them is during the IETF LC, but I'm unsure about the process here. Best regards, Andreas From superuser@gmail.com Wed Jul 4 07:59:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7283D21F8857 for ; Wed, 4 Jul 2012 07:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skO-qNKnU9BU for ; Wed, 4 Jul 2012 07:59:21 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E70D21F873D for ; Wed, 4 Jul 2012 07:59:19 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so11566431lbb.31 for ; Wed, 04 Jul 2012 07:59:29 -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=BnQ8ZIbKGhcpMH809fVV5+exlFid/MVjA31Oc4KZVAQ=; b=HyC5fWiyvdB3Ns42JKRR93Kr0f8xeihmka4yq0ykIz69arzRkd9Mi7hFtpMCXyoOs5 t/OPfMABsIWRmsDstHoqHVF1NYhOLVxWEpyRgP4NcLgJnpwWhkbhEVluWcxC8Lf6kou2 R9YqAkovw0ustbiPi1KYO4zptCimoC6cCegeHjsyta6+eUOd0gLjkpHmIB7Hr49e+2bv gzWXfYwsPggys7XcKGG+Gr7b6Ni6DsVZZylTP5uhH1/RkhwWO7bGu5/IP7FbcRUpC3Uw PnsdizJ9aFG+NFYvMrHsTBkkIytS1jdgZNVjaq0rixkiyYP3WwpOWm58VlAjcTak6BoD bASg== MIME-Version: 1.0 Received: by 10.112.49.100 with SMTP id t4mr10181536lbn.10.1341413969557; Wed, 04 Jul 2012 07:59:29 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 4 Jul 2012 07:59:29 -0700 (PDT) In-Reply-To: References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> <20120703190401.GL17454@1wt.eu> <4FF344C5.6000105@gmx.de> <4FF347D3.7000905@gmx.de> <4FF34CAE.5020302@gmx.de> Date: Wed, 4 Jul 2012 07:59:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=bcaec554d63c26f9a804c4024749 Cc: Julian Reschke , Willy Tarreau , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 14:59:23 -0000 --bcaec554d63c26f9a804c4024749 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 3, 2012 at 1:10 PM, Barry Leiba wrote: > > Manipulating HTTP messages *properly* is non-trivial; I don't believe > that > > trying to add more special cases will do anything except making things > > worse. > > Ack. > > OK, I think Julian, Willy, and I have exhausted ourselves on this. > :-) Any comments from others? > > Was this general two-format header thing done deliberately, or were their competing implementations or specifications at some time in the past and they were just merged? I basically concur with Barry, that having two formats for something is just bad form. We should pick one and go with that. But I think that idea becomes pretty hard to enforce when apparently, with HTTP, that ship has already unfortunately sailed and parsers to handle both formats are widely deployed. Converging on one is bigger than this document. It would be nice of this got "fixed" at a lower level in httpbis, but I'll shut up now as I feel them turning their guns on me. :-) -MSK --bcaec554d63c26f9a804c4024749 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 3, 2012 at 1:10 PM, Barry Leiba <barryleiba@computer.o= rg> wrote:
> Manipulating HTTP messages *properly* is non-trivial= ; I don't believe that
> trying to add more special cases will do anything except making things=
> worse.

Ack.

OK, I think Julian, Willy, and I have exhausted ourselves on this.
:-) =A0Any comments from others?


Was this general two-format header thing done deliberately, or = were their competing implementations or specifications at some time in the = past and they were just merged?

I basically concur with Barry, that having two formats for something is= just bad form.=A0 We should pick one and go with that.

But I think = that idea becomes pretty hard to enforce when apparently, with HTTP, that s= hip has already unfortunately sailed and parsers to handle both formats are= widely deployed.=A0 Converging on one is bigger than this document.

It would be nice of this got "fixed" at a lower level in http= bis, but I'll shut up now as I feel them turning their guns on me.=A0 := -)

-MSK
--bcaec554d63c26f9a804c4024749-- From alexey.melnikov@isode.com Wed Jul 4 08:06:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324AB21F8833 for ; Wed, 4 Jul 2012 08:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3ASVy27NRJG for ; Wed, 4 Jul 2012 08:06:46 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id D011921F8815 for ; Wed, 4 Jul 2012 08:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1341414407; d=isode.com; s=selector; i=@isode.com; bh=wuGJwtz0gQMsFQik/3ALAc/G90DQsJ7N/b5Gg4xtPOU=; 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=JBMcSEUS1BoNnDKvKG6IYXGjmpkXc1EJ73NlA3+jcgQgIv2f+0DaULIVrOFrrYlkbGQ7qb x7IIjyLBzp2adENe5597GVHGbSigz6/JwWIWRsN/sgmpXM5z25jBIFIel84Jt+0w35T4K7 jkLdpWeSX4UFdYWIFy+5cWNuKoaEzsA=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 4 Jul 2012 16:06:46 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FF45C09.9080102@isode.com> Date: Wed, 04 Jul 2012 16:06:49 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "Murray S. Kucherawy" References: <4FF33C11.6040300@gmx.de> <4FF33F45.90307@gmx.de> <20120703190401.GL17454@1wt.eu> <4FF344C5.6000105@gmx.de> <4FF347D3.7000905@gmx.de> <4FF34CAE.5020302@gmx.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050408070103040003040205" Cc: Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 15:06:47 -0000 This is a multi-part message in MIME format. --------------050408070103040003040205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/07/2012 15:59, Murray S. Kucherawy wrote: > On Tue, Jul 3, 2012 at 1:10 PM, Barry Leiba > wrote: > > > Manipulating HTTP messages *properly* is non-trivial; I don't > believe that > > trying to add more special cases will do anything except making > things > > worse. > > Ack. > > OK, I think Julian, Willy, and I have exhausted ourselves on this. > :-) Any comments from others? > > > Was this general two-format header thing done deliberately, Yes! > or were their competing implementations or specifications at some time > in the past and they were just merged? > > I basically concur with Barry, that having two formats for something > is just bad form. We should pick one and go with that. > > But I think that idea becomes pretty hard to enforce when apparently, > with HTTP, that ship has already unfortunately sailed and parsers to > handle both formats are widely deployed. Converging on one is bigger > than this document. > > It would be nice of this got "fixed" at a lower level in httpbis, but > I'll shut up now as I feel them turning their guns on me. :-) --------------050408070103040003040205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 04/07/2012 15:59, Murray S. Kucherawy wrote:
On Tue, Jul 3, 2012 at 1:10 PM, Barry Leiba <barryleiba@computer.org> wrote:
> Manipulating HTTP messages *properly* is non-trivial; I don't believe that
> trying to add more special cases will do anything except making things
> worse.

Ack.

OK, I think Julian, Willy, and I have exhausted ourselves on this.
:-)  Any comments from others?


Was this general two-format header thing done deliberately,
Yes!
or were their competing implementations or specifications at some time in the past and they were just merged?

I basically concur with Barry, that having two formats for something is just bad form.  We should pick one and go with that.

But I think that idea becomes pretty hard to enforce when apparently, with HTTP, that ship has already unfortunately sailed and parsers to handle both formats are widely deployed.  Converging on one is bigger than this document.

It would be nice of this got "fixed" at a lower level in httpbis, but I'll shut up now as I feel them turning their guns on me.  :-)

--------------050408070103040003040205-- From w@1wt.eu Wed Jul 4 08:48:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62E121F870F for ; Wed, 4 Jul 2012 08:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.93 X-Spam-Level: X-Spam-Status: No, score=-4.93 tagged_above=-999 required=5 tests=[AWL=-2.887, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+0DuCX1mnaF for ; Wed, 4 Jul 2012 08:48:10 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id CE3CC21F8700 for ; Wed, 4 Jul 2012 08:48:09 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q64Fm770023905; Wed, 4 Jul 2012 17:48:07 +0200 Date: Wed, 4 Jul 2012 17:48:07 +0200 From: Willy Tarreau To: "Murray S. Kucherawy" Message-ID: <20120704154807.GC23139@1wt.eu> References: <20120703190401.GL17454@1wt.eu> <4FF344C5.6000105@gmx.de> <4FF347D3.7000905@gmx.de> <4FF34CAE.5020302@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Julian Reschke , Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 15:48:10 -0000 On Wed, Jul 04, 2012 at 07:59:29AM -0700, Murray S. Kucherawy wrote: > On Tue, Jul 3, 2012 at 1:10 PM, Barry Leiba wrote: > > > > Manipulating HTTP messages *properly* is non-trivial; I don't believe > > that > > > trying to add more special cases will do anything except making things > > > worse. > > > > Ack. > > > > OK, I think Julian, Willy, and I have exhausted ourselves on this. > > :-) Any comments from others? > > > > > Was this general two-format header thing done deliberately, or were their > competing implementations or specifications at some time in the past and > they were just merged? I think it dates at least back to SMTP, where you very commonly see this with the Cc and To headers. Also, keep in mind that the two formats have a real use, to limit the max length of a given header field value without forcing everyone to send multiple occurrences each on their own line. Regards, Willy From melvincarvalho@gmail.com Wed Jul 4 12:05:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EDA21F85E3 for ; Wed, 4 Jul 2012 12:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+4PhEslRA1Z for ; Wed, 4 Jul 2012 12:05:02 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DDD0D21F862B for ; Wed, 4 Jul 2012 12:05:01 -0700 (PDT) Received: by vcqp1 with SMTP id p1so5538327vcq.31 for ; Wed, 04 Jul 2012 12:05:12 -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=ed2kbCU+y80MM92aaY9A+3Su7KSkLEOl2srBJyQ20LY=; b=fdJ2q1XbT3fczoEocGK80mSf7VwbqgNE6n908Gi+0CBegFbJ3SvRA0DiNkkOsV6LDe vtikwnim+pO6uOkrwFOLsG08WjOpUM/UNNK22M2hBJ1bHnCnDSMRhq42pqOg5FO5n0y6 yLiBWfPhEObUZ5848RllXd0hj2PrkyOtq4x6Vom1e7BbYdt7pSfr649WSPTUvQUP1FL5 miNO7GYojuIct9JqWN6gDcrStmrliX8t/+uAaRiLirrSxZ8Y4KkF7mPnsT5YPM7OzMXR qgUViTP56Wmg4TCztm4Z+ajrN6VM9fpEQkBzrYOqCPj8ijK5wrKQPAF8CXH0+BKKbxfe 5pew== MIME-Version: 1.0 Received: by 10.52.28.99 with SMTP id a3mr4558717vdh.68.1341428712845; Wed, 04 Jul 2012 12:05:12 -0700 (PDT) Received: by 10.52.166.102 with HTTP; Wed, 4 Jul 2012 12:05:12 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <1A87B9DE-ECEC-4F07-8734-131D4BB564EB@ve7jtb.com> <911C1091-6D88-4937-BF4C-0FCB264B6AEF@ve7jtb.com> Date: Wed, 4 Jul 2012 21:05:12 +0200 Message-ID: From: Melvin Carvalho To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=20cf3079b920ebb2b204c405b51b Cc: Mark Nottingham , Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 19:05:03 -0000 --20cf3079b920ebb2b204c405b51b Content-Type: text/plain; charset=ISO-8859-1 On 4 July 2012 05:46, Murray S. Kucherawy wrote: > On Tue, Jul 3, 2012 at 1:17 PM, John Bradley wrote: > >> There are existing deployments of WF. Changes that lead to something >> incompatible with what is deployed >> are likely to receive more resistance, now that we have a WG draft. >> >> Not that changes can't be made with rough consensus.. >> >> It may have been easier though to have had Mark and others comments >> before the WG draft. > > That might have made it easier to have included some more of the SWD >> design. >> >> > The fact that there's a WG draft now doesn't change what's been deployed. > These are two orthogonal points. > > I (predictably) concur with Barry's statements about document evolution. > The working group could conceivably completely rewrite Webfinger at this > point if it so chooses, as driven by consensus. That includes applying > all, some, or none of Mark's comments, for example. > > If you have some changes you'd like to have the working group consider, > the floor is open. > One question I've been thinking about. Does the acct: scheme also apply to subdomains too, or just the parent domain, or only where an email exists? For example, are the following four, equivalent ways to describe an account? acct:bob@facebook.com acct:bob@www.facebook.com acct:bob@graph.facebook.com https://graph.facebook.com/bob > > -MSK > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --20cf3079b920ebb2b204c405b51b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 4 July 2012 05:46, Murray S. Kucheraw= y <superuser@gmail.com> wrote:
On Tue, Jul 3, 2012 at 1:17 PM, John Bradley <ve7jtb@ve7= jtb.com> wrote:
There are existing deployments of WF. =A0 Changes that lead to something in= compatible with what is deployed
are likely to receive more resistance, now that we have a WG draft.

Not that changes can't be made with rough consensus..

It may have been easier though to have had Mark and others comments before = the WG draft.=A0
That might have made it easier to have included some more of the SWD design= .


The fact that there's a WG draft now do= esn't change what's been deployed.=A0 These are two orthogonal poin= ts.

I (predictably) concur with Barry's statements about document=20 evolution.=A0 The working group could conceivably completely rewrite=20 Webfinger at this point if it so chooses, as driven by consensus.=A0 That i= ncludes applying all, some, or none of Mark's comments, for example.
If you have some changes you'd like to have the working group cons= ider, the floor is open.

One question I've been = thinking about.=A0 Does the acct: scheme also apply to subdomains too, or j= ust the parent domain, or only where an email exists?

For example, a= re the following four, equivalent ways to describe an account?

acct:bob@facebook.comacct:bob@www.facebook.com
acct:bob@graph.faceb= ook.com
https://graph.facebook.com/bob

=A0

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


--20cf3079b920ebb2b204c405b51b-- From ve7jtb@ve7jtb.com Wed Jul 4 12:56:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D8121F8657 for ; Wed, 4 Jul 2012 12:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK-hiC1tU8Kj for ; Wed, 4 Jul 2012 12:56:29 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B686F21F85DF for ; Wed, 4 Jul 2012 12:56:29 -0700 (PDT) Received: by ghbg16 with SMTP id g16so7512040ghb.31 for ; Wed, 04 Jul 2012 12:56:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=a6M4J/sWZpZvSY2wkw+ybbT/IANz2fh2NLJSwYavOe0=; b=AyHKHUWwd6E4W50TocKEqueZs5I6vyPR6X6PSYvqDjuDq/PFRdXw95vIcECys3IYTJ LmHAC2//HrEglWxYaqMHCKY6pIK6d4sLt69IygFx/uUx8gjkf8siWRS+x+wwFWR2AFKa nDmqvkvhi7qa924Yn6mjpWnY9SkQ68LMEITI52bxfUiyeuipHIhoOtdW7EjWbYi5Y00l ip9n8AjuOpAW7eE8jtZms1SbmPmSG4mbiQEArUvblAti/rDhqZ8RqHvd2NbtSgrJTEni 5Btg5PmxN7UvC/UGGYVbaJOPtKvTmqvgGCxu8O+Y/yesaC/tT5eC3wnUQnYClNoB3F4X 2WGg== Received: by 10.236.76.230 with SMTP id b66mr27136185yhe.93.1341431800523; Wed, 04 Jul 2012 12:56:40 -0700 (PDT) Received: from [192.168.1.211] (190-20-63-87.baf.movistar.cl. [190.20.63.87]) by mx.google.com with ESMTPS id f28sm17306391yhk.2.2012.07.04.12.56.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jul 2012 12:56:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_0F899FFD-FA43-4F3F-84D4-2C42E24D44FB"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Wed, 4 Jul 2012 15:56:29 -0400 Message-Id: <816E4270-6A7B-4B39-96E8-4A4C23DAE731@ve7jtb.com> References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <1A87B9DE-ECEC-4F07-8734-131D4BB564EB@ve7jtb.com> <911C1091-6D88-4937-BF4C-0FCB264B6AEF@ve7jtb.com> To: Melvin Carvalho X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnxkYGjIIx0x4WzLTOUJWHvKo1HDVoFgg2Nx4efSt2ZqGiriQadY4jd5deg1wRdBqDnnha6 Cc: Mark Nottingham , Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 19:56:30 -0000 --Apple-Mail=_0F899FFD-FA43-4F3F-84D4-2C42E24D44FB Content-Type: multipart/alternative; boundary="Apple-Mail=_6FD4966C-3E4C-4F15-A7A8-0243141A8CD8" --Apple-Mail=_6FD4966C-3E4C-4F15-A7A8-0243141A8CD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 They are all separate identifiers and could resolve to different = XRD/JRD. It would be up to the provider to make the four identifiers = return the same information. Though example 3 and 4 would at least share the same host-metta for = resolution. One unresolved problem is what happens in a hosted environment like = Google apps. If I have a domain like ve7jtb.com where I have pointed mail.ve7jtb.com, = calendar.ve7jtb.com , and the MX records to google. I may have no web server for ve7jtb.com or have it pointed at some = simple hosting service, that has no notion of WF. How would Google provide WF and the services that rely on it to those = hosted domains? This is a real problem. For openID 2.0 they asked the RP to check with = a special google service to see if it was hosted. This potentially allows for the hijacking of the discovery information = and might not be ideal for all protocols using WF. The ideas that have circulated are: 1 Using SRV records. Not all DNS services support SRV and users will = not configure not correctly (on the order of the experience with goggle = apps XMPP config) 2 Using MX records. Check the MX host if you can't find the host-metta. = This is more likely to be configurable but ties acct: and WF to SMTPl = in a way that is not ideal. Clients are also going to need to access = DNS directly. 3 Use a special subdomain. Check the host web = finger-discovery-home.ve7jtb.com if you can't find host-meta on the = target host. The downside id that it bends the principal of not = steeling namespace. the upside is that configuring an A record is = something users can do, and it is easy for WF clients. Solving this real world problem for WF is a high priority to be able to = deploy it. John B. On 2012-07-04, at 3:05 PM, Melvin Carvalho wrote: >=20 >=20 > On 4 July 2012 05:46, Murray S. Kucherawy wrote: > On Tue, Jul 3, 2012 at 1:17 PM, John Bradley = wrote: > There are existing deployments of WF. Changes that lead to something = incompatible with what is deployed > are likely to receive more resistance, now that we have a WG draft. >=20 > Not that changes can't be made with rough consensus.. >=20 > It may have been easier though to have had Mark and others comments = before the WG draft.=20 > That might have made it easier to have included some more of the SWD = design. >=20 >=20 > The fact that there's a WG draft now doesn't change what's been = deployed. These are two orthogonal points. >=20 > I (predictably) concur with Barry's statements about document = evolution. The working group could conceivably completely rewrite = Webfinger at this point if it so chooses, as driven by consensus. That = includes applying all, some, or none of Mark's comments, for example. >=20 > If you have some changes you'd like to have the working group = consider, the floor is open. >=20 > One question I've been thinking about. Does the acct: scheme also = apply to subdomains too, or just the parent domain, or only where an = email exists? >=20 > For example, are the following four, equivalent ways to describe an = account? >=20 > acct:bob@facebook.com > acct:bob@www.facebook.com > acct:bob@graph.facebook.com > https://graph.facebook.com/bob >=20 > =20 >=20 > -MSK >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 --Apple-Mail=_6FD4966C-3E4C-4F15-A7A8-0243141A8CD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 They = are all separate identifiers and could resolve to different XRD/JRD. =  It would be up to the provider to make the four identifiers return = the same information.

Though example 3 and 4 would at = least share the same host-metta for = resolution.

One unresolved problem is what = happens in a hosted environment like Google = apps.

If I have a domain like ve7jtb.com where I have pointed mail.ve7jtb.com, calendar.ve7jtb.com , and the MX = records to google.
I may have no web server for ve7jtb.com or have it pointed at some = simple hosting service, that has no notion of = WF.

How would Google provide WF and the = services that rely on it to those hosted = domains?

This is a real problem.   For = openID 2.0 they asked the RP to check with a special google service to = see if it was hosted.
This potentially allows for the = hijacking of the discovery information and might not be ideal for all = protocols using WF.

The ideas that have = circulated are:
1 Using SRV records.   Not all DNS = services support SRV and users will not configure not correctly =  (on the order of the experience with goggle apps XMPP = config)
2 Using MX records.  Check the MX host if you = can't find the host-metta.   This is more likely to be configurable = but ties acct:  and WF to SMTPl in a way that is not ideal. =  Clients are also going to need to access DNS directly.
3 = Use a special subdomain.  Check the host web finger-discovery-home.ve7= jtb.com if you can't find host-meta on the target host.  The = downside id that it bends the principal of not steeling namespace. =  the upside is that configuring an A record is something users can = do, and it is easy for WF clients.

Solving this = real world problem for WF is a high priority to be able to deploy = it.

John B.
On 2012-07-04, = at 3:05 PM, Melvin Carvalho wrote:



On 4 July 2012 05:46, Murray S. Kucherawy <superuser@gmail.com> = wrote:
On Tue, Jul 3, 2012 at 1:17 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
There are existing deployments of WF.   Changes that lead to = something incompatible with what is deployed
are likely to receive more resistance, now that we have a WG draft.

Not that changes can't be made with rough consensus..

It may have been easier though to have had Mark and others comments = before the WG draft. 
That might have made it easier to have included some more of the SWD = design.


The fact that there's a WG draft now = doesn't change what's been deployed.  These are two orthogonal = points.

I (predictably) concur with Barry's statements about document=20 evolution.  The working group could conceivably completely rewrite=20= Webfinger at this point if it so chooses, as driven by consensus.  = That includes applying all, some, or none of Mark's comments, for = example.

If you have some changes you'd like to have the working = group consider, the floor is open.

One question I've been = thinking about.  Does the acct: scheme also apply to subdomains = too, or just the parent domain, or only where an email = exists?

For example, are the following four, equivalent ways to = describe an account?

acct:bob@facebook.com
acct:bob@www.facebook.com<= br>acct:bob@graph.facebook.com<= /a>
https://graph.facebook.com/bob=

 

-MSK

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


= --Apple-Mail=_6FD4966C-3E4C-4F15-A7A8-0243141A8CD8-- --Apple-Mail=_0F899FFD-FA43-4F3F-84D4-2C42E24D44FB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw NDE5NTYzMFowIwYJKoZIhvcNAQkEMRYEFHJ5L1yFiGoQsNloZw+yg9nUqP5iMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AFNu0H1h5KcyninMtugXGQ0NymcL8NnJAoWdnOMQRIbB0OaTLoAyLE6wdb7kqqXQfXGJ7+JMJj8M 0aGDu1AOkx/eokh6aMDhh6GiuoEH02nTI1sU5jT9G1OiUYCGQUmtId95AEDUUr48UqOcF8r/J6RE yhBOiGwlqrKBhaqcAihsSgQpJqIqQJkQkymYOWKM+idrP9HFR79wVJ2EPiqYdbM04sYUuR3qzPqZ 7xBbsczpwiHV+KnQFbv5MAeLSQ0FSpmT/KPGeF7ykyJfx4WawePvT3PGgs8+2zjkVzy5v2zKqyDT Wew8XgmxIXmeJfkLLByYu9w0MGF4QVHPyYYgcgsAAAAAAAA= --Apple-Mail=_0F899FFD-FA43-4F3F-84D4-2C42E24D44FB-- From sm@resistor.net Wed Jul 4 13:14:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565A021F8547 for ; Wed, 4 Jul 2012 13:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8Q37KjS0Pum for ; Wed, 4 Jul 2012 13:14:07 -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 79F1121F85CD for ; Wed, 4 Jul 2012 13:14:07 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q64KEACL012176; Wed, 4 Jul 2012 13:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341432858; bh=Qcpzyu5tgYw6vynHFF5DIu0UkXtMIq0o0z+VHoMDCwU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fygLx/z5RhxWiRLsls7SGOg8LSguoVGRjA1bRu78xKJZiN9dx+saadM8ey4Sye0Nz LR5rR5mF37mI915mqxsAVPp2dzi0pTm0wDFZot+QSJH4D4azwkslBnW5ylhJLJC0OH R5kdqtON4K+GBxCCvJ4tL9iO4/wn9Ek2ingIOSmc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341432858; i=@resistor.net; bh=Qcpzyu5tgYw6vynHFF5DIu0UkXtMIq0o0z+VHoMDCwU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LHiAWmYKeS2pmK+tg7c1G0hH4iw0iKKqV31rsTIHLnDcuppR2QLpZG82dzQIglOmY pAR8IIyEXFoPl4Co9NSi9CDkJ4ftOEgWVPFRH3u3mgdI2n/q1NQHMPfxLjfDgaIYL5 03ZMLW22YhNMM15EuSMclQ6vQnX9tazha95epmtY= Message-Id: <6.2.5.6.2.20120704123329.05e60578@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 04 Jul 2012 13:12:18 -0700 To: Andreas Petersson From: SM In-Reply-To: <20120704165602.61d722a9@hetzer> References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 20:14:11 -0000 Hi Andreas, At 07:56 04-07-2012, Andreas Petersson wrote: >The reason to standardize this is so that more proxies will do this >instead of X-Forwarded-* (e.g. For). I do not expect people to start >using this, who currently do not use X-Forwarded-For. XFF is so widely >spread so those who wants to disclose this information does it already. If the above was the rule, there are many things which the IETF would not be doing anymore. For example, there was a time when security considerations were not given any thought. Nowadays, you have to have some text about security considerations even if a protocol has been in wide use. >One use case which I believe is pretty big is to geo-locate the users >to localize the content in various ways. I thought that geolocation of users was about DNS tricks. :-) It has been argued in the past that it is not optimal to do the geolocation at the HTTP level. >I don't think that is an elegant solution, but it is part of the >reality. If this use is intrusive on privacy is probably a matter of >taste. I beg to differ about privacy being a matter of taste. >"... and so decreases ..." >I don't see how it decreases if people are following an >RFC-specification of the format, or just the de facto format that >everyone already uses. I would look at this in terms of people instead of technical specifications. The de-facto argument won't fly well in policy circles. >What regulations and cross-border controls are you talking about here? >Can you elaborate? The privacy regulations in various countries differ significantly (as an unrelated example see http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf ). >I would think that most parties to follow the laws in their respective >country, which may be part of the problem, of course, but also quite >expected. Yes. >Well, the document is current under AD review. It would have been >better if you raised your comments during the WGLC. If you find new >issues, I guess the time to raise them is during the IETF LC, but I'm >unsure about the process here. If you are unsure about the process, you can ask the document shepherd. BTW, as a quick comment, I like the text which Stephen Farrell provided at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06557.html At 05:01 04-07-2012, Andreas Petersson wrote: >This header field is not only for debugging, so that should >probably be expanded. Something else that should be added? Yes, the text needs some work. >I do think that the text should say something about the current use of >similar header fields though, otherwise it may look like everything is >fine unless you don't use this, which is not true. >Users should also be aware of all other different headers and cookies >that their browsers sends out, so they can be identified by those too, >but mentioning that here seems out of scope to me. What I was trying to express was: tell the user what to think about so that he or she can decide. If you say "everyone does this, so why don't you do it", you might as well drop the privacy section altogether. Regards, -sm From stephen.farrell@cs.tcd.ie Wed Jul 4 13:45:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF80D21F8656 for ; Wed, 4 Jul 2012 13:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCce34X9w9H3 for ; Wed, 4 Jul 2012 13:45:25 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD9521F8638 for ; Wed, 4 Jul 2012 13:45:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E3C8315754B; Wed, 4 Jul 2012 21:45:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341434732; bh=SUr0Bnst8Vc9cV 3M1LRSYYVYav3lP9d1EDMTOD9o+1I=; b=chTMWEAQoQNXVVgwlZpNCBpC/bEamf yVWvAJc1YkwRD3VYODV6jfuAQfDZnJhqri+gpc5OZzue6kcUg8Wrpgqd+DTas4s/ fOVHphQWsdQqHc10nBmcnXXribYnVxtACQuk9wPwlHa0GIksmSkuzc22b6r8k4su PkEE/9N0ZwfGZiQJd654kIDKNpv8dcH/kfHUuqAWKELq1AEpuKBlqBwZA7IBSzGD zY0S03DyhVcj3IZE+DGbEaU4YRqzeFMjnICSp0he3anWTkX4M4HLaAA2aEq29sXg dVZvVgb7R0YPX5fio6K/fW080/RVgoyolwRRG0HkPYfSPjwny5Q4B56Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id HAJA2pLPG0kg; Wed, 4 Jul 2012 21:45:32 +0100 (IST) Received: from [10.87.48.11] (unknown [86.41.15.232]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6C7C117147F; Wed, 4 Jul 2012 21:45:32 +0100 (IST) Message-ID: <4FF4AB6B.6090803@cs.tcd.ie> Date: Wed, 04 Jul 2012 21:45:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andreas Petersson References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> In-Reply-To: <20120704165602.61d722a9@hetzer> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 20:45:33 -0000 Hiya, Basically agreeing with SM's latest below... On 07/04/2012 03:56 PM, Andreas Petersson wrote: > On Wed, 04 Jul 2012 14:37:09 +0100 > Stephen Farrell wrote: > >> >> Hi Andreas, >> >> On 07/04/2012 01:01 PM, Andreas Petersson wrote: >>> On Sun, 01 Jul 2012 14:39:18 +0100 >>> Stephen Farrell wrote: >>>> One argument given is that a direct connection would expose the >>>> client IP anyway, but that's not comparing this proposal against >>>> today's reality, which ought to be the point. >>> >>> If you, as a user, bother to find out whether the proxy is anonymizing >>> or not, you can not know that now either. >> >> I can't really parse the above sorry. > > Sorry, it should read: > "If you, as a user, don't bother to find out whether the proxy is > anonymizing or not, you can not know that* now either." > > *) That the proxy is not giving away your IP-address. Ok, now I get what you said, but I don't get its relevance;-) Are you assuming that most users would have any clue how to figure out that a proxy is doing this spec? They won't. So talking here about (or assuming) that a user could do this is missing the point I think. >>> A proxy that is appending "Forwarded" do that because it do not want to >>> anonymize user. If that is the desire, the proxy may already append >>> X-Forwarded-For, which is really widespread. >> >> I think that needs to be clear in 8.3. >> >>> Also, if the intention of the proxy isn't to anonymize, the owner may >>> also give out logfiles to untrusted parties as well. >>> >>> Do you believe that "todays reality" is that you can go and seek up a >>> proxy, that you know nothing about, browse through it, and trust that >>> it will anonymize your requests? Even if the proxy owner doesn't call >>> the proxy "anonymizing"? >> >> No I don't. But direct connections are not today's reality >> which is what's implied by the current 8.3. > > Well, they do exist of course. > But also non-direct connections are discussed in the current version > of 8.3. The problem I had was that the current text compared the situation with these headers used vs. direct connections to argue that there's no privacy impact. I think that's just not a good argument to make. >>> As said, X-Forwarded-For does already exists and is implemented in >>> all large proxy-servers, so this is nothing new, it is only a >>> standardization of that. >>> >>> I don't think this document is the place for guidelines, neither for >>> how to set up an anonymizing proxy, nor how to browse the web in an >>> anonymous way. >>> >>> >>>> I also think the text in that section seems to be trying to sell >>>> this as having no privacy impact, and I just don't think that is >>>> the case. >>> >>> I do not see what that impact would be really. Please explain when this >>> specification have an impact, compared to todays reality. >> >> Presumably the reason to standardise this is so that more proxies >> will do it this way. That reduces privacy to some extent unless >> nobody adopts this. > > The reason to standardize this is so that more proxies will do this > instead of X-Forwarded-* (e.g. For). I do not expect people to start > using this, who currently do not use X-Forwarded-For. XFF is so widely > spread so those who wants to disclose this information does it already. This is an aside (maybe): the text above makes it sound like you think this is entirely the proxy's choice and that that's fine. I don't agree with that. The information concerned is about the user and is identifying in various ways. Just because XFF does this without asking doesn't make that right. > If your concern is that more people will start using this just because > it exists, well, yes, that may have a privacy impact. Right. > If this is you concern, I start to understand your point. I don't share > your concern but we can surely mention that this header field should not > be used for people that do not see an actual need for it. The "people" you refer to above are who? I think you need to consider the people whose information is being shared as well. I think you need to make it clear to the reader that there are privacy consequences. Its clear that many readers (and perhaps writers:-) don't consider that aspect important, but they ought to really IMO. >>> Do you suggest that we should advise people not use this at all? It may >>> be a nice thought, but I think it is far to idealistic. Unfortunately, >>> such a proxy-service would be abused for a lot of things. So most >>> people do not want to run such a service, and lots of network owners >>> wouldn't like to host it, etc. >> >> I didn't suggest that. I'm asking for truth in advertising. > > Ok, just asking. > >> >>>> I've only looked at 8.3, but I believe the privacy considerations >>>> section is wrong when it says that standardising this has no new >>>> privacy impact. >>> >>> I do not entirely agree with you here. But I notice that there are more >>> support for this opinion, so lets try to come up with something. >>> >>> This is the text SM sent: >>> ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05774.html >>> SM, correct me if I'm wrong). >>> >>> In recent years, there has been growing concerns about privacy. >>> There is a tradeoff between ensuring privacy for users versus >>> disclosing information which is useful for debugging. The Forwarded >>> HTTP header field, by design, exposes information which affects the >>> privacy of users. This header field should not be used if the proxy >>> is being operated as a privacy service. >>> >>> This header field is not only for debugging, so that should >>> probably be expanded. Something else that should be added? >> >> Depends on what else its used for I guess. If there are other >> (non-obvious uses) with privacy implications then those should >> I guess be mentioned. Not sure myself. (I'm assuming this >> information is mostly fed into the marketing machine.) > > One use case which I believe is pretty big is to geo-locate the users > to localize the content in various ways. > I don't think that is an elegant solution, but it is part of the > reality. If this use is intrusive on privacy is probably a matter of > taste. Ah. Then that does warrant a mention. And I think you also need to say why you're not following the RFC 6280 way of handling location information as well maybe (I'd need to read both docs). In any case, location needs to be mentioned in this I'd say and you ought look at RFC 6280 and see if parts of it apply here. >>> I do think that the text should say something about the current use of >>> similar header fields though, otherwise it may look like everything is >>> fine unless you don't use this, which is not true. >> >> Right. >> >>> Users should also be aware of all other different headers and cookies >>> that their browsers sends out, so they can be identified by those too, >>> but mentioning that here seems out of scope to me. >> >> I agree that such things are out of scope. >> >> Ok, Alexey asked for text, how about something like this >> for 8.3: > > It's a start, but I have some concerns (see below). > >> "The existing X-Forwarded-* headers expose information that >> some users (or regulators) consider privacy sensitive. This >> header field standardises that practice and so decreases user >> privacy. > > "... and so decreases ..." > I don't see how it decreases if people are following an > RFC-specification of the format, or just the de facto format that > everyone already uses. There will be more of them doing it, hence the decrease. >> However, with the current widespread use of >> X-Forwarded-*, that impact is considered acceptable as it >> improves interoperability, which might also allow for >> better privacy controls in future. Implementers and operators >> deploying this header (or X-Forwarded-* equivalents) need to >> consider whether and how doing so impacts on user privacy and >> for example whether relevant regulations such as cross-border >> controls might come into play. See [ref] for additional >> guidance." > > What regulations and cross-border controls are you talking about here? > Can you elaborate? Its not an area in which I'm expert (maybe nobody is;-) but for example a quick search shows a Canadian web page [1] that says in part: "Organizations need to make it plain to individuals that their information may be processed in a foreign country..." Doing this, and making it "plain" to the user that the information will cross a border (or even knowing that) might be considered hard I guess. I've no idea if that applies to what you're doing here or not, but presumably someone writing code or deploying this (or the existing X-Forwarded-*) should have checked that kind of thing out. [1] http://www.priv.gc.ca/information/guide/2009/gl_dab_090127_e.asp >> I don't have a good reference to hand, but referring to >> something that tells implementers and/or operators how to >> play nice would be useful I think, since it seems that >> many don't know (or don't care, and claim not to know;-) > > Anyone else who can point to some relevant document for this matter? > I would think that most parties to follow the laws in their respective > country, which may be part of the problem, of course, but also quite > expected. > >> BTW - I still haven't had a chance to read the whole thing, >> though, so might have more comments when I do. > > Well, the document is current under AD review. It would have been > better if you raised your comments during the WGLC. If you find new > issues, I guess the time to raise them is during the IETF LC, but I'm > unsure about the process here. To be honest, I'm not sure about WGLCs in appsawg in general. Maybe that's a process step that needs more thought for "area" WGs since its a bit different in terms of people's focus. Or maybe not. Anyway, sorry for not having gone through it all properly. I read an earlier version and privacy was my main comment then fwiw. S > > > Best regards, > Andreas > > From jasnell@gmail.com Wed Jul 4 13:45:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8508F21F8638 for ; Wed, 4 Jul 2012 13:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.979 X-Spam-Level: X-Spam-Status: No, score=-6.979 tagged_above=-999 required=5 tests=[AWL=-3.515, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDBq4xweXZ6J for ; Wed, 4 Jul 2012 13:45:56 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 602DE21F85C7 for ; Wed, 4 Jul 2012 13:45:56 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so4642918wib.13 for ; Wed, 04 Jul 2012 13:46:07 -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:content-transfer-encoding; bh=VyI4Krte7AUrU2Sn/sDLyNuaREOhEcD5qybs0CDtX4o=; b=GbVbCX3kPoXZTxLOLUhTYl+OUBeXe3212pa9Bxo+Lrg/HqZ24CwX46Wiq5xperNVPl OZlBXjjy7MaHY4tSClVjyVkT+2NVnGUFIKai75kkS9VQIkLML9F4kivdCuOOtYkf0WYs wnFqQ3ac1mBbPttI7tPkc2gdaeCleZxJlbUOPlfNG5EG8HeMjekjkEN7suAU1iePXZD7 p1/1WGCtACyCjEG5e/V2HfcCzbesyUemkOxvM+S6lfSzagcW1RMsGbieD5E6vMAIAv/z 8uQS2zLn4r1RL3Yrjn1JF1vfmIUw2dUQHawR7BPDLtTh3+RPkx6jXNONc7mbLAUc0haS w2Cw== Received: by 10.180.86.106 with SMTP id o10mr16946448wiz.22.1341434766925; Wed, 04 Jul 2012 13:46:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.67 with HTTP; Wed, 4 Jul 2012 13:45:46 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> From: James M Snell Date: Wed, 4 Jul 2012 13:45:46 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 20:45:58 -0000 The second issue here is the part about webfinger that bothers me the most... there really is no clear reason why XRD should be required here. The additional indirection serves no significant valuable purpose that I can determine. The Simple Web Discovery draft is better overall I think but much more can be done to simplify things and provide a much more succinct and useful protocol. Simply because XRD is in use today by a few early adopters, there's absolutely no reason to rubber stamp it here. I appreciate those early adopters for giving a great demonstration of how it shouldn't be done. In my previous feedback, I've demonstrated that the same benefits can be achieved without the use of XRD at all... in fact, we can achieve exactly the same result and eliminate a good third of everything that's discussed in the current WF draft... Using WF's own use cases from Section 4... Locating a user's blog... Assuming, for privacy purposes, we hash the acct id; and assuming we define "blog" as a Link Relation... GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/blog Host: example.org HTTP/1.1 302 Found Location: http://blogs.example.com/bob/ Link: ; rel=3D"avatar", ; rel=3D"http://webfinger.net/rel/profile= -page" Locating a user's contact info... GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/vcard Host: example.org HTTP/1.1 200 OK Context-Type: text/vcard {vcard data} Simplifying the Login Process GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/openid Host: example.org HTTP/1.1 302 Found Location: https://openid.example.com/carol Retrieving device info GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/tipsi Host: example.org HTTP/1.1 302 Found Location: http://192.168.1.5/npap/ So in each case we achieve the same fundamental goal without the additional indirection or use of XRD. A specific implementation could choose to use XRD if they'd like, but it shouldn't be a requirement. For instance, suppose... GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/xrd Host: example.org HTTP/1.1 200 OK Content-Type: application/json {...} Doing this would be an entirely optional implementation choice, however. If I did, for instance... GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd Specifying no additional path, the server could very well just forward me on to an HTML representation of my profile that contains microdata/RDFa properties I could harvest. The server should be allowed to serve up whatever information it wants, in whatever format it wants; client applications will determine for themselves whether that data is usable or not. Keeps the protocol, and the spec, as drop dead simple as possible. - James On Tue, Jul 3, 2012 at 6:59 PM, Phillip Hallam-Baker wro= te: > I recall something rather different. I recall a claim that the IPR was > open when in fact the registry was to be operated on a commercial > basis. > > This technology keeps appearing in specs without any apparent > requirement to motivate it. In OpenID the only reason for =3DPhill being > required was that user@domain was not supported as we were told that > people wanted to use the URL of their blog. > > > On Tue, Jul 3, 2012 at 7:53 PM, John Bradley wrote: >> I recall that there were strait answers and a meeting with the OASIS law= yer on the topic back in the day. >> >> Not everyone trusted the answers apparently, but you can't make everyon= e happy. >> >> The IPR you are concerned about related to XRI resolution and not the XR= DS or XRD XML document formats. >> >> There should be no more IPR concern than there is with other OASIS specs= like SAML. >> >> That said I am not advocating the use of XRD, SWD used a simple link da= ta type JSON format. >> >> The XRD and JRD format are heavily influenced by the link data format if= you look at it closely. >> >> Regards >> John B. >> >> >> >> On 2012-07-03, at 6:29 PM, Phillip Hallam-Baker wrote: >> >>> What are the PR encumbrances of XRD? >>> >>> The XRI folk never gave me a straight answer, it is all tainted until >>> there is an explicit statement AFIK. >>> >>> On Tue, Jul 3, 2012 at 5:27 PM, James M Snell wrote= : >>>> Great to see this conversation coming up... A couple of months ago I >>>> posted a few thoughts on WebFinger on my personal blog [1]... I've >>>> copied the relevant bits here for discussion. The short summary: >>>> WebFinger is ok but can be made so much simpler. >>>> >>>> [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.htm= l >>>> >>>> ... >>>> Ok... so [WebFinger] seems simple enough, but can we make it even >>>> simpler? I think we definitely can. Let's start by eliminating the >>>> requirement to use XRD. Look at the first response... what is the XRD >>>> document giving us? A Link. One Link. Ok, not really a Link, but a URI >>>> Template. Wait, so that's two things we I actually need to process >>>> before I can actually look up information about the user "bob"... >>>> let's eliminate both of those things and simply provide a means of >>>> looking up information about the user directly.. for instance: >>>> >>>> GET /.well-known/finger/acct%3Abob%40example.org HTTP/1.1 >>>> Host: example.org >>>> >>>> If we still need to know things about the domain, then we can finger >>>> that domain... >>>> >>>> GET /.well-known/finger/example.org HTTP/1.1 >>>> Host: example.org >>>> >>>> But looking up basic information about the user should not be >>>> predicated on first looking up basic information about the domain. >>>> Those can, and should, be two completely separate tasks. >>>> >>>> There is a problem here, however. A big problem actually. Many >>>> enterprises frown on putting things that look like email addresses >>>> into URLs because of fairly significant privacy concerns. So let's >>>> change that, instead of passing the acct: ID directly, we'll pass a >>>> hash of the acct id.. much more secure and private that way... >>>> >>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 >>>> Host: example.org >>>> >>>> Ah, that's better... and in the process I managed to eliminate about a >>>> third of what the WebFinger draft currently requires. >>>> >>>> It boils down to nothing more than this: >>>> If I want to know something about user "bob@example.org", I sent a GET >>>> request to http://example.org/.well-known/finger/{md5("bob@example.org= ")} >>>> and see what I get back. No absolute need to parse any XML. No need to >>>> process any URI Templates. No need to define special query string >>>> parameters. Keep it very simple and we're essentially done. >>>> >>>> Ok, so what about the response from the server? What would that look >>>> like? Currently, WebFinger requires that the response has to either be >>>> XRD or this other thing called JRD. While I don't have any problem >>>> with using either of those particular formats, I do not believe that >>>> the WebFinger spec needs to declare that any format MUST be supported. >>>> It should be up to the server to provide whatever format it wishes. >>>> The client can determine if it's able to get what it's needs from the >>>> provided format or not. If the response is HTML and includes Link or >>>> Anchor elements that use appropriately labelled rel attribute values, >>>> then the client should be able to get the information it needs; if the >>>> response is JSON and includes appropriately labeled information in a >>>> way the client can understand, then great. That's what we have things >>>> like the Accept request header for... >>>> >>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 >>>> Host: example.org >>>> Accept: application/xrd+xml, text/html, application/atom+xml >>>> >>>> The client can tell the server what format it would like and the >>>> server can respond appropriately. These mechanism are widely used and >>>> the abstract notion of a Link is fairly universal now and easily >>>> represented in multiple formats. >>>> >>>> The response to the above request could very well be as simple as: >>>> >>>> HTTP/1.1 204 No Content >>>> Link: ; rel=3D"blog", >>>> ; rel=3D"profile", >>>> ; rel=3D"avatar" >>>> >>>> Sure, this hypothetical type of response may be impractical if a >>>> particular user has a significantly large number of links associated >>>> with it, but (a) realistically most users won't have that many at any >>>> single service and (b) this is just an example, I did say that I have >>>> no problem with XRD/JRD being used... it just shouldn't be required. >>>> >>>> Another possibility. Just to stretch the imagination a bit more. >>>> Suppose I want to know the location of the user's blog and I send this >>>> for a request: >>>> >>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1.= 1 >>>> Host: example.org >>>> >>>> Note the addition of the "/blog" at the end of the request URI. Let's >>>> just say that the last little bit there is a rel value. If the user >>>> has only a single rel=3D"blog" Link, then the server can tell me where >>>> it is with a simple redirect: >>>> >>>> HTTP/1.1 302 Found >>>> Location: http://blogs.example.org/bob >>>> >>>> If there happen to be multiple "blog" links associated with that >>>> particular user, then the server can tell me about all of them... >>>> >>>> HTTP/1.1 300 Multiple Choices >>>> Location: http://blogs.example.org/bobs_default_blog >>>> Link: ; rel=3D"blog", >>>> ; rel=3D"blog" >>>> >>>> What if I want to know about some other kind of Link associated with >>>> the user... well, I simply replace "/blog" with the other rel >>>> attribute value... >>>> >>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard HTTP= /1.1 >>>> Host: example.org >>>> >>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar HTT= P/1.1 >>>> Host: example.org >>>> >>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/ >>>> http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fprovider HTTP/1.1 >>>> Host: example.org >>>> >>>> Whatever specific link rel I want to know about, I just append that to >>>> the end. If I need to know about more than one, separate them by a >>>> comma: >>>> >>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard,avat= ar >>>> HTTP/1.1 >>>> Host: example.org >>>> >>>> Which could return something along the lines of... >>>> >>>> HTTP/1.1 300 Multiple Choices >>>> Link: ; rel=3D"vcard", >>>> ; rel=3D"avatar" >>>> >>>> Or it could return an XRD or JRD... either way, it works just fine. >>>> The point is that it's MUCH simpler than what WebFinger defines and >>>> requires fewer moving parts (no required XML parsing, no required URI >>>> Template processing, no required querystring parameters, etc). >>>> >>>> With regards to security considerations, the original Finger protocol >>>> was quite problematic because of the potential for inappropriate >>>> disclosure of sensitive information about an account. The same basic >>>> concern would be applicable to WebFinger depending on what information >>>> was being made available for discovery. I've already dealt with one >>>> particular concern -- the use of an email-like identifier within the >>>> discovery URI... requiring a hash is a simple fix there. But what else >>>> can be done? >>>> >>>> Well, obviously, we're talking about a HTTP request here. When a >>>> requester sends an unauthenticated HTTP request to discover >>>> information about a user, the server can choose to respond with only >>>> the most basic generic and public information about the user and >>>> possibly some links to that user's public facing services (their blog, >>>> their avatar, etc). Mechanisms such as OAuth 2 can be employed, >>>> however, to support much more interesting scenarios. For instance, a >>>> trusted third party could acquire an OAuth 2 access token to request >>>> additional, more detailed information about a user... >>>> >>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1.= 1 >>>> Host: example.org >>>> Authentication: Bearer {my_access_token} >>>> >>>> Such requests can be easily tracked, rate-limited, etc, making the >>>> protocol generally much more reliable and secure than the original >>>> finger protocol. Unfortunately, the current WebFinger specification >>>> does not adequately address this particular concern. >>>> .... >>>> >>>> - James >>>> >>>> On Tue, Jul 3, 2012 at 12:24 AM, Mike Jones wrote: >>>>> You've essentially described Simple Web Discovery! It avoids the com= plications introduced by host-meta exactly by using its own .well-known val= ue. The basic example is: >>>>> >>>>> GET /.well-known/simple-web-discovery?principal=3Dmailto:joe@exampl= e.com&service=3Durn:example.org:service:calendar HTTP/1.1 >>>>> Host: example.com >>>>> >>>>> HTTP/1.1 200 OK >>>>> Content-Type: application/json >>>>> >>>>> { >>>>> "locations": ["http://calendars.example.net/calendars/joseph"] >>>>> } >>>>> >>>>> See http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 fo= r more details. By design, there aren't many... >>>>> >>>>> -- Mike >>>>> >>>>> -----Original Message----- >>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf= .org] On Behalf Of Mark Nottingham >>>>> Sent: Monday, July 02, 2012 10:47 PM >>>>> To: IETF Apps Discuss >>>>> Subject: [apps-discuss] Looking at Webfinger >>>>> >>>>> I've pretty much ignored the whole webfinger / acct: / SWD discussion= (too much!). However, since it's apparent it may soon become Real, I had a= look. >>>>> >>>>> In a nutshell, my initial reaction is "It's Not Nearly As Bad As I Th= ought It Would Be." :) >>>>> >>>>> With that in mind, a few questions / comments (I'll resist going into= editorial matters, for the time being): >>>>> >>>>> * First and foremost, why use host-meta? What value does adding this = extra step to the dance bring, beyond "We've defined it, therefore we must = use it?" >>>>> >>>>> As I think I've said many times before, the whole point of a .well-kn= own URI is to group like uses together, to avoid having a "dictionary" reso= urce that gets bloated with many application's unrelated data, thereby over= burdening clients with too much information (especially when they're constr= ained, e.g., mobile). >>>>> >>>>> As such, host-meta is a spectacularly bad example of a well-known URI= . Defining a end-all-be-all well-known-URI kind of removes the point of hav= ing a registry, after all... >>>>> >>>>> Instead, why not just define a NEW well-known URI for user data? That= has a more constrained scope, and saves one round trip (or more). E.g., >>>>> >>>>> GET /.well-known/webfinger?user=3Dbob%40example.com HTTP/1.0 >>>>> Host: example.com >>>>> >>>>> I.e., let webfinger define the URI template to use. Yes, some impleme= ntations might want to come up with crazy URIs, but is that really a proble= m we want to solve? >>>>> >>>>> Astute observers will notice that this approach removes the need for = an ACCT URI scheme (at least here). >>>>> >>>>> >>>>> * What's the fascination with XRD and JRD? These specifications seem = to be creeping into IETF architecture; first it was in a pure security cont= ext, but now folks are talking about using them in a much more generic way,= as a cornerstone of what we do. As such, I think they deserve a MUCH close= r look, especially since we're defining things with "Web" in their name whe= n the W3C has already defined solutions in this space. >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> -- >>>>> Mark Nottingham http://www.mnot.net/ >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> >>> -- >>> Website: http://hallambaker.com/ >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > > > -- > Website: http://hallambaker.com/ From wmills@yahoo-inc.com Wed Jul 4 14:04:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A434D21F8692 for ; Wed, 4 Jul 2012 14:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.48 X-Spam-Level: X-Spam-Status: No, score=-17.48 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, NORMAL_HTTP_TO_IP=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2pCjNuy47gM for ; Wed, 4 Jul 2012 14:04:31 -0700 (PDT) Received: from nm11-vm4.bullet.mail.ne1.yahoo.com (nm11-vm4.bullet.mail.ne1.yahoo.com [98.138.91.171]) by ietfa.amsl.com (Postfix) with SMTP id D684721F862A for ; Wed, 4 Jul 2012 14:04:30 -0700 (PDT) Received: from [98.138.90.52] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jul 2012 21:04:42 -0000 Received: from [98.138.89.199] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jul 2012 21:04:42 -0000 Received: from [127.0.0.1] by omp1057.mail.ne1.yahoo.com with NNFMP; 04 Jul 2012 21:04:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 230496.67595.bm@omp1057.mail.ne1.yahoo.com Received: (qmail 11835 invoked by uid 60001); 4 Jul 2012 21:04:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1341435881; bh=UI2HxAnHR8davZmjtd/QX8nt2i1zbijV9qpc3nXAX+A=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=k1/QtmWxz81+2RXiJ4aLB/sTSMoyRIIlYFCj0GqERzmr1epbTxrVGMIpB1B4DgtGfJWZ/NuuPRGTwN9C1zBlOW1tuESbiRUPDqAot/b6qMCzIi8hO/g4VZibh8jID1LBTK7FR2EWeRLawROOTAz0Fx/TGg54oqjUK59lk4AloMg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=G7mdIqswopqWYIo0aeZxxdM/4Bv421TTw2edhrEKCSlTpoj1O4MibcTrpxl6w5JTT0c8ghScAs3REdM3WhDbcF0Bw9EEPPXiOz7YGyr5TuVk4V859fqR4epeOHGvAiP2jPbAA/gIEE4r2u2ARQD9+aMx/JyYESIOxa195/+oW3o=; X-YMail-OSG: .tbbg3EVM1nJNtPUCNQpj7Lqxkwul8E2_h6Zuh6RZC_WDNE 1FuH5mNAKoEeuGUBlG83cWS8KidPSIMXZn_uaTkp7ieJB28aabvBmT2GhE2Z MLoIrmdPa0oZBo.t9ria2iQIEOAiFDK_0tYAnPothvQrsRy_PVi.0IwhDD_A Altz4wWHwfqrb3EiDsFY4CxFvqAR0uoBobb3E83FR_5EC9Qv1Je.hBu.Nk0z 7Z6jrtXcmuW1NBAIpXqji5By9S0NjIhZYsy8ftvdfgB6MamU0H9AIcL403xl ypVdtz0Y8cWrVEMxVBKtqxRIj2gxUmJKO6vnhh9kICfMzlMNeEuGe8jeM1fd fD_dwK0tohyYePFFdNlBzIWCthr556Gglp96feGzf8h6oMx0eZHL2zzdwD7e ZpJoe5tPJs4lzcQAEt6F9g6MzloImZqdyyAqmrlbtVvzMTOvjytV3YG2y.Xx xOhHCpBjapDq.ywJMbbUyvQOZxOe1aRv7T8Vl.WZea0Id5v7gsWadtF2Uaf2 AZ5dIqcJ97x8tT3imMu_gIJvp_K2nApJhVF21urV1JS_93hgisWlIVcBbqJL Cs.cFu1CUG.LZWWsj4COGShOxuyf8t_tBaS5e61c5dJEFz4O9k1MwZWfge78 DK57qymNfhIAUUC0vw2A1HOrAIy20yCZkaf0SO2AXBFKEyqqSYV_0yn3IHUQ TkIm0.i2yESdEX79xIdlTK189KKTu.rqcAZqI4y7S1RsneeRT.PSzyfGmMPF ftZcvAOfkMaYuML4cgb3ZbyTG9hSFWPQ3VdqbZVUCXBQp29YlZdnYtUl9pLZ z4UuHW8EqHvjb34KSlg8vcShSV2mLysysTsULSc6Aj9JzRMtP1x2NDAkFjvM EX5pOHtFBAN2dnvQ0ELPqNOuSH14K3z6I5S1y3UXRpSvV0d.6F0SxyyrmU2q U16Afh1CpHrESZbiutfil5MmIcMcX7ZkykqYlv4BPjc1vWuAbPKNDLN_mLcr OT1cAZZBpuh.o9IoSP97wZUIgRbJjnYi78x.4y_Vj1lY0i.MYsizd_iJw7CM igBvuRowOf6yDxsejGtAknIrd.aLBi6tYnxN5uvlkOJXz.yuLBRw87PdH_NI _mDFITNKtzlwTVVrWRmy768tEyFqqcs0rPfFr Received: from [209.131.62.115] by web31802.mail.mud.yahoo.com via HTTP; Wed, 04 Jul 2012 14:04:41 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> Message-ID: <1341435881.26890.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Wed, 4 Jul 2012 14:04:41 -0700 (PDT) From: William Mills To: James M Snell , Phillip Hallam-Baker In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-1916415527-1341435881=:26890" Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 21:04:33 -0000 ---1036955950-1916415527-1341435881=:26890 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I like the idea of registering a well-known for WF.=A0=A0 I'm not so=A0 muc= h in favor of changing the current query format.=A0 There are tonss of ways= to get the data in there, the one in the draft now has extant implementati= ons.=A0 The current syntax is easily extensible and sufficient, and not in = my opinion overly complex.=A0 I tend not to be a fan of stuffing things int= o the URL when there are multiple data items to deal with, query or post pa= rameters make more sense to me.=0A=0A-bill=0A=0A=0A=0A>____________________= ____________=0A> From: James M Snell =0A>To: Phillip Hal= lam-Baker =0A>Cc: Mark Nottingham ; IETF = Apps Discuss =0A>Sent: Wednesday, July 4, 2012 1:45= PM=0A>Subject: Re: [apps-discuss] Looking at Webfinger=0A> =0A>The second = issue here is the part about webfinger that bothers me the=0A>most... there= really is no clear reason why XRD should be required=0A>here. The addition= al indirection serves no significant valuable=0A>purpose that I can determi= ne. The Simple Web Discovery draft is better=0A>overall I think but much mo= re can be done to simplify things and=0A>provide a much more succinct and u= seful protocol. Simply because XRD=0A>is in use today by a few early adopte= rs, there's absolutely no reason=0A>to rubber stamp it here. I appreciate t= hose early adopters for giving=0A>a great demonstration of how it shouldn't= be done.=0A>=0A>In my previous feedback, I've demonstrated that the same b= enefits can=0A>be achieved without the use of XRD at all... in fact, we can= achieve=0A>exactly the same result and eliminate a good third of everythin= g=0A>that's discussed in the current WF draft... Using WF's own use cases= =0A>from Section 4...=0A>=0A>Locating a user's blog...=0A>=0A>Assuming, for= privacy purposes, we hash the acct id; and assuming we=0A>define "blog" as= a Link Relation...=0A>=0A>=A0 GET /.well-known/finger/fc5e68b29fa1d255bd03= 8a167ca0b9bd/blog=0A>=A0 Host: example.org=0A>=0A>=A0 HTTP/1.1 302 Found=0A= >=A0 Location: http://blogs.example.com/bob/=0A>=A0 Link: ; rel=3D"avatar",=0A>=A0 =A0 ; rel=3D"http://webfinger.net/rel/profile-page"=0A>=0A>Locating a user'= s contact info...=0A>=0A>=A0 GET /.well-known/finger/fc5e68b29fa1d255bd038a= 167ca0b9bd/vcard=0A>=A0 Host: example.org=0A>=0A>=A0 HTTP/1.1 200 OK=0A>=A0= Context-Type: text/vcard=0A>=0A>=A0 {vcard data}=0A>=0A>Simplifying the Lo= gin Process=0A>=0A>=A0 GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0= b9bd/openid=0A>=A0 Host: example.org=0A>=0A>=A0 HTTP/1.1 302 Found=0A>=A0 L= ocation: https://openid.example.com/carol=0A>=0A>Retrieving device info=0A>= =0A>=A0 GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/tipsi=0A>= =A0 Host: example.org=0A>=0A>=A0 HTTP/1.1 302 Found=0A>=A0 Location: http:/= /192.168.1.5/npap/=0A>=0A>=0A>So in each case we achieve the same fundament= al goal without the=0A>additional indirection or use of XRD. A specific imp= lementation could=0A>choose to use XRD if they'd like, but it shouldn't be = a requirement.=0A>For instance, suppose...=0A>=0A>=A0 GET /.well-known/fing= er/fc5e68b29fa1d255bd038a167ca0b9bd/xrd=0A>=A0 Host: example.org=0A>=0A>=A0= HTTP/1.1 200 OK=0A>=A0 Content-Type: application/json=0A>=0A>=A0 {...}=0A>= =0A>Doing this would be an entirely optional implementation choice,=0A>howe= ver. If I did, for instance...=0A>=0A>=A0 GET /.well-known/finger/fc5e68b29= fa1d255bd038a167ca0b9bd=0A>=0A>Specifying no additional path, the server co= uld very well just forward=0A>me on to an HTML representation of my profile= that contains=0A>microdata/RDFa properties I could harvest. The server sho= uld be=0A>allowed to serve up whatever information it wants, in whatever fo= rmat=0A>it wants; client applications will determine for themselves whether= =0A>that data is usable or not. Keeps the protocol, and the spec, as drop= =0A>dead simple as possible.=0A>=0A>- James=0A>=0A>On Tue, Jul 3, 2012 at 6= :59 PM, Phillip Hallam-Baker wrote:=0A>> I recall someth= ing rather different. I recall a claim that the IPR was=0A>> open when in f= act the registry was to be operated on a commercial=0A>> basis.=0A>>=0A>> T= his technology keeps appearing in specs without any apparent=0A>> requireme= nt to motivate it. In OpenID the only reason for =3DPhill being=0A>> requir= ed was that user@domain was not supported as we were told that=0A>> people = wanted to use the URL of their blog.=0A>>=0A>>=0A>> On Tue, Jul 3, 2012 at = 7:53 PM, John Bradley wrote:=0A>>> I recall that there = were strait answers and a meeting with the OASIS lawyer on the topic back i= n the day.=0A>>>=0A>>> Not everyone trusted the answers apparently,=A0 but = you can't make everyone happy.=0A>>>=0A>>> The IPR you are concerned about = related to XRI resolution and not the XRDS or XRD XML document formats.=0A>= >>=0A>>> There should be no more IPR concern than there is with other OASIS= specs like SAML.=0A>>>=0A>>> That said I am not advocating the use of XRD,= =A0 SWD used a simple link data type JSON format.=0A>>>=0A>>> The XRD and J= RD format are heavily influenced by the link data format if you look at it = closely.=0A>>>=0A>>> Regards=0A>>> John B.=0A>>>=0A>>>=0A>>>=0A>>> On 2012-= 07-03, at 6:29 PM, Phillip Hallam-Baker wrote:=0A>>>=0A>>>> What are the PR= encumbrances of XRD?=0A>>>>=0A>>>> The XRI folk never gave me a straight a= nswer, it is all tainted until=0A>>>> there is an explicit statement AFIK.= =0A>>>>=0A>>>> On Tue, Jul 3, 2012 at 5:27 PM, James M Snell wrote:=0A>>>>> Great to see this conversation coming up... A couple o= f months ago I=0A>>>>> posted a few thoughts on WebFinger on my personal bl= og [1]... I've=0A>>>>> copied the relevant bits here for discussion. The sh= ort summary:=0A>>>>> WebFinger is ok but can be made so much simpler.=0A>>>= >>=0A>>>>> [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfing= er.html=0A>>>>>=0A>>>>> ...=0A>>>>> Ok... so [WebFinger] seems simple enoug= h, but can we make it even=0A>>>>> simpler? I think we definitely can. Let'= s start by eliminating the=0A>>>>> requirement to use XRD. Look at the firs= t response... what is the XRD=0A>>>>> document giving us? A Link. One Link.= Ok, not really a Link, but a URI=0A>>>>> Template. Wait, so that's two thi= ngs we I actually need to process=0A>>>>> before I can actually look up inf= ormation about the user "bob"...=0A>>>>> let's eliminate both of those thin= gs and simply provide a means of=0A>>>>> looking up information about the u= ser directly.. for instance:=0A>>>>>=0A>>>>>=A0 GET /.well-known/finger/acc= t%3Abob%40example.org HTTP/1.1=0A>>>>>=A0 Host: example.org=0A>>>>>=0A>>>>>= If we still need to know things about the domain, then we can finger=0A>>>= >> that domain...=0A>>>>>=0A>>>>>=A0 GET /.well-known/finger/example.org HT= TP/1.1=0A>>>>>=A0 Host: example.org=0A>>>>>=0A>>>>> But looking up basic in= formation about the user should not be=0A>>>>> predicated on first looking = up basic information about the domain.=0A>>>>> Those can, and should, be tw= o completely separate tasks.=0A>>>>>=0A>>>>> There is a problem here, howev= er. A big problem actually. Many=0A>>>>> enterprises frown on putting thing= s that look like email addresses=0A>>>>> into URLs because of fairly signif= icant privacy concerns. So let's=0A>>>>> change that, instead of passing th= e acct: ID directly, we'll pass a=0A>>>>> hash of the acct id.. much more s= ecure and private that way...=0A>>>>>=0A>>>>>=A0 GET /.well-known/finger/f4= 9c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1=0A>>>>>=A0 Host: example.org=0A>>>>= >=0A>>>>> Ah, that's better... and in the process I managed to eliminate ab= out a=0A>>>>> third of what the WebFinger draft currently requires.=0A>>>>>= =0A>>>>> It boils down to nothing more than this:=0A>>>>> If I want to know= something about user "bob@example.org", I sent a GET=0A>>>>> request to ht= tp://example.org/.well-known/finger/{md5("bob@example.org")}=0A>>>>> and se= e what I get back. No absolute need to parse any XML. No need to=0A>>>>> pr= ocess any URI Templates. No need to define special query string=0A>>>>> par= ameters. Keep it very simple and we're essentially done.=0A>>>>>=0A>>>>> Ok= , so what about the response from the server? What would that look=0A>>>>> = like? Currently, WebFinger requires that the response has to either be=0A>>= >>> XRD or this other thing called JRD. While I don't have any problem=0A>>= >>> with using either of those particular formats, I do not believe that=0A= >>>>> the WebFinger spec needs to declare that any format MUST be supported= .=0A>>>>> It should be up to the server to provide whatever format it wishe= s.=0A>>>>> The client can determine if it's able to get what it's needs fro= m the=0A>>>>> provided format or not. If the response is HTML and includes = Link or=0A>>>>> Anchor elements that use appropriately labelled rel attribu= te values,=0A>>>>> then the client should be able to get the information it= needs; if the=0A>>>>> response is JSON and includes appropriately labeled = information in a=0A>>>>> way the client can understand, then great. That's = what we have things=0A>>>>> like the Accept request header for...=0A>>>>>= =0A>>>>>=A0 GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1= .1=0A>>>>>=A0 Host: example.org=0A>>>>>=A0 Accept: application/xrd+xml, tex= t/html, application/atom+xml=0A>>>>>=0A>>>>> The client can tell the server= what format it would like and the=0A>>>>> server can respond appropriately= . These mechanism are widely used and=0A>>>>> the abstract notion of a Link= is fairly universal now and easily=0A>>>>> represented in multiple formats= .=0A>>>>>=0A>>>>> The response to the above request could very well be as s= imple as:=0A>>>>>=0A>>>>>=A0 HTTP/1.1 204 No Content=0A>>>>>=A0 Link: ; rel=3D"blog",=0A>>>>>=A0 =A0 ; rel=3D"profile",=0A>>>>>=A0 =A0 ; rel=3D"avatar"=0A>>>>>=0A>>>>> Sure, this hypothetical type of = response may be impractical if a=0A>>>>> particular user has a significantl= y large number of links associated=0A>>>>> with it, but (a) realistically m= ost users won't have that many at any=0A>>>>> single service and (b) this i= s just an example, I did say that I have=0A>>>>> no problem with XRD/JRD be= ing used... it just shouldn't be required.=0A>>>>>=0A>>>>> Another possibil= ity. Just to stretch the imagination a bit more.=0A>>>>> Suppose I want to = know the location of the user's blog and I send this=0A>>>>> for a request:= =0A>>>>>=0A>>>>>=A0 GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302b= a/blog HTTP/1.1=0A>>>>>=A0 Host: example.org=0A>>>>>=0A>>>>> Note the addit= ion of the "/blog" at the end of the request URI. Let's=0A>>>>> just say th= at the last little bit there is a rel value. If the user=0A>>>>> has only a= single rel=3D"blog" Link, then the server can tell me where=0A>>>>> it is = with a simple redirect:=0A>>>>>=0A>>>>>=A0 HTTP/1.1 302 Found=0A>>>>>=A0 Lo= cation: http://blogs.example.org/bob=0A>>>>>=0A>>>>> If there happen to be = multiple "blog" links associated with that=0A>>>>> particular user, then th= e server can tell me about all of them...=0A>>>>>=0A>>>>>=A0 HTTP/1.1 300 M= ultiple Choices=0A>>>>>=A0 Location: http://blogs.example.org/bobs_default_= blog=0A>>>>>=A0 Link: ; rel=3D"= blog",=0A>>>>>=A0 =A0 ; rel=3D"bl= og"=0A>>>>>=0A>>>>> What if I want to know about some other kind of Link as= sociated with=0A>>>>> the user... well, I simply replace "/blog" with the o= ther rel=0A>>>>> attribute value...=0A>>>>>=0A>>>>>=A0 =A0 GET /.well-known= /finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard HTTP/1.1=0A>>>>>=A0 Host: ex= ample.org=0A>>>>>=0A>>>>>=A0 =A0 GET /.well-known/finger/f49c533fa0f0bc7ee9= cc8c88902302ba/avatar HTTP/1.1=0A>>>>>=A0 Host: example.org=0A>>>>>=0A>>>>>= =A0 =A0 GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/=0A>>>>> h= ttp%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fprovider HTTP/1.1=0A>>>>>=A0 Ho= st: example.org=0A>>>>>=0A>>>>> Whatever specific link rel I want to know a= bout, I just append that to=0A>>>>> the end. If I need to know about more t= han one, separate them by a=0A>>>>> comma:=0A>>>>>=0A>>>>>=A0 =A0 GET /.wel= l-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard,avatar=0A>>>>> HTTP/1= .1=0A>>>>>=A0 Host: example.org=0A>>>>>=0A>>>>> Which could return somethin= g along the lines of...=0A>>>>>=0A>>>>>=A0 HTTP/1.1 300 Multiple Choices=0A= >>>>>=A0 Link: ; rel=3D"vcard",=0A>>>>>=A0 = =A0 ; rel=3D"avatar"=0A>>>>>=0A>>>>> Or it coul= d return an XRD or JRD... either way, it works just fine.=0A>>>>> The point= is that it's MUCH simpler than what WebFinger defines and=0A>>>>> requires= fewer moving parts (no required XML parsing, no required URI=0A>>>>> Templ= ate processing, no required querystring parameters, etc).=0A>>>>>=0A>>>>> W= ith regards to security considerations, the original Finger protocol=0A>>>>= > was quite problematic because of the potential for inappropriate=0A>>>>> = disclosure of sensitive information about an account.=A0 The same basic=0A>= >>>> concern would be applicable to WebFinger depending on what information= =0A>>>>> was being made available for discovery. I've already dealt with on= e=0A>>>>> particular concern -- the use of an email-like identifier within = the=0A>>>>> discovery URI... requiring a hash is a simple fix there. But wh= at else=0A>>>>> can be done?=0A>>>>>=0A>>>>> Well, obviously, we're talking= about a HTTP request here. When a=0A>>>>> requester sends an unauthenticat= ed HTTP request to discover=0A>>>>> information about a user, the server ca= n choose to respond with only=0A>>>>> the most basic generic and public inf= ormation about the user and=0A>>>>> possibly some links to that user's publ= ic facing services (their blog,=0A>>>>> their avatar, etc). Mechanisms such= as OAuth 2 can be employed,=0A>>>>> however, to support much more interest= ing scenarios. For instance, a=0A>>>>> trusted third party could acquire an= OAuth 2 access token to request=0A>>>>> additional, more detailed informat= ion about a user...=0A>>>>>=0A>>>>>=A0 GET /.well-known/finger/f49c533fa0f0= bc7ee9cc8c88902302ba/blog HTTP/1.1=0A>>>>>=A0 Host: example.org=0A>>>>>=A0 = Authentication: Bearer {my_access_token}=0A>>>>>=0A>>>>> Such requests can = be easily tracked, rate-limited, etc, making the=0A>>>>> protocol generally= much more reliable and secure than the original=0A>>>>> finger protocol. U= nfortunately, the current WebFinger specification=0A>>>>> does not adequate= ly address this particular concern.=0A>>>>> ....=0A>>>>>=0A>>>>> - James=0A= >>>>>=0A>>>>> On Tue, Jul 3, 2012 at 12:24 AM, Mike Jones wrote:=0A>>>>>> You've essentially described Simple Web Discov= ery!=A0 It avoids the complications introduced by host-meta exactly by usin= g its own .well-known value.=A0 The basic example is:=0A>>>>>>=0A>>>>>>=A0 = GET /.well-known/simple-web-discovery?principal=3Dmailto:joe@example.com&s= ervice=3Durn:example.org:service:calendar HTTP/1.1=0A>>>>>>=A0 Host: examp= le.com=0A>>>>>>=0A>>>>>>=A0 HTTP/1.1 200 OK=0A>>>>>>=A0 Content-Type: app= lication/json=0A>>>>>>=0A>>>>>>=A0 {=0A>>>>>>=A0 =A0 "locations": ["http:/= /calendars.example.net/calendars/joseph"]=0A>>>>>>=A0 }=0A>>>>>>=0A>>>>>> = See http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 for more= details.=A0 By design, there aren't many...=0A>>>>>>=0A>>>>>>=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike=0A>>>>>>=0A>>>>= >> -----Original Message-----=0A>>>>>> From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mark Nottingham=0A>>>>>= > Sent: Monday, July 02, 2012 10:47 PM=0A>>>>>> To: IETF Apps Discuss=0A>>>= >>> Subject: [apps-discuss] Looking at Webfinger=0A>>>>>>=0A>>>>>> I've pre= tty much ignored the whole webfinger / acct: / SWD discussion (too much!). = However, since it's apparent it may soon become Real, I had a look.=0A>>>>>= >=0A>>>>>> In a nutshell, my initial reaction is "It's Not Nearly As Bad As= I Thought It Would Be." :)=0A>>>>>>=0A>>>>>> With that in mind, a few ques= tions / comments (I'll resist going into editorial matters, for the time be= ing):=0A>>>>>>=0A>>>>>> * First and foremost, why use host-meta? What value= does adding this extra step to the dance bring, beyond "We've defined it, = therefore we must use it?"=0A>>>>>>=0A>>>>>> As I think I've said many time= s before, the whole point of a .well-known URI is to group like uses togeth= er, to avoid having a "dictionary" resource that gets bloated with many app= lication's unrelated data, thereby overburdening clients with too much info= rmation (especially when they're constrained, e.g., mobile).=0A>>>>>>=0A>>>= >>> As such, host-meta is a spectacularly bad example of a well-known URI. = Defining a end-all-be-all well-known-URI kind of removes the point of havin= g a registry, after all...=0A>>>>>>=0A>>>>>> Instead, why not just define a= NEW well-known URI for user data? That has a more constrained scope, and s= aves one round trip (or more). E.g.,=0A>>>>>>=0A>>>>>> GET /.well-known/web= finger?user=3Dbob%40example.com HTTP/1.0=0A>>>>>> Host: example.com=0A>>>>>= >=0A>>>>>> I.e., let webfinger define the URI template to use. Yes, some im= plementations might want to come up with crazy URIs, but is that really a p= roblem we want to solve?=0A>>>>>>=0A>>>>>> Astute observers will notice tha= t this approach removes the need for an ACCT URI scheme (at least here).=0A= >>>>>>=0A>>>>>>=0A>>>>>> * What's the fascination with XRD and JRD? These s= pecifications seem to be creeping into IETF architecture; first it was in a= pure security context, but now folks are talking about using them in a muc= h more generic way, as a cornerstone of what we do. As such, I think they d= eserve a MUCH closer look, especially since we're defining things with "Web= " in their name when the W3C has already defined solutions in this space.= =0A>>>>>>=0A>>>>>> Thanks,=0A>>>>>>=0A>>>>>>=0A>>>>>> --=0A>>>>>> Mark Nott= ingham=A0 http://www.mnot.net/=0A>>>>>>=0A>>>>>>=0A>>>>>>=0A>>>>>> ________= _______________________________________=0A>>>>>> apps-discuss mailing list= =0A>>>>>> apps-discuss@ietf.org=0A>>>>>> https://www.ietf.org/mailman/listi= nfo/apps-discuss=0A>>>>>>=0A>>>>>>=0A>>>>>> _______________________________= ________________=0A>>>>>> apps-discuss mailing list=0A>>>>>> apps-discuss@i= etf.org=0A>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss=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>>>> --=0A>>>> Website: http:/= /hallambaker.com/=0A>>>> _______________________________________________=0A= >>>> apps-discuss mailing list=0A>>>> apps-discuss@ietf.org=0A>>>> https://= www.ietf.org/mailman/listinfo/apps-discuss=0A>>>=0A>>=0A>>=0A>>=0A>> --=0A>= > Website: http://hallambaker.com/=0A>_____________________________________= __________=0A>apps-discuss mailing list=0A>apps-discuss@ietf.org=0A>https:/= /www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A> ---1036955950-1916415527-1341435881=:26890 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I like the idea of registering a well-known for WF.   I'm not s= o  much in favor of changing the current query format.  There are= tonss of ways to get the data in there, the one in the draft now has extan= t implementations.  The current syntax is easily extensible and suffic= ient, and not in my opinion overly complex.  I tend not to be a fan of= stuffing things into the URL when there are multiple data items to deal wi= th, query or post parameters make more sense to me.

-bill

From: James M Snell <jasnell@gmail.com> To: Phillip Hallam-Baker= <hallam@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>; IETF Apps Discuss <apps-d= iscuss@ietf.org>
Sent:= Wednesday, July 4, 2012 1:45 PM
Subject: Re: [apps-discuss] Looking at Webfinger
=

The second issue here is the part about webfinger that bothers = me the
most... there really is no clear reason why XRD should be require= d
here. The additional indirection serves no significant valuable
pur= pose that I can determine. The Simple Web Discovery draft is better
over= all I think but much more can be done to simplify things and
provide a much more su= ccinct and useful protocol. Simply because XRD
is in use today by a few = early adopters, there's absolutely no reason
to rubber stamp it here. I = appreciate those early adopters for giving
a great demonstration of how = it shouldn't be done.

In my previous feedback, I've demonstrated tha= t the same benefits can
be achieved without the use of XRD at all... in = fact, we can achieve
exactly the same result and eliminate a good third = of everything
that's discussed in the current WF draft... Using WF's own= use cases
from Section 4...

Locating a user's blog...

Ass= uming, for privacy purposes, we hash the acct id; and assuming we
define= "blog" as a Link Relation...

  GET /.well-known/finger/fc5e68b= 29fa1d255bd038a167ca0b9bd/blog
  Host: example.org

  HT= TP/1.1 302 Found
  Location: http://blogs.exam= ple.com/bob/
  Link: <http://www.example.com/~bob/bob.jpg>; = rel=3D"avatar",
    <http://www.example.com/~bob/>; rel=3D"http://webfing= er.net/rel/profile-page"

Locating a user's contact info...
  GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/vcard
=   Host: example.org

  HTTP/1.1 200 OK
  Context-Ty= pe: text/vcard

  {vcard data}

Simplifying the Login Proc= ess

  GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/= openid
  Host: example.org

  HTTP/1.1 302 Found
&nbs= p; Location: https://openid.example.com/carol

Retrieving d= evice info

  GET /.well-known/finger/fc5e68b29fa1d255bd038a167c= a0b9bd/tipsi
  Host: example.org

  HTTP/1.1 302 Found  Location: = http://192.168.1.5/npap/


So in each case we achieve the same= fundamental goal without the
additional indirection or use of XRD. A sp= ecific implementation could
choose to use XRD if they'd like, but it sho= uldn't be a requirement.
For instance, suppose...

  GET /.we= ll-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/xrd
  Host: exampl= e.org

  HTTP/1.1 200 OK
  Content-Type: application/jso= n

  {...}

Doing this would be an entirely optional imple= mentation choice,
however. If I did, for instance...

  GET /= .well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd

Specifying no additional path, the server could very well just forward
me on to an HT= ML representation of my profile that contains
microdata/RDFa properties = I could harvest. The server should be
allowed to serve up whatever infor= mation it wants, in whatever format
it wants; client applications will d= etermine for themselves whether
that data is usable or not. Keeps the pr= otocol, and the spec, as drop
dead simple as possible.

- James
On Tue, Jul 3, 2012 at 6:59 PM, Phillip Hallam-Baker <hallam@gmail.com= > wrote:
> I recall something rather different. I recall a cla= im that the IPR was
> open when in fact the registry was to be operat= ed on a commercial
> basis.
>
> This technology keeps app= earing in specs without any apparent
> requirement to motivate it. In= OpenID the only reason for =3DPhill being
> required was that user@domain was not supported as we were told that
> people wanted t= o use the URL of their blog.
>
>
> On Tue, Jul 3, 2012 at= 7:53 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>> I re= call that there were strait answers and a meeting with the OASIS lawyer on = the topic back in the day.
>>
>> Not everyone trusted the= answers apparently,  but you can't make everyone happy.
>>>> The IPR you are concerned about related to XRI resolution and no= t the XRDS or XRD XML document formats.
>>
>> There shoul= d be no more IPR concern than there is with other OASIS specs like SAML.>>
>> That said I am not advocating the use of XRD,  S= WD used a simple link data type JSON format.
>>
>> The XR= D and JRD format are heavily influenced by the link data format if you look at it closely.
>>
>> Regards
>> John B.>>
>>
>>
>> On 2012-07-03, at 6:29 PM, Ph= illip Hallam-Baker wrote:
>>
>>> What are the PR encum= brances of XRD?
>>>
>>> The XRI folk never gave me = a straight answer, it is all tainted until
>>> there is an expl= icit statement AFIK.
>>>
>>> On Tue, Jul 3, 2012 at= 5:27 PM, James M Snell <jasnell@gmail.com> wrote:
>>>= > Great to see this conversation coming up... A couple of months ago I>>>> posted a few thoughts on WebFinger on my personal blog [= 1]... I've
>>>> copied the relevant bits here for discussion= . The short summary:
>>>> WebFinger is ok but can be made so= much simpler.
>>>>
>>>> [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-w= ebfinger.html
>>>>
>>>> ...
>>&g= t;> Ok... so [WebFinger] seems simple enough, but can we make it even>>>> simpler? I think we definitely can. Let's start by elimin= ating the
>>>> requirement to use XRD. Look at the first res= ponse... what is the XRD
>>>> document giving us? A Link. On= e Link. Ok, not really a Link, but a URI
>>>> Template. Wait= , so that's two things we I actually need to process
>>>> be= fore I can actually look up information about the user "bob"...
>>= >> let's eliminate both of those things and simply provide a means of=
>>>> looking up information about the user directly.. for i= nstance:
>>>>
>>>>  GET /.well-known/finger/acct%3Abob%40example.org HTTP/1.1
>>>>&= nbsp; Host: example.org
>>>>
>>>> If we still= need to know things about the domain, then we can finger
>>>&g= t; that domain...
>>>>
>>>>  GET /.well-= known/finger/example.org HTTP/1.1
>>>>  Host: example.o= rg
>>>>
>>>> But looking up basic information= about the user should not be
>>>> predicated on first looki= ng up basic information about the domain.
>>>> Those can, an= d should, be two completely separate tasks.
>>>>
>>= >> There is a problem here, however. A big problem actually. Many
= >>>> enterprises frown on putting things that look like email a= ddresses
>>>> into URLs because of fairly significant privac= y concerns. So let's
>>>> change that, instead of passing the acct: ID directly, we'll pass a
>>>> hash of th= e acct id.. much more secure and private that way...
>>>>>>>>  GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902= 302ba HTTP/1.1
>>>>  Host: example.org
>>>&= gt;
>>>> Ah, that's better... and in the process I managed t= o eliminate about a
>>>> third of what the WebFinger draft c= urrently requires.
>>>>
>>>> It boils down to= nothing more than this:
>>>> If I want to know something ab= out user "bob@example.org", I sent a GET
>>>> request to http://exa= mple.org/.well-known/finger/{md5("bob@example.org")}
>>>>= and see what I get back. No absolute need to parse any XML. No need to
>= >>> process any URI Templates. No need to define special query str= ing
>>>> parameters. Keep it very simple and we're essential= ly done.
>>>>
>>>> Ok, so what about the resp= onse from the server? What would that look
>>>> like? Curren= tly, WebFinger requires that the response has to either be
>>>&= gt; XRD or this other thing called JRD. While I don't have any problem
&= gt;>>> with using either of those particular formats, I do not bel= ieve that
>>>> the WebFinger spec needs to declare that any = format MUST be supported.
>>>> It should be up to the server= to provide whatever format it wishes.
>>>> The client can d= etermine if it's able to get what it's needs from the
>>>> p= rovided format or not. If the response is HTML and includes Link or
>>>> Anchor elements that use appropriately labelled rel= attribute values,
>>>> then the client should be able to ge= t the information it needs; if the
>>>> response is JSON and= includes appropriately labeled information in a
>>>> way th= e client can understand, then great. That's what we have things
>>= >> like the Accept request header for...
>>>>
>&= gt;>>  GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba = HTTP/1.1
>>>>  Host: example.org
>>>>&nb= sp; Accept: application/xrd+xml, text/html, application/atom+xml
>>= ;>>
>>>> The client can tell the server what format it= would like and the
>>>> server can respond appropriately. T= hese mechanism are widely used and
>>>> the abstract notion = of a Link is fairly universal now and easily
>>>> represented in multiple formats.
>>>>
>>>> T= he response to the above request could very well be as simple as:
>&g= t;>>
>>>>  HTTP/1.1 204 No Content
>>>= ;>  Link: <http://blogs.example.org/bob/>; rel=3D"blog",
>>>= >    <http://example.org/profiles/bob>; rel=3D"profile",
>&= gt;>>    <http://example.org/profiles/avatar>; rel=3D"avata= r"
>>>>
>>>> Sure, this hypothetical type of = response may be impractical if a
>>>> particular user has a = significantly large number of links associated
>>>> with it,= but (a) realistically most users won't have that many at any
>>&g= t;> single service and (b) this is just an example, I did say that I have
&= gt;>>> no problem with XRD/JRD being used... it just shouldn't be = required.
>>>>
>>>> Another possibility. Just= to stretch the imagination a bit more.
>>>> Suppose I want = to know the location of the user's blog and I send this
>>>>= for a request:
>>>>
>>>>  GET /.well-kn= own/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1.1
>>>&g= t;  Host: example.org
>>>>
>>>> Note the= addition of the "/blog" at the end of the request URI. Let's
>>&g= t;> just say that the last little bit there is a rel value. If the user<= br>>>>> has only a single rel=3D"blog" Link, then the server ca= n tell me where
>>>> it is with a simple redirect:
>&g= t;>>
>>>>  HTTP/1.1 302 Found
>>>>  Location: http://blogs.example.org/bob
>>>= >
>>>> If there happen to be multiple "blog" links associ= ated with that
>>>> particular user, then the server can tel= l me about all of them...
>>>>
>>>>  HTT= P/1.1 300 Multiple Choices
>>>>  Location: http://blogs.e= xample.org/bobs_default_blog
>>>>  Link: <http://b= logs.example.org/bobs_default_blog>; rel=3D"blog",
>>>&g= t;    <http://blogs.example.org/bobs_other_blog>; rel=3D"bl= og"
>>>>
>>>> What if I want to know about so= me other kind of Link associated with
>>>> the user... well, I simply rep= lace "/blog" with the other rel
>>>> attribute value...
&= gt;>>>
>>>>    GET /.well-known/finger/f4= 9c533fa0f0bc7ee9cc8c88902302ba/vcard HTTP/1.1
>>>>  Hos= t: example.org
>>>>
>>>>    GET /.w= ell-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar HTTP/1.1
>&g= t;>>  Host: example.org
>>>>
>>>>&= nbsp;   GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/
&= gt;>>> http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fprovider HTTP/= 1.1
>>>>  Host: example.org
>>>>
>= >>> Whatever specific link rel I want to know about, I just append= that to
>>>> the end. If I need to know about more than one= , separate them by a
>>>> comma:
>>>>
>>>>    GET /.well-kno= wn/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard,avatar
>>>>= HTTP/1.1
>>>>  Host: example.org
>>>>>>>> Which could return something along the lines of...
&g= t;>>>
>>>>  HTTP/1.1 300 Multiple Choices
&= gt;>>>  Link: <http://example.org/bob.vcard>; rel=3D"vcard",
>= ;>>>    <http://example.org/bob.jpg>; rel=3D"avatar"
>>= >>
>>>> Or it could return an XRD or JRD... either way= , it works just fine.
>>>> The point is that it's MUCH simpl= er than what WebFinger defines and
>>>> requires fewer movin= g parts (no required XML parsing, no required URI
>>>> Templ= ate processing, no required querystring parameters, etc).
>>>><= br>>>>> With regards to security considerations, the original F= inger protocol
>>>> was quite problematic because of the pot= ential for inappropriate
>>>> disclosure of sensitive inform= ation about an account.  The same basic
>>>> concern wo= uld be applicable to WebFinger depending on what information
>>>= ;> was being made available for discovery. I've already dealt with one>>>> particular concern -- the use of an email-like identifie= r within the
>>>> discovery URI... requiring a hash is a sim= ple fix there. But what else
>>>> can be done?
>>&g= t;>
>>>> Well, obviously, we're talking about a HTTP requ= est here. When a
>>>> requester sends an unauthenticated HTT= P request to discover
>>>> information about a user, the server can choose to respond with only
>>>> the most ba= sic generic and public information about the user and
>>>> p= ossibly some links to that user's public facing services (their blog,
&g= t;>>> their avatar, etc). Mechanisms such as OAuth 2 can be employ= ed,
>>>> however, to support much more interesting scenarios= . For instance, a
>>>> trusted third party could acquire an = OAuth 2 access token to request
>>>> additional, more detail= ed information about a user...
>>>>
>>>> = ; GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1.1>>>>  Host: example.org
>>>>  Authent= ication: Bearer {my_access_token}
>>>>
>>>> S= uch requests can be easily tracked, rate-limited, etc, making the
>&g= t;>> protocol generally much more reliable and secure than the original
>>>> finger protocol. Unfortunately, the current W= ebFinger specification
>>>> does not adequately address this= particular concern.
>>>> ....
>>>>
>&g= t;>> - James
>>>>
>>>> On Tue, Jul 3, 2= 012 at 12:24 AM, Mike Jones <Michael.Jones@microsoft.= com> wrote:
>>>>> You've essentially described Sim= ple Web Discovery!  It avoids the complications introduced by host-met= a exactly by using its own .well-known value.  The basic example is:>>>>>
>>>>>  GET /.well-known/simp= le-web-discovery?principal=3Dmailto:joe@example.com&service=3Durn:exampl= e.org:service:calendar HTTP/1.1
>>>>>  Host: example.com
>>>>>
>>>>>  HTTP/1.= 1 200 OK
>>>>>  Content-Type: application/json
&= gt;>>>>
>>>>>  {
>>>>>= ;    "locations": ["http://calendars.example.net/calendars/josep= h"]
>>>>>  }
>>>>>
>>= ;>>> See http://tools.ietf.org/html/draft-jones-= simple-web-discovery-02 for more details.  By design, there aren't= many...
>>>>>
>>>>>     = ;                     &nb= sp;     -- Mike
>>>>>
>>>>> -= ----Original Message-----
>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mark Nottingha= m
>>>>> Sent: Monday, July 02, 2012 10:47 PM
>>&= gt;>> To: IETF Apps Discuss
>>>>> Subject: [apps-di= scuss] Looking at Webfinger
>>>>>
>>>>>= I've pretty much ignored the whole webfinger / acct: / SWD discussion (too= much!). However, since it's apparent it may soon become Real, I had a look= .
>>>>>
>>>>> In a nutshell, my initial= reaction is "It's Not Nearly As Bad As I Thought It Would Be." :)
>&= gt;>>>
>>>>> With that in mind, a few questions = / comments (I'll resist going into editorial matters, for the time being):
>>>>>
>>>>> * First and foremo= st, why use host-meta? What value does adding this extra step to the dance = bring, beyond "We've defined it, therefore we must use it?"
>>>= >>
>>>>> As I think I've said many times before, th= e whole point of a .well-known URI is to group like uses together, to avoid= having a "dictionary" resource that gets bloated with many application's u= nrelated data, thereby overburdening clients with too much information (esp= ecially when they're constrained, e.g., mobile).
>>>>>>>>>> As such, host-meta is a spectacularly bad example of = a well-known URI. Defining a end-all-be-all well-known-URI kind of removes = the point of having a registry, after all...
>>>>>
>= ;>>>> Instead, why not just define a NEW well-known URI for use= r data? That has a more constrained scope, and saves one round trip (or more). E.g.,
>>>>>
>>>>> GET /.wel= l-known/webfinger?user=3Dbob%40example.com HTTP/1.0
>>>>>= Host: example.com
>>>>>
>>>>> I.e., le= t webfinger define the URI template to use. Yes, some implementations might= want to come up with crazy URIs, but is that really a problem we want to s= olve?
>>>>>
>>>>> Astute observers will= notice that this approach removes the need for an ACCT URI scheme (at leas= t here).
>>>>>
>>>>>
>>>>= ;> * What's the fascination with XRD and JRD? These specifications seem = to be creeping into IETF architecture; first it was in a pure security cont= ext, but now folks are talking about using them in a much more generic way,= as a cornerstone of what we do. As such, I think they deserve a MUCH close= r look, especially since we're defining things with "Web" in their name when the W3C has already defined solutions in this space.
>>= >>>
>>>>> Thanks,
>>>>>
>= ;>>>>
>>>>> --
>>>>> Mark N= ottingham  http://= www.mnot.net/
>>>>>
>>>>>
>&g= t;>>>
>>>>> ____________________________________= ___________
>>>>> apps-discuss mailing list
>>&g= t;>> apps-discuss@ietf.org
>>>>> h= ttps://www.ietf.org/mailman/listinfo/apps-discuss
>>>>&g= t;
>>>>>
>>>>> ________________________= _______________________
>>>>> apps-discuss mailing list
>>>>> apps-discuss@ietf.org
>>&= gt;>> https://www.ietf.org/mailman/listinfo/apps-discuss>>>> _______________________________________________
>&g= t;>> apps-discuss mailing list
>>>> apps-discus= s@ietf.org
>>>> https://www.ietf.org/mailman/listi= nfo/apps-discuss
>>>
>>>
>>>
>= ;>> --
>>> Website: http://hallambaker.com/
>>> ______________= _________________________________
>>> apps-discuss mailing list
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>= ;
>
>
> --
> Website: http://hallambaker.com/
___________________= ____________________________
apps-discuss mailing list
apps-di= scuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-disc= uss


---1036955950-1916415527-1341435881=:26890-- From jasnell@gmail.com Wed Jul 4 14:06:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20221F8698 for ; Wed, 4 Jul 2012 14:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.685 X-Spam-Level: X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[AWL=-2.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5Ws1FpgpKxz for ; Wed, 4 Jul 2012 14:06:41 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD7EB21F862A for ; Wed, 4 Jul 2012 14:06:40 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so5247097wgb.13 for ; Wed, 04 Jul 2012 14:06: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:from:date:message-id:subject:to :cc:content-type; bh=jDCQZKIFyddQ3Q39X6fV2srLculs6+Zd9hjvSAVfl1Y=; b=uRQqKRuUIStKCeIrbkAhMWX+/+tnd27XPRWp0gt67KiZ2fdhcfE2YSDwlz0T8UC5i/ XUs9QDNpqMt2VrSfwqQ0w7yka8qj9txLQkrQBpZQzJUOO/QZE38yRtOGK4ZYGdsUjttz KLy6E8HO/GxM1FYJMrQ2GyNRCQfKQeZK9SzzJQqQQUbxfF5mtmDJ8GMFT/fz00MKi9u9 NkkfPwfDSclZl1DhyDVTWfIKG90g09nbbTMC0Yf5Kv/65/tvjLsV/tl57HgppN6vLSrE Rvfc2mR8b+6LgFVahueRd+2FSse+CbxH0kHwJo0vf4xsJEq9p9dVsAzWJ+oQMiKRYokm Kx4A== Received: by 10.180.78.231 with SMTP id e7mr13270989wix.22.1341436011663; Wed, 04 Jul 2012 14:06:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.67 with HTTP; Wed, 4 Jul 2012 14:06:31 -0700 (PDT) In-Reply-To: References: <20120704002826.31184.30649.idtracker@ietfa.amsl.com> From: James M Snell Date: Wed, 4 Jul 2012 14:06:31 -0700 Message-ID: To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-nottingham-http-problem-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 21:06:41 -0000 In general, the feedback I offered you previously still applies, I think. However, that said, assuming things move forward with the draft, I do not believe the "describedby" link rel is a great choice here. Another option would be to use the "type" link I introduced here [1]. It's a fairly minor detail, however, so if it stays with "describedby" that's fine too. [1] http://tools.ietf.org/html/draft-snell-additional-link-relations-04 On Tue, Jul 3, 2012 at 5:48 PM, Mark Nottingham wrote: > FYI. > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-nottingham-http-problem-00.txt >> Date: 4 July 2012 10:28:26 AM AEST >> To: mnot@mnot.net >> >> >> A new version of I-D, draft-nottingham-http-problem-00.txt >> has been successfully submitted by Mark Nottingham and posted to the >> IETF repository. >> >> Filename: draft-nottingham-http-problem >> Revision: 00 >> Title: Indicating Details of Problems to Machines in HTTP >> Creation date: 2012-07-04 >> WG ID: Individual Submission >> Number of pages: 9 >> URL: http://www.ietf.org/internet-drafts/draft-nottingham-http-problem-00.txt >> Status: http://datatracker.ietf.org/doc/draft-nottingham-http-problem >> Htmlized: http://tools.ietf.org/html/draft-nottingham-http-problem-00 >> >> >> Abstract: >> This specification proposes a "Problem Detail" as an extensible way >> to carry machine-readable details of HTTP errors in a response, to >> avoid the need to invent new response formats for non-human >> consumers. >> >> >> >> >> The IETF Secretariat > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ve7jtb@ve7jtb.com Wed Jul 4 14:18:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10D221F8567 for ; Wed, 4 Jul 2012 14:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwJK3xv2P3aF for ; Wed, 4 Jul 2012 14:17:58 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09A2821F8541 for ; Wed, 4 Jul 2012 14:17:57 -0700 (PDT) Received: by yhq56 with SMTP id 56so9123096yhq.31 for ; Wed, 04 Jul 2012 14:18:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=LrZ1c1CXUulwGIGRzMnA0ppMaiveC6fqQJ2GLjPR3sQ=; b=Y2JLsR4p5geB9xrsGyCizQiADU8Z4XdarbaSYfJK2nOixfRQ886inNAhRdq0M+UyJd /U/IcINPw5M+/WeWbRlsFRdAyuDzzTxRHRgrp8oJyHi09X4YjWAnot7gOEB2evvclD7m 3EidAU1lhu+DA8KHedbSwrihEvCBZNRC2TZDoN2lGcrNM8/73w521a0KdDm6XG5+IulB o7NwTuS/xzEwBoUmOwTLVUlGydb82ExZ1QRJLTh3L/ms+y8CDqklC3jcYX4S7Dm+hzjV pWLcrKK4SHIPNU48i5VrSteJ2hpDqplngMwhiUR1UBYKuzcjCHAEIdZZmLTuvWR0eOex auGQ== Received: by 10.236.109.229 with SMTP id s65mr27677979yhg.10.1341436689428; Wed, 04 Jul 2012 14:18:09 -0700 (PDT) Received: from [192.168.1.211] (190-20-63-87.baf.movistar.cl. [190.20.63.87]) by mx.google.com with ESMTPS id y8sm18310954anj.11.2012.07.04.14.18.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jul 2012 14:18:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_0FF1BEAD-E936-4E58-A3A3-50171B13C45A"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Wed, 4 Jul 2012 17:18:00 -0400 Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> To: James M Snell X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnXjkkzas5DENmu/MfOGamJrBkUjfTpeOYiuXgnrOE3r3VieAWQLr6w0kSCP5UCQf6DyyUy Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 21:18:00 -0000 --Apple-Mail=_0FF1BEAD-E936-4E58-A3A3-50171B13C45A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In some ways XRD is an artifact of trying to use host-meta. I agree that if starting from a clean sheet is possible then using the = SWD approach of=20 having a specific .well-known location for discovery is better than = trying to overload host-meta with query parameters. I am personally fine with using a redirect, though I understand there = was push back in WF to that because not all hosting environments support = redirects. That was one reason why SWD supported a very basic application level = redirect. For openID Connect I don't think there is any interest in a non JSON = format. If WF as submitted goes forward then we would profile it down = for just JRD support.' I agree that it can be simpler and not require a new URI scheme.=20 One reason for a JSON format in SWD is to allow for multiple links per = rel to be returned to an application for fault tolerance. =20 For the unloved XRI spec there was a way to get the response in HTML, = and that was probably used as much and the XRDS format. I agree a html response format should be possible if not necessarily the = default. The question is if there is enough interest in the WG to rework the = basic design. The current WF draft is the path of least resistance. John B. On 2012-07-04, at 4:45 PM, James M Snell wrote: > The second issue here is the part about webfinger that bothers me the > most... there really is no clear reason why XRD should be required > here. The additional indirection serves no significant valuable > purpose that I can determine. The Simple Web Discovery draft is better > overall I think but much more can be done to simplify things and > provide a much more succinct and useful protocol. Simply because XRD > is in use today by a few early adopters, there's absolutely no reason > to rubber stamp it here. I appreciate those early adopters for giving > a great demonstration of how it shouldn't be done. >=20 > In my previous feedback, I've demonstrated that the same benefits can > be achieved without the use of XRD at all... in fact, we can achieve > exactly the same result and eliminate a good third of everything > that's discussed in the current WF draft... Using WF's own use cases > from Section 4... >=20 > Locating a user's blog... >=20 > Assuming, for privacy purposes, we hash the acct id; and assuming we > define "blog" as a Link Relation... >=20 > GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/blog > Host: example.org >=20 > HTTP/1.1 302 Found > Location: http://blogs.example.com/bob/ > Link: ; rel=3D"avatar", > ; = rel=3D"http://webfinger.net/rel/profile-page" >=20 > Locating a user's contact info... >=20 > GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/vcard > Host: example.org >=20 > HTTP/1.1 200 OK > Context-Type: text/vcard >=20 > {vcard data} >=20 > Simplifying the Login Process >=20 > GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/openid > Host: example.org >=20 > HTTP/1.1 302 Found > Location: https://openid.example.com/carol >=20 > Retrieving device info >=20 > GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/tipsi > Host: example.org >=20 > HTTP/1.1 302 Found > Location: http://192.168.1.5/npap/ >=20 >=20 > So in each case we achieve the same fundamental goal without the > additional indirection or use of XRD. A specific implementation could > choose to use XRD if they'd like, but it shouldn't be a requirement. > For instance, suppose... >=20 > GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/xrd > Host: example.org >=20 > HTTP/1.1 200 OK > Content-Type: application/json >=20 > {...} >=20 > Doing this would be an entirely optional implementation choice, > however. If I did, for instance... >=20 > GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd >=20 > Specifying no additional path, the server could very well just forward > me on to an HTML representation of my profile that contains > microdata/RDFa properties I could harvest. The server should be > allowed to serve up whatever information it wants, in whatever format > it wants; client applications will determine for themselves whether > that data is usable or not. Keeps the protocol, and the spec, as drop > dead simple as possible. >=20 > - James >=20 > On Tue, Jul 3, 2012 at 6:59 PM, Phillip Hallam-Baker = wrote: >> I recall something rather different. I recall a claim that the IPR = was >> open when in fact the registry was to be operated on a commercial >> basis. >>=20 >> This technology keeps appearing in specs without any apparent >> requirement to motivate it. In OpenID the only reason for =3DPhill = being >> required was that user@domain was not supported as we were told that >> people wanted to use the URL of their blog. >>=20 >>=20 >> On Tue, Jul 3, 2012 at 7:53 PM, John Bradley = wrote: >>> I recall that there were strait answers and a meeting with the OASIS = lawyer on the topic back in the day. >>>=20 >>> Not everyone trusted the answers apparently, but you can't make = everyone happy. >>>=20 >>> The IPR you are concerned about related to XRI resolution and not = the XRDS or XRD XML document formats. >>>=20 >>> There should be no more IPR concern than there is with other OASIS = specs like SAML. >>>=20 >>> That said I am not advocating the use of XRD, SWD used a simple = link data type JSON format. >>>=20 >>> The XRD and JRD format are heavily influenced by the link data = format if you look at it closely. >>>=20 >>> Regards >>> John B. >>>=20 >>>=20 >>>=20 >>> On 2012-07-03, at 6:29 PM, Phillip Hallam-Baker wrote: >>>=20 >>>> What are the PR encumbrances of XRD? >>>>=20 >>>> The XRI folk never gave me a straight answer, it is all tainted = until >>>> there is an explicit statement AFIK. >>>>=20 >>>> On Tue, Jul 3, 2012 at 5:27 PM, James M Snell = wrote: >>>>> Great to see this conversation coming up... A couple of months ago = I >>>>> posted a few thoughts on WebFinger on my personal blog [1]... I've >>>>> copied the relevant bits here for discussion. The short summary: >>>>> WebFinger is ok but can be made so much simpler. >>>>>=20 >>>>> [1] = http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html >>>>>=20 >>>>> ... >>>>> Ok... so [WebFinger] seems simple enough, but can we make it even >>>>> simpler? I think we definitely can. Let's start by eliminating the >>>>> requirement to use XRD. Look at the first response... what is the = XRD >>>>> document giving us? A Link. One Link. Ok, not really a Link, but a = URI >>>>> Template. Wait, so that's two things we I actually need to process >>>>> before I can actually look up information about the user "bob"... >>>>> let's eliminate both of those things and simply provide a means of >>>>> looking up information about the user directly.. for instance: >>>>>=20 >>>>> GET /.well-known/finger/acct%3Abob%40example.org HTTP/1.1 >>>>> Host: example.org >>>>>=20 >>>>> If we still need to know things about the domain, then we can = finger >>>>> that domain... >>>>>=20 >>>>> GET /.well-known/finger/example.org HTTP/1.1 >>>>> Host: example.org >>>>>=20 >>>>> But looking up basic information about the user should not be >>>>> predicated on first looking up basic information about the domain. >>>>> Those can, and should, be two completely separate tasks. >>>>>=20 >>>>> There is a problem here, however. A big problem actually. Many >>>>> enterprises frown on putting things that look like email addresses >>>>> into URLs because of fairly significant privacy concerns. So let's >>>>> change that, instead of passing the acct: ID directly, we'll pass = a >>>>> hash of the acct id.. much more secure and private that way... >>>>>=20 >>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 >>>>> Host: example.org >>>>>=20 >>>>> Ah, that's better... and in the process I managed to eliminate = about a >>>>> third of what the WebFinger draft currently requires. >>>>>=20 >>>>> It boils down to nothing more than this: >>>>> If I want to know something about user "bob@example.org", I sent a = GET >>>>> request to = http://example.org/.well-known/finger/{md5("bob@example.org")} >>>>> and see what I get back. No absolute need to parse any XML. No = need to >>>>> process any URI Templates. No need to define special query string >>>>> parameters. Keep it very simple and we're essentially done. >>>>>=20 >>>>> Ok, so what about the response from the server? What would that = look >>>>> like? Currently, WebFinger requires that the response has to = either be >>>>> XRD or this other thing called JRD. While I don't have any problem >>>>> with using either of those particular formats, I do not believe = that >>>>> the WebFinger spec needs to declare that any format MUST be = supported. >>>>> It should be up to the server to provide whatever format it = wishes. >>>>> The client can determine if it's able to get what it's needs from = the >>>>> provided format or not. If the response is HTML and includes Link = or >>>>> Anchor elements that use appropriately labelled rel attribute = values, >>>>> then the client should be able to get the information it needs; if = the >>>>> response is JSON and includes appropriately labeled information in = a >>>>> way the client can understand, then great. That's what we have = things >>>>> like the Accept request header for... >>>>>=20 >>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 >>>>> Host: example.org >>>>> Accept: application/xrd+xml, text/html, application/atom+xml >>>>>=20 >>>>> The client can tell the server what format it would like and the >>>>> server can respond appropriately. These mechanism are widely used = and >>>>> the abstract notion of a Link is fairly universal now and easily >>>>> represented in multiple formats. >>>>>=20 >>>>> The response to the above request could very well be as simple as: >>>>>=20 >>>>> HTTP/1.1 204 No Content >>>>> Link: ; rel=3D"blog", >>>>> ; rel=3D"profile", >>>>> ; rel=3D"avatar" >>>>>=20 >>>>> Sure, this hypothetical type of response may be impractical if a >>>>> particular user has a significantly large number of links = associated >>>>> with it, but (a) realistically most users won't have that many at = any >>>>> single service and (b) this is just an example, I did say that I = have >>>>> no problem with XRD/JRD being used... it just shouldn't be = required. >>>>>=20 >>>>> Another possibility. Just to stretch the imagination a bit more. >>>>> Suppose I want to know the location of the user's blog and I send = this >>>>> for a request: >>>>>=20 >>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog = HTTP/1.1 >>>>> Host: example.org >>>>>=20 >>>>> Note the addition of the "/blog" at the end of the request URI. = Let's >>>>> just say that the last little bit there is a rel value. If the = user >>>>> has only a single rel=3D"blog" Link, then the server can tell me = where >>>>> it is with a simple redirect: >>>>>=20 >>>>> HTTP/1.1 302 Found >>>>> Location: http://blogs.example.org/bob >>>>>=20 >>>>> If there happen to be multiple "blog" links associated with that >>>>> particular user, then the server can tell me about all of them... >>>>>=20 >>>>> HTTP/1.1 300 Multiple Choices >>>>> Location: http://blogs.example.org/bobs_default_blog >>>>> Link: ; rel=3D"blog", >>>>> ; rel=3D"blog" >>>>>=20 >>>>> What if I want to know about some other kind of Link associated = with >>>>> the user... well, I simply replace "/blog" with the other rel >>>>> attribute value... >>>>>=20 >>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard = HTTP/1.1 >>>>> Host: example.org >>>>>=20 >>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar = HTTP/1.1 >>>>> Host: example.org >>>>>=20 >>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/ >>>>> http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fprovider HTTP/1.1 >>>>> Host: example.org >>>>>=20 >>>>> Whatever specific link rel I want to know about, I just append = that to >>>>> the end. If I need to know about more than one, separate them by a >>>>> comma: >>>>>=20 >>>>> GET = /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard,avatar >>>>> HTTP/1.1 >>>>> Host: example.org >>>>>=20 >>>>> Which could return something along the lines of... >>>>>=20 >>>>> HTTP/1.1 300 Multiple Choices >>>>> Link: ; rel=3D"vcard", >>>>> ; rel=3D"avatar" >>>>>=20 >>>>> Or it could return an XRD or JRD... either way, it works just = fine. >>>>> The point is that it's MUCH simpler than what WebFinger defines = and >>>>> requires fewer moving parts (no required XML parsing, no required = URI >>>>> Template processing, no required querystring parameters, etc). >>>>>=20 >>>>> With regards to security considerations, the original Finger = protocol >>>>> was quite problematic because of the potential for inappropriate >>>>> disclosure of sensitive information about an account. The same = basic >>>>> concern would be applicable to WebFinger depending on what = information >>>>> was being made available for discovery. I've already dealt with = one >>>>> particular concern -- the use of an email-like identifier within = the >>>>> discovery URI... requiring a hash is a simple fix there. But what = else >>>>> can be done? >>>>>=20 >>>>> Well, obviously, we're talking about a HTTP request here. When a >>>>> requester sends an unauthenticated HTTP request to discover >>>>> information about a user, the server can choose to respond with = only >>>>> the most basic generic and public information about the user and >>>>> possibly some links to that user's public facing services (their = blog, >>>>> their avatar, etc). Mechanisms such as OAuth 2 can be employed, >>>>> however, to support much more interesting scenarios. For instance, = a >>>>> trusted third party could acquire an OAuth 2 access token to = request >>>>> additional, more detailed information about a user... >>>>>=20 >>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog = HTTP/1.1 >>>>> Host: example.org >>>>> Authentication: Bearer {my_access_token} >>>>>=20 >>>>> Such requests can be easily tracked, rate-limited, etc, making the >>>>> protocol generally much more reliable and secure than the original >>>>> finger protocol. Unfortunately, the current WebFinger = specification >>>>> does not adequately address this particular concern. >>>>> .... >>>>>=20 >>>>> - James >>>>>=20 >>>>> On Tue, Jul 3, 2012 at 12:24 AM, Mike Jones = wrote: >>>>>> You've essentially described Simple Web Discovery! It avoids the = complications introduced by host-meta exactly by using its own = .well-known value. The basic example is: >>>>>>=20 >>>>>> GET = /.well-known/simple-web-discovery?principal=3Dmailto:joe@example.com&servi= ce=3Durn:example.org:service:calendar HTTP/1.1 >>>>>> Host: example.com >>>>>>=20 >>>>>> HTTP/1.1 200 OK >>>>>> Content-Type: application/json >>>>>>=20 >>>>>> { >>>>>> "locations": ["http://calendars.example.net/calendars/joseph"] >>>>>> } >>>>>>=20 >>>>>> See = http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 for more = details. By design, there aren't many... >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mark Nottingham >>>>>> Sent: Monday, July 02, 2012 10:47 PM >>>>>> To: IETF Apps Discuss >>>>>> Subject: [apps-discuss] Looking at Webfinger >>>>>>=20 >>>>>> I've pretty much ignored the whole webfinger / acct: / SWD = discussion (too much!). However, since it's apparent it may soon become = Real, I had a look. >>>>>>=20 >>>>>> In a nutshell, my initial reaction is "It's Not Nearly As Bad As = I Thought It Would Be." :) >>>>>>=20 >>>>>> With that in mind, a few questions / comments (I'll resist going = into editorial matters, for the time being): >>>>>>=20 >>>>>> * First and foremost, why use host-meta? What value does adding = this extra step to the dance bring, beyond "We've defined it, therefore = we must use it?" >>>>>>=20 >>>>>> As I think I've said many times before, the whole point of a = .well-known URI is to group like uses together, to avoid having a = "dictionary" resource that gets bloated with many application's = unrelated data, thereby overburdening clients with too much information = (especially when they're constrained, e.g., mobile). >>>>>>=20 >>>>>> As such, host-meta is a spectacularly bad example of a well-known = URI. Defining a end-all-be-all well-known-URI kind of removes the point = of having a registry, after all... >>>>>>=20 >>>>>> Instead, why not just define a NEW well-known URI for user data? = That has a more constrained scope, and saves one round trip (or more). = E.g., >>>>>>=20 >>>>>> GET /.well-known/webfinger?user=3Dbob%40example.com HTTP/1.0 >>>>>> Host: example.com >>>>>>=20 >>>>>> I.e., let webfinger define the URI template to use. Yes, some = implementations might want to come up with crazy URIs, but is that = really a problem we want to solve? >>>>>>=20 >>>>>> Astute observers will notice that this approach removes the need = for an ACCT URI scheme (at least here). >>>>>>=20 >>>>>>=20 >>>>>> * What's the fascination with XRD and JRD? These specifications = seem to be creeping into IETF architecture; first it was in a pure = security context, but now folks are talking about using them in a much = more generic way, as a cornerstone of what we do. As such, I think they = deserve a MUCH closer look, especially since we're defining things with = "Web" in their name when the W3C has already defined solutions in this = space. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Mark Nottingham http://www.mnot.net/ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> apps-discuss mailing list >>>>>> apps-discuss@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Website: http://hallambaker.com/ >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>=20 >>=20 >>=20 >>=20 >> -- >> Website: http://hallambaker.com/ --Apple-Mail=_0FF1BEAD-E936-4E58-A3A3-50171B13C45A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw NDIxMTgwMVowIwYJKoZIhvcNAQkEMRYEFC2zxQ9u2OsZus7alyXqc9bUyGcVMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AINOtlIooGJvnQB+biEIx0kOxlrfJMRfT0aCXPRfjg5g//nZ5kufqfnHozGoLxbxDKbQcSHk1RFs uT9GI55OHnbi+yGIz8Aa4mmy/++0v9je+AbNXy9lmByaudqZLaLKAA2pbiReMR/m5ZlO+Ke7wr06 HNxD+KoJTlndxONoSkTS1M82YeqJcbOBoN5IjWBt0fMkjgM9+oYArFmRnOhFZUo8PunVFYQw9Nm7 iUFebSfqejEaofa94QXJiL05+MqbKIZ6Q6VO4xB61nubnI2mJnGB6DpaZfe5Ma9QAfmiAxdUsSuV cPKIB4dGCIe+q+5s0vLRaiLU4PbHqb4piPhXAa4AAAAAAAA= --Apple-Mail=_0FF1BEAD-E936-4E58-A3A3-50171B13C45A-- From jasnell@gmail.com Wed Jul 4 14:34:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD3C21F861D for ; Wed, 4 Jul 2012 14:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.27 X-Spam-Level: X-Spam-Status: No, score=-5.27 tagged_above=-999 required=5 tests=[AWL=-1.806, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOGLQpH29-WV for ; Wed, 4 Jul 2012 14:34:08 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0883421F8618 for ; Wed, 4 Jul 2012 14:34:07 -0700 (PDT) Received: by werp11 with SMTP id p11so2728065wer.31 for ; Wed, 04 Jul 2012 14:34:18 -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:content-transfer-encoding; bh=ONvctFUxquzQm946W3Jypsa0oeQlwnIMroX+CsdvkAY=; b=0L9XYABkG1Q18wCsW2ThQ7y/peb+GjExOHum+t+Fv6oYRre4JP05Y56G9vjesszFKr iJ9UH3YZtlo553B9lCW30dgNeryD7sE7aLZ9/Uw2QzmBNbC9MuAuSiSx9JtuiemHJ8aW XnUAJ9bspZj+L7XYhLrB89ZKMLwRn1u38WeKqkBXBmw3inXs32ySWH+lHAbBgNMU7BAt /daFpDtjUTsem0ncqSWEPEcsjY3AbSWvzi3WPNv4+Te0DWWcrILArScJbh9G8J45+com c5jh3XGCBKdwsTRFEkwBr7dlic7JtSboEb0iFr3uELjYoiZR8Wer8fDao6BiShz3h+5b 6TGA== Received: by 10.216.209.95 with SMTP id r73mr7453519weo.157.1341437658398; Wed, 04 Jul 2012 14:34:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.67 with HTTP; Wed, 4 Jul 2012 14:33:58 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> From: James M Snell Date: Wed, 4 Jul 2012 14:33:58 -0700 Message-ID: To: John Bradley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 21:34:10 -0000 The redirect would not be strictly necessary. There'd be absolutely nothing wrong with the host returning a document that allows for an application-level redirect. The more important point is that the model can be greatly improved by not *requiring* the host-meta and XRD-indirection. On Wed, Jul 4, 2012 at 2:18 PM, John Bradley wrote: > In some ways XRD is an artifact of trying to use host-meta. > > I agree that if starting from a clean sheet is possible then using the SW= D approach of > having a specific .well-known location for discovery is better than tryin= g to overload host-meta with query parameters. > > I am personally fine with using a redirect, though I understand there was= push back in WF to that because not all hosting environments support redir= ects. > That was one reason why SWD supported a very basic application level redi= rect. > > For openID Connect I don't think there is any interest in a non JSON form= at. If WF as submitted goes forward then we would profile it down for jus= t JRD support.' > > I agree that it can be simpler and not require a new URI scheme. > > One reason for a JSON format in SWD is to allow for multiple links per re= l to be returned to an application for fault tolerance. > > For the unloved XRI spec there was a way to get the response in HTML, and= that was probably used as much and the XRDS format. > > I agree a html response format should be possible if not necessarily the = default. > > The question is if there is enough interest in the WG to rework the basic= design. > > The current WF draft is the path of least resistance. > > John B. > > On 2012-07-04, at 4:45 PM, James M Snell wrote: > >> The second issue here is the part about webfinger that bothers me the >> most... there really is no clear reason why XRD should be required >> here. The additional indirection serves no significant valuable >> purpose that I can determine. The Simple Web Discovery draft is better >> overall I think but much more can be done to simplify things and >> provide a much more succinct and useful protocol. Simply because XRD >> is in use today by a few early adopters, there's absolutely no reason >> to rubber stamp it here. I appreciate those early adopters for giving >> a great demonstration of how it shouldn't be done. >> >> In my previous feedback, I've demonstrated that the same benefits can >> be achieved without the use of XRD at all... in fact, we can achieve >> exactly the same result and eliminate a good third of everything >> that's discussed in the current WF draft... Using WF's own use cases >> from Section 4... >> >> Locating a user's blog... >> >> Assuming, for privacy purposes, we hash the acct id; and assuming we >> define "blog" as a Link Relation... >> >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/blog >> Host: example.org >> >> HTTP/1.1 302 Found >> Location: http://blogs.example.com/bob/ >> Link: ; rel=3D"avatar", >> ; rel=3D"http://webfinger.net/rel/profi= le-page" >> >> Locating a user's contact info... >> >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/vcard >> Host: example.org >> >> HTTP/1.1 200 OK >> Context-Type: text/vcard >> >> {vcard data} >> >> Simplifying the Login Process >> >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/openid >> Host: example.org >> >> HTTP/1.1 302 Found >> Location: https://openid.example.com/carol >> >> Retrieving device info >> >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/tipsi >> Host: example.org >> >> HTTP/1.1 302 Found >> Location: http://192.168.1.5/npap/ >> >> >> So in each case we achieve the same fundamental goal without the >> additional indirection or use of XRD. A specific implementation could >> choose to use XRD if they'd like, but it shouldn't be a requirement. >> For instance, suppose... >> >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/xrd >> Host: example.org >> >> HTTP/1.1 200 OK >> Content-Type: application/json >> >> {...} >> >> Doing this would be an entirely optional implementation choice, >> however. If I did, for instance... >> >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd >> >> Specifying no additional path, the server could very well just forward >> me on to an HTML representation of my profile that contains >> microdata/RDFa properties I could harvest. The server should be >> allowed to serve up whatever information it wants, in whatever format >> it wants; client applications will determine for themselves whether >> that data is usable or not. Keeps the protocol, and the spec, as drop >> dead simple as possible. >> >> - James >> >> On Tue, Jul 3, 2012 at 6:59 PM, Phillip Hallam-Baker = wrote: >>> I recall something rather different. I recall a claim that the IPR was >>> open when in fact the registry was to be operated on a commercial >>> basis. >>> >>> This technology keeps appearing in specs without any apparent >>> requirement to motivate it. In OpenID the only reason for =3DPhill bein= g >>> required was that user@domain was not supported as we were told that >>> people wanted to use the URL of their blog. >>> >>> >>> On Tue, Jul 3, 2012 at 7:53 PM, John Bradley wrote: >>>> I recall that there were strait answers and a meeting with the OASIS l= awyer on the topic back in the day. >>>> >>>> Not everyone trusted the answers apparently, but you can't make every= one happy. >>>> >>>> The IPR you are concerned about related to XRI resolution and not the = XRDS or XRD XML document formats. >>>> >>>> There should be no more IPR concern than there is with other OASIS spe= cs like SAML. >>>> >>>> That said I am not advocating the use of XRD, SWD used a simple link = data type JSON format. >>>> >>>> The XRD and JRD format are heavily influenced by the link data format = if you look at it closely. >>>> >>>> Regards >>>> John B. >>>> >>>> >>>> >>>> On 2012-07-03, at 6:29 PM, Phillip Hallam-Baker wrote: >>>> >>>>> What are the PR encumbrances of XRD? >>>>> >>>>> The XRI folk never gave me a straight answer, it is all tainted until >>>>> there is an explicit statement AFIK. >>>>> >>>>> On Tue, Jul 3, 2012 at 5:27 PM, James M Snell wro= te: >>>>>> Great to see this conversation coming up... A couple of months ago I >>>>>> posted a few thoughts on WebFinger on my personal blog [1]... I've >>>>>> copied the relevant bits here for discussion. The short summary: >>>>>> WebFinger is ok but can be made so much simpler. >>>>>> >>>>>> [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.h= tml >>>>>> >>>>>> ... >>>>>> Ok... so [WebFinger] seems simple enough, but can we make it even >>>>>> simpler? I think we definitely can. Let's start by eliminating the >>>>>> requirement to use XRD. Look at the first response... what is the XR= D >>>>>> document giving us? A Link. One Link. Ok, not really a Link, but a U= RI >>>>>> Template. Wait, so that's two things we I actually need to process >>>>>> before I can actually look up information about the user "bob"... >>>>>> let's eliminate both of those things and simply provide a means of >>>>>> looking up information about the user directly.. for instance: >>>>>> >>>>>> GET /.well-known/finger/acct%3Abob%40example.org HTTP/1.1 >>>>>> Host: example.org >>>>>> >>>>>> If we still need to know things about the domain, then we can finger >>>>>> that domain... >>>>>> >>>>>> GET /.well-known/finger/example.org HTTP/1.1 >>>>>> Host: example.org >>>>>> >>>>>> But looking up basic information about the user should not be >>>>>> predicated on first looking up basic information about the domain. >>>>>> Those can, and should, be two completely separate tasks. >>>>>> >>>>>> There is a problem here, however. A big problem actually. Many >>>>>> enterprises frown on putting things that look like email addresses >>>>>> into URLs because of fairly significant privacy concerns. So let's >>>>>> change that, instead of passing the acct: ID directly, we'll pass a >>>>>> hash of the acct id.. much more secure and private that way... >>>>>> >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 >>>>>> Host: example.org >>>>>> >>>>>> Ah, that's better... and in the process I managed to eliminate about= a >>>>>> third of what the WebFinger draft currently requires. >>>>>> >>>>>> It boils down to nothing more than this: >>>>>> If I want to know something about user "bob@example.org", I sent a G= ET >>>>>> request to http://example.org/.well-known/finger/{md5("bob@example.o= rg")} >>>>>> and see what I get back. No absolute need to parse any XML. No need = to >>>>>> process any URI Templates. No need to define special query string >>>>>> parameters. Keep it very simple and we're essentially done. >>>>>> >>>>>> Ok, so what about the response from the server? What would that look >>>>>> like? Currently, WebFinger requires that the response has to either = be >>>>>> XRD or this other thing called JRD. While I don't have any problem >>>>>> with using either of those particular formats, I do not believe that >>>>>> the WebFinger spec needs to declare that any format MUST be supporte= d. >>>>>> It should be up to the server to provide whatever format it wishes. >>>>>> The client can determine if it's able to get what it's needs from th= e >>>>>> provided format or not. If the response is HTML and includes Link or >>>>>> Anchor elements that use appropriately labelled rel attribute values= , >>>>>> then the client should be able to get the information it needs; if t= he >>>>>> response is JSON and includes appropriately labeled information in a >>>>>> way the client can understand, then great. That's what we have thing= s >>>>>> like the Accept request header for... >>>>>> >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 >>>>>> Host: example.org >>>>>> Accept: application/xrd+xml, text/html, application/atom+xml >>>>>> >>>>>> The client can tell the server what format it would like and the >>>>>> server can respond appropriately. These mechanism are widely used an= d >>>>>> the abstract notion of a Link is fairly universal now and easily >>>>>> represented in multiple formats. >>>>>> >>>>>> The response to the above request could very well be as simple as: >>>>>> >>>>>> HTTP/1.1 204 No Content >>>>>> Link: ; rel=3D"blog", >>>>>> ; rel=3D"profile", >>>>>> ; rel=3D"avatar" >>>>>> >>>>>> Sure, this hypothetical type of response may be impractical if a >>>>>> particular user has a significantly large number of links associated >>>>>> with it, but (a) realistically most users won't have that many at an= y >>>>>> single service and (b) this is just an example, I did say that I hav= e >>>>>> no problem with XRD/JRD being used... it just shouldn't be required. >>>>>> >>>>>> Another possibility. Just to stretch the imagination a bit more. >>>>>> Suppose I want to know the location of the user's blog and I send th= is >>>>>> for a request: >>>>>> >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1= .1 >>>>>> Host: example.org >>>>>> >>>>>> Note the addition of the "/blog" at the end of the request URI. Let'= s >>>>>> just say that the last little bit there is a rel value. If the user >>>>>> has only a single rel=3D"blog" Link, then the server can tell me whe= re >>>>>> it is with a simple redirect: >>>>>> >>>>>> HTTP/1.1 302 Found >>>>>> Location: http://blogs.example.org/bob >>>>>> >>>>>> If there happen to be multiple "blog" links associated with that >>>>>> particular user, then the server can tell me about all of them... >>>>>> >>>>>> HTTP/1.1 300 Multiple Choices >>>>>> Location: http://blogs.example.org/bobs_default_blog >>>>>> Link: ; rel=3D"blog", >>>>>> ; rel=3D"blog" >>>>>> >>>>>> What if I want to know about some other kind of Link associated with >>>>>> the user... well, I simply replace "/blog" with the other rel >>>>>> attribute value... >>>>>> >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard HTT= P/1.1 >>>>>> Host: example.org >>>>>> >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar HT= TP/1.1 >>>>>> Host: example.org >>>>>> >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/ >>>>>> http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fprovider HTTP/1.1 >>>>>> Host: example.org >>>>>> >>>>>> Whatever specific link rel I want to know about, I just append that = to >>>>>> the end. If I need to know about more than one, separate them by a >>>>>> comma: >>>>>> >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard,ava= tar >>>>>> HTTP/1.1 >>>>>> Host: example.org >>>>>> >>>>>> Which could return something along the lines of... >>>>>> >>>>>> HTTP/1.1 300 Multiple Choices >>>>>> Link: ; rel=3D"vcard", >>>>>> ; rel=3D"avatar" >>>>>> >>>>>> Or it could return an XRD or JRD... either way, it works just fine. >>>>>> The point is that it's MUCH simpler than what WebFinger defines and >>>>>> requires fewer moving parts (no required XML parsing, no required UR= I >>>>>> Template processing, no required querystring parameters, etc). >>>>>> >>>>>> With regards to security considerations, the original Finger protoco= l >>>>>> was quite problematic because of the potential for inappropriate >>>>>> disclosure of sensitive information about an account. The same basi= c >>>>>> concern would be applicable to WebFinger depending on what informati= on >>>>>> was being made available for discovery. I've already dealt with one >>>>>> particular concern -- the use of an email-like identifier within the >>>>>> discovery URI... requiring a hash is a simple fix there. But what el= se >>>>>> can be done? >>>>>> >>>>>> Well, obviously, we're talking about a HTTP request here. When a >>>>>> requester sends an unauthenticated HTTP request to discover >>>>>> information about a user, the server can choose to respond with only >>>>>> the most basic generic and public information about the user and >>>>>> possibly some links to that user's public facing services (their blo= g, >>>>>> their avatar, etc). Mechanisms such as OAuth 2 can be employed, >>>>>> however, to support much more interesting scenarios. For instance, a >>>>>> trusted third party could acquire an OAuth 2 access token to request >>>>>> additional, more detailed information about a user... >>>>>> >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1= .1 >>>>>> Host: example.org >>>>>> Authentication: Bearer {my_access_token} >>>>>> >>>>>> Such requests can be easily tracked, rate-limited, etc, making the >>>>>> protocol generally much more reliable and secure than the original >>>>>> finger protocol. Unfortunately, the current WebFinger specification >>>>>> does not adequately address this particular concern. >>>>>> .... >>>>>> >>>>>> - James >>>>>> >>>>>> On Tue, Jul 3, 2012 at 12:24 AM, Mike Jones wrote: >>>>>>> You've essentially described Simple Web Discovery! It avoids the c= omplications introduced by host-meta exactly by using its own .well-known v= alue. The basic example is: >>>>>>> >>>>>>> GET /.well-known/simple-web-discovery?principal=3Dmailto:joe@examp= le.com&service=3Durn:example.org:service:calendar HTTP/1.1 >>>>>>> Host: example.com >>>>>>> >>>>>>> HTTP/1.1 200 OK >>>>>>> Content-Type: application/json >>>>>>> >>>>>>> { >>>>>>> "locations": ["http://calendars.example.net/calendars/joseph"] >>>>>>> } >>>>>>> >>>>>>> See http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 = for more details. By design, there aren't many... >>>>>>> >>>>>>> -- Mike >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ie= tf.org] On Behalf Of Mark Nottingham >>>>>>> Sent: Monday, July 02, 2012 10:47 PM >>>>>>> To: IETF Apps Discuss >>>>>>> Subject: [apps-discuss] Looking at Webfinger >>>>>>> >>>>>>> I've pretty much ignored the whole webfinger / acct: / SWD discussi= on (too much!). However, since it's apparent it may soon become Real, I had= a look. >>>>>>> >>>>>>> In a nutshell, my initial reaction is "It's Not Nearly As Bad As I = Thought It Would Be." :) >>>>>>> >>>>>>> With that in mind, a few questions / comments (I'll resist going in= to editorial matters, for the time being): >>>>>>> >>>>>>> * First and foremost, why use host-meta? What value does adding thi= s extra step to the dance bring, beyond "We've defined it, therefore we mus= t use it?" >>>>>>> >>>>>>> As I think I've said many times before, the whole point of a .well-= known URI is to group like uses together, to avoid having a "dictionary" re= source that gets bloated with many application's unrelated data, thereby ov= erburdening clients with too much information (especially when they're cons= trained, e.g., mobile). >>>>>>> >>>>>>> As such, host-meta is a spectacularly bad example of a well-known U= RI. Defining a end-all-be-all well-known-URI kind of removes the point of h= aving a registry, after all... >>>>>>> >>>>>>> Instead, why not just define a NEW well-known URI for user data? Th= at has a more constrained scope, and saves one round trip (or more). E.g., >>>>>>> >>>>>>> GET /.well-known/webfinger?user=3Dbob%40example.com HTTP/1.0 >>>>>>> Host: example.com >>>>>>> >>>>>>> I.e., let webfinger define the URI template to use. Yes, some imple= mentations might want to come up with crazy URIs, but is that really a prob= lem we want to solve? >>>>>>> >>>>>>> Astute observers will notice that this approach removes the need fo= r an ACCT URI scheme (at least here). >>>>>>> >>>>>>> >>>>>>> * What's the fascination with XRD and JRD? These specifications see= m to be creeping into IETF architecture; first it was in a pure security co= ntext, but now folks are talking about using them in a much more generic wa= y, as a cornerstone of what we do. As such, I think they deserve a MUCH clo= ser look, especially since we're defining things with "Web" in their name w= hen the W3C has already defined solutions in this space. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Mark Nottingham http://www.mnot.net/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>>>> >>>>> -- >>>>> Website: http://hallambaker.com/ >>>>> _______________________________________________ >>>>> apps-discuss mailing list >>>>> apps-discuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>> >>> >>> >>> >>> -- >>> Website: http://hallambaker.com/ > From jpanzer@google.com Wed Jul 4 15:16:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796A221F859E for ; Wed, 4 Jul 2012 15:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.841 X-Spam-Level: X-Spam-Status: No, score=-102.841 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ykATDMcFm2f for ; Wed, 4 Jul 2012 15:16:39 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 710E421F84D6 for ; Wed, 4 Jul 2012 15:16:39 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so11974547pbc.31 for ; Wed, 04 Jul 2012 15:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=WXd2A3BlT62rmj2eofH0Xjbsf3FZvnKZqSp+wl9Y6K0=; b=FOJthLmvHamRmpds2uL6kaVStfL7CUXW6i1AjPrHOGYbSTFiFVjxE5OGkGtugOOAg0 OKnrSHB2EJi0HQjRvPCIlxqrVkK2kzj5nfeV9D8C98E7xwpnHZrZmtNGUjrtI9QFWmb3 gjOuMgv2gHTQIkqaPFm/Yom1Wkmnk63Es08AYs/Ei67Njt3r8pL9lRja04ZGOTXtV/pz B2UIut7q19rIE9MNQB+FdGyCpFk4RrqJ1YhuDuFNNoKm4arN30fo2wKb5sAa2m9Lppmz 9yvOxWVHJhp/AZybsEnYU021sEKu0uHxFad6sjFIQe7JNOfAAtnxF8lt3OUHC+AfZAAt uuUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=WXd2A3BlT62rmj2eofH0Xjbsf3FZvnKZqSp+wl9Y6K0=; b=eqeJameAlDH7hjyFc5aIQdfYGri8xFa+hKFFKJI8j/m44G/BhbaE3nnW7LSbp+37M9 ps9bgvoc8I4kfkd/sciF7F3dGk+07VgtbbN33nEyU1+CbuTR89EqyVsrdnrC8dEd9hYQ lV61Jv4uGQxrYnJW0Qq1xj6aGIzacIJSsmhCtNKDcBYEAcHUAISg4zoCIQF1nJUA46Gt +g8QGHtJtiFqX6LbVrevZSORYW9mq4zu4yKva5ZF4Os6T9QN/0xIPx9sCDLdofCJGfps /3AnU9W3jSzUNSAB0yVzJ8zUx/hmsC7r7xWYozD7hi2CdZk1vxVC54zNEnHlfQXtjpCi WF2A== Received: by 10.68.223.35 with SMTP id qr3mr15164972pbc.83.1341440211113; Wed, 04 Jul 2012 15:16:51 -0700 (PDT) Received: by 10.68.223.35 with SMTP id qr3mr15164907pbc.83.1341440210363; Wed, 04 Jul 2012 15:16:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.58.69 with HTTP; Wed, 4 Jul 2012 15:16:30 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> From: John Panzer Date: Wed, 4 Jul 2012 15:16:30 -0700 Message-ID: To: James M Snell Content-Type: multipart/alternative; boundary=047d7b16308939e41604c40863bc X-System-Of-Record: true X-Gm-Message-State: ALoCoQll3M7mZiBxXwSMDmCJAwXRiTDZkqU9uJzq8JuSjBQ5zNv4LkNNhcgUiHJrVUWCjzJ07CRgfvQDwAl4o08QvxzONMdHC8AesgofOqLMyahtTpDp1kdrbtU+9RC0bBo5036QsVTko7lvLsdIei86yfsNPtJgcP8WSM4QZvA5Ku7ytKY3GWGJPlcuJtHPD9J7lIiryhYn Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 22:16:42 -0000 --047d7b16308939e41604c40863bc Content-Type: text/plain; charset=ISO-8859-1 Just as a historical note. The envisioned usage of host-meta was originally to avoid a specification which mandated a particular dynamic URL API at a particular /.well-known endpoint (because it may not be feasible to do that across all organizations and deployments). The host-meta document itself would be highly cacheable and so wouldn't incur an additional network trip in the common case. Having a 3xx redirect is a reasonable alternative that allows a similar escape hatch via something like mod_rewrite, albeit at the cost of needing an additional network trip each time. Since a deployment can always avoid the 3xx redirect with additional dynamic plumbing behind the well-known endpoint, I don't think that's a horrible thing. An application-level redirect would be almost equivalent to an HTTP redirect, but then there are two ways to do the same thing. If _only_ an application-level redirect is allowed, then you have to have at least a minimal dynamic service at the well-known endpoint (no more mod_rewrite). But the whole reason for this is to avoid the requirement for a dynamic service behind well-known... -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Wed, Jul 4, 2012 at 2:33 PM, James M Snell wrote: > The redirect would not be strictly necessary. There'd be absolutely > nothing wrong with the host returning a document that allows for an > application-level redirect. The more important point is that the model > can be greatly improved by not *requiring* the host-meta and > XRD-indirection. > > On Wed, Jul 4, 2012 at 2:18 PM, John Bradley wrote: > > In some ways XRD is an artifact of trying to use host-meta. > > > > I agree that if starting from a clean sheet is possible then using the > SWD approach of > > having a specific .well-known location for discovery is better than > trying to overload host-meta with query parameters. > > > > I am personally fine with using a redirect, though I understand there > was push back in WF to that because not all hosting environments support > redirects. > > That was one reason why SWD supported a very basic application level > redirect. > > > > For openID Connect I don't think there is any interest in a non JSON > format. If WF as submitted goes forward then we would profile it down for > just JRD support.' > > > > I agree that it can be simpler and not require a new URI scheme. > > > > One reason for a JSON format in SWD is to allow for multiple links per > rel to be returned to an application for fault tolerance. > > > > For the unloved XRI spec there was a way to get the response in HTML, > and that was probably used as much and the XRDS format. > > > > I agree a html response format should be possible if not necessarily the > default. > > > > The question is if there is enough interest in the WG to rework the > basic design. > > > > The current WF draft is the path of least resistance. > > > > John B. > > > > On 2012-07-04, at 4:45 PM, James M Snell wrote: > > > >> The second issue here is the part about webfinger that bothers me the > >> most... there really is no clear reason why XRD should be required > >> here. The additional indirection serves no significant valuable > >> purpose that I can determine. The Simple Web Discovery draft is better > >> overall I think but much more can be done to simplify things and > >> provide a much more succinct and useful protocol. Simply because XRD > >> is in use today by a few early adopters, there's absolutely no reason > >> to rubber stamp it here. I appreciate those early adopters for giving > >> a great demonstration of how it shouldn't be done. > >> > >> In my previous feedback, I've demonstrated that the same benefits can > >> be achieved without the use of XRD at all... in fact, we can achieve > >> exactly the same result and eliminate a good third of everything > >> that's discussed in the current WF draft... Using WF's own use cases > >> from Section 4... > >> > >> Locating a user's blog... > >> > >> Assuming, for privacy purposes, we hash the acct id; and assuming we > >> define "blog" as a Link Relation... > >> > >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/blog > >> Host: example.org > >> > >> HTTP/1.1 302 Found > >> Location: http://blogs.example.com/bob/ > >> Link: ; rel="avatar", > >> ; rel=" > http://webfinger.net/rel/profile-page" > >> > >> Locating a user's contact info... > >> > >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/vcard > >> Host: example.org > >> > >> HTTP/1.1 200 OK > >> Context-Type: text/vcard > >> > >> {vcard data} > >> > >> Simplifying the Login Process > >> > >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/openid > >> Host: example.org > >> > >> HTTP/1.1 302 Found > >> Location: https://openid.example.com/carol > >> > >> Retrieving device info > >> > >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/tipsi > >> Host: example.org > >> > >> HTTP/1.1 302 Found > >> Location: http://192.168.1.5/npap/ > >> > >> > >> So in each case we achieve the same fundamental goal without the > >> additional indirection or use of XRD. A specific implementation could > >> choose to use XRD if they'd like, but it shouldn't be a requirement. > >> For instance, suppose... > >> > >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/xrd > >> Host: example.org > >> > >> HTTP/1.1 200 OK > >> Content-Type: application/json > >> > >> {...} > >> > >> Doing this would be an entirely optional implementation choice, > >> however. If I did, for instance... > >> > >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd > >> > >> Specifying no additional path, the server could very well just forward > >> me on to an HTML representation of my profile that contains > >> microdata/RDFa properties I could harvest. The server should be > >> allowed to serve up whatever information it wants, in whatever format > >> it wants; client applications will determine for themselves whether > >> that data is usable or not. Keeps the protocol, and the spec, as drop > >> dead simple as possible. > >> > >> - James > >> > >> On Tue, Jul 3, 2012 at 6:59 PM, Phillip Hallam-Baker > wrote: > >>> I recall something rather different. I recall a claim that the IPR was > >>> open when in fact the registry was to be operated on a commercial > >>> basis. > >>> > >>> This technology keeps appearing in specs without any apparent > >>> requirement to motivate it. In OpenID the only reason for =Phill being > >>> required was that user@domain was not supported as we were told that > >>> people wanted to use the URL of their blog. > >>> > >>> > >>> On Tue, Jul 3, 2012 at 7:53 PM, John Bradley > wrote: > >>>> I recall that there were strait answers and a meeting with the OASIS > lawyer on the topic back in the day. > >>>> > >>>> Not everyone trusted the answers apparently, but you can't make > everyone happy. > >>>> > >>>> The IPR you are concerned about related to XRI resolution and not the > XRDS or XRD XML document formats. > >>>> > >>>> There should be no more IPR concern than there is with other OASIS > specs like SAML. > >>>> > >>>> That said I am not advocating the use of XRD, SWD used a simple link > data type JSON format. > >>>> > >>>> The XRD and JRD format are heavily influenced by the link data format > if you look at it closely. > >>>> > >>>> Regards > >>>> John B. > >>>> > >>>> > >>>> > >>>> On 2012-07-03, at 6:29 PM, Phillip Hallam-Baker wrote: > >>>> > >>>>> What are the PR encumbrances of XRD? > >>>>> > >>>>> The XRI folk never gave me a straight answer, it is all tainted until > >>>>> there is an explicit statement AFIK. > >>>>> > >>>>> On Tue, Jul 3, 2012 at 5:27 PM, James M Snell > wrote: > >>>>>> Great to see this conversation coming up... A couple of months ago I > >>>>>> posted a few thoughts on WebFinger on my personal blog [1]... I've > >>>>>> copied the relevant bits here for discussion. The short summary: > >>>>>> WebFinger is ok but can be made so much simpler. > >>>>>> > >>>>>> [1] > http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html > >>>>>> > >>>>>> ... > >>>>>> Ok... so [WebFinger] seems simple enough, but can we make it even > >>>>>> simpler? I think we definitely can. Let's start by eliminating the > >>>>>> requirement to use XRD. Look at the first response... what is the > XRD > >>>>>> document giving us? A Link. One Link. Ok, not really a Link, but a > URI > >>>>>> Template. Wait, so that's two things we I actually need to process > >>>>>> before I can actually look up information about the user "bob"... > >>>>>> let's eliminate both of those things and simply provide a means of > >>>>>> looking up information about the user directly.. for instance: > >>>>>> > >>>>>> GET /.well-known/finger/acct%3Abob%40example.org HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> If we still need to know things about the domain, then we can finger > >>>>>> that domain... > >>>>>> > >>>>>> GET /.well-known/finger/example.org HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> But looking up basic information about the user should not be > >>>>>> predicated on first looking up basic information about the domain. > >>>>>> Those can, and should, be two completely separate tasks. > >>>>>> > >>>>>> There is a problem here, however. A big problem actually. Many > >>>>>> enterprises frown on putting things that look like email addresses > >>>>>> into URLs because of fairly significant privacy concerns. So let's > >>>>>> change that, instead of passing the acct: ID directly, we'll pass a > >>>>>> hash of the acct id.. much more secure and private that way... > >>>>>> > >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> Ah, that's better... and in the process I managed to eliminate > about a > >>>>>> third of what the WebFinger draft currently requires. > >>>>>> > >>>>>> It boils down to nothing more than this: > >>>>>> If I want to know something about user "bob@example.org", I sent a > GET > >>>>>> request to http://example.org/.well-known/finger/{md5(" > bob@example.org")} > >>>>>> and see what I get back. No absolute need to parse any XML. No need > to > >>>>>> process any URI Templates. No need to define special query string > >>>>>> parameters. Keep it very simple and we're essentially done. > >>>>>> > >>>>>> Ok, so what about the response from the server? What would that look > >>>>>> like? Currently, WebFinger requires that the response has to either > be > >>>>>> XRD or this other thing called JRD. While I don't have any problem > >>>>>> with using either of those particular formats, I do not believe that > >>>>>> the WebFinger spec needs to declare that any format MUST be > supported. > >>>>>> It should be up to the server to provide whatever format it wishes. > >>>>>> The client can determine if it's able to get what it's needs from > the > >>>>>> provided format or not. If the response is HTML and includes Link or > >>>>>> Anchor elements that use appropriately labelled rel attribute > values, > >>>>>> then the client should be able to get the information it needs; if > the > >>>>>> response is JSON and includes appropriately labeled information in a > >>>>>> way the client can understand, then great. That's what we have > things > >>>>>> like the Accept request header for... > >>>>>> > >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1 > >>>>>> Host: example.org > >>>>>> Accept: application/xrd+xml, text/html, application/atom+xml > >>>>>> > >>>>>> The client can tell the server what format it would like and the > >>>>>> server can respond appropriately. These mechanism are widely used > and > >>>>>> the abstract notion of a Link is fairly universal now and easily > >>>>>> represented in multiple formats. > >>>>>> > >>>>>> The response to the above request could very well be as simple as: > >>>>>> > >>>>>> HTTP/1.1 204 No Content > >>>>>> Link: ; rel="blog", > >>>>>> ; rel="profile", > >>>>>> ; rel="avatar" > >>>>>> > >>>>>> Sure, this hypothetical type of response may be impractical if a > >>>>>> particular user has a significantly large number of links associated > >>>>>> with it, but (a) realistically most users won't have that many at > any > >>>>>> single service and (b) this is just an example, I did say that I > have > >>>>>> no problem with XRD/JRD being used... it just shouldn't be required. > >>>>>> > >>>>>> Another possibility. Just to stretch the imagination a bit more. > >>>>>> Suppose I want to know the location of the user's blog and I send > this > >>>>>> for a request: > >>>>>> > >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog > HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> Note the addition of the "/blog" at the end of the request URI. > Let's > >>>>>> just say that the last little bit there is a rel value. If the user > >>>>>> has only a single rel="blog" Link, then the server can tell me where > >>>>>> it is with a simple redirect: > >>>>>> > >>>>>> HTTP/1.1 302 Found > >>>>>> Location: http://blogs.example.org/bob > >>>>>> > >>>>>> If there happen to be multiple "blog" links associated with that > >>>>>> particular user, then the server can tell me about all of them... > >>>>>> > >>>>>> HTTP/1.1 300 Multiple Choices > >>>>>> Location: http://blogs.example.org/bobs_default_blog > >>>>>> Link: ; rel="blog", > >>>>>> ; rel="blog" > >>>>>> > >>>>>> What if I want to know about some other kind of Link associated with > >>>>>> the user... well, I simply replace "/blog" with the other rel > >>>>>> attribute value... > >>>>>> > >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard > HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar > HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/ > >>>>>> http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fprovider HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> Whatever specific link rel I want to know about, I just append that > to > >>>>>> the end. If I need to know about more than one, separate them by a > >>>>>> comma: > >>>>>> > >>>>>> GET > /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard,avatar > >>>>>> HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> Which could return something along the lines of... > >>>>>> > >>>>>> HTTP/1.1 300 Multiple Choices > >>>>>> Link: ; rel="vcard", > >>>>>> ; rel="avatar" > >>>>>> > >>>>>> Or it could return an XRD or JRD... either way, it works just fine. > >>>>>> The point is that it's MUCH simpler than what WebFinger defines and > >>>>>> requires fewer moving parts (no required XML parsing, no required > URI > >>>>>> Template processing, no required querystring parameters, etc). > >>>>>> > >>>>>> With regards to security considerations, the original Finger > protocol > >>>>>> was quite problematic because of the potential for inappropriate > >>>>>> disclosure of sensitive information about an account. The same > basic > >>>>>> concern would be applicable to WebFinger depending on what > information > >>>>>> was being made available for discovery. I've already dealt with one > >>>>>> particular concern -- the use of an email-like identifier within the > >>>>>> discovery URI... requiring a hash is a simple fix there. But what > else > >>>>>> can be done? > >>>>>> > >>>>>> Well, obviously, we're talking about a HTTP request here. When a > >>>>>> requester sends an unauthenticated HTTP request to discover > >>>>>> information about a user, the server can choose to respond with only > >>>>>> the most basic generic and public information about the user and > >>>>>> possibly some links to that user's public facing services (their > blog, > >>>>>> their avatar, etc). Mechanisms such as OAuth 2 can be employed, > >>>>>> however, to support much more interesting scenarios. For instance, a > >>>>>> trusted third party could acquire an OAuth 2 access token to request > >>>>>> additional, more detailed information about a user... > >>>>>> > >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog > HTTP/1.1 > >>>>>> Host: example.org > >>>>>> Authentication: Bearer {my_access_token} > >>>>>> > >>>>>> Such requests can be easily tracked, rate-limited, etc, making the > >>>>>> protocol generally much more reliable and secure than the original > >>>>>> finger protocol. Unfortunately, the current WebFinger specification > >>>>>> does not adequately address this particular concern. > >>>>>> .... > >>>>>> > >>>>>> - James > >>>>>> > >>>>>> On Tue, Jul 3, 2012 at 12:24 AM, Mike Jones < > Michael.Jones@microsoft.com> wrote: > >>>>>>> You've essentially described Simple Web Discovery! It avoids the > complications introduced by host-meta exactly by using its own .well-known > value. The basic example is: > >>>>>>> > >>>>>>> GET /.well-known/simple-web-discovery?principal=mailto: > joe@example.com&service=urn:example.org:service:calendar HTTP/1.1 > >>>>>>> Host: example.com > >>>>>>> > >>>>>>> HTTP/1.1 200 OK > >>>>>>> Content-Type: application/json > >>>>>>> > >>>>>>> { > >>>>>>> "locations": ["http://calendars.example.net/calendars/joseph"] > >>>>>>> } > >>>>>>> > >>>>>>> See http://tools.ietf.org/html/draft-jones-simple-web-discovery-02for more details. By design, there aren't many... > >>>>>>> > >>>>>>> -- Mike > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: apps-discuss-bounces@ietf.org [mailto: > apps-discuss-bounces@ietf.org] On Behalf Of Mark Nottingham > >>>>>>> Sent: Monday, July 02, 2012 10:47 PM > >>>>>>> To: IETF Apps Discuss > >>>>>>> Subject: [apps-discuss] Looking at Webfinger > >>>>>>> > >>>>>>> I've pretty much ignored the whole webfinger / acct: / SWD > discussion (too much!). However, since it's apparent it may soon become > Real, I had a look. > >>>>>>> > >>>>>>> In a nutshell, my initial reaction is "It's Not Nearly As Bad As I > Thought It Would Be." :) > >>>>>>> > >>>>>>> With that in mind, a few questions / comments (I'll resist going > into editorial matters, for the time being): > >>>>>>> > >>>>>>> * First and foremost, why use host-meta? What value does adding > this extra step to the dance bring, beyond "We've defined it, therefore we > must use it?" > >>>>>>> > >>>>>>> As I think I've said many times before, the whole point of a > .well-known URI is to group like uses together, to avoid having a > "dictionary" resource that gets bloated with many application's unrelated > data, thereby overburdening clients with too much information (especially > when they're constrained, e.g., mobile). > >>>>>>> > >>>>>>> As such, host-meta is a spectacularly bad example of a well-known > URI. Defining a end-all-be-all well-known-URI kind of removes the point of > having a registry, after all... > >>>>>>> > >>>>>>> Instead, why not just define a NEW well-known URI for user data? > That has a more constrained scope, and saves one round trip (or more). E.g., > >>>>>>> > >>>>>>> GET /.well-known/webfinger?user=bob%40example.com HTTP/1.0 > >>>>>>> Host: example.com > >>>>>>> > >>>>>>> I.e., let webfinger define the URI template to use. Yes, some > implementations might want to come up with crazy URIs, but is that really a > problem we want to solve? > >>>>>>> > >>>>>>> Astute observers will notice that this approach removes the need > for an ACCT URI scheme (at least here). > >>>>>>> > >>>>>>> > >>>>>>> * What's the fascination with XRD and JRD? These specifications > seem to be creeping into IETF architecture; first it was in a pure security > context, but now folks are talking about using them in a much more generic > way, as a cornerstone of what we do. As such, I think they deserve a MUCH > closer look, especially since we're defining things with "Web" in their > name when the W3C has already defined solutions in this space. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Mark Nottingham http://www.mnot.net/ > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Website: http://hallambaker.com/ > >>>>> _______________________________________________ > >>>>> apps-discuss mailing list > >>>>> apps-discuss@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss > >>>> > >>> > >>> > >>> > >>> -- > >>> Website: http://hallambaker.com/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7b16308939e41604c40863bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just as a historical note. =A0The envisioned usage of host-meta was origina= lly to avoid a specification which mandated a particular dynamic URL API at= a particular /.well-known endpoint (because it may not be feasible to do t= hat across all organizations and deployments). =A0The host-meta document it= self would be highly cacheable and so wouldn't incur an additional netw= ork trip in the common case.

Having a 3xx redirect is a reasonable alternative that allow= s a similar escape hatch via something like mod_rewrite, albeit at the cost= of needing an additional network trip each time. =A0Since a deployment can= always avoid the 3xx redirect with additional dynamic plumbing behind the = well-known endpoint, I don't think that's a horrible thing.

An application-level redirect would be almost equivalent to = an HTTP redirect, but then there are two ways to do the same thing. =A0If _= only_ an application-level redirect is allowed, then you have to have at le= ast a minimal dynamic service at the well-known endpoint (no more mod_rewri= te). =A0But the whole reason for this is to avoid the requirement for a dyn= amic service behind well-known...

--
John Panzer / Google
jpanzer@google.com = / abstractione= er.org / @jpanzer



On Wed, Jul 4= , 2012 at 2:33 PM, James M Snell <jasnell@gmail.com> wrote:<= br>
The redirect would not be strictly necessary. There'd be absolutely
nothing wrong with the host returning a document that allows for an
application-level redirect. The more important point is that the model
can be greatly improved by not *requiring* the host-meta and
XRD-indirection.

On Wed, Jul 4, 2012 at 2:18 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> In some ways XRD is an artifact of trying to use host-meta.
>
> I agree that if starting from a clean sheet is possible then using the= SWD approach of
> having a specific .well-known location for discovery is better than tr= ying to overload host-meta with query parameters.
>
> I am personally fine with using a redirect, though I understand there = was push back in WF to that because not all hosting environments support re= directs.
> That was one reason why SWD supported a very basic application level r= edirect.
>
> For openID Connect I don't think there is any interest in a non JS= ON format. =A0 If WF as submitted goes forward then we would profile it dow= n for just JRD support.'
>
> I agree that it can be simpler and not require a new URI scheme.
>
> One reason for a JSON format in SWD is to allow for multiple links per= rel to be returned to an application for fault tolerance.
>
> For the unloved XRI spec there was a way to get the response in HTML, = and that was probably used as much and the XRDS format.
>
> I agree a html response format should be possible if not necessarily t= he default.
>
> The question is if there is enough interest in the WG to rework the ba= sic design.
>
> The current WF draft is the path of least resistance.
>
> John B.
>
> On 2012-07-04, at 4:45 PM, James M Snell wrote:
>
>> The second issue here is the part about webfinger that bothers me = the
>> most... there really is no clear reason why XRD should be required=
>> here. The additional indirection serves no significant valuable >> purpose that I can determine. The Simple Web Discovery draft is be= tter
>> overall I think but much more can be done to simplify things and >> provide a much more succinct and useful protocol. Simply because X= RD
>> is in use today by a few early adopters, there's absolutely no= reason
>> to rubber stamp it here. I appreciate those early adopters for giv= ing
>> a great demonstration of how it shouldn't be done.
>>
>> In my previous feedback, I've demonstrated that the same benef= its can
>> be achieved without the use of XRD at all... in fact, we can achie= ve
>> exactly the same result and eliminate a good third of everything >> that's discussed in the current WF draft... Using WF's own= use cases
>> from Section 4...
>>
>> Locating a user's blog...
>>
>> Assuming, for privacy purposes, we hash the acct id; and assuming = we
>> define "blog" as a Link Relation...
>>
>> =A0GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/blog >> =A0Host: example.= org
>>
>> =A0HTTP/1.1 302 Found
>> =A0Location: http://blogs.example.com/bob/
>> =A0Link: <http://www.example.com/~bob/bob.jpg>; rel=3D"avata= r",
>> =A0 =A0<http://www.example.com/~bob/>; rel=3D"http://webfinger.net/rel/pro= file-page"
>>
>> Locating a user's contact info...
>>
>> =A0GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/vcard<= br> >> =A0Host: example.= org
>>
>> =A0HTTP/1.1 200 OK
>> =A0Context-Type: text/vcard
>>
>> =A0{vcard data}
>>
>> Simplifying the Login Process
>>
>> =A0GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/openid=
>> =A0Host: example.= org
>>
>> =A0HTTP/1.1 302 Found
>> =A0Location: https://openid.example.com/carol
>>
>> Retrieving device info
>>
>> =A0GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/tipsi<= br> >> =A0Host: example.= org
>>
>> =A0HTTP/1.1 302 Found
>> =A0Location: http://192.168.1.5/npap/
>>
>>
>> So in each case we achieve the same fundamental goal without the >> additional indirection or use of XRD. A specific implementation co= uld
>> choose to use XRD if they'd like, but it shouldn't be a re= quirement.
>> For instance, suppose...
>>
>> =A0GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/xrd >> =A0Host: example.= org
>>
>> =A0HTTP/1.1 200 OK
>> =A0Content-Type: application/json
>>
>> =A0{...}
>>
>> Doing this would be an entirely optional implementation choice, >> however. If I did, for instance...
>>
>> =A0GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd
>>
>> Specifying no additional path, the server could very well just for= ward
>> me on to an HTML representation of my profile that contains
>> microdata/RDFa properties I could harvest. The server should be >> allowed to serve up whatever information it wants, in whatever for= mat
>> it wants; client applications will determine for themselves whethe= r
>> that data is usable or not. Keeps the protocol, and the spec, as d= rop
>> dead simple as possible.
>>
>> - James
>>
>> On Tue, Jul 3, 2012 at 6:59 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>>> I recall something rather different. I recall a claim that the= IPR was
>>> open when in fact the registry was to be operated on a commerc= ial
>>> basis.
>>>
>>> This technology keeps appearing in specs without any apparent<= br> >>> requirement to motivate it. In OpenID the only reason for =3DP= hill being
>>> required was that user@domain was not supported as we were tol= d that
>>> people wanted to use the URL of their blog.
>>>
>>>
>>> On Tue, Jul 3, 2012 at 7:53 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>>> I recall that there were strait answers and a meeting with= the OASIS lawyer on the topic back in the day.
>>>>
>>>> Not everyone trusted the answers apparently, =A0but you ca= n't make everyone happy.
>>>>
>>>> The IPR you are concerned about related to XRI resolution = and not the XRDS or XRD XML document formats.
>>>>
>>>> There should be no more IPR concern than there is with oth= er OASIS specs like SAML.
>>>>
>>>> That said I am not advocating the use of XRD, =A0SWD used = a simple link data type JSON format.
>>>>
>>>> The XRD and JRD format are heavily influenced by the link = data format if you look at it closely.
>>>>
>>>> Regards
>>>> John B.
>>>>
>>>>
>>>>
>>>> On 2012-07-03, at 6:29 PM, Phillip Hallam-Baker wrote:
>>>>
>>>>> What are the PR encumbrances of XRD?
>>>>>
>>>>> The XRI folk never gave me a straight answer, it is al= l tainted until
>>>>> there is an explicit statement AFIK.
>>>>>
>>>>> On Tue, Jul 3, 2012 at 5:27 PM, James M Snell <jasnell@gmail.com> wrote:
>>>>>> Great to see this conversation coming up... A coup= le of months ago I
>>>>>> posted a few thoughts on WebFinger on my personal = blog [1]... I've
>>>>>> copied the relevant bits here for discussion. The = short summary:
>>>>>> WebFinger is ok but can be made so much simpler. >>>>>>
>>>>>> [1] http://chmod777self.blo= gspot.com/2012/03/thoughts-on-webfinger.html
>>>>>>
>>>>>> ...
>>>>>> Ok... so [WebFinger] seems simple enough, but can = we make it even
>>>>>> simpler? I think we definitely can. Let's star= t by eliminating the
>>>>>> requirement to use XRD. Look at the first response= ... what is the XRD
>>>>>> document giving us? A Link. One Link. Ok, not real= ly a Link, but a URI
>>>>>> Template. Wait, so that's two things we I actu= ally need to process
>>>>>> before I can actually look up information about th= e user "bob"...
>>>>>> let's eliminate both of those things and simpl= y provide a means of
>>>>>> looking up information about the user directly.. f= or instance:
>>>>>>
>>>>>> GET /.well-known/finger/acct%3Abob%40example.org HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>> If we still need to know things about the domain, = then we can finger
>>>>>> that domain...
>>>>>>
>>>>>> GET /.well-known/finger/example.org HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>> But looking up basic information about the user sh= ould not be
>>>>>> predicated on first looking up basic information a= bout the domain.
>>>>>> Those can, and should, be two completely separate = tasks.
>>>>>>
>>>>>> There is a problem here, however. A big problem ac= tually. Many
>>>>>> enterprises frown on putting things that look like= email addresses
>>>>>> into URLs because of fairly significant privacy co= ncerns. So let's
>>>>>> change that, instead of passing the acct: ID direc= tly, we'll pass a
>>>>>> hash of the acct id.. much more secure and private= that way...
>>>>>>
>>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c8890= 2302ba HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>> Ah, that's better... and in the process I mana= ged to eliminate about a
>>>>>> third of what the WebFinger draft currently requir= es.
>>>>>>
>>>>>> It boils down to nothing more than this:
>>>>>> If I want to know something about user "bob@example.org", I sent a GET
>>>>>> request to http://example.org/.well-known/finger/{m= d5("bob@example.org")}=
>>>>>> and see what I get back. No absolute need to parse= any XML. No need to
>>>>>> process any URI Templates. No need to define speci= al query string
>>>>>> parameters. Keep it very simple and we're esse= ntially done.
>>>>>>
>>>>>> Ok, so what about the response from the server? Wh= at would that look
>>>>>> like? Currently, WebFinger requires that the respo= nse has to either be
>>>>>> XRD or this other thing called JRD. While I don= 9;t have any problem
>>>>>> with using either of those particular formats, I d= o not believe that
>>>>>> the WebFinger spec needs to declare that any forma= t MUST be supported.
>>>>>> It should be up to the server to provide whatever = format it wishes.
>>>>>> The client can determine if it's able to get w= hat it's needs from the
>>>>>> provided format or not. If the response is HTML an= d includes Link or
>>>>>> Anchor elements that use appropriately labelled re= l attribute values,
>>>>>> then the client should be able to get the informat= ion it needs; if the
>>>>>> response is JSON and includes appropriately labele= d information in a
>>>>>> way the client can understand, then great. That= 9;s what we have things
>>>>>> like the Accept request header for...
>>>>>>
>>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c8890= 2302ba HTTP/1.1
>>>>>> Host: example.org
>>>>>> Accept: application/xrd+xml, text/html, applicatio= n/atom+xml
>>>>>>
>>>>>> The client can tell the server what format it woul= d like and the
>>>>>> server can respond appropriately. These mechanism = are widely used and
>>>>>> the abstract notion of a Link is fairly universal = now and easily
>>>>>> represented in multiple formats.
>>>>>>
>>>>>> The response to the above request could very well = be as simple as:
>>>>>>
>>>>>> HTTP/1.1 204 No Content
>>>>>> Link: <http://blogs.example.org/bob/>; rel=3D"blog= ",
>>>>>> =A0 <http://example.org/profiles/bob>; rel=3D"pr= ofile",
>>>>>> =A0 <http://example.org/profiles/avatar>; rel=3D&q= uot;avatar"
>>>>>>
>>>>>> Sure, this hypothetical type of response may be im= practical if a
>>>>>> particular user has a significantly large number o= f links associated
>>>>>> with it, but (a) realistically most users won'= t have that many at any
>>>>>> single service and (b) this is just an example, I = did say that I have
>>>>>> no problem with XRD/JRD being used... it just shou= ldn't be required.
>>>>>>
>>>>>> Another possibility. Just to stretch the imaginati= on a bit more.
>>>>>> Suppose I want to know the location of the user= 9;s blog and I send this
>>>>>> for a request:
>>>>>>
>>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c8890= 2302ba/blog HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>> Note the addition of the "/blog" at the = end of the request URI. Let's
>>>>>> just say that the last little bit there is a rel v= alue. If the user
>>>>>> has only a single rel=3D"blog" Link, the= n the server can tell me where
>>>>>> it is with a simple redirect:
>>>>>>
>>>>>> HTTP/1.1 302 Found
>>>>>> Location: http://blogs.example.org/bob
>>>>>>
>>>>>> If there happen to be multiple "blog" li= nks associated with that
>>>>>> particular user, then the server can tell me about= all of them...
>>>>>>
>>>>>> HTTP/1.1 300 Multiple Choices
>>>>>> Location: http://blogs.example.org/bobs_default_blog=
>>>>>> Link: <http://blogs.example.org/bobs_default_blog= >; rel=3D"blog",
>>>>>> =A0 <http://blogs.example.org/bobs_other_blog&g= t;; rel=3D"blog"
>>>>>>
>>>>>> What if I want to know about some other kind of Li= nk associated with
>>>>>> the user... well, I simply replace "/blog&quo= t; with the other rel
>>>>>> attribute value...
>>>>>>
>>>>>> =A0 GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c= 88902302ba/vcard HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>> =A0 GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c= 88902302ba/avatar HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>> =A0 GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c= 88902302ba/
>>>>>> http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fprovider HTTP/1.1 >>>>>> Host: example.org
>>>>>>
>>>>>> Whatever specific link rel I want to know about, I= just append that to
>>>>>> the end. If I need to know about more than one, se= parate them by a
>>>>>> comma:
>>>>>>
>>>>>> =A0 GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c= 88902302ba/vcard,avatar
>>>>>> HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>> Which could return something along the lines of...=
>>>>>>
>>>>>> HTTP/1.1 300 Multiple Choices
>>>>>> Link: <http://example.org/bob.vcard>; rel=3D"vcard&= quot;,
>>>>>> =A0 <http://example.org/bob.jpg>; rel=3D"avatar"=
>>>>>>
>>>>>> Or it could return an XRD or JRD... either way, it= works just fine.
>>>>>> The point is that it's MUCH simpler than what = WebFinger defines and
>>>>>> requires fewer moving parts (no required XML parsi= ng, no required URI
>>>>>> Template processing, no required querystring param= eters, etc).
>>>>>>
>>>>>> With regards to security considerations, the origi= nal Finger protocol
>>>>>> was quite problematic because of the potential for= inappropriate
>>>>>> disclosure of sensitive information about an accou= nt. =A0The same basic
>>>>>> concern would be applicable to WebFinger depending= on what information
>>>>>> was being made available for discovery. I've a= lready dealt with one
>>>>>> particular concern -- the use of an email-like ide= ntifier within the
>>>>>> discovery URI... requiring a hash is a simple fix = there. But what else
>>>>>> can be done?
>>>>>>
>>>>>> Well, obviously, we're talking about a HTTP re= quest here. When a
>>>>>> requester sends an unauthenticated HTTP request to= discover
>>>>>> information about a user, the server can choose to= respond with only
>>>>>> the most basic generic and public information abou= t the user and
>>>>>> possibly some links to that user's public faci= ng services (their blog,
>>>>>> their avatar, etc). Mechanisms such as OAuth 2 can= be employed,
>>>>>> however, to support much more interesting scenario= s. For instance, a
>>>>>> trusted third party could acquire an OAuth 2 acces= s token to request
>>>>>> additional, more detailed information about a user= ...
>>>>>>
>>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c8890= 2302ba/blog HTTP/1.1
>>>>>> Host: example.org
>>>>>> Authentication: Bearer {my_access_token}
>>>>>>
>>>>>> Such requests can be easily tracked, rate-limited,= etc, making the
>>>>>> protocol generally much more reliable and secure t= han the original
>>>>>> finger protocol. Unfortunately, the current WebFin= ger specification
>>>>>> does not adequately address this particular concer= n.
>>>>>> ....
>>>>>>
>>>>>> - James
>>>>>>
>>>>>> On Tue, Jul 3, 2012 at 12:24 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>>>> You've essentially described Simple Web Di= scovery! =A0It avoids the complications introduced by host-meta exactly by = using its own .well-known value. =A0The basic example is:
>>>>>>>
>>>>>>> =A0GET /.well-known/simple-web-discovery?princ= ipal=3Dmailto:joe@example.com&se= rvice=3Durn:example.org:service:calendar HTTP/1.1
>>>>>>> =A0Host: example.com
>>>>>>>
>>>>>>> =A0HTTP/1.1 200 OK
>>>>>>> =A0Content-Type: application/json
>>>>>>>
>>>>>>> =A0{
>>>>>>> =A0 "locations": ["http://cale= ndars.example.net/calendars/joseph"]
>>>>>>> =A0}
>>>>>>>
>>>>>>> See http://tools.ietf.org/ht= ml/draft-jones-simple-web-discovery-02 for more details. =A0By design, = there aren't many...
>>>>>>>
>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 -- Mike
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Ma= rk Nottingham
>>>>>>> Sent: Monday, July 02, 2012 10:47 PM
>>>>>>> To: IETF Apps Discuss
>>>>>>> Subject: [apps-discuss] Looking at Webfinger >>>>>>>
>>>>>>> I've pretty much ignored the whole webfing= er / acct: / SWD discussion (too much!). However, since it's apparent i= t may soon become Real, I had a look.
>>>>>>>
>>>>>>> In a nutshell, my initial reaction is "It= 's Not Nearly As Bad As I Thought It Would Be." :)
>>>>>>>
>>>>>>> With that in mind, a few questions / comments = (I'll resist going into editorial matters, for the time being):
>>>>>>>
>>>>>>> * First and foremost, why use host-meta? What = value does adding this extra step to the dance bring, beyond "We'v= e defined it, therefore we must use it?"
>>>>>>>
>>>>>>> As I think I've said many times before, th= e whole point of a .well-known URI is to group like uses together, to avoid= having a "dictionary" resource that gets bloated with many appli= cation's unrelated data, thereby overburdening clients with too much in= formation (especially when they're constrained, e.g., mobile).
>>>>>>>
>>>>>>> As such, host-meta is a spectacularly bad exam= ple of a well-known URI. Defining a end-all-be-all well-known-URI kind of r= emoves the point of having a registry, after all...
>>>>>>>
>>>>>>> Instead, why not just define a NEW well-known = URI for user data? That has a more constrained scope, and saves one round t= rip (or more). E.g.,
>>>>>>>
>>>>>>> GET /.well-known/webfinger?user=3Dbob%40example.com HTTP/1.0
>>>>>>> Host: example.com
>>>>>>>
>>>>>>> I.e., let webfinger define the URI template to= use. Yes, some implementations might want to come up with crazy URIs, but = is that really a problem we want to solve?
>>>>>>>
>>>>>>> Astute observers will notice that this approac= h removes the need for an ACCT URI scheme (at least here).
>>>>>>>
>>>>>>>
>>>>>>> * What's the fascination with XRD and JRD?= These specifications seem to be creeping into IETF architecture; first it = was in a pure security context, but now folks are talking about using them = in a much more generic way, as a cornerstone of what we do. As such, I thin= k they deserve a MUCH closer look, especially since we're defining thin= gs with "Web" in their name when the W3C has already defined solu= tions in this space.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mark Nottingham =A0 http://www.mnot.net/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> apps-discuss mailing list
>>>>>>> apps-= discuss@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ap= ps-discuss
>>>>>>>
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> apps-discuss mailing list
>>>>>>> apps-= discuss@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ap= ps-discuss
>>>>>> _______________________________________________ >>>>>> apps-discuss mailing list
>>>>>> apps-disc= uss@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/apps-d= iscuss
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Website: http://hallambaker.com/
>>>>> _______________________________________________
>>>>> apps-discuss mailing list
>>>>> apps-discuss@= ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/apps-discu= ss
>>>>
>>>
>>>
>>>
>>> --
>>> Website: http://hallambaker.com/
>
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--047d7b16308939e41604c40863bc-- From mnot@mnot.net Wed Jul 4 15:37:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C539C11E807F for ; Wed, 4 Jul 2012 15:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.302 X-Spam-Level: X-Spam-Status: No, score=-105.302 tagged_above=-999 required=5 tests=[AWL=-2.703, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VA7pStqFAqa for ; Wed, 4 Jul 2012 15:37:00 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9243111E8073 for ; Wed, 4 Jul 2012 15:36:58 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2F53422E257; Wed, 4 Jul 2012 18:37:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: Date: Thu, 5 Jul 2012 08:36:59 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net> References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> To: John Panzer X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 22:37:02 -0000 On 05/07/2012, at 8:16 AM, John Panzer wrote: > Just as a historical note. The envisioned usage of host-meta was = originally to avoid a specification which mandated a particular dynamic = URL API at a particular /.well-known endpoint (because it may not be = feasible to do that across all organizations and deployments). The = host-meta document itself would be highly cacheable and so wouldn't = incur an additional network trip in the common case. >=20 > Having a 3xx redirect is a reasonable alternative that allows a = similar escape hatch via something like mod_rewrite, albeit at the cost = of needing an additional network trip each time. Since a deployment can = always avoid the 3xx redirect with additional dynamic plumbing behind = the well-known endpoint, I don't think that's a horrible thing. >=20 > An application-level redirect would be almost equivalent to an HTTP = redirect, but then there are two ways to do the same thing. If _only_ = an application-level redirect is allowed, then you have to have at least = a minimal dynamic service at the well-known endpoint (no more = mod_rewrite). But the whole reason for this is to avoid the requirement = for a dynamic service behind well-known... "dynamic" and "static" are properties of the implementation, not the = interface. HTTP doesn't require that any particular URL be "dynamic"; = anything can, with the right metadata, be cached (and indeed, I've = cached many, many things with the wrong metadata, because of silly site = operators and their ideas about "dynamic"). Now, if people want to target a particular implementation that makes it = easier to serve a particular style of URL without writing code, fine, = but let's not confuse things. E.g., a URL like http://example.com/.well-known/user/bob is easy to serve in pretty much any way you like with Apache. I'm also going to push back on the "it may not be feasible to do that = across all organizations and deployments" motivation. This is a race to = the bottom. The trick is to make it accessible enough to get sufficient = traction to pull everyone along, without pandering to *everyone*'s = requirements. Regards, -- Mark Nottingham http://www.mnot.net/ From ve7jtb@ve7jtb.com Wed Jul 4 15:42:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDB611E8085 for ; Wed, 4 Jul 2012 15:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KV0mQP6gPdP for ; Wed, 4 Jul 2012 15:42:10 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADBB621F8621 for ; Wed, 4 Jul 2012 15:42:09 -0700 (PDT) Received: by ghbg16 with SMTP id g16so7608363ghb.31 for ; Wed, 04 Jul 2012 15:42:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=ScBgZhd78Y/s7iVK41v0cCko4g7Jocv88HnXv9/BnbY=; b=XGqBpUwmoguPF4vbq5xAIAmXHxiS1fK7+kyXPaRHwLz7XAfIkHK6CwnRHN+sOobXGA qHZzFdcW0EaIlQpeTDxdbEEUOK0LoFFtKIviFhCwMMES9F6zfEpk4aKOGL/L4oWr+XJK sPVrUN4Emnxw2ALRMNo/+Rxxz43IpCr2mb2nt403E4iKGGlFepMTk6eROYPN6S113IrW NSFqL8GK+xmip+VVaSypdDws3W0qh5qdBqTttFrwdFo4BD0xmjVkAiVNTBCkSKvXmCyB CGUcDZNpbf/Q3kHPfPO4M98vc3DCMgD2VTElQ9YcxJPhwtx5zfmhRpvwde92VPoRbZxY R7VA== Received: by 10.236.124.13 with SMTP id w13mr27009896yhh.76.1341441739730; Wed, 04 Jul 2012 15:42:19 -0700 (PDT) Received: from [192.168.1.211] (190-20-63-87.baf.movistar.cl. [190.20.63.87]) by mx.google.com with ESMTPS id l49sm39203512yhj.8.2012.07.04.15.42.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jul 2012 15:42:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_C5DC2F63-8E25-4EE5-9E7A-B64658AB26F3"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Wed, 4 Jul 2012 18:42:04 -0400 Message-Id: <0B0057F3-6BA2-41F7-B7AD-0481EFEE5983@ve7jtb.com> References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> To: John Panzer X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlAEipYoqbz3KV+rre+wRwnDa0jfJwawJFfZAXvGoSVzowazJySvijENgeAkAAgPFZc3t1f Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 22:42:13 -0000 --Apple-Mail=_C5DC2F63-8E25-4EE5-9E7A-B64658AB26F3 Content-Type: multipart/alternative; boundary="Apple-Mail=_035EF547-71D0-4D44-9639-60D1484E5CC8" --Apple-Mail=_035EF547-71D0-4D44-9639-60D1484E5CC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 At the moment we have WF adding query parameters to host-meta to avoid = multiple round trips in the case where you can have a dynamic service. The goal for SWD was to get the thing you are looking for on the first = try if possible. If that is not possible return a cacheable document = that gives you the new base URL for a second query. Without the dynamic service behind host-meta you get a template on the = first try and then must expand the template for your second try. =20 You also loose the ability to query for a specific rel because there is = only one template parameter for the URL. I agree that host-meta makes sense for looking up host services. The = question that some are asking is if using that as an extra indirection = for looking up end-user information is the best approach. Thanks for the background. John B. On 2012-07-04, at 6:16 PM, John Panzer wrote: > Just as a historical note. The envisioned usage of host-meta was = originally to avoid a specification which mandated a particular dynamic = URL API at a particular /.well-known endpoint (because it may not be = feasible to do that across all organizations and deployments). The = host-meta document itself would be highly cacheable and so wouldn't = incur an additional network trip in the common case. >=20 > Having a 3xx redirect is a reasonable alternative that allows a = similar escape hatch via something like mod_rewrite, albeit at the cost = of needing an additional network trip each time. Since a deployment can = always avoid the 3xx redirect with additional dynamic plumbing behind = the well-known endpoint, I don't think that's a horrible thing. >=20 > An application-level redirect would be almost equivalent to an HTTP = redirect, but then there are two ways to do the same thing. If _only_ = an application-level redirect is allowed, then you have to have at least = a minimal dynamic service at the well-known endpoint (no more = mod_rewrite). But the whole reason for this is to avoid the requirement = for a dynamic service behind well-known... >=20 > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer >=20 >=20 >=20 > On Wed, Jul 4, 2012 at 2:33 PM, James M Snell = wrote: > The redirect would not be strictly necessary. There'd be absolutely > nothing wrong with the host returning a document that allows for an > application-level redirect. The more important point is that the model > can be greatly improved by not *requiring* the host-meta and > XRD-indirection. >=20 > On Wed, Jul 4, 2012 at 2:18 PM, John Bradley = wrote: > > In some ways XRD is an artifact of trying to use host-meta. > > > > I agree that if starting from a clean sheet is possible then using = the SWD approach of > > having a specific .well-known location for discovery is better than = trying to overload host-meta with query parameters. > > > > I am personally fine with using a redirect, though I understand = there was push back in WF to that because not all hosting environments = support redirects. > > That was one reason why SWD supported a very basic application level = redirect. > > > > For openID Connect I don't think there is any interest in a non JSON = format. If WF as submitted goes forward then we would profile it down = for just JRD support.' > > > > I agree that it can be simpler and not require a new URI scheme. > > > > One reason for a JSON format in SWD is to allow for multiple links = per rel to be returned to an application for fault tolerance. > > > > For the unloved XRI spec there was a way to get the response in = HTML, and that was probably used as much and the XRDS format. > > > > I agree a html response format should be possible if not necessarily = the default. > > > > The question is if there is enough interest in the WG to rework the = basic design. > > > > The current WF draft is the path of least resistance. > > > > John B. > > > > On 2012-07-04, at 4:45 PM, James M Snell wrote: > > > >> The second issue here is the part about webfinger that bothers me = the > >> most... there really is no clear reason why XRD should be required > >> here. The additional indirection serves no significant valuable > >> purpose that I can determine. The Simple Web Discovery draft is = better > >> overall I think but much more can be done to simplify things and > >> provide a much more succinct and useful protocol. Simply because = XRD > >> is in use today by a few early adopters, there's absolutely no = reason > >> to rubber stamp it here. I appreciate those early adopters for = giving > >> a great demonstration of how it shouldn't be done. > >> > >> In my previous feedback, I've demonstrated that the same benefits = can > >> be achieved without the use of XRD at all... in fact, we can = achieve > >> exactly the same result and eliminate a good third of everything > >> that's discussed in the current WF draft... Using WF's own use = cases > >> from Section 4... > >> > >> Locating a user's blog... > >> > >> Assuming, for privacy purposes, we hash the acct id; and assuming = we > >> define "blog" as a Link Relation... > >> > >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/blog > >> Host: example.org > >> > >> HTTP/1.1 302 Found > >> Location: http://blogs.example.com/bob/ > >> Link: ; rel=3D"avatar", > >> ; = rel=3D"http://webfinger.net/rel/profile-page" > >> > >> Locating a user's contact info... > >> > >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/vcard > >> Host: example.org > >> > >> HTTP/1.1 200 OK > >> Context-Type: text/vcard > >> > >> {vcard data} > >> > >> Simplifying the Login Process > >> > >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/openid > >> Host: example.org > >> > >> HTTP/1.1 302 Found > >> Location: https://openid.example.com/carol > >> > >> Retrieving device info > >> > >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/tipsi > >> Host: example.org > >> > >> HTTP/1.1 302 Found > >> Location: http://192.168.1.5/npap/ > >> > >> > >> So in each case we achieve the same fundamental goal without the > >> additional indirection or use of XRD. A specific implementation = could > >> choose to use XRD if they'd like, but it shouldn't be a = requirement. > >> For instance, suppose... > >> > >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/xrd > >> Host: example.org > >> > >> HTTP/1.1 200 OK > >> Content-Type: application/json > >> > >> {...} > >> > >> Doing this would be an entirely optional implementation choice, > >> however. If I did, for instance... > >> > >> GET /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd > >> > >> Specifying no additional path, the server could very well just = forward > >> me on to an HTML representation of my profile that contains > >> microdata/RDFa properties I could harvest. The server should be > >> allowed to serve up whatever information it wants, in whatever = format > >> it wants; client applications will determine for themselves whether > >> that data is usable or not. Keeps the protocol, and the spec, as = drop > >> dead simple as possible. > >> > >> - James > >> > >> On Tue, Jul 3, 2012 at 6:59 PM, Phillip Hallam-Baker = wrote: > >>> I recall something rather different. I recall a claim that the IPR = was > >>> open when in fact the registry was to be operated on a commercial > >>> basis. > >>> > >>> This technology keeps appearing in specs without any apparent > >>> requirement to motivate it. In OpenID the only reason for =3DPhill = being > >>> required was that user@domain was not supported as we were told = that > >>> people wanted to use the URL of their blog. > >>> > >>> > >>> On Tue, Jul 3, 2012 at 7:53 PM, John Bradley = wrote: > >>>> I recall that there were strait answers and a meeting with the = OASIS lawyer on the topic back in the day. > >>>> > >>>> Not everyone trusted the answers apparently, but you can't make = everyone happy. > >>>> > >>>> The IPR you are concerned about related to XRI resolution and not = the XRDS or XRD XML document formats. > >>>> > >>>> There should be no more IPR concern than there is with other = OASIS specs like SAML. > >>>> > >>>> That said I am not advocating the use of XRD, SWD used a simple = link data type JSON format. > >>>> > >>>> The XRD and JRD format are heavily influenced by the link data = format if you look at it closely. > >>>> > >>>> Regards > >>>> John B. > >>>> > >>>> > >>>> > >>>> On 2012-07-03, at 6:29 PM, Phillip Hallam-Baker wrote: > >>>> > >>>>> What are the PR encumbrances of XRD? > >>>>> > >>>>> The XRI folk never gave me a straight answer, it is all tainted = until > >>>>> there is an explicit statement AFIK. > >>>>> > >>>>> On Tue, Jul 3, 2012 at 5:27 PM, James M Snell = wrote: > >>>>>> Great to see this conversation coming up... A couple of months = ago I > >>>>>> posted a few thoughts on WebFinger on my personal blog [1]... = I've > >>>>>> copied the relevant bits here for discussion. The short = summary: > >>>>>> WebFinger is ok but can be made so much simpler. > >>>>>> > >>>>>> [1] = http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html > >>>>>> > >>>>>> ... > >>>>>> Ok... so [WebFinger] seems simple enough, but can we make it = even > >>>>>> simpler? I think we definitely can. Let's start by eliminating = the > >>>>>> requirement to use XRD. Look at the first response... what is = the XRD > >>>>>> document giving us? A Link. One Link. Ok, not really a Link, = but a URI > >>>>>> Template. Wait, so that's two things we I actually need to = process > >>>>>> before I can actually look up information about the user = "bob"... > >>>>>> let's eliminate both of those things and simply provide a means = of > >>>>>> looking up information about the user directly.. for instance: > >>>>>> > >>>>>> GET /.well-known/finger/acct%3Abob%40example.org HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> If we still need to know things about the domain, then we can = finger > >>>>>> that domain... > >>>>>> > >>>>>> GET /.well-known/finger/example.org HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> But looking up basic information about the user should not be > >>>>>> predicated on first looking up basic information about the = domain. > >>>>>> Those can, and should, be two completely separate tasks. > >>>>>> > >>>>>> There is a problem here, however. A big problem actually. Many > >>>>>> enterprises frown on putting things that look like email = addresses > >>>>>> into URLs because of fairly significant privacy concerns. So = let's > >>>>>> change that, instead of passing the acct: ID directly, we'll = pass a > >>>>>> hash of the acct id.. much more secure and private that way... > >>>>>> > >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba = HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> Ah, that's better... and in the process I managed to eliminate = about a > >>>>>> third of what the WebFinger draft currently requires. > >>>>>> > >>>>>> It boils down to nothing more than this: > >>>>>> If I want to know something about user "bob@example.org", I = sent a GET > >>>>>> request to = http://example.org/.well-known/finger/{md5("bob@example.org")} > >>>>>> and see what I get back. No absolute need to parse any XML. No = need to > >>>>>> process any URI Templates. No need to define special query = string > >>>>>> parameters. Keep it very simple and we're essentially done. > >>>>>> > >>>>>> Ok, so what about the response from the server? What would that = look > >>>>>> like? Currently, WebFinger requires that the response has to = either be > >>>>>> XRD or this other thing called JRD. While I don't have any = problem > >>>>>> with using either of those particular formats, I do not believe = that > >>>>>> the WebFinger spec needs to declare that any format MUST be = supported. > >>>>>> It should be up to the server to provide whatever format it = wishes. > >>>>>> The client can determine if it's able to get what it's needs = from the > >>>>>> provided format or not. If the response is HTML and includes = Link or > >>>>>> Anchor elements that use appropriately labelled rel attribute = values, > >>>>>> then the client should be able to get the information it needs; = if the > >>>>>> response is JSON and includes appropriately labeled information = in a > >>>>>> way the client can understand, then great. That's what we have = things > >>>>>> like the Accept request header for... > >>>>>> > >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba = HTTP/1.1 > >>>>>> Host: example.org > >>>>>> Accept: application/xrd+xml, text/html, application/atom+xml > >>>>>> > >>>>>> The client can tell the server what format it would like and = the > >>>>>> server can respond appropriately. These mechanism are widely = used and > >>>>>> the abstract notion of a Link is fairly universal now and = easily > >>>>>> represented in multiple formats. > >>>>>> > >>>>>> The response to the above request could very well be as simple = as: > >>>>>> > >>>>>> HTTP/1.1 204 No Content > >>>>>> Link: ; rel=3D"blog", > >>>>>> ; rel=3D"profile", > >>>>>> ; rel=3D"avatar" > >>>>>> > >>>>>> Sure, this hypothetical type of response may be impractical if = a > >>>>>> particular user has a significantly large number of links = associated > >>>>>> with it, but (a) realistically most users won't have that many = at any > >>>>>> single service and (b) this is just an example, I did say that = I have > >>>>>> no problem with XRD/JRD being used... it just shouldn't be = required. > >>>>>> > >>>>>> Another possibility. Just to stretch the imagination a bit = more. > >>>>>> Suppose I want to know the location of the user's blog and I = send this > >>>>>> for a request: > >>>>>> > >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog = HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> Note the addition of the "/blog" at the end of the request URI. = Let's > >>>>>> just say that the last little bit there is a rel value. If the = user > >>>>>> has only a single rel=3D"blog" Link, then the server can tell = me where > >>>>>> it is with a simple redirect: > >>>>>> > >>>>>> HTTP/1.1 302 Found > >>>>>> Location: http://blogs.example.org/bob > >>>>>> > >>>>>> If there happen to be multiple "blog" links associated with = that > >>>>>> particular user, then the server can tell me about all of = them... > >>>>>> > >>>>>> HTTP/1.1 300 Multiple Choices > >>>>>> Location: http://blogs.example.org/bobs_default_blog > >>>>>> Link: ; rel=3D"blog",= > >>>>>> ; rel=3D"blog" > >>>>>> > >>>>>> What if I want to know about some other kind of Link associated = with > >>>>>> the user... well, I simply replace "/blog" with the other rel > >>>>>> attribute value... > >>>>>> > >>>>>> GET = /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> GET = /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/ > >>>>>> http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fprovider HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> Whatever specific link rel I want to know about, I just append = that to > >>>>>> the end. If I need to know about more than one, separate them = by a > >>>>>> comma: > >>>>>> > >>>>>> GET = /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard,avatar > >>>>>> HTTP/1.1 > >>>>>> Host: example.org > >>>>>> > >>>>>> Which could return something along the lines of... > >>>>>> > >>>>>> HTTP/1.1 300 Multiple Choices > >>>>>> Link: ; rel=3D"vcard", > >>>>>> ; rel=3D"avatar" > >>>>>> > >>>>>> Or it could return an XRD or JRD... either way, it works just = fine. > >>>>>> The point is that it's MUCH simpler than what WebFinger defines = and > >>>>>> requires fewer moving parts (no required XML parsing, no = required URI > >>>>>> Template processing, no required querystring parameters, etc). > >>>>>> > >>>>>> With regards to security considerations, the original Finger = protocol > >>>>>> was quite problematic because of the potential for = inappropriate > >>>>>> disclosure of sensitive information about an account. The same = basic > >>>>>> concern would be applicable to WebFinger depending on what = information > >>>>>> was being made available for discovery. I've already dealt with = one > >>>>>> particular concern -- the use of an email-like identifier = within the > >>>>>> discovery URI... requiring a hash is a simple fix there. But = what else > >>>>>> can be done? > >>>>>> > >>>>>> Well, obviously, we're talking about a HTTP request here. When = a > >>>>>> requester sends an unauthenticated HTTP request to discover > >>>>>> information about a user, the server can choose to respond with = only > >>>>>> the most basic generic and public information about the user = and > >>>>>> possibly some links to that user's public facing services = (their blog, > >>>>>> their avatar, etc). Mechanisms such as OAuth 2 can be employed, > >>>>>> however, to support much more interesting scenarios. For = instance, a > >>>>>> trusted third party could acquire an OAuth 2 access token to = request > >>>>>> additional, more detailed information about a user... > >>>>>> > >>>>>> GET /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog = HTTP/1.1 > >>>>>> Host: example.org > >>>>>> Authentication: Bearer {my_access_token} > >>>>>> > >>>>>> Such requests can be easily tracked, rate-limited, etc, making = the > >>>>>> protocol generally much more reliable and secure than the = original > >>>>>> finger protocol. Unfortunately, the current WebFinger = specification > >>>>>> does not adequately address this particular concern. > >>>>>> .... > >>>>>> > >>>>>> - James > >>>>>> > >>>>>> On Tue, Jul 3, 2012 at 12:24 AM, Mike Jones = wrote: > >>>>>>> You've essentially described Simple Web Discovery! It avoids = the complications introduced by host-meta exactly by using its own = .well-known value. The basic example is: > >>>>>>> > >>>>>>> GET = /.well-known/simple-web-discovery?principal=3Dmailto:joe@example.com&servi= ce=3Durn:example.org:service:calendar HTTP/1.1 > >>>>>>> Host: example.com > >>>>>>> > >>>>>>> HTTP/1.1 200 OK > >>>>>>> Content-Type: application/json > >>>>>>> > >>>>>>> { > >>>>>>> "locations": = ["http://calendars.example.net/calendars/joseph"] > >>>>>>> } > >>>>>>> > >>>>>>> See = http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 for more = details. By design, there aren't many... > >>>>>>> > >>>>>>> -- Mike > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mark Nottingham > >>>>>>> Sent: Monday, July 02, 2012 10:47 PM > >>>>>>> To: IETF Apps Discuss > >>>>>>> Subject: [apps-discuss] Looking at Webfinger > >>>>>>> > >>>>>>> I've pretty much ignored the whole webfinger / acct: / SWD = discussion (too much!). However, since it's apparent it may soon become = Real, I had a look. > >>>>>>> > >>>>>>> In a nutshell, my initial reaction is "It's Not Nearly As Bad = As I Thought It Would Be." :) > >>>>>>> > >>>>>>> With that in mind, a few questions / comments (I'll resist = going into editorial matters, for the time being): > >>>>>>> > >>>>>>> * First and foremost, why use host-meta? What value does = adding this extra step to the dance bring, beyond "We've defined it, = therefore we must use it?" > >>>>>>> > >>>>>>> As I think I've said many times before, the whole point of a = .well-known URI is to group like uses together, to avoid having a = "dictionary" resource that gets bloated with many application's = unrelated data, thereby overburdening clients with too much information = (especially when they're constrained, e.g., mobile). > >>>>>>> > >>>>>>> As such, host-meta is a spectacularly bad example of a = well-known URI. Defining a end-all-be-all well-known-URI kind of removes = the point of having a registry, after all... > >>>>>>> > >>>>>>> Instead, why not just define a NEW well-known URI for user = data? That has a more constrained scope, and saves one round trip (or = more). E.g., > >>>>>>> > >>>>>>> GET /.well-known/webfinger?user=3Dbob%40example.com HTTP/1.0 > >>>>>>> Host: example.com > >>>>>>> > >>>>>>> I.e., let webfinger define the URI template to use. Yes, some = implementations might want to come up with crazy URIs, but is that = really a problem we want to solve? > >>>>>>> > >>>>>>> Astute observers will notice that this approach removes the = need for an ACCT URI scheme (at least here). > >>>>>>> > >>>>>>> > >>>>>>> * What's the fascination with XRD and JRD? These = specifications seem to be creeping into IETF architecture; first it was = in a pure security context, but now folks are talking about using them = in a much more generic way, as a cornerstone of what we do. As such, I = think they deserve a MUCH closer look, especially since we're defining = things with "Web" in their name when the W3C has already defined = solutions in this space. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Mark Nottingham http://www.mnot.net/ > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Website: http://hallambaker.com/ > >>>>> _______________________________________________ > >>>>> apps-discuss mailing list > >>>>> apps-discuss@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss > >>>> > >>> > >>> > >>> > >>> -- > >>> Website: http://hallambaker.com/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 --Apple-Mail=_035EF547-71D0-4D44-9639-60D1484E5CC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 At = the moment we have WF adding query parameters to host-meta to avoid = multiple round trips in the case where you can have a dynamic = service.

The goal for SWD was to get the thing you = are looking for on the first try if possible.  If that is not = possible return a cacheable document that gives you the new base URL for = a second query.

Without the dynamic service = behind host-meta you get a template on the first try and then must = expand the template for your second try.   
You also = loose the ability to query for a specific rel  because there is = only one template parameter for the URL.

I = agree that host-meta makes sense for looking up host services.   = The question that some are asking is if using that as an extra = indirection for looking up end-user information is the best = approach.

Thanks for the = background.
John B.

On = 2012-07-04, at 6:16 PM, John Panzer wrote:

Just as a = historical note.  The envisioned usage of host-meta was originally = to avoid a specification which mandated a particular dynamic URL API at = a particular /.well-known endpoint (because it may not be feasible to do = that across all organizations and deployments).  The host-meta = document itself would be highly cacheable and so wouldn't incur an = additional network trip in the common case.

Having a 3xx redirect is a reasonable alternative that = allows a similar escape hatch via something like mod_rewrite, albeit at = the cost of needing an additional network trip each time.  Since a = deployment can always avoid the 3xx redirect with additional dynamic = plumbing behind the well-known endpoint, I don't think that's a horrible = thing.

An application-level redirect would be almost equivalent = to an HTTP redirect, but then there are two ways to do the same thing. =  If _only_ an application-level redirect is allowed, then you have = to have at least a minimal dynamic service at the well-known endpoint = (no more mod_rewrite).  But the whole reason for this is to avoid = the requirement for a dynamic service behind well-known...

--
John Panzer / = Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Wed, = Jul 4, 2012 at 2:33 PM, James M Snell <jasnell@gmail.com> wrote:
The redirect would not be strictly necessary. There'd be absolutely
nothing wrong with the host returning a document that allows for an
application-level redirect. The more important point is that the = model
can be greatly improved by not *requiring* the host-meta and
XRD-indirection.

On Wed, Jul 4, 2012 at 2:18 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> In some ways XRD is an artifact of trying to use host-meta.
>
> I agree that if starting from a clean sheet is possible then using = the SWD approach of
> having a specific .well-known location for discovery is better than = trying to overload host-meta with query parameters.
>
> I am personally fine with using a redirect, though I understand = there was push back in WF to that because not all hosting environments = support redirects.
> That was one reason why SWD supported a very basic application = level redirect.
>
> For openID Connect I don't think there is any interest in a non = JSON format.   If WF as submitted goes forward then we would = profile it down for just JRD support.'
>
> I agree that it can be simpler and not require a new URI = scheme.
>
> One reason for a JSON format in SWD is to allow for multiple links = per rel to be returned to an application for fault tolerance.
>
> For the unloved XRI spec there was a way to get the response in = HTML, and that was probably used as much and the XRDS format.
>
> I agree a html response format should be possible if not = necessarily the default.
>
> The question is if there is enough interest in the WG to rework the = basic design.
>
> The current WF draft is the path of least resistance.
>
> John B.
>
> On 2012-07-04, at 4:45 PM, James M Snell wrote:
>
>> The second issue here is the part about webfinger that bothers = me the
>> most... there really is no clear reason why XRD should be = required
>> here. The additional indirection serves no significant = valuable
>> purpose that I can determine. The Simple Web Discovery draft is = better
>> overall I think but much more can be done to simplify things = and
>> provide a much more succinct and useful protocol. Simply = because XRD
>> is in use today by a few early adopters, there's absolutely no = reason
>> to rubber stamp it here. I appreciate those early adopters for = giving
>> a great demonstration of how it shouldn't be done.
>>
>> In my previous feedback, I've demonstrated that the same = benefits can
>> be achieved without the use of XRD at all... in fact, we can = achieve
>> exactly the same result and eliminate a good third of = everything
>> that's discussed in the current WF draft... Using WF's own use = cases
>> from Section 4...
>>
>> Locating a user's blog...
>>
>> Assuming, for privacy purposes, we hash the acct id; and = assuming we
>> define "blog" as a Link Relation...
>>
>>  GET = /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/blog
>>  Host: example.org
>>
>>  HTTP/1.1 302 Found
>>  Location: http://blogs.example.com/bob/
>>  Link: <http://www.example.com/~bob/bob.jpg>; = rel=3D"avatar",
>>    <http://www.example.com/~bob/>; rel=3D"http://webfinger.net/rel/profile-page"
>>
>> Locating a user's contact info...
>>
>>  GET = /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/vcard
>>  Host: example.org
>>
>>  HTTP/1.1 200 OK
>>  Context-Type: text/vcard
>>
>>  {vcard data}
>>
>> Simplifying the Login Process
>>
>>  GET = /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/openid
>>  Host: example.org
>>
>>  HTTP/1.1 302 Found
>>  Location: https://openid.example.com/carol
>>
>> Retrieving device info
>>
>>  GET = /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/tipsi
>>  Host: example.org
>>
>>  HTTP/1.1 302 Found
>>  Location: http://192.168.1.5/npap/
>>
>>
>> So in each case we achieve the same fundamental goal without = the
>> additional indirection or use of XRD. A specific implementation = could
>> choose to use XRD if they'd like, but it shouldn't be a = requirement.
>> For instance, suppose...
>>
>>  GET = /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd/xrd
>>  Host: example.org
>>
>>  HTTP/1.1 200 OK
>>  Content-Type: application/json
>>
>>  {...}
>>
>> Doing this would be an entirely optional implementation = choice,
>> however. If I did, for instance...
>>
>>  GET = /.well-known/finger/fc5e68b29fa1d255bd038a167ca0b9bd
>>
>> Specifying no additional path, the server could very well just = forward
>> me on to an HTML representation of my profile that contains
>> microdata/RDFa properties I could harvest. The server should = be
>> allowed to serve up whatever information it wants, in whatever = format
>> it wants; client applications will determine for themselves = whether
>> that data is usable or not. Keeps the protocol, and the spec, = as drop
>> dead simple as possible.
>>
>> - James
>>
>> On Tue, Jul 3, 2012 at 6:59 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>>> I recall something rather different. I recall a claim that = the IPR was
>>> open when in fact the registry was to be operated on a = commercial
>>> basis.
>>>
>>> This technology keeps appearing in specs without any = apparent
>>> requirement to motivate it. In OpenID the only reason for = =3DPhill being
>>> required was that user@domain was not supported as we were = told that
>>> people wanted to use the URL of their blog.
>>>
>>>
>>> On Tue, Jul 3, 2012 at 7:53 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>>> I recall that there were strait answers and a meeting = with the OASIS lawyer on the topic back in the day.
>>>>
>>>> Not everyone trusted the answers apparently,  but = you can't make everyone happy.
>>>>
>>>> The IPR you are concerned about related to XRI = resolution and not the XRDS or XRD XML document formats.
>>>>
>>>> There should be no more IPR concern than there is with = other OASIS specs like SAML.
>>>>
>>>> That said I am not advocating the use of XRD,  SWD = used a simple link data type JSON format.
>>>>
>>>> The XRD and JRD format are heavily influenced by the = link data format if you look at it closely.
>>>>
>>>> Regards
>>>> John B.
>>>>
>>>>
>>>>
>>>> On 2012-07-03, at 6:29 PM, Phillip Hallam-Baker = wrote:
>>>>
>>>>> What are the PR encumbrances of XRD?
>>>>>
>>>>> The XRI folk never gave me a straight answer, it is = all tainted until
>>>>> there is an explicit statement AFIK.
>>>>>
>>>>> On Tue, Jul 3, 2012 at 5:27 PM, James M Snell = <jasnell@gmail.com> = wrote:
>>>>>> Great to see this conversation coming up... A = couple of months ago I
>>>>>> posted a few thoughts on WebFinger on my = personal blog [1]... I've
>>>>>> copied the relevant bits here for discussion. = The short summary:
>>>>>> WebFinger is ok but can be made so much = simpler.
>>>>>>
>>>>>> [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-web= finger.html
>>>>>>
>>>>>> ...
>>>>>> Ok... so [WebFinger] seems simple enough, but = can we make it even
>>>>>> simpler? I think we definitely can. Let's start = by eliminating the
>>>>>> requirement to use XRD. Look at the first = response... what is the XRD
>>>>>> document giving us? A Link. One Link. Ok, not = really a Link, but a URI
>>>>>> Template. Wait, so that's two things we I = actually need to process
>>>>>> before I can actually look up information about = the user "bob"...
>>>>>> let's eliminate both of those things and simply = provide a means of
>>>>>> looking up information about the user = directly.. for instance:
>>>>>>
>>>>>> GET /.well-known/finger/acct%3Abob%40example.org = HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>> If we still need to know things about the = domain, then we can finger
>>>>>> that domain...
>>>>>>
>>>>>> GET /.well-known/finger/example.org = HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>> But looking up basic information about the user = should not be
>>>>>> predicated on first looking up basic = information about the domain.
>>>>>> Those can, and should, be two completely = separate tasks.
>>>>>>
>>>>>> There is a problem here, however. A big problem = actually. Many
>>>>>> enterprises frown on putting things that look = like email addresses
>>>>>> into URLs because of fairly significant privacy = concerns. So let's
>>>>>> change that, instead of passing the acct: ID = directly, we'll pass a
>>>>>> hash of the acct id.. much more secure and = private that way...
>>>>>>
>>>>>> GET = /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>> Ah, that's better... and in the process I = managed to eliminate about a
>>>>>> third of what the WebFinger draft currently = requires.
>>>>>>
>>>>>> It boils down to nothing more than this:
>>>>>> If I want to know something about user "bob@example.org", I sent a GET
>>>>>> request to http://example.org/.well-known/finger/{md5("bob@example.org")}
>>>>>> and see what I get back. No absolute need to = parse any XML. No need to
>>>>>> process any URI Templates. No need to define = special query string
>>>>>> parameters. Keep it very simple and we're = essentially done.
>>>>>>
>>>>>> Ok, so what about the response from the server? = What would that look
>>>>>> like? Currently, WebFinger requires that the = response has to either be
>>>>>> XRD or this other thing called JRD. While I = don't have any problem
>>>>>> with using either of those particular formats, = I do not believe that
>>>>>> the WebFinger spec needs to declare that any = format MUST be supported.
>>>>>> It should be up to the server to provide = whatever format it wishes.
>>>>>> The client can determine if it's able to get = what it's needs from the
>>>>>> provided format or not. If the response is HTML = and includes Link or
>>>>>> Anchor elements that use appropriately labelled = rel attribute values,
>>>>>> then the client should be able to get the = information it needs; if the
>>>>>> response is JSON and includes appropriately = labeled information in a
>>>>>> way the client can understand, then great. = That's what we have things
>>>>>> like the Accept request header for...
>>>>>>
>>>>>> GET = /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba HTTP/1.1
>>>>>> Host: example.org
>>>>>> Accept: application/xrd+xml, text/html, = application/atom+xml
>>>>>>
>>>>>> The client can tell the server what format it = would like and the
>>>>>> server can respond appropriately. These = mechanism are widely used and
>>>>>> the abstract notion of a Link is fairly = universal now and easily
>>>>>> represented in multiple formats.
>>>>>>
>>>>>> The response to the above request could very = well be as simple as:
>>>>>>
>>>>>> HTTP/1.1 204 No Content
>>>>>> Link: <http://blogs.example.org/bob/>; rel=3D"blog",
= >>>>>>   <http://example.org/profiles/bob>; = rel=3D"profile",
>>>>>>   <http://example.org/profiles/avatar>; = rel=3D"avatar"
>>>>>>
>>>>>> Sure, this hypothetical type of response may be = impractical if a
>>>>>> particular user has a significantly large = number of links associated
>>>>>> with it, but (a) realistically most users won't = have that many at any
>>>>>> single service and (b) this is just an example, = I did say that I have
>>>>>> no problem with XRD/JRD being used... it just = shouldn't be required.
>>>>>>
>>>>>> Another possibility. Just to stretch the = imagination a bit more.
>>>>>> Suppose I want to know the location of the = user's blog and I send this
>>>>>> for a request:
>>>>>>
>>>>>> GET = /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>> Note the addition of the "/blog" at the end of = the request URI. Let's
>>>>>> just say that the last little bit there is a = rel value. If the user
>>>>>> has only a single rel=3D"blog" Link, then the = server can tell me where
>>>>>> it is with a simple redirect:
>>>>>>
>>>>>> HTTP/1.1 302 Found
>>>>>> Location: http://blogs.example.org/bob
>>>>>>
>>>>>> If there happen to be multiple "blog" links = associated with that
>>>>>> particular user, then the server can tell me = about all of them...
>>>>>>
>>>>>> HTTP/1.1 300 Multiple Choices
>>>>>> Location: http://blogs.example.org/bobs_default_blog
>>>>>> Link: <http://blogs.example.org/bobs_default_blog>; = rel=3D"blog",
>>>>>>   <http://blogs.example.org/bobs_other_blog>; = rel=3D"blog"
>>>>>>
>>>>>> What if I want to know about some other kind of = Link associated with
>>>>>> the user... well, I simply replace "/blog" with = the other rel
>>>>>> attribute value...
>>>>>>
>>>>>>   GET = /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>>   GET = /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>>   GET = /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/
>>>>>> http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fprovider = HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>> Whatever specific link rel I want to know = about, I just append that to
>>>>>> the end. If I need to know about more than one, = separate them by a
>>>>>> comma:
>>>>>>
>>>>>>   GET = /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/vcard,avatar
>>>>>> HTTP/1.1
>>>>>> Host: example.org
>>>>>>
>>>>>> Which could return something along the lines = of...
>>>>>>
>>>>>> HTTP/1.1 300 Multiple Choices
>>>>>> Link: <http://example.org/bob.vcard>; rel=3D"vcard",
= >>>>>>   <http://example.org/bob.jpg>; rel=3D"avatar"
>>>>>>
>>>>>> Or it could return an XRD or JRD... either way, = it works just fine.
>>>>>> The point is that it's MUCH simpler than what = WebFinger defines and
>>>>>> requires fewer moving parts (no required XML = parsing, no required URI
>>>>>> Template processing, no required querystring = parameters, etc).
>>>>>>
>>>>>> With regards to security considerations, the = original Finger protocol
>>>>>> was quite problematic because of the potential = for inappropriate
>>>>>> disclosure of sensitive information about an = account.  The same basic
>>>>>> concern would be applicable to WebFinger = depending on what information
>>>>>> was being made available for discovery. I've = already dealt with one
>>>>>> particular concern -- the use of an email-like = identifier within the
>>>>>> discovery URI... requiring a hash is a simple = fix there. But what else
>>>>>> can be done?
>>>>>>
>>>>>> Well, obviously, we're talking about a HTTP = request here. When a
>>>>>> requester sends an unauthenticated HTTP request = to discover
>>>>>> information about a user, the server can choose = to respond with only
>>>>>> the most basic generic and public information = about the user and
>>>>>> possibly some links to that user's public = facing services (their blog,
>>>>>> their avatar, etc). Mechanisms such as OAuth 2 = can be employed,
>>>>>> however, to support much more interesting = scenarios. For instance, a
>>>>>> trusted third party could acquire an OAuth 2 = access token to request
>>>>>> additional, more detailed information about a = user...
>>>>>>
>>>>>> GET = /.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog HTTP/1.1
>>>>>> Host: example.org
>>>>>> Authentication: Bearer {my_access_token}
>>>>>>
>>>>>> Such requests can be easily tracked, = rate-limited, etc, making the
>>>>>> protocol generally much more reliable and = secure than the original
>>>>>> finger protocol. Unfortunately, the current = WebFinger specification
>>>>>> does not adequately address this particular = concern.
>>>>>> ....
>>>>>>
>>>>>> - James
>>>>>>
>>>>>> On Tue, Jul 3, 2012 at 12:24 AM, Mike Jones = <Michael.Jones@microsoft.com> wrote:
>>>>>>> You've essentially described Simple Web = Discovery!  It avoids the complications introduced by host-meta = exactly by using its own .well-known value.  The basic example = is:
>>>>>>>
>>>>>>>  GET = /.well-known/simple-web-discovery?principal=3Dmailto:joe@example.com&service=3Durn:exam= ple.org:service:calendar HTTP/1.1
>>>>>>>  Host: example.com
>>>>>>>
>>>>>>>  HTTP/1.1 200 OK
>>>>>>>  Content-Type: application/json
>>>>>>>
>>>>>>>  {
>>>>>>>   "locations": ["http://calendars.example.net/calendars/joseph"]
>>>>>>>  }
>>>>>>>
>>>>>>> See http://tools.ietf.org/html/draft-jones-simple-web-discov= ery-02 for more details.  By design, there aren't many...
>>>>>>>
>>>>>>>             =                   -- = Mike
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: apps-discuss-bounces@ietf.or= g [mailto:apps-discuss-bounces@ietf.or= g] On Behalf Of Mark Nottingham
>>>>>>> Sent: Monday, July 02, 2012 10:47 PM
>>>>>>> To: IETF Apps Discuss
>>>>>>> Subject: [apps-discuss] Looking at = Webfinger
>>>>>>>
>>>>>>> I've pretty much ignored the whole = webfinger / acct: / SWD discussion (too much!). However, since it's = apparent it may soon become Real, I had a look.
>>>>>>>
>>>>>>> In a nutshell, my initial reaction is "It's = Not Nearly As Bad As I Thought It Would Be." :)
>>>>>>>
>>>>>>> With that in mind, a few questions / = comments (I'll resist going into editorial matters, for the time = being):
>>>>>>>
>>>>>>> * First and foremost, why use host-meta? = What value does adding this extra step to the dance bring, beyond "We've = defined it, therefore we must use it?"
>>>>>>>
>>>>>>> As I think I've said many times before, the = whole point of a .well-known URI is to group like uses together, to = avoid having a "dictionary" resource that gets bloated with many = application's unrelated data, thereby overburdening clients with too = much information (especially when they're constrained, e.g., = mobile).
>>>>>>>
>>>>>>> As such, host-meta is a spectacularly bad = example of a well-known URI. Defining a end-all-be-all well-known-URI = kind of removes the point of having a registry, after all...
>>>>>>>
>>>>>>> Instead, why not just define a NEW = well-known URI for user data? That has a more constrained scope, and = saves one round trip (or more). E.g.,
>>>>>>>
>>>>>>> GET /.well-known/webfinger?user=3Dbob%40example.com = HTTP/1.0
>>>>>>> Host: example.com
>>>>>>>
>>>>>>> I.e., let webfinger define the URI template = to use. Yes, some implementations might want to come up with crazy URIs, = but is that really a problem we want to solve?
>>>>>>>
>>>>>>> Astute observers will notice that this = approach removes the need for an ACCT URI scheme (at least here).
>>>>>>>
>>>>>>>
>>>>>>> * What's the fascination with XRD and JRD? = These specifications seem to be creeping into IETF architecture; first = it was in a pure security context, but now folks are talking about using = them in a much more generic way, as a cornerstone of what we do. As = such, I think they deserve a MUCH closer look, especially since we're = defining things with "Web" in their name when the W3C has already = defined solutions in this space.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mark Nottingham   http://www.mnot.net/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> = _______________________________________________
>>>>>>> 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 >>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Website: http://hallambaker.com/
>>>>> _______________________________________________
>>>>> apps-discuss mailing list
>>>>> apps-discuss@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>
>>>
>>>
>>>
>>> --
>>> Website: http://hallambaker.com/
>
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


= --Apple-Mail=_035EF547-71D0-4D44-9639-60D1484E5CC8-- --Apple-Mail=_C5DC2F63-8E25-4EE5-9E7A-B64658AB26F3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw NDIyNDIwNFowIwYJKoZIhvcNAQkEMRYEFLGDQS6Bb44FDKUowVdqPBw9ojaEMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AE502oE8HzGcLmbuhPyBHWQ5WqIGhWS3B5dMYsbrqUOpZVeiplmLHvXLu9OJF6jQQJRcqdtjs5vq sMFQrT9WjXtfcl/ha+hux6iji2QWlVYsji6t2/mmXIbMoxXAjbaubH2zfg0F8MXgcnr4v6te21zN XeioBBb9z0xlGRZVg8bdOvPKlsxTds2s3nw/zRJjPVnB7kRbdfcg1s67+tutOVJs9QgtwuHBxCSH aZrSdx7bOI5c+timiHOTdWis4g3mp6TrLC44y/gduGiJs9fvnwv2/pfSRJfvrRhCeJ2ZlXymMm5o YfoQBD8MpvyyQFFmt9Rs8w80IeDI4wOxhniu1XMAAAAAAAA= --Apple-Mail=_C5DC2F63-8E25-4EE5-9E7A-B64658AB26F3-- From jpanzer@google.com Wed Jul 4 15:58:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F4911E8085 for ; Wed, 4 Jul 2012 15:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.909 X-Spam-Level: X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAN6VPlsUDcC for ; Wed, 4 Jul 2012 15:58:37 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDC511E8086 for ; Wed, 4 Jul 2012 15:58:37 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so12021438pbc.31 for ; Wed, 04 Jul 2012 15:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=u0AbXFQB6NQq1w/3sXIKmGEQrMvMOBkxda30ld5t36A=; b=MWVqk5IXUb/h4rO0TT0fgAlbKni08/Z+G4Gk193TDWlqp5g/jCNa9gMGyoTsW3E6aj hVUBPXTlXwMc4/djBjr2T22XBZijp+R+bf0hrtQK1eFroSNw+S0mXpIPrDmeiOEocx2O sxpCUUyWN1nj7pZGNzerJPAhWzyDMl+SXnUOR//agwap73YaEfAMhFV0X+mJMdfeI98/ J7gS11qOhjxRuSIHVYqdlB67Ukl0aT+CesvM53fY24Clt4cGVFFbFDk0a7fYuuOhLS7m Pd6mFkxDPH2uTw3tqrYPG8SlC7nXBxCLtjwE5UwdTfHyePAsQporL4Q4DFThs3T7DFZl XZZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=u0AbXFQB6NQq1w/3sXIKmGEQrMvMOBkxda30ld5t36A=; b=QcT9irjyywJfaCCeQFlCZdpuk3xCRhcLymxMKTrIwaw4ER1YyTwtvPEkaAOJhW5Di/ W9jfJMKmmmR1hubn/fNoHYpNinajWH5Erbb4jUSiYPlfTXWfXlPZEsIjAxlcmm5F3hVB OfeoaWMhGW9VD7MF6wjf0bUo5akhu0Zv46iHe62OCGLgtbzSOZO/P6pn4/NFTF9uvpvf IGCoDfzRivF8qBL18WIYuiojYaNrLsQ5YuZhEk5jKvTlzph4f7ByOgGfQKKBXXEP3nXu Mv9ZPC9aqbg3ohMnSnnnHlnIEPJyA64V55x00t59gdsBGTWOHSgjMMi5iSUEHpW1pxUQ Lrtw== Received: by 10.66.72.136 with SMTP id d8mr32725160pav.21.1341442729092; Wed, 04 Jul 2012 15:58:49 -0700 (PDT) Received: by 10.66.72.136 with SMTP id d8mr32725142pav.21.1341442728905; Wed, 04 Jul 2012 15:58:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.58.69 with HTTP; Wed, 4 Jul 2012 15:58:28 -0700 (PDT) In-Reply-To: <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net> References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net> From: John Panzer Date: Wed, 4 Jul 2012 15:58:28 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=f46d042f978e57cd9f04c408f9a7 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkRjyWtfdefEVUrCuQsFIpSI7fk/2neWGWfjcyugQRrivMqh0LmlPH6V8pqlGcxQnntqAsgNH2e10wgt8mwLmsb4b/uFLvzjSGGUsWEzklctmC5JMSonm1jfzSDQiTuXqhKHDNkcct8SP+k3Wnlyp5L7mQrsKcd2fVH5tiaRRCY6W2zdAzIBDSnG/sEZ0z4Ybwm4oe2 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2012 22:58:38 -0000 --f46d042f978e57cd9f04c408f9a7 Content-Type: text/plain; charset=ISO-8859-1 Mark -- Of course I was speaking about practical realities of typical web server administration and deployment. In practical terms, adding a new mod_rewrite rule or moral equivalent is going to be easier than adding a new PHP script that connects to a database. The latter is just always going to be a much higher bar. And, something that returns per-user data is generally going to need a dynamic service of some kind, unless your site has just a handful of users and you don't mind going through a publishing exercise each time you add or change a user... None of this has anything to do with the interface, just deployment realities. And in reality all of this is going to need a dynamic service somewhere for each non-trivial site, this is all just a question of how to hook it up. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham wrote: > On 05/07/2012, at 8:16 AM, John Panzer wrote: > > > Just as a historical note. The envisioned usage of host-meta was > originally to avoid a specification which mandated a particular dynamic URL > API at a particular /.well-known endpoint (because it may not be feasible > to do that across all organizations and deployments). The host-meta > document itself would be highly cacheable and so wouldn't incur an > additional network trip in the common case. > > > > Having a 3xx redirect is a reasonable alternative that allows a similar > escape hatch via something like mod_rewrite, albeit at the cost of needing > an additional network trip each time. Since a deployment can always avoid > the 3xx redirect with additional dynamic plumbing behind the well-known > endpoint, I don't think that's a horrible thing. > > > > An application-level redirect would be almost equivalent to an HTTP > redirect, but then there are two ways to do the same thing. If _only_ an > application-level redirect is allowed, then you have to have at least a > minimal dynamic service at the well-known endpoint (no more mod_rewrite). > But the whole reason for this is to avoid the requirement for a dynamic > service behind well-known... > > "dynamic" and "static" are properties of the implementation, not the > interface. HTTP doesn't require that any particular URL be "dynamic"; > anything can, with the right metadata, be cached (and indeed, I've cached > many, many things with the wrong metadata, because of silly site operators > and their ideas about "dynamic"). > > Now, if people want to target a particular implementation that makes it > easier to serve a particular style of URL without writing code, fine, but > let's not confuse things. > > E.g., a URL like > > http://example.com/.well-known/user/bob > > is easy to serve in pretty much any way you like with Apache. > > I'm also going to push back on the "it may not be feasible to do that > across all organizations and deployments" motivation. This is a race to the > bottom. The trick is to make it accessible enough to get sufficient > traction to pull everyone along, without pandering to *everyone*'s > requirements. > > Regards, > > -- > Mark Nottingham http://www.mnot.net/ > > > > --f46d042f978e57cd9f04c408f9a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark -- Of course I was speaking about practical realities of typical web s= erver administration and deployment. =A0In practical terms, adding a new mo= d_rewrite rule or moral equivalent is going to be easier than adding a new = PHP script that connects to a database. =A0The latter is just always going = to be a much higher bar.

And, something that returns per-user data is generally going= to need a dynamic service of some kind, unless your site has just a handfu= l of users and you don't mind going through a publishing exercise each = time you add or change a user...

None of this has anything to do with the interface, jus= t deployment realities. =A0And in reality all of this is going to need a dy= namic service somewhere for each non-trivial site, this is all just a quest= ion of how to hook it up.

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org= / @jpanzer



On Wed, Jul 4= , 2012 at 3:36 PM, Mark Nottingham <mnot@mnot.net> wrote:
On 05/07/2012, at 8:16 AM, John Panzer wrote:

> Just as a historical note. =A0The envisioned usage of host-meta was or= iginally to avoid a specification which mandated a particular dynamic URL A= PI at a particular /.well-known endpoint (because it may not be feasible to= do that across all organizations and deployments). =A0The host-meta docume= nt itself would be highly cacheable and so wouldn't incur an additional= network trip in the common case.
>
> Having a 3xx redirect is a reasonable alternative that allows a simila= r escape hatch via something like mod_rewrite, albeit at the cost of needin= g an additional network trip each time. =A0Since a deployment can always av= oid the 3xx redirect with additional dynamic plumbing behind the well-known= endpoint, I don't think that's a horrible thing.
>
> An application-level redirect would be almost equivalent to an HTTP re= direct, but then there are two ways to do the same thing. =A0If _only_ an a= pplication-level redirect is allowed, then you have to have at least a mini= mal dynamic service at the well-known endpoint (no more mod_rewrite). =A0Bu= t the whole reason for this is to avoid the requirement for a dynamic servi= ce behind well-known...

"dynamic" and "static" are properties of the impl= ementation, not the interface. HTTP doesn't require that any particular= URL be "dynamic"; anything can, with the right metadata, be cach= ed (and indeed, I've cached many, many things with the wrong metadata, = because of silly site operators and their ideas about "dynamic").=

Now, if people want to target a particular implementation that makes it eas= ier to serve a particular style of URL without writing code, fine, but let&= #39;s not confuse things.

E.g., a URL like

http:= //example.com/.well-known/user/bob

is easy to serve in pretty much any way you like with Apache.

I'm also going to push back on the "it may not be feasible to do t= hat across all organizations and deployments" motivation. This is a ra= ce to the bottom. The trick is to make it accessible enough to get sufficie= nt traction to pull everyone along, without pandering to *everyone*'s r= equirements.

Regards,

--
Mark Nottingham =A0 http= ://www.mnot.net/




--f46d042f978e57cd9f04c408f9a7-- From duerst@it.aoyama.ac.jp Wed Jul 4 17:48:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664E521F8539 for ; Wed, 4 Jul 2012 17:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.546 X-Spam-Level: X-Spam-Status: No, score=-99.546 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb6x+Mt6jAG4 for ; Wed, 4 Jul 2012 17:48:58 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id D3C6121F8534 for ; Wed, 4 Jul 2012 17:48:56 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q650mvfW012251 for ; Thu, 5 Jul 2012 09:48:58 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 141e_776b_3432e894_c63b_11e1_a781_001d096c5782; Thu, 05 Jul 2012 09:48:57 +0900 Received: from [IPv6:::1] ([133.2.210.1]:39372) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 5 Jul 2012 09:49:01 +0900 Message-ID: <4FF4E474.6080608@it.aoyama.ac.jp> Date: Thu, 05 Jul 2012 09:48:52 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Melvin Carvalho References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <1A87B9DE-ECEC-4F07-8734-131D4BB564EB@ve7jtb.com> <911C1091-6D88-4937-BF4C-0FCB264B6AEF@ve7jtb.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 00:48:59 -0000 On 2012/07/05 4:05, Melvin Carvalho wrote: > One question I've been thinking about. Does the acct: scheme also apply to > subdomains too, or just the parent domain, or only where an email exists? > > For example, are the following four, equivalent ways to describe an account? > > acct:bob@facebook.com > acct:bob@www.facebook.com > acct:bob@graph.facebook.com > https://graph.facebook.com/bob In general, no. If you know a lot about facebook, and you trust them that they won't change things, you might be able to infer that the account or person behind these URIs is one and the same, but that would be at your own risk, and may depend on what exactly you are trying to do. Regards, Martin. From mnot@mnot.net Wed Jul 4 18:52:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101CC11E8079 for ; Wed, 4 Jul 2012 18:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.313 X-Spam-Level: X-Spam-Status: No, score=-105.313 tagged_above=-999 required=5 tests=[AWL=-2.714, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-r6Kh0Mlfwx for ; Wed, 4 Jul 2012 18:52:17 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5E87C11E8073 for ; Wed, 4 Jul 2012 18:52:17 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E8E8022E257; Wed, 4 Jul 2012 21:52:22 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: Date: Thu, 5 Jul 2012 11:52:19 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <4CA6B596-424C-4A60-954F-8E7F18272EA6@mnot.net> References: <20120704002826.31184.30649.idtracker@ietfa.amsl.com> <647904D2-D497-4E54-9CBB-7E636F2E9F7D@mnot.net> To: mike amundsen X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-http-problem-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 01:52:18 -0000 On 04/07/2012, at 3:54 PM, mike amundsen wrote: > > A registered value of "error" might be preferable to using = "describedby"; esp for machine clients that might encounter = "describedby" in other contexts. >=20 > That was some of the feedback I got pre-draft, and I agree that a = different relation might be better. I'm not sure about "error" because = it might be misinterpreted; was maybe thinking about a simple = "problem-detail" or "problem-type" (because the detail is the *whole* = set of details about the type *and* instance of the problem). >=20 > What misinterpretation of "error" do you foresee? I want to avoid encouraging people to see the format as the indication = of the error -- that is and always should be the status code. > Can you help me get a better handle on the difference you have in mind = between "detail" and "type" and/or "type" and" instance" here? I see two things - 1. Identifying the nature of the problem (e.g. from the draft - "out = of credit"). This is *why* the status code (in this case, 403 Forbidden) = was generated, but not specific to this instance of the problem -- many = people can get "out of credit" and get the same machine-readable = identifier. 2. Identifying the instance of the problem (e.g., when it happened to = bob when his account was low last Thursday). #1 is already covered (although we're talking about changing its name). #2 isn't yet. I'm not convinced that it should be part of the "core"; = making links to errors available exposes a LOT of sensitive information, = potentially, and it's at best a convenience. The most common case for = identifying the instance of an error, AIUI, is to allow a user to quote = that to support, so they can dig into why it happened; however, a = service doesn't necessarily need that (e.g., if they track errors by = user, it's just a matter of looking up recent errors for that user). Of course, a particular problem type, or deployment of it, could extend = to offer such a link. > > Also, I've found using a "code" property has been helpful for = machine clients as this will be static no matter the language used to = express the title text >=20 > That's the function that the URI has in mine. >=20 > So the content at the other end of URI "z" will always be the same = content, no matter the app using this URI, or the specifics that = _caused_ the "problem", right? Yes. > FWIW, in my current usage, the href points to a record that is = specific to the immediate problem. This means it is possible that the = server will create and collect error logging information at these URIs. >=20 > I assume that possibility is not accounted for in your baseline = design. No. See above. Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Jul 4 18:59:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9E021F850C for ; Wed, 4 Jul 2012 18:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.289 X-Spam-Level: X-Spam-Status: No, score=-105.289 tagged_above=-999 required=5 tests=[AWL=-2.690, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1phnjfS-GHJN for ; Wed, 4 Jul 2012 18:59:30 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2460821F8508 for ; Wed, 4 Jul 2012 18:59:30 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7B22222E253; Wed, 4 Jul 2012 21:59:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4FF3F807.8080508@berkeley.edu> Date: Thu, 5 Jul 2012 11:59:32 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <191C54A5-7412-49CB-9DCC-793AB7860B01@mnot.net> References: <20120703004409.1599.57166.idtracker@ietfa.amsl.com> <5976E21A-81BC-4576-8609-B2C04C218C10@mnot.net> <4FF24F6D.7050807@berkeley.edu> <158A57BD-6421-4587-B90A-F8E1C98FFC5B@mnot.net> <4FF2BABF.8090003@ninebynine.org> <4FF3F807.8080508@berkeley.edu> To: Erik Wilde X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss , Graham Klyne Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-link-template-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 01:59:30 -0000 On 04/07/2012, at 6:00 PM, Erik Wilde wrote: > so a question i am interested in looking at would be the following: = would it make sense to consider a "URI parameter registry", so that = syntax and semantics of URI template parameters could be made reusable = across media types and/or link relations? I don't think so. The intuitive thing, to me, is to be able to map them = to URIs somehow. -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Jul 4 19:28:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676CE21F84F8 for ; Wed, 4 Jul 2012 19:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.265 X-Spam-Level: X-Spam-Status: No, score=-105.265 tagged_above=-999 required=5 tests=[AWL=-2.666, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djvZFmOuxcUe for ; Wed, 4 Jul 2012 19:28:31 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BC2BD21F84D0 for ; Wed, 4 Jul 2012 19:28:31 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DDB5722E256 for ; Wed, 4 Jul 2012 22:28:37 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jul 2012 12:28:34 +1000 References: <20120705022204.29179.82506.idtracker@ietfa.amsl.com> To: IETF Apps Discuss Message-Id: <87D923B1-0931-4336-ABF1-A5D1B0C495BE@mnot.net> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-json-home-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 02:28:32 -0000 Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-json-home-01.txt > Date: 5 July 2012 12:22:04 PM AEST > To: mnot@mnot.net >=20 >=20 > A new version of I-D, draft-nottingham-json-home-01.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Filename: draft-nottingham-json-home > Revision: 01 > Title: Home Documents for HTTP APIs > Creation date: 2012-07-05 > WG ID: Individual Submission > Number of pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-nottingham-json-home-01.txt > Status: = http://datatracker.ietf.org/doc/draft-nottingham-json-home > Htmlized: = http://tools.ietf.org/html/draft-nottingham-json-home-01 > Diff: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-nottingham-json-home-01 >=20 > Abstract: > This document proposes a "home document" format for non-browser HTTP > clients. >=20 >=20 >=20 >=20 > The IETF Secretariat -- Mark Nottingham http://www.mnot.net/ From paulej@packetizer.com Wed Jul 4 20:23:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B55811E8080 for ; Wed, 4 Jul 2012 20:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2G7AKNoqZux for ; Wed, 4 Jul 2012 20:23:15 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2392021F8483 for ; Wed, 4 Jul 2012 20:23:15 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q653NO15024025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jul 2012 23:23:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341458605; bh=4WySoX0wTxqXroumCPVtSeYZBiGjMt/2IHmKlHKRh5c=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ALczUVdV5mAoiZfb7cUr/G4r9K/cqm1FD5b/iDQMZ0dGF2fyd9xnLk2SYGOkowuCb IrFtWKCnJe/ly/X7YBINa1Dxb04re+ahCXgqeA8bCePkU6Ye7BxeKcTTIdgKHgSxnQ cHQhYm9LEldbXld/opB7kPZ0577NcfdQbXqrajYM= From: "Paul E. Jones" To: "'Mark Nottingham'" , "'IETF Apps Discuss'" References: In-Reply-To: Date: Wed, 4 Jul 2012 23:23:32 -0400 Message-ID: <067f01cd5a5d$8edd2b50$ac9781f0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFb3Wt68HpLZ7ZyHnoKMrZHlzcyBZf85hdA Content-Language: en-us Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 03:23:16 -0000 Mark, WebFinger has been around now for a few years. This most recent effort is one of formally documenting it. The plan for a long time has been that discovering information about users or entities on the Internet would be via host-meta and, more specifically, Link-based Resource Descriptor Documents (LRDD). XRD was created for this purpose, which is why we see it used in this document. JRD was subsequently introduced as RFC 6415 was developed. While LRDD is still present on the server side, the most recent version of the WebFinger spec effectively hides that via the "resource" parameter. So, it's not really that we're building upon host-meta, but really that we're formally documenting the procedures that were laid down long ago. WebFinger and host-meta was moving along together. What I find most attractive about the approach taken is the consistency and the fit with the web linking work that you did, essentially serving up a set of link relations related to the entity that is queried. WebFinger will serve up an XRD or JRD document, as desired by the client, that contains a list of link relations that allow one to convey through those relations all sorts of information about the entity being queried. That might be a vCard, portable contacts, OpenID identifier, mail server configuration, or other. Another thing I find attractive is the consistency in the approach to discovery. Regardless of the URI, I can query for information in precisely the same way. It might be an acct URI, a mailto URI, an HTTP URI, etc. If I want to discover information about acct:paulej@packetizer.com or http://www.packetizer.com/people/paulej, I can use the same discovery mechanism. In this case, the server might even be configured to return the same set of information of both identifiers refer to the same entity. In any case, it is important to allow for discovery of entities on the Internet that are not necessarily users, but any URI. Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of Mark Nottingham > Sent: Tuesday, July 03, 2012 1:47 AM > To: IETF Apps Discuss > Subject: [apps-discuss] Looking at Webfinger > > I've pretty much ignored the whole webfinger / acct: / SWD discussion (too > much!). However, since it's apparent it may soon become Real, I had a > look. > > In a nutshell, my initial reaction is "It's Not Nearly As Bad As I Thought > It Would Be." :) > > With that in mind, a few questions / comments (I'll resist going into > editorial matters, for the time being): > > * First and foremost, why use host-meta? What value does adding this extra > step to the dance bring, beyond "We've defined it, therefore we must use > it?" > > As I think I've said many times before, the whole point of a .well-known > URI is to group like uses together, to avoid having a "dictionary" > resource that gets bloated with many application's unrelated data, thereby > overburdening clients with too much information (especially when they're > constrained, e.g., mobile). > > As such, host-meta is a spectacularly bad example of a well-known URI. > Defining a end-all-be-all well-known-URI kind of removes the point of > having a registry, after all... > > Instead, why not just define a NEW well-known URI for user data? That has > a more constrained scope, and saves one round trip (or more). E.g., > > GET /.well-known/webfinger?user=bob%40example.com HTTP/1.0 > Host: example.com > > I.e., let webfinger define the URI template to use. Yes, some > implementations might want to come up with crazy URIs, but is that really > a problem we want to solve? > > Astute observers will notice that this approach removes the need for an > ACCT URI scheme (at least here). > > > * What's the fascination with XRD and JRD? These specifications seem to be > creeping into IETF architecture; first it was in a pure security context, > but now folks are talking about using them in a much more generic way, as > a cornerstone of what we do. As such, I think they deserve a MUCH closer > look, especially since we're defining things with "Web" in their name when > the W3C has already defined solutions in this space. > > Thanks, > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From paulej@packetizer.com Wed Jul 4 20:28:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B6721F8491 for ; Wed, 4 Jul 2012 20:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BZOs7jm+piM for ; Wed, 4 Jul 2012 20:28:02 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9327D21F848F for ; Wed, 4 Jul 2012 20:28:02 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q653SDEV024161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jul 2012 23:28:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341458894; bh=Xnw+nolTBGfeKdnvtS8+eicPs6t+C0JZPkORTRwGZj8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=W1QxQ/4B6lnsiskgdGp8YxoJp/57l2BAms+bSyYmnX/mHr9/ErxByKE1UQTAOMVif cH2DN6cmmpVdWXZ4nh9CW+jrEBrNe46UFDU4KGSNq+y94Dn9A3UjamWGxEWVoZsNdz GAuih2HWdRzrl6XhpGTVia6J4kGEpbWdUlQESqBw= From: "Paul E. Jones" To: "'Peter Saint-Andre'" , "'Phillip Hallam-Baker'" References: <4FF31849.6040504@stpeter.im> In-Reply-To: <4FF31849.6040504@stpeter.im> Date: Wed, 4 Jul 2012 23:28:21 -0400 Message-ID: <068101cd5a5e$3ac3ab60$b04b0220$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFb3Wt68HpLZ7ZyHnoKMrZHlzcyBQNisEMVAc3igXICMDM2MJfB+v4A Content-Language: en-us Cc: 'Mark Nottingham' , 'IETF Apps Discuss' Subject: Re: [apps-discuss] the need for acct (was: Re: Looking at Webfinger) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 03:28:03 -0000 Peter, > > If I click on an acct: link in a browser I would have a range of > > possible options: > > * Grab the public WebFinger data > > * Grab the profile data exposed to me by virtue of me being a friend. > > * Attempt to connect on chat > > Don't we have xmpp: for that? Yeah, but this would be the means through which one might discover a person's XMPP URI. > > * Attempt to send an email > > Don't we have mailto: for that? Ditto. > You're saying that acct: would be a general identifier and that > applications could attempt many different kinds of interactions with that > account, using specific protocols like SMTP or XMPP. But deciding whether > to attempt such interactions would depend on knowing if the service > provider actually offers email service, IM service, public profiles, > microblogging, etc. Presumably that information could be discovered via > WebFinger (for a particular account), but I wouldn't assume that one can > send email to an account simply because an acct: URI exists. I personally would not assume this is the means through which clients launch applications, but the means through which one discovers the modalities of communication possible and the URIs associated with those modalities. Paul From superuser@gmail.com Wed Jul 4 21:23:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261E411E8079 for ; Wed, 4 Jul 2012 21:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZ-ppQkt8kOy for ; Wed, 4 Jul 2012 21:23:47 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14D1D11E8099 for ; Wed, 4 Jul 2012 21:23:45 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so12298357lbb.31 for ; Wed, 04 Jul 2012 21:23: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=fCh1h2NeHkSSO2AGuJ5bpIXuWwDWhysniPw1egEtZdc=; b=MpypGh/cAAQVp3uvGtIFqVNfn2lIQ0bYdAiV/W2W4sXMDqQmQhrs0gjG0jbBGX2m7z KovZUgq7G/WgqAYUUTMPH0rwXO+SKv1l0nlLHsChv5FrLNGfHcq+8IgoJ6JXDPM9WOgk 0d+JMZveTOQsyWtbrvf9YqLR+vAwyCJ1XQ9MB5vOeJYBz9dvpZDZNNnYM9eYc1zlw0PI hYwZ4wKoEk/tjshmjDwXNiOw7SzC6GhA3dX+oOWV1fizJDYYiyk3NIv5QhN2/RyONMsO fXeq0/ABhi60GAjod+lmASiwTccqT9ULqt2eZa+jdzUof+LcLzu8mOaeWMwEeEq6fx/G W0/A== MIME-Version: 1.0 Received: by 10.112.49.100 with SMTP id t4mr11113129lbn.10.1341462237728; Wed, 04 Jul 2012 21:23:57 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 4 Jul 2012 21:23:57 -0700 (PDT) In-Reply-To: <20120704154807.GC23139@1wt.eu> References: <20120703190401.GL17454@1wt.eu> <4FF344C5.6000105@gmx.de> <4FF347D3.7000905@gmx.de> <4FF34CAE.5020302@gmx.de> <20120704154807.GC23139@1wt.eu> Date: Wed, 4 Jul 2012 21:23:57 -0700 Message-ID: From: "Murray S. Kucherawy" To: Willy Tarreau Content-Type: multipart/alternative; boundary=bcaec554d63c28d12d04c40d846a Cc: Julian Reschke , Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 04:23:48 -0000 --bcaec554d63c28d12d04c40d846a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 4, 2012 at 8:48 AM, Willy Tarreau wrote: > I think it dates at least back to SMTP, where you very commonly see this > with > the Cc and To headers. Also, keep in mind that the two formats have a real > use, > to limit the max length of a given header field value without forcing > everyone > to send multiple occurrences each on their own line. > > I'm not sure that's a valid comparison. You can't have more than one To or Cc field with mail. The only option is to update the one that's there, or add one if it's missing. In this case we're talking about forwarding, and the path requests take. That's analogous to trace fields in email, and you're never allowed to modify those. You always add new ones. -MSK --bcaec554d63c28d12d04c40d846a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 4, 2012 at 8:48 AM, Willy Tarreau <w@1wt.eu<= /a>> wrote:
I think it dates at least back to SMTP, where you very commonly see this wi= th
the Cc and To headers. Also, keep in mind that the two formats have a real = use,
to limit the max length of a given header field value without forcing every= one
to send multiple occurrences each on their own line.


I'm not sure that's a valid comparison.= =A0 You can't have more than one To or Cc field with mail.=A0 The only = option is to update the one that's there, or add one if it's missin= g.

In this case we're talking about forwarding, and the path requests = take. =A0 That's analogous to trace fields in email, and you're nev= er allowed to modify those.=A0 You always add new ones.

-MSK
--bcaec554d63c28d12d04c40d846a-- From w@1wt.eu Wed Jul 4 23:20:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E2D21F8525 for ; Wed, 4 Jul 2012 23:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[AWL=-2.695, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piWwC1Yt-ZXE for ; Wed, 4 Jul 2012 23:20:55 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id AD5AE21F8530 for ; Wed, 4 Jul 2012 23:20:53 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q656KvQB026785; Thu, 5 Jul 2012 08:20:57 +0200 Date: Thu, 5 Jul 2012 08:20:57 +0200 From: Willy Tarreau To: "Murray S. Kucherawy" Message-ID: <20120705062057.GG25027@1wt.eu> References: <4FF344C5.6000105@gmx.de> <4FF347D3.7000905@gmx.de> <4FF34CAE.5020302@gmx.de> <20120704154807.GC23139@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Julian Reschke , Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 06:20:55 -0000 On Wed, Jul 04, 2012 at 09:23:57PM -0700, Murray S. Kucherawy wrote: > On Wed, Jul 4, 2012 at 8:48 AM, Willy Tarreau wrote: > > > I think it dates at least back to SMTP, where you very commonly see this > > with > > the Cc and To headers. Also, keep in mind that the two formats have a real > > use, > > to limit the max length of a given header field value without forcing > > everyone > > to send multiple occurrences each on their own line. > > > > > I'm not sure that's a valid comparison. You can't have more than one To or > Cc field with mail. The only option is to update the one that's there, or > add one if it's missing. Well, then maybe it's not valid but my mail agent (mutt) perfectly recognizes multiple headers and happily merges them. I've been used to do this for sending e-mails for a long time, maybe I took a bad habit for something non-standard. > In this case we're talking about forwarding, and the path requests take. > That's analogous to trace fields in email, and you're never allowed to > modify those. You always add new ones. Yeah, just like the Received: header. However, just like the HTTP Set-Cookie header, it's non-foldable because it contains a date which embeds a comma. Regards, Willy From melvincarvalho@gmail.com Wed Jul 4 23:36:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA2221F8539 for ; Wed, 4 Jul 2012 23:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKO1Ur5yX0H3 for ; Wed, 4 Jul 2012 23:36:03 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3385D21F8530 for ; Wed, 4 Jul 2012 23:36:03 -0700 (PDT) Received: by vcqp1 with SMTP id p1so5763547vcq.31 for ; Wed, 04 Jul 2012 23:36:15 -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=Nw5W7xRjLaBxgJLKgGRJQX5AH7AeOtYcJSM+eLScMws=; b=oi4slrQ7B5X48QOPzVFlr6MW4jZ7m5/hWbDPcVeoEZoM8LheP4UBIkgGuYYWr9V4Zj YJGVjd/vDxnlkrczMppvWTP76FNRuogWMOUogRvb8NxQgkFm0Lo7239RzhlvVX3qmB+h venYwnBJfwYAVpaLd85cKY7Cmk3DWe7j9k4Z9AjoObXsGMNsOgomXG7oqBqf94r3GHWQ va6qPjRHPbkTz7vaDCtOlcPoMPRzS3pBaEt37Vx86ML/cDQgBzLGMZg3F9oaS51yiHpW SDTyl2vmr/FJfcaLw5U5Jy4cZRHscRYk7gM9wgsBbIldWn7EH+yHNxRG8fXTJaPhYR3Q 6slQ== MIME-Version: 1.0 Received: by 10.52.28.99 with SMTP id a3mr5225087vdh.68.1341470175592; Wed, 04 Jul 2012 23:36:15 -0700 (PDT) Received: by 10.52.166.102 with HTTP; Wed, 4 Jul 2012 23:36:15 -0700 (PDT) In-Reply-To: <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net> References: <4E1F6AAD24975D4BA5B168042967394366574F93@TK5EX14MBXC283.redmond.corp.microsoft.com> <44C43601-A355-44B7-8C8E-1F435E4E567A@ve7jtb.com> <35550AA9-E003-4917-B08C-93CB6CC2CB07@mnot.net> Date: Thu, 5 Jul 2012 08:36:15 +0200 Message-ID: From: Melvin Carvalho To: Mark Nottingham Content-Type: multipart/alternative; boundary=20cf3079b9204b019e04c40f5d3d Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 06:36:04 -0000 --20cf3079b9204b019e04c40f5d3d Content-Type: text/plain; charset=ISO-8859-1 On 5 July 2012 00:36, Mark Nottingham wrote: > On 05/07/2012, at 8:16 AM, John Panzer wrote: > > > Just as a historical note. The envisioned usage of host-meta was > originally to avoid a specification which mandated a particular dynamic URL > API at a particular /.well-known endpoint (because it may not be feasible > to do that across all organizations and deployments). The host-meta > document itself would be highly cacheable and so wouldn't incur an > additional network trip in the common case. > > > > Having a 3xx redirect is a reasonable alternative that allows a similar > escape hatch via something like mod_rewrite, albeit at the cost of needing > an additional network trip each time. Since a deployment can always avoid > the 3xx redirect with additional dynamic plumbing behind the well-known > endpoint, I don't think that's a horrible thing. > > > > An application-level redirect would be almost equivalent to an HTTP > redirect, but then there are two ways to do the same thing. If _only_ an > application-level redirect is allowed, then you have to have at least a > minimal dynamic service at the well-known endpoint (no more mod_rewrite). > But the whole reason for this is to avoid the requirement for a dynamic > service behind well-known... > > "dynamic" and "static" are properties of the implementation, not the > interface. HTTP doesn't require that any particular URL be "dynamic"; > anything can, with the right metadata, be cached (and indeed, I've cached > many, many things with the wrong metadata, because of silly site operators > and their ideas about "dynamic"). > > Now, if people want to target a particular implementation that makes it > easier to serve a particular style of URL without writing code, fine, but > let's not confuse things. > > E.g., a URL like > > http://example.com/.well-known/user/bob > > is easy to serve in pretty much any way you like with Apache. > > I'm also going to push back on the "it may not be feasible to do that > across all organizations and deployments" motivation. This is a race to the > bottom. The trick is to make it accessible enough to get sufficient > traction to pull everyone along, without pandering to *everyone*'s > requirements. > Really nice idea. I've already implemented this on my homepage, took only a few minutes. > > Regards, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --20cf3079b9204b019e04c40f5d3d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 5 July 2012 00:36, Mark Nottingham <mnot= @mnot.net> wrote:
On 05/07/2012, at 8:16 AM, John Panzer wrote:

> Just as a historical note. =A0The envisioned usage of host-meta was or= iginally to avoid a specification which mandated a particular dynamic URL A= PI at a particular /.well-known endpoint (because it may not be feasible to= do that across all organizations and deployments). =A0The host-meta docume= nt itself would be highly cacheable and so wouldn't incur an additional= network trip in the common case.
>
> Having a 3xx redirect is a reasonable alternative that allows a simila= r escape hatch via something like mod_rewrite, albeit at the cost of needin= g an additional network trip each time. =A0Since a deployment can always av= oid the 3xx redirect with additional dynamic plumbing behind the well-known= endpoint, I don't think that's a horrible thing.
>
> An application-level redirect would be almost equivalent to an HTTP re= direct, but then there are two ways to do the same thing. =A0If _only_ an a= pplication-level redirect is allowed, then you have to have at least a mini= mal dynamic service at the well-known endpoint (no more mod_rewrite). =A0Bu= t the whole reason for this is to avoid the requirement for a dynamic servi= ce behind well-known...

"dynamic" and "static" are properties of the impl= ementation, not the interface. HTTP doesn't require that any particular= URL be "dynamic"; anything can, with the right metadata, be cach= ed (and indeed, I've cached many, many things with the wrong metadata, = because of silly site operators and their ideas about "dynamic").=

Now, if people want to target a particular implementation that makes it eas= ier to serve a particular style of URL without writing code, fine, but let&= #39;s not confuse things.

E.g., a URL like

http:= //example.com/.well-known/user/bob

is easy to serve in pretty much any way you like with Apache.

I'm also going to push back on the "it may not be feasible to do t= hat across all organizations and deployments" motivation. This is a ra= ce to the bottom. The trick is to make it accessible enough to get sufficie= nt traction to pull everyone along, without pandering to *everyone*'s r= equirements.

Really nice idea.=A0 I've already implemented thi= s on my homepage, took only a few minutes.
=A0

Regards,

--
Mark Nottingham =A0 http= ://www.mnot.net/



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

--20cf3079b9204b019e04c40f5d3d-- From mccabe@archive.org Thu Jul 5 02:39:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DED21F8601 for ; Thu, 5 Jul 2012 02:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c0WfBQ7H895 for ; Thu, 5 Jul 2012 02:39:04 -0700 (PDT) Received: from mail.archive.org (mail.us.archive.org [207.241.224.6]) by ietfa.amsl.com (Postfix) with ESMTP id A304821F85CD for ; Thu, 5 Jul 2012 02:39:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.archive.org (Postfix) with ESMTP id 488F86841075; Thu, 5 Jul 2012 02:39:17 -0700 (PDT) Received: from mail.archive.org ([127.0.0.1]) by localhost (mail.archive.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id saD3XgNSG1NU; Thu, 5 Jul 2012 02:39:16 -0700 (PDT) Received: from mikemac-2.local (208-90-212-115.PUBLIC.monkeybrains.net [208.90.212.115]) by mail.archive.org (Postfix) with ESMTPSA id 67A5E6840159; Thu, 5 Jul 2012 02:39:16 -0700 (PDT) Message-ID: <4FF560C4.8@archive.org> Date: Thu, 05 Jul 2012 02:39:16 -0700 From: Mike McCabe User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.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 Subject: [apps-discuss] json-patch tests X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 09:39:05 -0000 On Mon, 2012-07-02 at 10:01 +1000, Mark Nottingham wrote: > Also, anyone interesting in starting to collect test cases, as we've done for URI Templates ? I've been working on a set of tests for the last few weeks. I've posted them to github: https://github.com/mikemccabe/json-patch-tests The test set is still incomplete, and probably incorrect in places. Suggestions and patches welcome! Regards, Mike From andreas@sbin.se Thu Jul 5 05:19:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E776421F861D for ; Thu, 5 Jul 2012 05:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2diUaoOv9wK for ; Thu, 5 Jul 2012 05:19:44 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id C367F21F861A for ; Thu, 5 Jul 2012 05:19:43 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q65CJrRj032239; Thu, 5 Jul 2012 12:19:53 GMT Date: Thu, 5 Jul 2012 14:19:51 +0200 From: Andreas Petersson To: Stephen Farrell Message-ID: <20120705141951.3ef8eec7@hetzer> In-Reply-To: <4FF4AB6B.6090803@cs.tcd.ie> References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <4FF4AB6B.6090803@cs.tcd.ie> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 12:19:45 -0000 On Wed, 04 Jul 2012 21:45:31 +0100 Stephen Farrell wrote: >=20 > Hiya, >=20 > Basically agreeing with SM's latest below... > ...=20 > Hi, I have rewritten the "Privacy Considerations", using parts of your suggestions. My proposal: "In recent years, there has been growing concerns about privacy. There is a tradeoff beteween ensuring privacy for users versus disclosing information which is useful for debugging and statistics. The Forwarded HTTP header field, by design, exposes information that some users consider privacy sensitive. =46rom an end-user perspective, intermediate proxies in the request path are either known or unknown. Hidden proxies using this extension will preserve the information of a direct connection, and thus it has no end-user privacy impact. Proxies that are known to the end-user, such as explicitly configured proxies, using this extention may not anonymize the end-user IP address. The possessor of such proxy need to consider whether, and how, deploying this extension impacts on user privacy. An end-user must also be aware of that the users IP address may already be forwarded by proxies using the header field X-Forwarded-For, which is already wideley used. An end-user who want to be anonymus must be aware of these extensions. Such end-users must also ensure that the used proxy server, thought being anonymizing, in reality is. A proxy server that is intended to anonymize the request should not use this header field. In cases where the possessor of the proxy want to be able to trace where requests came from, but do not want to leak the information further, can use the possibility of obfuscating the client address." Let me know what you think. Best regards, Andreas From stephen.farrell@cs.tcd.ie Thu Jul 5 05:35:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B836C21F8653 for ; Thu, 5 Jul 2012 05:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89cLLG-L6TZR for ; Thu, 5 Jul 2012 05:35:08 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E590B21F865D for ; Thu, 5 Jul 2012 05:35:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D767C17151D; Thu, 5 Jul 2012 13:35:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341491715; bh=zwGIKwI8TbuE0Y 0vwlEMnhxFIj4u3kQDQc/Z7+9I138=; b=jjW1JAhynELj6lG6P9OTfdllWO44u4 p6sDRsci/6Fx2Qriwolyl/TKzEh3uYoW84XV5Ljvgasq2Ca4MZ5MA90sOG0Ak6nn aYsExwMrK2sr14QH91CL2myiq7O1sptGx4AZIBM3rcG8U/pSMEnUj9Xz28T6W+X5 /C3jBhsJxdJ2WC4Q7Z9EuXabn05hpmD/nxtseuZi+aO2niQdyccdxMrjNy8v9fvs 1KvWf/z0umsH4wM4/xGopWQMMgxoWHNySrISAmPs+7a3YwWXC7Mk9fB0AlQMh0z5 mRDb6TsxnIRmXIZxUvLWceLuTf17jKoJIy8OygXuePpMT+OHIZxKtVvg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id DrzeKikMt2u6; Thu, 5 Jul 2012 13:35:15 +0100 (IST) Received: from [10.87.48.11] (unknown [86.41.13.125]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1D38917151C; Thu, 5 Jul 2012 13:35:14 +0100 (IST) Message-ID: <4FF58A01.9040904@cs.tcd.ie> Date: Thu, 05 Jul 2012 13:35:13 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andreas Petersson References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <4FF4AB6B.6090803@cs.tcd.ie> <20120705141951.3ef8eec7@hetzer> In-Reply-To: <20120705141951.3ef8eec7@hetzer> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 12:35:09 -0000 Hi Andreas, I think that needs more work. Will get back later on with specific comments. Cheers, S. On 07/05/2012 01:19 PM, Andreas Petersson wrote: > On Wed, 04 Jul 2012 21:45:31 +0100 > Stephen Farrell wrote: > >> >> Hiya, >> >> Basically agreeing with SM's latest below... >> ... >> > > Hi, > > I have rewritten the "Privacy Considerations", using parts of your > suggestions. > > > My proposal: > > "In recent years, there has been growing concerns about privacy. > There is a tradeoff beteween ensuring privacy for users versus > disclosing information which is useful for debugging and statistics. > The Forwarded HTTP header field, by design, exposes information that > some users consider privacy sensitive. > > From an end-user perspective, intermediate proxies in the request path > are either known or unknown. Hidden proxies using this extension will > preserve the information of a direct connection, and thus it has no > end-user privacy impact. Proxies that are known to the end-user, > such as explicitly configured proxies, using this extention may not > anonymize the end-user IP address. The possessor of such proxy need > to consider whether, and how, deploying this extension impacts on > user privacy. > > An end-user must also be aware of that the users IP address may already > be forwarded by proxies using the header field X-Forwarded-For, which is > already wideley used. > An end-user who want to be anonymus must be aware of these extensions. > Such end-users must also ensure that the used proxy server, thought > being anonymizing, in reality is. > > A proxy server that is intended to anonymize the request should not use > this header field. In cases where the possessor of the proxy want to be > able to trace where requests came from, but do not want to leak the > information further, can use the possibility of obfuscating the client > address." > > > Let me know what you think. > > Best regards, > Andreas > > From hallam@gmail.com Thu Jul 5 05:38:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CF821F8697 for ; Thu, 5 Jul 2012 05:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7fpcQeYQCkZ for ; Thu, 5 Jul 2012 05:38:21 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A90D721F847E for ; Thu, 5 Jul 2012 05:38:21 -0700 (PDT) Received: by yenq13 with SMTP id q13so8117663yen.31 for ; Thu, 05 Jul 2012 05:38: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=VadCd6JzCE8WdmhC9jiSCaU+7BuCFbZSvcdRWjHNkmg=; b=s7UOGfoXFcPqqWCdDsY+5n3QRMmxt3Oy7ECzqkMUBXZaNgxPWXk8UixkExBizd/Uq/ i1kPNA5MOt6KuS1/HMji4epoRRVoUKUObyA9P0ggozkV1M4qX0QdqwH/NaLGPfxbFis4 ccqEo2jpdtWYprZp0Vj/vQodW3RJEUU4b8c/vQtbyCjgS2fWDdeWg8VOb7e0RLbi6Rvq hTqMNZI+d83dI4ZMa07peNuxg2iM7bk3RCW86WOXdG6GIhdIQe9jfejja9HWSO9unqJE 9DYs4/dVPA+ybAB2fwSZpWueVbl1xKoL5QwfEr15/1X1U5zWe9eGySd+ENrgG3xIZ244 5f/Q== MIME-Version: 1.0 Received: by 10.60.18.114 with SMTP id v18mr26494416oed.34.1341491914600; Thu, 05 Jul 2012 05:38:34 -0700 (PDT) Received: by 10.182.64.166 with HTTP; Thu, 5 Jul 2012 05:38:34 -0700 (PDT) In-Reply-To: <067f01cd5a5d$8edd2b50$ac9781f0$@packetizer.com> References: <067f01cd5a5d$8edd2b50$ac9781f0$@packetizer.com> Date: Thu, 5 Jul 2012 08:38:34 -0400 Message-ID: From: Phillip Hallam-Baker To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 12:38:22 -0000 IETF Working Group process is not just a documentation effort. If all that is required is to document what exists then an independent submission is more appropriate. In this case we have a protocol that engages in what many of us feel is a weird, inefficient and convoluted approach with no apparent motivation. It would be bad even if XRI was not tainted from an IPR standpoint (and will remain tainted unless the rights holders release the right to run a registry). Finger was the simplest protocol, so why is WebFinger complex. Why is it anything more than a single HTTP lookup to request the relevant data? That is what Web servers are designed to support after all. I can see that it might be appropriate to make use of the HTTP authentication capability to return different profiles depending on who is asking. But that is also well established. On Wed, Jul 4, 2012 at 11:23 PM, Paul E. Jones wrote: > Mark, > > WebFinger has been around now for a few years. This most recent effort is > one of formally documenting it. The plan for a long time has been that > discovering information about users or entities on the Internet would be via > host-meta and, more specifically, Link-based Resource Descriptor Documents > (LRDD). XRD was created for this purpose, which is why we see it used in > this document. JRD was subsequently introduced as RFC 6415 was developed. > While LRDD is still present on the server side, the most recent version of > the WebFinger spec effectively hides that via the "resource" parameter. So, > it's not really that we're building upon host-meta, but really that we're > formally documenting the procedures that were laid down long ago. WebFinger > and host-meta was moving along together. > > What I find most attractive about the approach taken is the consistency and > the fit with the web linking work that you did, essentially serving up a set > of link relations related to the entity that is queried. WebFinger will > serve up an XRD or JRD document, as desired by the client, that contains a > list of link relations that allow one to convey through those relations all > sorts of information about the entity being queried. That might be a vCard, > portable contacts, OpenID identifier, mail server configuration, or other. > > Another thing I find attractive is the consistency in the approach to > discovery. Regardless of the URI, I can query for information in precisely > the same way. It might be an acct URI, a mailto URI, an HTTP URI, etc. If > I want to discover information about acct:paulej@packetizer.com or > http://www.packetizer.com/people/paulej, I can use the same discovery > mechanism. In this case, the server might even be configured to return the > same set of information of both identifiers refer to the same entity. In > any case, it is important to allow for discovery of entities on the Internet > that are not necessarily users, but any URI. > > Paul > >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] >> On Behalf Of Mark Nottingham >> Sent: Tuesday, July 03, 2012 1:47 AM >> To: IETF Apps Discuss >> Subject: [apps-discuss] Looking at Webfinger >> >> I've pretty much ignored the whole webfinger / acct: / SWD discussion (too >> much!). However, since it's apparent it may soon become Real, I had a >> look. >> >> In a nutshell, my initial reaction is "It's Not Nearly As Bad As I Thought >> It Would Be." :) >> >> With that in mind, a few questions / comments (I'll resist going into >> editorial matters, for the time being): >> >> * First and foremost, why use host-meta? What value does adding this extra >> step to the dance bring, beyond "We've defined it, therefore we must use >> it?" >> >> As I think I've said many times before, the whole point of a .well-known >> URI is to group like uses together, to avoid having a "dictionary" >> resource that gets bloated with many application's unrelated data, thereby >> overburdening clients with too much information (especially when they're >> constrained, e.g., mobile). >> >> As such, host-meta is a spectacularly bad example of a well-known URI. >> Defining a end-all-be-all well-known-URI kind of removes the point of >> having a registry, after all... >> >> Instead, why not just define a NEW well-known URI for user data? That has >> a more constrained scope, and saves one round trip (or more). E.g., >> >> GET /.well-known/webfinger?user=bob%40example.com HTTP/1.0 >> Host: example.com >> >> I.e., let webfinger define the URI template to use. Yes, some >> implementations might want to come up with crazy URIs, but is that really >> a problem we want to solve? >> >> Astute observers will notice that this approach removes the need for an >> ACCT URI scheme (at least here). >> >> >> * What's the fascination with XRD and JRD? These specifications seem to be >> creeping into IETF architecture; first it was in a pure security context, >> but now folks are talking about using them in a much more generic way, as >> a cornerstone of what we do. As such, I think they deserve a MUCH closer >> look, especially since we're defining things with "Web" in their name when >> the W3C has already defined solutions in this space. >> >> Thanks, >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> _______________________________________________ >> 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 -- Website: http://hallambaker.com/ From barryleiba.mailing.lists@gmail.com Thu Jul 5 06:38:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E46621F854D for ; Thu, 5 Jul 2012 06:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.151 X-Spam-Level: X-Spam-Status: No, score=-103.151 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjI2mKLiOyRo for ; Thu, 5 Jul 2012 06:38:11 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45A1A21F84FF for ; Thu, 5 Jul 2012 06:38:11 -0700 (PDT) Received: by bkty7 with SMTP id y7so425745bkt.31 for ; Thu, 05 Jul 2012 06:38:24 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=GulGm21MKK7e08USCgi9/23LMGpA7iJGRgav/UFsawE=; b=UAd7pA6qtJh3p0CNprVuFnU7kZB265S6MYtIpIfDFWH8HRhfoT2f01yrvm0JqrV0/b 4IR7jRrWQd5ooYkHXAlf8M+TvOHR5i47wROqtl3j87Fz8/cL6ekoveRNd+qtO6RQFIGQ ETFR+Nn30SgnXH/c2s23syNpZrXPHJZPC2bGWyaPyGpcnBChhumOkhAMj/RFTuKUnXYC TvpeltS6V3YQEzUQ7oTO4o4mDV9c/oXQMTHiLwk8QWO1bTcY/9u1n3OmpKeHer65e4Mi vRFWlWn7lbJF+5Ga+Q6AV6QiegP6ilevbHBTtnjSL/QNii+kb6Lfc5y8alBSqaC5XrDQ zxUg== MIME-Version: 1.0 Received: by 10.152.136.18 with SMTP id pw18mr26025971lab.17.1341495504105; Thu, 05 Jul 2012 06:38:24 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Thu, 5 Jul 2012 06:38:24 -0700 (PDT) In-Reply-To: <20120704165602.61d722a9@hetzer> References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> Date: Thu, 5 Jul 2012 09:38:24 -0400 X-Google-Sender-Auth: SPDipyQAKLzXRDpDfayRyMcd4XQ Message-ID: From: Barry Leiba To: Andreas Petersson Content-Type: multipart/alternative; boundary=f46d042f927afd71c104c41542dc Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 13:38:12 -0000 --f46d042f927afd71c104c41542dc Content-Type: text/plain; charset=ISO-8859-1 Just a small comment for now; more when I'm at a real keyboard. > Well, the document is current under AD review. It would have been > better if you raised your comments during the WGLC. If you find new > issues, I guess the time to raise them is during the IETF LC, but I'm > unsure about the process here. Earlier review and comment is always good, but: 1. Stephen isn't a regular appsawg participant, and I don't expect him to get reviews in by WGLC. 2. Stephen is an Area Director, so he's busy reviewing a lot of things, and it's good that we're getting his comments this early. He can also give comments and DISCUSS positions during IESG Evaluation, which comes after the IETF Last Call. Barry --f46d042f927afd71c104c41542dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just a small comment for now; more when I'm at a real keyboard.
> Well, the document is cu= rrent under AD review. It would have been
> better if you raised your= comments during the WGLC. If you find new
> issues, I guess the time to raise them is during the IETF LC, but I= 9;m
> unsure about the process here.

Earlier review and comment is always good, but:

1. Stephen isn't a regular appsawg partic= ipant, and I don't expect him to get reviews in by WGLC.

2. Stephen is an Area Director, so he's busy r= eviewing a lot of things, and it's good that we're getting his comm= ents this early. =A0He can also give comments and DISCUSS positions during = IESG Evaluation, which comes after the IETF Last Call.

Barry
--f46d042f927afd71c104c41542dc-- From andreas@sbin.se Thu Jul 5 06:45:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8108721F85EA for ; Thu, 5 Jul 2012 06:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rvupVOkQUAs for ; Thu, 5 Jul 2012 06:45:30 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id A320021F853D for ; Thu, 5 Jul 2012 06:45:28 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q65DjR1P026628; Thu, 5 Jul 2012 13:45:27 GMT Date: Thu, 5 Jul 2012 15:45:22 +0200 From: Andreas Petersson To: Barry Leiba Message-ID: <20120705154522.238dd914@hetzer> In-Reply-To: References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 13:45:30 -0000 On Thu, 5 Jul 2012 09:38:24 -0400 Barry Leiba wrote: > Just a small comment for now; more when I'm at a real keyboard. > > > Well, the document is current under AD review. It would have been > > better if you raised your comments during the WGLC. If you find new > > issues, I guess the time to raise them is during the IETF LC, but I'm > > unsure about the process here. > > Earlier review and comment is always good, but: > > 1. Stephen isn't a regular appsawg participant, and I don't expect him to > get reviews in by WGLC. Ack, I did not now that. > 2. Stephen is an Area Director, so he's busy reviewing a lot of things, and > it's good that we're getting his comments this early. He can also give > comments and DISCUSS positions during IESG Evaluation, which comes after > the IETF Last Call. Ok. :) /andreas From gonzalo.camarillo@ericsson.com Thu Jul 5 07:55:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16CE21F8735; Thu, 5 Jul 2012 07:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.914 X-Spam-Level: X-Spam-Status: No, score=-105.914 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2hg0dN28dJi; Thu, 5 Jul 2012 07:55:37 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 74B4F21F8723; Thu, 5 Jul 2012 07:55:33 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-fa-4ff5aaf20230 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9B.11.23986.2FAA5FF4; Thu, 5 Jul 2012 16:55:46 +0200 (CEST) Received: from [131.160.126.161] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Thu, 5 Jul 2012 16:55:45 +0200 Message-ID: <4FF5AAF0.2060306@ericsson.com> Date: Thu, 5 Jul 2012 17:55:44 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Henry S. Thompson" References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+Jvre6nVV/9Da6/k7FY/XIFm8XtV7PY LM7ebGSymPFnIrMDi8eSJT+ZPBY92cDq8eXyZ7YA5igum5TUnMyy1CJ9uwSujL6V0xkLjkdU rFndwdzAONe+i5GTQ0LAROJN+xk2CFtM4sK99UA2F4eQwClGic4Jm1ggnDWMEhean7N3MXJw 8ApoS9w87gzSwCKgInH45x0WEJtNwEJiy637YLaoQLDEvO6bYDavgKDEyZlPwGwRAU2JYw/u M4LYzALXGCWWLlIAsYUFvCTuHvzNBGILCRhLvN50mBnE5gQ6bvKrZnaI4yQl7rWvZoPo1ZOY crUFao68xPa3c5gherUllj9rYZnAKDQLyepZSFpmIWlZwMi8ilE4NzEzJ73cSC+1KDO5uDg/ T684dRMjMMAPbvmtuoPxzjmRQ4zSHCxK4rzWW/f4CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amC0e93k8urwy5Oi1991cHcopDXYVfE9Wdhf+zCxILl3/+LlZw1zNrSxXLO727XU2VukWXKL 4YQ89j0JyrI2rWlH1WqFxF4kFoWu27rBJu/FdMUftUpMO38+V+s6vP2Rk9Gn3ekvsv4UuPps PRyYYRhhfvnJMZlJ7FLf65b6F2wU33XXcY8NX4oSS3FGoqEWc1FxIgBlkky0PgIAAA== Cc: "draft-camarillo-rai-media-policy-dataset.all@tools.ietf.org" , "apps-discuss@ietf.org" , "iesg@ietf.org" Subject: Re: [apps-discuss] Appsdir review of draft-camarillo-rai-media-policy-dataset-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 14:55:43 -0000 Hi Henry, thanks for your review. It is great that somebody with a good understanding of XML has reviewed the document. My answers inline: On 31/05/2012 4:13 PM, Henry S. Thompson wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-camarillo-rai-media-policy-dataset-01 > Title: A User Agent Profile Data Set for Media Policy > Reviewer: Henry S. Thompson > Review Date: 31 May 2012 > IETF Last Call Date: 2012-06-11 > > Summary: This draft is almost ready for publication as a Proposed > Standard but has a few issues that should be fixed > before publication > > Major Issues: > > 1 A bit more context is needed, given that section 3 dives right in to > defining attributes. We need to know Why this XML format > is _needed_ -- why aren't session definitions (per RFC4566) > sufficient? Just a brief explanation of motivation should do the job. The first paragraph of the Introduction references the framework document, which describes everything related to session policies in SIP. All the background information needed to understand the whole mechanism is there. This is actually a document bundle made up of three documents: the framework, the event package, and the document format (i.e., the document you reviewed). > 5.3/4/5/6 "Multiple elements MAY only be present > in a container element if each applies to a different set of streams > (e.g., one element for incoming and one for > outgoing streams)." -- How is this possible? The only 'container > element' allowed by the schema is . How does an > application know _which_ stream is meant to be constrained by _which_ > allowed set??? Simlarly for all the other allowed/excluded elts, and > various max/min settings if they appear under rather > than . Yes, Sections 5.3, 5.4, 5.5, 5.6, 6.3, 6.4, and 6.5 all contain a similar paragraph. Those elements can be present in a container element, and they can have a direction attribute. If there is more than one element (e.g., more than one element within a element), they will be distinguished by their direction attribute. That is, one element will apply to outgoing media streams (i.e., sendonly direction attribute) and the other will apply to incoming media streams (i.e., recvonly direction attribute): http://tools.ietf.org/html/draft-camarillo-rai-media-policy-dataset-01#section-3.3.2 > 6.5 max-stream-bw: It's not clear if it's an error == "MUST ignore" if > the media-type attribute and the label attribute conflict, i.e. the > stream picked out by the label isn't for the named media. In a > similar vein, it's not clear to what extent merging is restricted to > pairs whose label and/or media match. . . As usual, this draft specifies what to do in the most common error situations but does not describe every possible error that may occur. This error will not typically occur because if the bandwidth limit applies to a given stream, it will simply have a label attribute, and not a media-type attribute. The media-type attribute is used when the bandwidth limit applies, in general, to all streams of a given media type (e.g., to all audio streams). Therefore, both attributes are not be used together. > Similar issues arise for . Same as above. > Minor Issues: > > 3.1 It's a bit odd to reference XML 3rd edition -- XML 5e [1] has been > available for over 3 years now. . . I have updated the reference per your suggestion. > 3.3.4 'media-type' attribute -- Are more specific values than those > listed allowed? Probably the most common understanding of the phrase > 'media type' is exemplified by text/plain, image/svg or > application/xml -- if these are _not_ allowed, say so. If they are, > include one or two in the "such as" list. In the SIP context, media types are understood as defined in SDP spec. Accordingly, that is how this draft uses them: http://tools.ietf.org/html/rfc4566#section-8.2.1 > 4.1 Wrt codecs, the two MUST statements wrt description > vs. offer/answer are superficially contradictory. This para. needs to > be split into two sub-cases, so the processing for single > descr. vs. pair of descrs is clear. Good point. I have rephrased the paragraph so that the handling of both cases is explained separately and explicitly. > 4.1 It would be nice to see two generic templates demonstrating the > mapping rules for the one- and two-description cases, i.e. something > along the lines of > > c=IN IP4 h > m=m1 p1 RTP/AVP c11 c12 . . . > a=label:l1 > a=rtpmap:c11 t11 m1 > a=rtpmap:c12 t12 > a=rtpmap:. . . t11 > m=m2 p2 RTP/AVP c21 c22 . . . > a=label:l2 > a=rtpmap:c21 t21 t12 > a=rtpmap:c22 t22 > a=rtpmap:. . . . . . > . . . h:p1 > > > m2 > > t21 > > > t22 > > . . . > h:p2 > > . . . > > > > and similarly for the two-input case. Section 7.2 already contains both examples. > 4.1 The fact that the specified mapping is lossy in both directions > should be called out, e.g. v= and t= lines are lost in one direction, > and is lost in the other. I have added the following text: Note that these mapping rules do not include rules for all elements that need to be present in a session info document or in an SDP description. That is, some of those elements are generated following their associated general rules (e.g., the general rules to generate SDP v= and t= lines). > 5.1 Wouldn't this be better at the _end_ of section 5, once the > elements to be merged have been introduced? It may be a bit clearer, but I would like to avoid this type of structural changes at this point if possible. > 5.1.2 > > The two end tags should be > and respectively. Fixed. > 7.1 The element needs > xmlns="urn:ietf:params:xml:ns:mediadataset" Fixed. > The end tags and should be > and respectively. Fixed. > 7.2 Both elements need > xmlns="urn:ietf:params:xml:ns:mediadataset" Fixed. > All the elements need 'q' attributes according to the > text. The schema does not require this. Shouldn't it do so? elements need to have 'q' attributes when they are used within an element. However, when they are used in other context (e.g., within a element), they do not need to. So, the schema should not require. Nevertheless, you are right that some of the examples were missing the 'q' attributes. I have fixed them. > 8 Schema > > ElementInfoContext is undefined. I presume something along the lines > of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > is what you meant, if I read the text correctly. Actually, we were supposed to remove that element from this version of the draft but failed to do so. Now I have removed it. Thanks for catching this. > With the above fixes to schema and instances, the examples are all valid. > > Nits: > > 3.1 "namespace URIs for schemas" --> "namespace URIs for elements", I > would prefer. . . Fixed. > 4 "<\session-info>" --> "" Fixed. > 5.1.2 "encoding of profile of the codec" --> "encoding or profile of > the codec" > [I guess. . .] Fixed. > ----------- > "Other encoding or profiles of the same codec are unaffected." --> > "Other encodings or profiles of the same codec are unaffected." > ----------- Fixed. > "apply all containers it has received one after the other the > set of media- types/codecs it supports." --> > > "apply all containers it has received one after the other to the > set of media- types/codecs it supports." > > [I guess. . .] Fixed. > ht > > [1] http://www.w3.org/TR/2008/REC-xml-20081126/ I have also added you name to the Acknowledgments Section. I have just submitted a new version of the draft that includes all your comments above: http://www.ietf.org/id/draft-camarillo-rai-media-policy-dataset-02.txt Thanks, Gonzalo From paulej@packetizer.com Thu Jul 5 08:10:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60BC21F873A for ; Thu, 5 Jul 2012 08:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOXi4gmxAq4m for ; Thu, 5 Jul 2012 08:10:38 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C3A1321F8734 for ; Thu, 5 Jul 2012 08:10:37 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q65FAnFS012799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Jul 2012 11:10:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341501050; bh=kWQofI5/sBusmL3+xd5Q8LUr4IyoTyis92zxzXTFjsM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=bBuErCVqcJhAoD2DYJjqJwdtRjNbbBY9w8+DqavnIXvP7iN8SBu1e5tq1mj72YHig nvv6owS0O2rCegFVRwOpMjns8RKzH0Qt2xVcEuOaU6Cp2ZPh0vR4WVk7v1VnbGMUEA FlSiFTiWIuii2D0WvvzKfcRwT501LLQRgdP+2mA0= From: "Paul E. Jones" To: "'Phillip Hallam-Baker'" References: <067f01cd5a5d$8edd2b50$ac9781f0$@packetizer.com> In-Reply-To: Date: Thu, 5 Jul 2012 11:10:58 -0400 Message-ID: <071a01cd5ac0$6274e0e0$275ea2a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFb3Wt68HpLZ7ZyHnoKMrZHlzcyBQGKzjJ7AvRlkUuX2b/bwA== Content-Language: en-us Cc: 'Mark Nottingham' , 'IETF Apps Discuss' Subject: Re: [apps-discuss] Looking at Webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 15:10:38 -0000 Philip, > IETF Working Group process is not just a documentation effort. If all that > is required is to document what exists then an independent submission is > more appropriate. The work on WebFinger is not entirely one of documenting, either. Perhaps I stated that too strongly. The concepts have been brewing over the past few years, but that's not unusual for many protocols that are brought into the IETF. In this case and others, the group has influenced the specifics of the protocol. > In this case we have a protocol that engages in what many of us feel is a > weird, inefficient and convoluted approach with no apparent motivation. I personally find this statement a bit surprising. I cannot claim to have come up with the idea or the elements that are included in WebFinger, Hostmeta, or XRD, so I do feel I speak without bias when I say that it was pretty easy for me to implement and I do understand exactly what I get. I can issue a query and I get back a set of link relations about an entity. I can then select the particular link relation of interest and further query to get the specific information I seek. > It would be bad even if XRI was not tainted from an IPR standpoint (and will > remain tainted unless the rights holders release the right to run a > registry). I'm not sure why XRI is often mentioned, since XRD and JRD are both unrelated to XRI, as far as I know, and are both trivial to produce and consume. They're just containers for a set of link relations. > Finger was the simplest protocol, so why is WebFinger complex. Why is it > anything more than a single HTTP lookup to request the relevant data? That > is what Web servers are designed to support after all. Finger returns unstructured data, which was fine back in the day. WebFinger returns structured data, which makes it suitable for machine processing. Why is this considered complex? https://packetizer.com/.well-known/host-meta? \ resource=acct:paulej@packetizer.com It's a simple HTTP GET that returns a set of link relations (and possible properties). > I can see that it might be appropriate to make use of the HTTP > authentication capability to return different profiles depending on who is > asking. But that is also well established. The spec does not speak to authenticating users at all. Are you saying this is a concern or as it should be? Paul From acooper@cdt.org Thu Jul 5 14:07:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A9B21F854A for ; Thu, 5 Jul 2012 14:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdrVcpsnFNRv for ; Thu, 5 Jul 2012 14:07:49 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1236D21F8541 for ; Thu, 5 Jul 2012 14:07:48 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 5 Jul 2012 17:08:02 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <20120705141951.3ef8eec7@hetzer> Date: Thu, 5 Jul 2012 17:08:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5FDC74E3-FB58-4D88-B847-53E9576D14EC@cdt.org> References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <4FF4AB6B.6090803@cs.tcd.ie> <20120705141951.3ef8eec7@hetzer> To: Andreas Petersson X-Mailer: Apple Mail (2.1084) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 21:07:50 -0000 Hi Andreas, I tend to agree with Stephen that there is no value in saying that = hidden proxies' use of this field has "no end-user privacy impact." In = fact, it's not even true. Every IP address that gets conveyed has a = potential privacy impact, not least because they can be used as the = basis for legal information requests. Conveyance of identifiers is = obviously not unique to this spec, but that doesn't mean this spec can = claim some high ground that all other IP-based protocols cannot. Also, as far as I can tell my question about the limits on which = identifiers can be carried in the header = = was not addressed in the text. At the least I would expect caution = against the use of permanent, unique identifiers in public network = environments. If it's not even possible to say that, then the fact that = absolutely any identifier might show up here needs to be called out = explicitly. I still think = http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02#secti= on-4 is worth a look, as there are topics in there that deserve a = mention here too (e.g., the fact that Forwarded identifiers contribute = to end host fingerprinting, certainly more so than direct connections). Alissa=20 On Jul 5, 2012, at 8:19 AM, Andreas Petersson wrote: > On Wed, 04 Jul 2012 21:45:31 +0100 > Stephen Farrell wrote: >=20 >>=20 >> Hiya, >>=20 >> Basically agreeing with SM's latest below... >> ...=20 >>=20 >=20 > Hi, >=20 > I have rewritten the "Privacy Considerations", using parts of your > suggestions. >=20 >=20 > My proposal: >=20 > "In recent years, there has been growing concerns about privacy. > There is a tradeoff beteween ensuring privacy for users versus > disclosing information which is useful for debugging and statistics. > The Forwarded HTTP header field, by design, exposes information that > some users consider privacy sensitive. >=20 > =46rom an end-user perspective, intermediate proxies in the request = path > are either known or unknown. Hidden proxies using this extension will > preserve the information of a direct connection, and thus it has no > end-user privacy impact. Proxies that are known to the end-user, > such as explicitly configured proxies, using this extention may not > anonymize the end-user IP address. The possessor of such proxy need > to consider whether, and how, deploying this extension impacts on > user privacy. >=20 > An end-user must also be aware of that the users IP address may = already > be forwarded by proxies using the header field X-Forwarded-For, which = is > already wideley used. > An end-user who want to be anonymus must be aware of these extensions. > Such end-users must also ensure that the used proxy server, thought > being anonymizing, in reality is. >=20 > A proxy server that is intended to anonymize the request should not = use > this header field. In cases where the possessor of the proxy want to = be > able to trace where requests came from, but do not want to leak the > information further, can use the possibility of obfuscating the client > address." >=20 >=20 > Let me know what you think. >=20 > Best regards, > Andreas > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From andreas@sbin.se Thu Jul 5 14:42:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63B521F8541 for ; Thu, 5 Jul 2012 14:42:55 -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=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id II5hyWj8vILr for ; Thu, 5 Jul 2012 14:42:54 -0700 (PDT) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFEB21F8540 for ; Thu, 5 Jul 2012 14:42:54 -0700 (PDT) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 0B1284000C for ; Thu, 5 Jul 2012 23:43:07 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id F3FC64000B; Thu, 5 Jul 2012 23:43:06 +0200 (CEST) Received: from [192.168.0.13] (c-6dc2e455.028-453-6c6b701.cust.bredbandsbolaget.se [85.228.194.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 09F6140008; Thu, 5 Jul 2012 23:43:04 +0200 (CEST) Message-ID: <4FF60A67.6080001@sbin.se> Date: Thu, 05 Jul 2012 23:43:03 +0200 From: Andreas Petersson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: SM References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <6.2.5.6.2.20120704123329.05e60578@resistor.net> In-Reply-To: <6.2.5.6.2.20120704123329.05e60578@resistor.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 21:42:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/4/12 10:12 PM, SM wrote: > Hi Andreas, At 07:56 04-07-2012, Andreas Petersson wrote: >> The reason to standardize this is so that more proxies will do >> this instead of X-Forwarded-* (e.g. For). I do not expect people >> to start using this, who currently do not use X-Forwarded-For. >> XFF is so widely spread so those who wants to disclose this >> information does it already. > > If the above was the rule, there are many things which the IETF > would not be doing anymore. For example, there was a time when > security considerations were not given any thought. Nowadays, you > have to have some text about security considerations even if a > protocol has been in wide use. > >> One use case which I believe is pretty big is to geo-locate the >> users to localize the content in various ways. > > I thought that geolocation of users was about DNS tricks. :-) It > has been argued in the past that it is not optimal to do the > geolocation at the HTTP level. The DNS tricks are for making the request end up in the "right" datacenter. I was talking about localizing the content. For example, serve the web page in a different language (yes, I know that this is not a good way of doing it, but it exists in real life). >> I don't think that is an elegant solution, but it is part of the >> reality. If this use is intrusive on privacy is probably a matter >> of taste. > > I beg to differ about privacy being a matter of taste. I did not say that. Please do not make up things that I haven't written. >> "... and so decreases ..." I don't see how it decreases if people >> are following an RFC-specification of the format, or just the de >> facto format that everyone already uses. > > I would look at this in terms of people instead of technical > specifications. The de-facto argument won't fly well in policy > circles. Well, yes, but if I write something that makes it look like privacy stands or falls with this particular header field, those people will get the wrong idea. I think it is wrong to encourage people to believe they are anonymous, just because of the absence of this header field. Those people should not trust a proxy owner either. And, as I have said many times, writing a guideline for anonymizing is far more complex than anything that would fit in this document. >> What regulations and cross-border controls are you talking about >> here? Can you elaborate? > > The privacy regulations in various countries differ significantly > (as an unrelated example see > http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf > > ). > >> I would think that most parties to follow the laws in their >> respective country, which may be part of the problem, of course, >> but also quite expected. > > Yes. > >> Well, the document is current under AD review. It would have >> been better if you raised your comments during the WGLC. If you >> find new issues, I guess the time to raise them is during the >> IETF LC, but I'm unsure about the process here. > > If you are unsure about the process, you can ask the document > shepherd. > > BTW, as a quick comment, I like the text which Stephen Farrell > provided at > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06557.html I > borrowed much of it into my new version. But, I think the beginning was too much focused on the old, non-standard header. The text in this document must be focused on that. I also think that the cross-border control stuff was pretty vague. Are ISP:s supposed to mask the src-field of a IP connection when a border is crossed? > At 05:01 04-07-2012, Andreas Petersson wrote: >> This header field is not only for debugging, so that should >> probably be expanded. Something else that should be added? > > Yes, the text needs some work. > >> I do think that the text should say something about the current >> use of similar header fields though, otherwise it may look like >> everything is fine unless you don't use this, which is not true. >> Users should also be aware of all other different headers and >> cookies that their browsers sends out, so they can be identified >> by those too, but mentioning that here seems out of scope to me. > > What I was trying to express was: tell the user what to think about > so that he or she can decide. If you say "everyone does this, so > why don't you do it", you might as well drop the privacy section > altogether. This is changed in the new version. Best regards, andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP9gpmAAoJEEaYRbQUWNleiXkP+wbF/YYmgRKn/HRjFcH5xW8a EX5Ctx9CCcp1jyKB8Ej2pC+lhjt7x+D/VEqHfocKLFWtqQYJUkG26W19CGOTeo46 L8LAMlgaZ7EByYNFZdzaiug4eqMJa1eU0sYuBeZa9F4oeyvHZcjHx+jbqB+kjDgN v1IZSfGwzIfJ5nc3GZZ3+v0iuHF4XDhDXqvb6rNHinLF1BCpSSGNR2zC9mT1p7J6 3nC5l8rLaDISmjAryLohan9sW/8ZXB1Orbcl8ttFi5dQ5BRVIlWd7yCH8u1ZOPiI vg3UHgJMwkw2PxK8iO+o5GK0gLld/FXccLmXXPlNEAy3TCZOcWqMTZC15MNrq/i2 eRNHkL2zeBPbxzHkHPY3r4lxm0WyjfHUo2UgPphcZV0nuxI54GlRT+TbHJduU8Zt OhCJI5VGJH6pAtkQ/4C9HBaB5w0eW0oytCE9nlI3gliPbTkeEs6TfMxyyMCMGI9k vRTQsucL4/tq2AnARV3Lvu+/s4NJGeOJltWNkZK64OxR72Gb75NvrrGQbH/8lWTs C3fn4ggHiotbVFEtVz1HSUH8GEp19LDhDJGzClwlu8Ieu4z/b8BerIXTAxe74BTf d+aI6t/cAbe8iVWvSTcY0VaZPvtmT+22+1WQFK0XRgXUNRDrQhE9OIa7GLfK348E PfsRUCUxH+zbIZMQhHme =E1BO -----END PGP SIGNATURE----- From andreas@sbin.se Thu Jul 5 15:20:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63BB21F854A for ; Thu, 5 Jul 2012 15:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, SARE_RMML_Stock1=0.21] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mkSBWp89UPO for ; Thu, 5 Jul 2012 15:20:46 -0700 (PDT) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by ietfa.amsl.com (Postfix) with ESMTP id 848A021F8577 for ; Thu, 5 Jul 2012 15:20:46 -0700 (PDT) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 36FB74000B for ; Fri, 6 Jul 2012 00:21:00 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 2C0CC40008; Fri, 6 Jul 2012 00:21:00 +0200 (CEST) Received: from [192.168.0.13] (c-6dc2e455.028-453-6c6b701.cust.bredbandsbolaget.se [85.228.194.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 4DF9040002; Fri, 6 Jul 2012 00:20:59 +0200 (CEST) Message-ID: <4FF6134A.2040709@sbin.se> Date: Fri, 06 Jul 2012 00:20:58 +0200 From: Andreas Petersson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alissa Cooper References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <4FF4AB6B.6090803@cs.tcd.ie> <20120705141951.3ef8eec7@hetzer> <5FDC74E3-FB58-4D88-B847-53E9576D14EC@cdt.org> In-Reply-To: <5FDC74E3-FB58-4D88-B847-53E9576D14EC@cdt.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 22:20:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/5/12 11:08 PM, Alissa Cooper wrote: > I tend to agree with Stephen that there is no value in saying that > hidden proxies' use of this field has "no end-user privacy > impact." In fact, it's not even true. Every IP address that gets > conveyed has a potential privacy impact, not least because they can > be used as the basis for legal information requests. Conveyance of > identifiers is obviously not unique to this spec, but that doesn't > mean this spec can claim some high ground that all other IP-based > protocols cannot. So the end users intention is not relevant at all? If the end user wants to be anonymous, the user must Make Sure to be anonymous. But if that is not the intention, the end user shoud NEVER assume he is anonymous, and can NEVER count on that. All other IP-based protocols (that are not forwarded), is sending the source address, in every IP packet. But you know that of course, so I guess I am misunderstanding you. Can you please express this in a more clear way? > Also, as far as I can tell my question about the limits on which > identifiers can be carried in the header > > was not addressed in the text. At the least I would expect caution > against the use of permanent, unique identifiers in public network > environments. If it's not even possible to say that, then the fact > that absolutely any identifier might show up here needs to be > called out explicitly. A static assigned token is of course no good for anonymizing a user, and in the new version of the "Privacy considerations", it is explicitly written that an anonymizing proxy should not use this extension (I guess there may be situation where you could feed false information in this header for whatever purpose, but I'm not gonna figure out such schemes). Back to the tokens, of course there is data that is really bad to put in this header field. Your example of credit card number was far beyond my imagination. I can add some sentence warning about not placing sensitive data there, and also being careful about using a static identifier. A static identifier (containing a random string) is however at worst about on the same level as a statically assigned IP address. > I still think > http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02#section-4 > is worth a look, as there are topics in there that deserve a > mention here > too (e.g., the fact that Forwarded identifiers contribute to end host fingerprinting, > certainly more so than direct connections). I understand the underlying ideas, but I can't agree with everything there. "some users realize privacy benefits associated with IP address sharing, and some may even take steps to ensure that NAT functionality sits between them and the public Internet. IP address sharing makes the actions of all users behind the NAT function unattributable to any single host, creating room for abuse but also providing some identity protection for non- abusive users who wish to transmit data with reduced risk of being uniquely identified." I think this is to give a false feeling of privacy. A user must now that the one controlling this NAT will be able to do a lot of things with the end users data. And can also, at any time give out information about the user. Using NAT is a very, very weak way of gaining almost no anonymization. A user Must actively seek to be anonymous, to truly be so. Besides that, I think NAT is causing enough pain on its own, and should not be encouraged. :-) Taking the discussion under consideration, a modified version (I'm a bit tired, but something like this): "In recent years, there has been growing concerns about privacy. There is a tradeoff beteween ensuring privacy for users versus disclosing information which is useful for debugging and statistics. The Forwarded HTTP header field, by design, exposes information that some users consider privacy sensitive. - From an end-user perspective, intermediate proxies in the request path are either known or unknown. Hidden proxies using this extension will preserve the information of a direct connection, but can still have end-user privacy impact. Proxies that are known to the end-user, such as explicitly configured proxies, using this extention may not anonymize the end-user IP address. The possessor of such proxy need to consider whether, and how, deploying this extension impacts on user privacy. An end-user must also be aware of that the users IP address may already be forwarded by proxies using the header field X-Forwarded-For, which is already wideley used. An end-user who want to be anonymus must be aware of these extensions. Such end-users must also ensure that the used proxy server, thought being anonymizing, in reality is. A proxy server that is intended to anonymize the request should not use this header field. In cases where the possessor of the proxy want to be able to trace where requests came from, but do not want to leak the information further, can use the possibility of obfuscating the client address. When generating such tokens care must be taken not to include private or in other way sensitive information in the token. When using such tokens, it should also be considered not to use static tokens per user, as that will increase the possibility for external organizations to track separate users." Best regards, Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP9hNJAAoJEEaYRbQUWNle4sIQAOOfUAZ2UDHCA2P5t3GC1VLe 0qK5onwvCyPetqIM6JvPltvhJ7lynH6bKFCOM2ni7buEIvY/i0/OT5W4BL+xn1dB Tx/wV13kYM8BFY+VhTj/BQg2iWBABEsbN+Jsj+23p1uXAo2bL37U8tBSkOXb0FYU JPKhaDl7D5NcZuYy7PD/NW6+Ys8pzC3EHFypiLgDlwHdMrrHUxWBv2UhRCsisbqO U0h6uF2Opqwjp/EPygK6enHLIXnl9Wb2kGmYAESu0l4KWfAvP/a6GI2CZ3f+nDSM CE/s/AvqCeDXkwBUVhaMTnX9OXiiV7PnENnpm6HZnwoAY2RHGwa6N+fuR4shjywA aUlnwEcMEwh9kr4u4fp3OIOyBxa+EsHa8cnvLvUdEgiTH3M7C8asfQh/M4QFaEOp RJKgeRKoeQvPTJpct+PEx2lUI0tCFs19RwLBVjNRN8BoVc/9zOk4jGHPq28A0Xid xveBeJDQjZQHnAhfEl1ROKiDHJ7mX+DEZF1BojAa3OtQcIUczXsjk28ALHz9ZAm1 Evllt6xUzPSgujwj2mZPN2v0ukojSPIlMFGhwotQ7toGtXloQdznevjxS88Infaq UZZ+pLF92SD0PwhgGgJQrdTF8QigtCbw5wJq8dSRPWq4Tgw1tiHWydI4buAEAuHP ZLV/+OnE/qkT4ZSh0H2q =AOv1 -----END PGP SIGNATURE----- From andreas@sbin.se Thu Jul 5 15:26:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D460911E80C4 for ; Thu, 5 Jul 2012 15:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjbjN6DESaH6 for ; Thu, 5 Jul 2012 15:26:27 -0700 (PDT) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by ietfa.amsl.com (Postfix) with ESMTP id 08FCB11E80CA for ; Thu, 5 Jul 2012 15:26:27 -0700 (PDT) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 2B14A4000B for ; Fri, 6 Jul 2012 00:26:41 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 1813140008; Fri, 6 Jul 2012 00:26:41 +0200 (CEST) Received: from [192.168.0.13] (c-6dc2e455.028-453-6c6b701.cust.bredbandsbolaget.se [85.228.194.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 8D02F40002; Fri, 6 Jul 2012 00:26:40 +0200 (CEST) Message-ID: <4FF614A0.1050809@sbin.se> Date: Fri, 06 Jul 2012 00:26:40 +0200 From: Andreas Petersson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <4FF4AB6B.6090803@cs.tcd.ie> <20120705141951.3ef8eec7@hetzer> <4FF58A01.9040904@cs.tcd.ie> In-Reply-To: <4FF58A01.9040904@cs.tcd.ie> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 22:26:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/5/12 2:35 PM, Stephen Farrell wrote: > > Hi Andreas, > > I think that needs more work. Will get back later on with specific > comments. > Thanks for this invaluable piece of information. ;-) When you do get back, please comment on the version I wrote for the reply to Alissa Cooper. Best regards, Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP9hSeAAoJEEaYRbQUWNlebbcP/2xmUlwunydYTb4vjNE/Z/WP 4IlAJFSWvOFPbaPi0gAwXKrKLqyJaKuQFobVYw726j8G1cvZU8MH8xxfYrEWDpkj hkXcLGY2JPC6bWF12HAbic6bbGDPehrPArNLtZDmcEk5Jb+IgpJGMHfHXBe+uQMS SbOGGyBmXas5Q4xaRkz/o8ZUFJ9vG4y46w5zGx0ScqRbbJdwGl0YQ9upWWkCmJnb wAoTONFKO2OKYCg+8r80DMvs3zvRMFH9JY7UUvcd3YWYOLl+YLu8KXVfli+3b2rJ PrkLRM+KOX/RQbOVOjXJlBJeoIHhoFGRzKrY3iQGh+83wpyKuN5QYQrHIi2u7DAG DsRJ1/P5NwVSB1oEMRCtkLtEYVD5AmgAAJOk8OcvHD5UIMvbb3gkNpUj0YYM2UrP 2mJxoJWuek8ktd06FR1d7VLg1Au4TOU5iqL4gQqOzxcJqawF4u2kdDS2AfpS0gcg piK3fqehKjiTPq5XBGKERGg5QRohUSfmFSHHMEJsKE19619t0GslgAsy3pakij8k rQ4TC7pTcOT7JSAC4KMDiUTYgIpiecqclO92CJ9hK+qMS2qxOPWDVdI7VsgLABek 5s/7ydwXCuDOcuwOY6+jw4Epv2hzLCtzfRjglmJ5rCu91oeuyZ/kpWH8vizcR9Fl FzlDGWFC2z6SU2UwhMMG =TxMH -----END PGP SIGNATURE----- From sm@resistor.net Thu Jul 5 16:49:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8276D21F865E for ; Thu, 5 Jul 2012 16:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oOOSxsd3qyA for ; Thu, 5 Jul 2012 16:49:44 -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 1875421F865D for ; Thu, 5 Jul 2012 16:49:44 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q65Nnqe7010549; Thu, 5 Jul 2012 16:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341532198; bh=3jb2KN4k2ic92SUJbA/pcmWyEjLyoRNgW46zKaXKSfw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=KCOo2YJIMy8iJFbwZS7Chw0kwzng3C4RU8j7eurnMBJvag46sIhEkQTw5XSWKqFxV H/qGbgX+8mofWjm4XPs/GjxdoJJAyqlUYQvCCvwuQyuRer8cvUQ+5FUaE5LJA6WXGi u4GqL8FlzDqnn6itN36y7+lHz64cqC7sswAPShYE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341532198; i=@resistor.net; bh=3jb2KN4k2ic92SUJbA/pcmWyEjLyoRNgW46zKaXKSfw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=E35WguydkOOQYUHGYw1yNNFYDaP83+Reem8OvUTeUWKHqUYrtFWwOQBiXHcOyNijo d1/OoBo6zus+SCRacLaKTk8rSDkWQ/HGCNyAeDkcHS9toxN3iBaP+f+x7ngiAP0FUQ 0lNm/kCsrqyhMwG2HLpVZeCuNa6CQzDdjeC8/Id0= Message-Id: <6.2.5.6.2.20120705145938.086e16a0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 05 Jul 2012 16:14:41 -0700 To: Andreas Petersson From: SM In-Reply-To: <4FF60A67.6080001@sbin.se> References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <6.2.5.6.2.20120704123329.05e60578@resistor.net> <4FF60A67.6080001@sbin.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2012 23:49:48 -0000 Hi Andreas, At 14:43 05-07-2012, Andreas Petersson wrote: >I did not say that. Please do not make up things that I haven't written. Sorry about that. It was a quick comment as the comments in this message. >Well, yes, but if I write something that makes it look like privacy >stands or falls with this particular header field, those people will >get the wrong idea. I see your point. >I think it is wrong to encourage people to believe they are anonymous, >just because of the absence of this header field. >Those people should not trust a proxy owner either. Yes. I don't really know how to put the following in words. The argument is not about encouraging people to believe that they are anonymous. It is also not about conveying the wrong idea. I would describe it as "there are the pros, these are the cons, and the reader gets to make an informed descision". >And, as I have said many times, writing a guideline for anonymizing is >far more complex than anything that would fit in this document. Yes. >I also think that the cross-border control stuff was pretty vague. >Are ISP:s supposed to mask the src-field of a IP connection when a >border is crossed? A similar argument was raised during a discussion about DNS providing the client IP address to authoritative DNS servers. The notion of consent is sometimes used in privacy discussions. Regards, -sm From sm@resistor.net Fri Jul 6 02:41:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D47C21F869C for ; Fri, 6 Jul 2012 02:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzEpeTZiQI0l for ; Fri, 6 Jul 2012 02:41:19 -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 A253221F86B4 for ; Fri, 6 Jul 2012 02:41:19 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q669fQZd020232; Fri, 6 Jul 2012 02:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341567694; bh=BLSyxMI6qm08mI6W2kqp3O8LaZ+E9EYWds7B5u96YB8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=K651Lz2T68SThYX4XUqcjnjyA9noC/cIIDdHULJuHOird7FB8SIJoBTSsfrdhCTp4 VQoD1WeOlErt1zRyVrcSo1G2vr6Q2apkOIyUdxOrqj4SYmVFkckkC4KwWElSjg/o6X sg5sPXBbFBlyZw3zQrt/4Z5Gtvnydwj2lxLv6fsk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341567694; i=@resistor.net; bh=BLSyxMI6qm08mI6W2kqp3O8LaZ+E9EYWds7B5u96YB8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RUAeIA9WIRvCZAaVSGYEWT/CpAK6bnpcG7cxSRQDbl2cMbxI7EnCSqXSGEfz3z8fq c7dpgOdqJrTUNcvsbPBXGzcYmppKU2eviUDkVAeIICZ888yr/oCqqAbhANFYUykjUl lDGvs6DwLLGjAIBe1QO8ACD36Mzz0QJmBLHtlYjw= Message-Id: <6.2.5.6.2.20120706003649.09b5fb28@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Jul 2012 02:41:19 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: <20120705141951.3ef8eec7@hetzer> References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <4FF4AB6B.6090803@cs.tcd.ie> <20120705141951.3ef8eec7@hetzer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Privacy considerations - draft-ietf-appsawg-http-forwarded-05 (was: Status of draft-ietf-appsawg-http-forwarded-04.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 09:41:22 -0000 Hello, I'll start with comments about draft-ietf-appsawg-http-forwarded-05 for context. In the Introduction section: "In today's HTTP landscape, there are a multitude of different applications acting as a proxy for the user agent and effectively anonymizing the requests to look as if they originated from the proxy IP address or in other ways changing the information in the original request." This anonymous "feature" is created at the reverse proxy (load balancing, etc.). It occurs nearer to the user for when content filtering. In both cases the average user may not be aware of this "feature". Let's assume that we are customizing the HTTP response based on the source IP address. There is a problem in the two cases mentioned about. The "fix" is to have the information forwarded through a header, e.g. X-Forwarded-For. I don't know whether everyone agrees or disagrees that this unintended feature should be kept as it enhances privacy. I'll assume that everyone disagrees as it is about the same as saying that NAT is a security feature. The draft introduces forwarding and reverse proxies in Section 4: "This applies to forwarding proxies, as well as reverse proxies." This covers a wider range of proxies than the examples mentioned in Section 1. An obfuscated identifier is proposed in Section 6.3: "A generated identifier may be used where there is a wish to keep the internal IP addresses secret while still allowing the Forwarded header field to be used for tracing." Section 8.2 discusses about information leakage: "The Forwarded HTTP header field can reveal internal structures of the network setup behind the NAT or proxy setup, which may be undesired. This can be addressed either by using obfuscated elements, preventing the internal nodes from updating the HTTP header field, or by having an egress proxy removing entries that reveals internal network This header field should never be copied into response messages by origin servers or intermediaries, as it can reveal the whole proxy chain to the client." The way this is argued is that in the two cases mentioned above (see comment about Introduction) there is information leakage together with a proposal on how to address the problem. Section 8.3 is about privacy considerations, i.e. what is a concern to the user instead of a concern about disclosing information about infrastructure (Section 8.2). In non-technical discussions, this is where the argument is about consent (and intent). Although the proposal ends up with privacy concerns, these concerns are somewhat of an indirect effect of what has been discussed up to this subsection as the "forward proxies" cover other cases too. At 05:19 05-07-2012, Andreas Petersson wrote: >My proposal: > >"In recent years, there has been growing concerns about privacy. >There is a tradeoff beteween ensuring privacy for users versus >disclosing information which is useful for debugging and statistics. >The Forwarded HTTP header field, by design, exposes information that >some users consider privacy sensitive. The argument here is that this technology exposes information which the user considers as having an impact on his/her privacy. it's unrelated to the two cases mentioned above, i.e. the user does not necessary know about the proxy between him/her and the web server. Assuming that the user knows, the privacy "feature" is still a side effect. > From an end-user perspective, intermediate proxies in the request path >are either known or unknown. Hidden proxies using this extension will >preserve the information of a direct connection, and thus it has no >end-user privacy impact. Proxies that are known to the end-user, >such as explicitly configured proxies, using this extention may not >anonymize the end-user IP address. The possessor of such proxy need >to consider whether, and how, deploying this extension impacts on >user privacy. I suggest looking at this in terms of forward proxies and from a user perspective. >An end-user must also be aware of that the users IP address may already >be forwarded by proxies using the header field X-Forwarded-For, which is >already wideley used. A similar argument is not being used for Section 8.2. >An end-user who want to be anonymus must be aware of these extensions. >Such end-users must also ensure that the used proxy server, thought >being anonymizing, in reality is. > >A proxy server that is intended to anonymize the request should not use >this header field. In cases where the possessor of the proxy want to be >able to trace where requests came from, but do not want to leak the >information further, can use the possibility of obfuscating the client >address." The one before it needs some work. I'll try and explain the point. If the user explicitly chooses a proxy so that the client IP address is not disclosed and the proxy reveals this information through the Forwarded HTTP header field, it is a problem. This is where it can be said that a proxy where such behavior is undesired should not include the Forwarded HTTP header field. Add a note that the if the information can also be revealed through the X-Forwarded-For header field and care must be taken not to include that header field. I hope that the above comments provide a way forward to address the privacy considerations issue. Regards, -sm From andreas@sbin.se Fri Jul 6 04:24:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C6C21F86FD for ; Fri, 6 Jul 2012 04:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLe7fXeD+TUy for ; Fri, 6 Jul 2012 04:24:43 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id CA26921F879A for ; Fri, 6 Jul 2012 04:24:42 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q66BOuYB024770; Fri, 6 Jul 2012 11:24:56 GMT Date: Fri, 6 Jul 2012 13:24:54 +0200 From: Andreas Petersson To: SM Message-ID: <20120706132454.266f6e9d@hetzer> In-Reply-To: <6.2.5.6.2.20120706003649.09b5fb28@resistor.net> References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <4FF4AB6B.6090803@cs.tcd.ie> <20120705141951.3ef8eec7@hetzer> <6.2.5.6.2.20120706003649.09b5fb28@resistor.net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Privacy considerations - draft-ietf-appsawg-http-forwarded-05 (was: Status of draft-ietf-appsawg-http-forwarded-04.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 11:24:44 -0000 On Fri, 06 Jul 2012 02:41:19 -0700 SM wrote: > Hello, > > I'll start with comments about draft-ietf-appsawg-http-forwarded-05 > for context. > > In the Introduction section: > > "In today's HTTP landscape, there are a multitude of different > applications acting as a proxy for the user agent and effectively > anonymizing the requests to look as if they originated from the proxy > IP address or in other ways changing the information in the original > request." This section is somewhat rewritten after comments from AD Barry Leiba. The updated version reads: In today's HTTP landscape, there are a multitude of different applications that act as proxies for the user agents, providing features such as caching, content filtering, content compression, crypto offload, and load balancing. But these proxies make the requests appear as if they originated from the proxy's IP address, or in other ways changing the information in the original request. I don't know if you think this is better or worse, but this based on the suggestion from Barry. For further discussion, please use that version. > This anonymous "feature" is created at the reverse proxy (load > balancing, etc.). It occurs nearer to the user for when content > filtering. In both cases the average user may not be aware of this > "feature". Let's assume that we are customizing the HTTP response > based on the source IP address. There is a problem in the two cases > mentioned about. The "fix" is to have the information forwarded > through a header, e.g. X-Forwarded-For. > > I don't know whether everyone agrees or disagrees that this > unintended feature should be kept as it enhances privacy. I'll > assume that everyone disagrees as it is about the same as saying that > NAT is a security feature. I do not really see your point here. In a reverse proxy environment, I have really hard to see how this would impact on privacy, as both the reverse proxy and the web server are within the same organization. > The draft introduces forwarding and reverse proxies in Section 4: > > "This applies to forwarding proxies, as well as reverse proxies." > > This covers a wider range of proxies than the examples mentioned in Section 1. So your suggestion is that I should also include "reverse proxies" in Section 1? (or is there some other point that I miss here?) > An obfuscated identifier is proposed in Section 6.3: > > "A generated identifier may be used where there is a wish to keep the > internal IP addresses secret while still allowing the Forwarded > header field to be used for tracing." > > Section 8.2 discusses about information leakage: > > "The Forwarded HTTP header field can reveal internal structures of the > network setup behind the NAT or proxy setup, which may be undesired. > This can be addressed either by using obfuscated elements, preventing > the internal nodes from updating the HTTP header field, or by having > an egress proxy removing entries that reveals internal network > This header field should never be copied into response messages by > origin servers or intermediaries, as it can reveal the whole proxy > chain to the client." > > The way this is argued is that in the two cases mentioned above (see > comment about Introduction) there is information leakage together > with a proposal on how to address the problem. > > Section 8.3 is about privacy considerations, i.e. what is a concern > to the user instead of a concern about disclosing information about > infrastructure (Section 8.2). In non-technical discussions, this is > where the argument is about consent (and intent). Although the > proposal ends up with privacy concerns, these concerns are somewhat > of an indirect effect of what has been discussed up to this > subsection as the "forward proxies" cover other cases too. Is this only an informative sort of digest, or is there some critique here, that I fail to understand? :) > At 05:19 05-07-2012, Andreas Petersson wrote: > >My proposal: > > > >"In recent years, there has been growing concerns about privacy. > >There is a tradeoff beteween ensuring privacy for users versus > >disclosing information which is useful for debugging and statistics. > >The Forwarded HTTP header field, by design, exposes information that > >some users consider privacy sensitive. > > The argument here is that this technology exposes information which > the user considers as having an impact on his/her privacy. it's > unrelated to the two cases mentioned above, i.e. the user does not > necessary know about the proxy between him/her and the web > server. Assuming that the user knows, the privacy "feature" is still > a side effect. This text is more or less the same as the one you proposed: In recent years, there has been growing concerns about privacy. There is a tradeoff between ensuring privacy for users versus disclosing information which is useful for debugging. The Forwarded HTTP header field, by design, exposes information which affects the privacy of users. This header field should not be used if the proxy is being operated as a privacy service. Except for the last sentence, which I include later. > > From an end-user perspective, intermediate proxies in the request path > >are either known or unknown. Hidden proxies using this extension will > >preserve the information of a direct connection, and thus it has no > >end-user privacy impact. Proxies that are known to the end-user, > >such as explicitly configured proxies, using this extention may not > >anonymize the end-user IP address. The possessor of such proxy need > >to consider whether, and how, deploying this extension impacts on > >user privacy. > > I suggest looking at this in terms of forward proxies and from a user > perspective. Can you be more concrete? Also notice, that this section is slightly updated, see: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06594.html > >An end-user must also be aware of that the users IP address may already > >be forwarded by proxies using the header field X-Forwarded-For, which is > >already wideley used. > > A similar argument is not being used for Section 8.2. That can be added. > >An end-user who want to be anonymus must be aware of these extensions. > >Such end-users must also ensure that the used proxy server, thought > >being anonymizing, in reality is. > > > >A proxy server that is intended to anonymize the request should not use > >this header field. In cases where the possessor of the proxy want to be > >able to trace where requests came from, but do not want to leak the > >information further, can use the possibility of obfuscating the client > >address." > > The one before it needs some work. I'll try and explain the > point. If the user explicitly chooses a proxy so that the client IP > address is not disclosed and the proxy reveals this information > through the Forwarded HTTP header field, it is a problem. Then the user made the wrong decision. How can a user choose a proxy, with the intention to be anonymized, in some way, without making sure that the proxy has that feature? If the proxy owner adds these fields he will probably also reveal the source IP-address in a legal case or for abuse issues. So: 1. The user U are looking for a proxy server. 2. The constraint is that the proxy server should not disclose the users IP address. 3. Proxy server P discloses users IP addresses. 4. U choses P. 5. Above shows that the user failed to fill his own constraints. I understand your point, and I simply think you are wrong here. > This is > where it can be said that a proxy where such behavior is undesired > should not include the Forwarded HTTP header field. Add a note that > the if the information can also be revealed through the > X-Forwarded-For header field and care must be taken not to include > that header field. It may be undesired by the end user (some of them), but desired by the proxy owner. But for some reason the user did chose to use the proxy. If the intent was to be anonymous, the end user must choose an anonymizing proxy, if the intent was something else, well, then he must weight the benefits and the drawback of that proxy server. My text says: "Proxies that are known to the end-user, such as explicitly configured proxies, using this extention may* not anonymize the end-user IP address. The possessor of such proxy need to consider whether, and how, deploying this extension impacts on user privacy." I think this text is saying what you are discussing? *) I do not intend this "may" to be interpreted as as suggestion to the proxy owner. I want this to simply inform the end user that such behavior exists. Can that be expressed better? > I hope that the above comments provide a way forward to address the > privacy considerations issue. Yes and no. :-) BR, Andreas From stephen.farrell@cs.tcd.ie Fri Jul 6 09:58:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB55A21F8707 for ; Fri, 6 Jul 2012 09:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg7s2pOgbJvr for ; Fri, 6 Jul 2012 09:58:54 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A38F221F86FD for ; Fri, 6 Jul 2012 09:58:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0D5A41714FA; Fri, 6 Jul 2012 17:59:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341593949; bh=PqYM4LKXc9r4Az LhB7bvwFIBAjLSpzt/F2gyJ+VrT+k=; b=ALtNQsFxdfyZvTwAXHMWWL3AX8TtDQ ZPq4EMU3ljsNGbStGSfy7J9sT0xbqXn3waWhn/BAEYDbDQ50pCMtALZng3yMGdYG 9aqXERDCNWPAVqPlg6jFzyhh18nVSbCTFTVvh/JZONhjF6B6a/48V2peEqYIuJaT mbJN7QbFm1HAbjpXPUJX0dxjVTRgCRbrTvyTfYOOupQP+OyTRjsv+vV59QUH8Nlt Wyo8u4Nd0ZQ5ztxF3n9K1A2L6lhvc6Wkk2+55CLzV/C9rU9sr/2rwCXMs7oGuFkE 5UZCJ8yvxizzHDO0Ef97/tq/ZllBgDL61dGuxesoYI4EE3AVMbQTn0ig== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id eTBtDzm0Ophs; Fri, 6 Jul 2012 17:59:09 +0100 (IST) Received: from [IPv6:2001:770:10:203:e993:2cab:e0c2:33e7] (unknown [IPv6:2001:770:10:203:e993:2cab:e0c2:33e7]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A33AE1714F8; Fri, 6 Jul 2012 17:59:09 +0100 (IST) Message-ID: <4FF7195E.7080502@cs.tcd.ie> Date: Fri, 06 Jul 2012 17:59:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <4FF4AB6B.6090803@cs.tcd.ie> <20120705141951.3ef8eec7@hetzer> <6.2.5.6.2.20120706003649.09b5fb28@resistor.net> <20120706132454.266f6e9d@hetzer> In-Reply-To: <20120706132454.266f6e9d@hetzer> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Privacy considerations - draft-ietf-appsawg-http-forwarded-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 16:58:54 -0000 So in some offlist mail Andreas and I (with a bit of help from Barry) arrived at the text below, modulo a couple of issues that I think still need list discussion. (I believe Andreas doesn't think any further changes are needed.) Issue#1: since this header can and will be used for figuring out the user's location (via a geo-ip database), the question arises as to whether the kind of handling of location that geopriv arrived at (see RFC 6280) is required here or not. There are arguments on both sides, so what's right here? Issue#2: Using a static token per user to obfuscate the address allows correlation of all of each user's activities, and that's been shown to be a significantexposure with respect to de-anonymizing the user. On the other hand, changing one user's token from instance to instance removes a significant amount of usefulness from the function, by NOT allowing that sort of correlation. Would it be worth mentioning that so that it's clear why a proxy would *want* the static token, and should an example way to generate such tokens be included in the draft? Cheers, S. 8.3. Privacy considerations In recent years, there have been growing concerns about privacy. There is a trade off between ensuring privacy for users versus disclosing information which is useful for example for debugging, statistics and generating location-dependent content. The Forwarded HTTP header field, by design, exposes information that some users consider privacy sensitive, in order to allow for such uses. Proxies using this extension will preserve the information of a direct connection, which has an end-user privacy impact, if the end- user or deployer doesn't know or expect that this is the case. Implementers and deployers of such proxies need to consider whether, and how, deploying this extension affects user privacy. Note that users' IP addresses may already be forwarded by proxies using the header field X-Forwarded-For, which is widely used. A proxy that needs to be able to trace the source of requests, but that does not want to leak the information further, can obfuscate the client address. When generating such tokens care must be taken not to include potentially sensitive information in the token. When using such tokens, a static token per user would increase the possibility for external organizations to track separate users. From paulej@packetizer.com Fri Jul 6 11:31:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2583911E80A2 for ; Fri, 6 Jul 2012 11:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9E+JQ76D4wx for ; Fri, 6 Jul 2012 11:31:13 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9841311E8079 for ; Fri, 6 Jul 2012 11:31:08 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q66IVOUb011364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 6 Jul 2012 14:31:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341599485; bh=S6Dxb/S0s20FoV+X5JGxF3mh1nav4Su+eN+sJMexQVU=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=RlYBx3WGPM0KXkkJSVw0re2ofoKJxVgNicagFh1SchzD9eoT+y1KspD5HShmWxWuF 3gIZTjHek11/RpMJYdJSJRc0h49O4kW+SPA3QRlRXPR/YIa0TuOtDA4pdIPXJSETEX xQS90aFoXY2x+WG1bj7UC+itUIv5TeUN6b2ANE58= From: "Paul E. Jones" To: Date: Fri, 6 Jul 2012 14:31:35 -0400 Message-ID: <089b01cd5ba5$93996ed0$bacc4c70$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_089C_01CD5B84.0C881CF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1bpImW6vNdKxtAReCYOuU9PP/C1Q== Content-Language: en-us Subject: [apps-discuss] Referencing content on social networking sites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 18:31:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_089C_01CD5B84.0C881CF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, I've often seen people post content on social networking sites like Facebook and Google+ and wondered what logic went into selecting the graphic to use to represent the content and the picture that appeared beside that text. Sometimes the social networking sites do a great job at displaying a good summary and image, but sometimes it's totally wrong. It's common to see headers like this in HTML documents: However, social networking sites do not consistently use that metadata, even when present. I'm not aware of a link relation defined specifically for such referencing purposes. However, something like this might work: Are there existing elements social networking sites follow or should follow? Is there value in recommending how and image and descriptive text are selected? Paul ------=_NextPart_000_089C_01CD5B84.0C881CF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I’ve = often seen people post content on social networking sites like Facebook = and Google+ and wondered what logic went into selecting the graphic to = use to represent the content and the picture that appeared beside that = text.  Sometimes the social networking sites do a great job at = displaying a good summary and image, but sometimes it’s totally = wrong.

 

It’s common to see headers like this in HTML = documents:

  <meta = name=3D”description” content=3D”This is text related = to the page”>

 

However, = social networking sites do not consistently use that metadata, even when = present.

 

I’m not aware of a link relation defined = specifically for such referencing purposes.  However, something = like this might work:

 

   = <link rel=3D”page-graphic” = href=3D”picture_to_display.jpg”>

 

Are there = existing elements social networking sites follow or should follow?  = Is there value in recommending how and image and descriptive text are = selected?

 

Paul

 

------=_NextPart_000_089C_01CD5B84.0C881CF0-- From barryleiba.mailing.lists@gmail.com Fri Jul 6 11:44:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04AF21F86C4 for ; Fri, 6 Jul 2012 11:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPRZbVYcsS8W for ; Fri, 6 Jul 2012 11:44:12 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED2521F86BB for ; Fri, 6 Jul 2012 11:44:12 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so14864645lbb.31 for ; Fri, 06 Jul 2012 11:44:28 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2SwThlXu/SVCbqja+/k0FS0JtapGDPu6vwJIl6J3dDM=; b=j7jVipGll84vSf8/IKjxomCL3tVcKI4HUmfAvuLIOahZ59Y9I4AVEVtx+4dW3LB943 RF3yVIRNjX7PxDL2hWVWIg8YmO8TrDipjgzjmbE9/d3w1BHFFq2RPbuQx4ziGvlqhymc 7cGBDPyiJF30vcDH+yChryH0OzLVozHVHI4JczlXZiLAC/PUOQWHOjD9mgZI3VmXf1Lz cCYL3LebN7LCijVsfiDp8I7KewRzzMDqsc23lWZhaSSBZbjn+gSwNSVsx5GXoKUP/7T/ YBbNBxKpcF2VmkaK+8+YKlj756xu9XujuRXJA/oV7fOL7KbVLbtFyZl1B+C6zf9Xj/hW 0Fkw== MIME-Version: 1.0 Received: by 10.152.108.144 with SMTP id hk16mr31080691lab.2.1341600268639; Fri, 06 Jul 2012 11:44:28 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Fri, 6 Jul 2012 11:44:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jul 2012 14:44:28 -0400 X-Google-Sender-Auth: reJ1rZHc8BvOAwN6cjCvBoZ5ULo Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Cc: "Roy T. Fielding" Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 18:44:13 -0000 Roy Fielding posted the following response on the httpbis mailing list, and I'm re-posting it here, so everyone sees it and so I can respond to it in context. ----------------------------------------------------- Regarding your comments on Forwarded: > Last paragraph of Section 4: >> Given that a proxy wishes to add a Forwarded header field to the >> outgoing request, if the incoming request has no such header field, >> the proxy simply adds the header field with the list of parameters >> desired. If, on the other hand, the incoming request has such a >> header field, the proxy can either add a comma and the list of >> parameters, or add a new instance of the header field. A proxy MAY >> remove all Forwarded header fields from a request. It MUST, however, >> ensure that the correct header field is updated in case of multiple >> Forwarded header fields. > > I find this confusing, I find that confusing too. It should just say that the new value MUST either be appended to the existing field-value or appended as a new field at the end of the header block. > and I question the value of having more than > one way of representing things. Why would a proxy want to add a comma > and a list, rather than adding a new instance? For performance and implementation reasons. Some proxies will store the field-value as a compounded hash of ordered list values until some generic routine writes the value as a single field; some will have already sent the received header fields downstream and thus have no other choice but to append as a new fieled; others will choose to append a separate Forwarded at the end in order to avoid buffer copies or for easier debugging. I don't think an HTTP header field needs to define one way to do it. We have left it unspecific in order to maximize flexibility in implementation. > If a proxy later wants > to selectively remove earlier information, how would it safely do it when > some had been added as list items into another header field? I assume by looking at the information it wants to selectively remove. It would be more common to simply delete the existing field and create a new one on the way downstream. > Doesn't it > complicate things to have to support various combinations? Yes, but that is governed by HTTP/1.1 parsing rules. > How would I > choose between these?: > > Forwarded: for=192.0.2.43,for=198.51.100.17 > > Forwarded: for=192.0.2.43 > Forwarded: for=198.51.100.17 They mean the same thing in HTTP (as in RFC822, MIME, etc.). > You either need to explain the pros and cons, or just provide one way > to do it. I guess I'd want to see a good reason for not just having one > header field per proxy. I realize that existing fields use this > mechanism, but we have a chance to be specific in a new specification. No, we don't. HTTP header fields cannot redefine HTTP parsing. All this field is doing is restating (unnecessarily) the facts implied by the list rule in HTTP field parsing. > It's also very awkward to have punctuation precedence that's backward > from how it works in English (and again, I know this is used elsewhere). > Here, commas are more powerful than semicolons, so you might have > something like this: > > Forwarded: for=192.0.2.43;proto=http,for=198.51.100.17;proto=https > > As someone who reads English, I find the way that gets grouped to be > surprising and unsettling, because I expect the break between "43" and > "proto=http" to be *stronger* than the break after "proto=http", and > it's not. People don't read HTTP header fields. This precedence is a leftover from MIME field parsing and it makes far less sense to create specialized parsers for each new field defined. The only header fields that got it wrong are Cookie and Set-Cookie, which resulted in more interoperability problems than all of the rest of HTTP combined. ....Roy From barryleiba.mailing.lists@gmail.com Fri Jul 6 11:52:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5AB11E808F for ; Fri, 6 Jul 2012 11:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHbhwV8l1P6q for ; Fri, 6 Jul 2012 11:52:54 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0207F11E8079 for ; Fri, 6 Jul 2012 11:52:53 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so14875110lbb.31 for ; Fri, 06 Jul 2012 11:53:10 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AKabR+0F9LVY4uO/3HCHEjmSjCAvjHLoeR4ew2Lye0k=; b=oyB/AwLOrYeXjJF2aBJyy9e0WP0p6+TW+3kRRCEII2403RCZb/sPKosMZuxhEpb1wW yMV4bjq3CQWpCrAgvjkdE8WZgk3p3kCTIJMu7CSkX2nQ0RC4jA/M1Vs9nJFNndRFbNi/ 8MdeThDysZc+FtwIZn3pHmvaoMFDl6gJHPEiUUUIWqcJ2jPfKq9UpMqqt1zSycUUlWDL WyQ+dhwicai9E7p8Wa9F234Sv7MgmTIIE36FO3SrXNCmiuPvFyDqgyaRyhtER7sYXN8A NgzYI4Fy5cfM4dfwH1LEE5GBn/zLGStEY80Wv0t8QbGmuLtCljJ5PMb6au0vLb2IdUUC iMwg== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr30929631lab.40.1341600790228; Fri, 06 Jul 2012 11:53:10 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Fri, 6 Jul 2012 11:53:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jul 2012 14:53:10 -0400 X-Google-Sender-Auth: ss2_kHDV82SNNkUn-8WMzTeE2Co Message-ID: From: Barry Leiba To: Apps Discuss , Andreas Petersson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Julian Reschke , "Roy T. Fielding" , Willy Tarreau Subject: Re: [apps-discuss] draft-ietf-appsawg-http-forwarded-05 issue: multiple copies of Forwarded vs comma-separated list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 18:52:55 -0000 >> Last paragraph of Section 4: >>> =A0 Given that a proxy wishes to add a Forwarded header field to the >>> =A0 outgoing request, if the incoming request has no such header field, >>> =A0 the proxy simply adds the header field with the list of parameters >>> =A0 desired. =A0If, on the other hand, the incoming request has such a >>> =A0 header field, the proxy can either add a comma and the list of >>> =A0 parameters, or add a new instance of the header field. =A0A proxy M= AY >>> =A0 remove all Forwarded header fields from a request. =A0It MUST, howe= ver, >>> =A0 ensure that the correct header field is updated in case of multiple >>> =A0 Forwarded header fields. >> >> I find this confusing, > > I find that confusing too. =A0It should just say that the new value > MUST either be appended to the existing field-value or appended > as a new field at the end of the header block. OK... we need to clean up the text a bit; see below. >> and I question the value of having more than >> one way of representing things. =A0Why would a proxy want to add a comma >> and a list, rather than adding a new instance? > > For performance and implementation reasons. =A0Some proxies will store > the field-value as a compounded hash of ordered list values until some > generic routine writes the value as a single field; some will have alread= y > sent the received header fields downstream and thus have no other > choice but to append as a new fieled; others will choose to append > a separate Forwarded at the end in order to avoid buffer copies > or for easier debugging. > > I don't think an HTTP header field needs to define one way to do it. > We have left it unspecific in order to maximize flexibility in > implementation. I continue to wish that HTTP had not defined the multiple-field-values situation the way it did, but through the course of this conversation with Julian, Willy, and now Roy, I have been convinced that it is defined how it is, and this is not the place to try to deal with that at all. My request now turns into one that asks for tighter text, making the instructions for adding and removing these fields as simple and clearly explained as possible. Andreas, I think you have a bunch of input for this. Please address my other comments along with this one and the result of your wordsmithing with Stephen, and post an -06 version for us to review and -- I hope -- proceed with. If you need help getting the words right for a clearer version of what we're discussing here, post to this thread and I'm sure help will soon arrive. :-) Thanks, everyone, for the input, and for convincing me that I was fighting the wrong battle. Barry From sm@resistor.net Fri Jul 6 12:10:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F5511E80A1 for ; Fri, 6 Jul 2012 12:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9VCFCjpLoi7 for ; Fri, 6 Jul 2012 12:10:26 -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 2287911E809F for ; Fri, 6 Jul 2012 12:10:26 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q66JAaEk000081; Fri, 6 Jul 2012 12:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341601841; bh=5DXsZtSZlqV3jSxImxB1l6O4TjFngnqPNOY+F5dGmEI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=r0jqkcB59XRfGp8k43iYclr6EB3FkDHB0dUeVWtqbDENTB5+3i2fgKpGt+mKOpJ11 b6NV6SKIZULnaX+M0z+EIziJacSOX4tL9saqvSjHeWF3HA7YaOllpJ5E1y5UcTaP5P bIRsm8pMyk+oRuc+7KA60m2FTNx0Dtu78BmmJTgw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341601841; i=@resistor.net; bh=5DXsZtSZlqV3jSxImxB1l6O4TjFngnqPNOY+F5dGmEI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DFwJCZV85DSzAgwB709Uvctppo9wQicZJQETyNA1EiT7nI3Qd4bGA9SiiDMbFy/1E 7iKud0JSMlUWZ1e8Xb/pgLoEPxvcZQf27q+WIHHXLVmTF80/vciMKN3UkwTxHlcPJy TjeZtGgRSNC/2yTyCpz+m2py/cTuHlHb+D5pvZuQ= Message-Id: <6.2.5.6.2.20120706085825.0a1318c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Jul 2012 11:45:36 -0700 To: Andreas Petersson From: SM In-Reply-To: <20120706132454.266f6e9d@hetzer> References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <4FF4AB6B.6090803@cs.tcd.ie> <20120705141951.3ef8eec7@hetzer> <6.2.5.6.2.20120706003649.09b5fb28@resistor.net> <20120706132454.266f6e9d@hetzer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Privacy considerations - draft-ietf-appsawg-http-forwarded-05 (was: Status of draft-ietf-appsawg-http-forwarded-04.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 19:10:29 -0000 Hi Andreas, At 04:24 06-07-2012, Andreas Petersson wrote: >This section is somewhat rewritten after comments from AD Barry Leiba. >The updated version reads: > > In today's HTTP landscape, there are a multitude of different > applications that act as proxies for the user agents, providing > features such as caching, content filtering, content compression, > crypto offload, and load balancing. But these proxies make the > requests appear as if they originated from the proxy's IP address, or > in other ways changing the information in the original request. > >I don't know if you think this is better or worse, but this based on >the suggestion from Barry. >For further discussion, please use that version. I used that section to provide context instead of arguing for it to be changed. The above text is better than what's in draft-ietf-appsawg-http-forwarded-05. >I do not really see your point here. >In a reverse proxy environment, I have really hard to see how this >would impact on privacy, as both the reverse proxy and the web server >are within the same organization. Again, the text I quoted and commented on was for context. It was actually to explain that it does not impact on privacy as they are generally run by the same organization. >So your suggestion is that I should also include "reverse proxies" in >Section 1? (or is there some other point that I miss here?) No. The point was to provide context. >Is this only an informative sort of digest, or is there some critique >here, that I fail to understand? :) Think of it as some informative sort of digest. There is a critique in the RFC Series from the illustrious MAPS. I view it as positive; the IETF will disagree with me as it favors discussions which could be qualified as tweeteresque. There is no such thing as failure. :-) >This text is more or less the same as the one you proposed: Yes, I remember proposing that text. >Can you be more concrete? As in "send text"? :-) >Also notice, that this section is slightly updated, see: >http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06594.html I read the message. I'll comment below. > > A similar argument is not being used for Section 8.2. > >That can be added. In my opinion, it may be better not to. That part of the draft is stable. It's easier to work on the part being discussed. >Then the user made the wrong decision. How can a user choose a proxy, If the user made the wrong decision it's not a problem once appropriate guidance has been provided. >with the intention to be anonymized, in some way, without making sure >that the proxy has that feature? I avoided using the word "anonymized" in my previous message. If I recall correctly my argument was that the client IP address is not being disclosed (the following test may be informative https://panopticlick.eff.org ) >If the proxy owner adds these fields he will probably also reveal the >source IP-address in a legal case or for abuse issues. > >So: >1. The user U are looking for a proxy server. >2. The constraint is that the proxy server should not disclose the > users IP address. >3. Proxy server P discloses users IP addresses. >4. U choses P. >5. Above shows that the user failed to fill his own constraints. > >I understand your point, and I simply think you are wrong here. If some parts of the world there is a risk to the user U if he or she does not carefully assess Item 3. This draft cannot make proxy server P not disclose the user's IP address in a HTTP header field. It cannot protect user U. I may be wrong; I can only point out what I think is a risk. >It may be undesired by the end user (some of them), but desired by >the proxy owner. But for some reason the user did chose to use the >proxy. If the intent was to be anonymous, the end user must choose an >anonymizing proxy, if the intent was something else, well, then he must >weight the benefits and the drawback of that proxy server. Yes. >My text says: >"Proxies that are known to the end-user, >such as explicitly configured proxies, using this extention may* not >anonymize the end-user IP address. The possessor of such proxy need >to consider whether, and how, deploying this extension impacts on >user privacy." > >I think this text is saying what you are discussing? No, it was the "An end-user who want to be anonymous" paragraph. >*) I do not intend this "may" to be interpreted as as suggestion to >the proxy owner. I want this to simply inform the end user that >such behavior exists. Can that be expressed better? Stephen Farrell suggested some text at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06599.html I have been informed through the mailing list that he is an Area Director. It has been said that Area Directors are like Greek gods. I don't have have any inclination to doubt that. :-) The text proposed is better. At 09:59 06-07-2012, Stephen Farrell wrote: >Issue#1: since this header can and will be used for figuring out >the user's location (via a geo-ip database), the question >arises as to whether the kind of handling of location that >geopriv arrived at (see RFC 6280) is required here or not. There >are arguments on both sides, so what's right here? The begs the question of whether the issue should be addressed on this draft or in GEOPRIV. RFC 6280 discusses about the architecture for Location-based services. I suggest some wording along the lines of "if this header field is to collect location information about the user it affects Geopriv" together with an informative reference to RFC 6280. >Issue#2: Using a static token per user to obfuscate the address >allows correlation of all of each user's activities, and that's >been shown to be a significantexposure with respect to >de-anonymizing the user. On the other hand, changing one user's >token from instance to instance removes a significant amount >of usefulness from the function, by NOT allowing that sort >of correlation. Would it be worth mentioning that so that >it's clear why a proxy would *want* the static token, and >should an example way to generate such tokens be included in >the draft? In simple terms, by trying to fix one problem the proposal created a new problem. It's worth discussing about correlation as that static token creates another piece of identifying information. Regards, -sm From behnam@gmail.com Fri Jul 6 13:50:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C94D11E80D3 for ; Fri, 6 Jul 2012 13:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC1MpFZzbu7C for ; Fri, 6 Jul 2012 13:50:41 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A607211E80C2 for ; Fri, 6 Jul 2012 13:50:40 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so15003095lbb.31 for ; Fri, 06 Jul 2012 13:50:57 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=TqN96LMp4hEXnhaKtJdO6I9q6Jo8I6IJccppZMKIGHU=; b=Tcn8CfFXPL+mIaX1VnPMYRwCtWd9AjfWMhdF4kShjqD6KW58CRlwH1XYg4sLZv6XO8 e7qBUIQ5drqlkT/cvZ9JNQ3D2AR9pyi2I4TxTPOEBHj32rcOlHy9LamBwj5ao5GCP9uD 8UKROpZCYB2LI28VHkytuWZmGp8QlEeZNCFx7pZ8xVS+Q6PeqBjet6EGBVjETQLPv0b+ v840sd/Q0sA/ikwBuPEWT8fvYx1p9Tljwvlquo2EHUiBAC4dlbJR+Nxpd06y5VAvjmf3 UI1wULWRkwubyYRU2+r1BBq5mRTLMyAdkYE/uUq8skdUb02dje9ZN6NxIDvaSftiyxyx +14w== Received: by 10.112.42.228 with SMTP id r4mr14041372lbl.4.1341607856957; Fri, 06 Jul 2012 13:50:56 -0700 (PDT) MIME-Version: 1.0 Sender: behnam@gmail.com Received: by 10.112.74.193 with HTTP; Fri, 6 Jul 2012 13:50:16 -0700 (PDT) In-Reply-To: <089b01cd5ba5$93996ed0$bacc4c70$@packetizer.com> References: <089b01cd5ba5$93996ed0$bacc4c70$@packetizer.com> From: Behnam Esfahbod Date: Fri, 6 Jul 2012 16:50:16 -0400 X-Google-Sender-Auth: OVCLwJj2U-C2fMnxqK7LJKKFTF4 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e0cb4efe3390bde9af04c42f6bbb Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Referencing content on social networking sites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 20:50:42 -0000 --e0cb4efe3390bde9af04c42f6bbb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Paul, Facebook uses the Open Graph Protocol. http://ogp.me/ *"The Open Graph protocol enables any web page to become a rich object in a social graph. For instance, this is used on Facebook to allow any web page to have the same functionality as any other object on Facebook."* OTOH, Google has been leading the development of OpenSocial protocol. http://docs.opensocial.org/display/OS/Home *"OpenSocial helps [social web]sites share their social data with the web. Applications that use the OpenSocial APIs can be embedded within a social network itself, or access a site's social data from anywhere on the web."* Of course the good old FOAF project is providing some of these functionalities as well, via the its extensions. http://wiki.foaf-project.org/w/FoafExtensions Best, -Behnam On Fri, Jul 6, 2012 at 2:31 PM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > I=E2=80=99ve often seen people post content on social networking sites li= ke > Facebook and Google+ and wondered what logic went into selecting the > graphic to use to represent the content and the picture that appeared > beside that text. Sometimes the social networking sites do a great job a= t > displaying a good summary and image, but sometimes it=E2=80=99s totally w= rong.**** > > ** ** > > It=E2=80=99s common to see headers like this in HTML documents:**** > > **** > > ** ** > > However, social networking sites do not consistently use that metadata, > even when present.**** > > ** ** > > I=E2=80=99m not aware of a link relation defined specifically for such re= ferencing > purposes. However, something like this might work:**** > > ** ** > > **** > > ** ** > > Are there existing elements social networking sites follow or should > follow? Is there value in recommending how and image and descriptive tex= t > are selected?**** > > ** ** > > Paul**** > > ** ** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --=20 ' =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8= =AF ' Behnam Esfahbod ' http://behnam.esfahbod.info * .. Persian Internet Society * ` * http://persian-isoc.org * o * 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B --e0cb4efe3390bde9af04c42f6bbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

Facebook uses the Open Graph P= rotocol.=C2=A0http://ogp.me/


=

"OpenSocial helps [social web]sites share their social data with th= e web. Applications that use the OpenSocial APIs can be embedded within a s= ocial network itself, or access a site's social data from anywhere on t= he web."

Of course the good old FOAF project is providing = some of these=C2=A0functionalities as well, via the its extensions.=C2=A0h= ttp://wiki.foaf-project.org/w/FoafExtensions

Best,
-Behnam



On Fri, Jul 6, 2012 at 2:31 PM, Paul E. = Jones <paulej@packetizer.com> wrote:

Folks,

=C2=A0

I=E2=80=99ve often seen people post content on socia= l networking sites like Facebook and Google+ and wondered what logic went i= nto selecting the graphic to use to represent the content and the picture t= hat appeared beside that text.=C2=A0 Sometimes the social networking sites = do a great job at displaying a good summary and image, but sometimes it=E2= =80=99s totally wrong.

=C2=A0

It=E2= =80=99s common to see headers like this in HTML documents:

=C2=A0 <meta name=3D=E2=80=9Ddescription=E2=80= =9D content=3D=E2=80=9DThis is text related to the page=E2=80=9D>=

=C2=A0

Howev= er, social networking sites do not consistently use that metadata, even whe= n present.

=C2=A0

=

I=E2=80=99m not aware of a link relation defined specifically for such refe= rencing purposes.=C2=A0 However, something like this might work:<= /u>

=C2=A0

=C2=A0=C2=A0 <link rel=3D=E2=80=9Dpage-graphic=E2=80=9D href=3D=E2=80= =9Dpicture_to_display.jpg=E2=80=9D>

=C2=A0

Are t= here existing elements social networking sites follow or should follow?=C2= =A0 Is there value in recommending how and image and descriptive text are s= elected?

=C2=A0

Paul

=C2=A0


__________________________= _____________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss




--
=C2=A0=C2=A0 =C2=A0'=C2=A0 =C2=A0=C2=A0 =D8=A8=D9=87=D9=86=D8= =A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
=C2=A0 =C2=A0 '=C2=A0= =C2=A0=C2=A0 Behnam Esfahbod
=C2=A0=C2=A0 '=C2=A0 =C2=A0 =C2=A0 http://behnam.esfahb= od.info
=C2=A0 *=C2=A0 .. =C2=A0 Persian Internet Society
=C2=A0*=C2=A0 `=C2=A0 = *=C2=A0 http://persia= n-isoc.org
=C2=A0 * o *=C2=A0=C2=A0 3E7F B4B6 6F4C A8AB 9BB9 7520 57= 01 CA40 259E 0F8B

--e0cb4efe3390bde9af04c42f6bbb-- From paulej@packetizer.com Fri Jul 6 14:13:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BC121F861A for ; Fri, 6 Jul 2012 14:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDDKmI72uPpn for ; Fri, 6 Jul 2012 14:13:48 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2B66F21F8619 for ; Fri, 6 Jul 2012 14:13:48 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q66LE2CI015484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jul 2012 17:14:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341609242; bh=p0BxuXLS044lAYbFN6VGXYjETg/j5kdOcHhnAhZExFs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=L9vn/BfySMk4S7o+8B9H/elBnWb2blPw3xbsxccbrIBF8oQ6C9tHIGvUbfGbiFpVr 5jfjmcS1DvByam4mvrej2vtWmZJ8AuBqjByu96SdmpR7pu4YcOv/xpyg5w62YN6rIp g55bvfWYbvkAIgsl/tFdC1JckHOlC8zBqnS0x3O8= From: "Paul E. Jones" To: "'Behnam Esfahbod'" References: <089b01cd5ba5$93996ed0$bacc4c70$@packetizer.com> In-Reply-To: Date: Fri, 6 Jul 2012 17:14:13 -0400 Message-ID: <08e201cd5bbc$4b911130$e2b33390$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08E3_01CD5B9A.C480D0C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGkKalUO1ItruTz+cg14RIwfrX7PgJPaan4l1ynjCA= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Referencing content on social networking sites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 21:13:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08E3_01CD5B9A.C480D0C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Behnam, =20 I=E2=80=99m not referring to stuff like that. What I=E2=80=99m = referring to is not really related to social networks, per se, but = that=E2=80=99s where I see the problem show up. =20 Let=E2=80=99s say you want to talk about a BBC article and post a link = on Facebook or Google+. The article might have a picture related to the = story and the first paragraph might serve as good text to appear when = including snippets of the article and text when posting such references = on social networking sites or blogs or elsewhere. =20 The problem is that these sites do not always grab the most apropos = image on the page, nor the most appropriate text. In fact, I=E2=80=99ve = seen some very bad =E2=80=9Cmisses=E2=80=9D. =20 So, what I=E2=80=99m thinking is that sites like the BBC, CNN, or even = one=E2=80=99s own personal blog should include a = =E2=80=9Cdescription=E2=80=9D metadata element and a link to an image = that is appropriate for the news article or blog entry to remove that = guesswork. Perhaps the right solution is markup in the HTML document = itself that flags certain content as appropriate. I don=E2=80=99t have = the solution, but it seems like we=E2=80=99re missing some basic = elements that make embedding =E2=80=9Crich references=E2=80=9D (for lack = of a better term) in other sites. =20 Paul =20 From: behnam@gmail.com [mailto:behnam@gmail.com] On Behalf Of Behnam = Esfahbod Sent: Friday, July 06, 2012 4:50 PM To: Paul E. Jones Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Referencing content on social networking = sites =20 Hi Paul, =20 Facebook uses the Open Graph Protocol. http://ogp.me/ =20 "The Open Graph protocol enables any web page to become a rich object in = a social graph. For instance, this is used on Facebook to allow any web = page to have the same functionality as any other object on Facebook." =20 OTOH, Google has been leading the development of OpenSocial protocol. = http://docs.opensocial.org/display/OS/Home =20 "OpenSocial helps [social web]sites share their social data with the = web. Applications that use the OpenSocial APIs can be embedded within a = social network itself, or access a site's social data from anywhere on = the web." =20 Of course the good old FOAF project is providing some of these = functionalities as well, via the its extensions. = http://wiki.foaf-project.org/w/FoafExtensions =20 Best, -Behnam =20 =20 =20 On Fri, Jul 6, 2012 at 2:31 PM, Paul E. Jones = wrote: Folks, =20 I=E2=80=99ve often seen people post content on social networking sites = like Facebook and Google+ and wondered what logic went into selecting = the graphic to use to represent the content and the picture that = appeared beside that text. Sometimes the social networking sites do a = great job at displaying a good summary and image, but sometimes = it=E2=80=99s totally wrong. =20 It=E2=80=99s common to see headers like this in HTML documents: =20 However, social networking sites do not consistently use that metadata, = even when present. =20 I=E2=80=99m not aware of a link relation defined specifically for such = referencing purposes. However, something like this might work: =20 =20 Are there existing elements social networking sites follow or should = follow? Is there value in recommending how and image and descriptive = text are selected? =20 Paul =20 _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss =20 --=20 ' =D8=A8=D9=87=D9=86=D8=A7=D9=85 = =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF ' Behnam Esfahbod ' http://behnam.esfahbod.info * .. Persian Internet Society * ` * http://persian-isoc.org * o * 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B =20 ------=_NextPart_000_08E3_01CD5B9A.C480D0C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Behnam,

 

I=E2=80=99m not referring to stuff like that.=C2=A0 What I=E2=80=99m = referring to is not really related to social networks, per se, but = that=E2=80=99s where I see the problem show up.

 

Let=E2=80=99s say you want to talk about a BBC article and post a = link on Facebook or Google+.=C2=A0 The article might have a picture = related to the story and the first paragraph might serve as good text to = appear when including snippets of the article and text when posting such = references on social networking sites or blogs or = elsewhere.

 

The problem is that these sites do not always grab the most apropos = image on the page, nor the most appropriate text.=C2=A0 In fact, = I=E2=80=99ve seen some very bad = =E2=80=9Cmisses=E2=80=9D.

 

So, what I=E2=80=99m thinking is that sites like the BBC, CNN, or = even one=E2=80=99s own personal blog should include a = =E2=80=9Cdescription=E2=80=9D metadata element and a link to an image = that is appropriate for the news article or blog entry to remove that = guesswork.=C2=A0 Perhaps the right solution is markup in the HTML = document itself that flags certain content as appropriate.=C2=A0 I = don=E2=80=99t have the solution, but it seems like we=E2=80=99re missing = some basic elements that make embedding =E2=80=9Crich = references=E2=80=9D (for lack of a better term) in other = sites.

 

Paul

 

From:= = behnam@gmail.com [mailto:behnam@gmail.com] On Behalf Of Behnam = Esfahbod
Sent: Friday, July 06, 2012 4:50 PM
To: = Paul E. Jones
Cc: apps-discuss@ietf.org
Subject: Re: = [apps-discuss] Referencing content on social networking = sites

 

Hi = Paul,

 

Facebook uses the Open Graph Protocol. http://ogp.me/

 

"The Open Graph protocol enables any web page = to become a rich object in a social graph. For instance, this is used on = Facebook to allow any web page to have the same functionality as any = other object on Facebook."

 

OTOH, Google has been leading the development of = OpenSocial protocol. http://docs.opensocial.org/display/OS/Home

 

"OpenSocial helps [social web]sites share = their social data with the web. Applications that use the OpenSocial = APIs can be embedded within a social network itself, or access a site's = social data from anywhere on the = web."

 

Of course the good old FOAF project is providing some = of these functionalities as well, via the its extensions. http://wiki.foaf-project.org/w/FoafExtensions<= /o:p>

 

Best,

-Behnam

 

 

 

On Fri, = Jul 6, 2012 at 2:31 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

I=E2=80=99ve= often seen people post content on social networking sites like Facebook = and Google+ and wondered what logic went into selecting the graphic to = use to represent the content and the picture that appeared beside that = text.  Sometimes the social networking sites do a great job at = displaying a good summary and image, but sometimes it=E2=80=99s totally = wrong.

 <= /o:p>

It=E2=80=99s= common to see headers like this in HTML documents:

  = <meta name=3D=E2=80=9Ddescription=E2=80=9D content=3D=E2=80=9DThis is = text related to the page=E2=80=9D>

 <= /o:p>

However, = social networking sites do not consistently use that metadata, even when = present.

 <= /o:p>

I=E2=80=99m = not aware of a link relation defined specifically for such referencing = purposes.  However, something like this might = work:

 <= /o:p>

  = <link rel=3D=E2=80=9Dpage-graphic=E2=80=9D = href=3D=E2=80=9Dpicture_to_display.jpg=E2=80=9D>

 <= /o:p>

Are there = existing elements social networking sites follow or should follow?  = Is there value in recommending how and image and descriptive text are = selected?

 

Paul

 


______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>



 

-- =

    '  =    =D8=A8=D9=87=D9=86=D8=A7=D9=85 = =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
    '  =    Behnam Esfahbod
   '      http://behnam.esfahbod.info
  *  .. =   Persian Internet Society
 *  `  *  http://persian-isoc.org
  * o = *   3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E = 0F8B

 

------=_NextPart_000_08E3_01CD5B9A.C480D0C0-- From bob@wyman.us Fri Jul 6 14:27:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3893A11E80F3 for ; Fri, 6 Jul 2012 14:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQCmy3Y2jQoV for ; Fri, 6 Jul 2012 14:27:16 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6372D11E808F for ; Fri, 6 Jul 2012 14:27:16 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so17469858obb.31 for ; Fri, 06 Jul 2012 14:27:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=E/fEq0T+1W+mGYsSeZ8nZPw+iG2h/4OizSijIOkcQts=; b=NwDmtR8uaXlE8njJSrS1hTDEJyFhDi/6wsn6rj+0L3tzlNPBp+kxhV1dA6HOmwUeIk 7qhcM8LYJxsBPJWBZxj0n2Avh8F5PZl0r3YZ3mlaffhVP3fR5tEWxUJzONTE5lqLotLS aftEqI0dv0a1AKHGM7vhjWHg40Vi3DPT7vtN+KVU0ksj69/tVeQBjgW/pyH7fONW6vSE G2s5fdq4XYnXP0jtgxU0KZCy5cSS5WSoG1ylvLDbN/YohQx8nmJerbxMY853oDosibTz XdCg5LAN/Yoo0eXIt3woBkS4ttkvJ/zY3hMfvo0KYZ2pzFCU/Qgzm4ACWOOSy905QzkJ LVQA== MIME-Version: 1.0 Received: by 10.182.136.71 with SMTP id py7mr27590455obb.45.1341610053473; Fri, 06 Jul 2012 14:27:33 -0700 (PDT) Received: by 10.60.36.200 with HTTP; Fri, 6 Jul 2012 14:27:33 -0700 (PDT) Received: by 10.60.36.200 with HTTP; Fri, 6 Jul 2012 14:27:33 -0700 (PDT) In-Reply-To: <089b01cd5ba5$93996ed0$bacc4c70$@packetizer.com> References: <089b01cd5ba5$93996ed0$bacc4c70$@packetizer.com> Date: Fri, 6 Jul 2012 17:27:33 -0400 Message-ID: From: Bob Wyman To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f5039caaa13e104c42fee09 X-Gm-Message-State: ALoCoQlMBca2JaWVCK3qH8obfhhJMS0oETD1/3rJeGeSbuSTzwP01qYXyeZu+0IbB17VWNl0r/14 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Referencing content on social networking sites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 21:27:17 -0000 --e89a8f5039caaa13e104c42fee09 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Are you looking for something like rich snippets? http://googlewebmastercentral.blogspot.com/2009/05/introducing-rich-snippet= s.html?m=3D1 On Jul 6, 2012 2:31 PM, "Paul E. Jones" wrote: > Folks,**** > > ** ** > > I=92ve often seen people post content on social networking sites like > Facebook and Google+ and wondered what logic went into selecting the > graphic to use to represent the content and the picture that appeared > beside that text. Sometimes the social networking sites do a great job a= t > displaying a good summary and image, but sometimes it=92s totally wrong.*= *** > > ** ** > > It=92s common to see headers like this in HTML documents:**** > > **** > > ** ** > > However, social networking sites do not consistently use that metadata, > even when present.**** > > ** ** > > I=92m not aware of a link relation defined specifically for such referenc= ing > purposes. However, something like this might work:**** > > ** ** > > ***= * > > ** ** > > Are there existing elements social networking sites follow or should > follow? Is there value in recommending how and image and descriptive tex= t > are selected?**** > > ** ** > > Paul**** > > ** ** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --e89a8f5039caaa13e104c42fee09 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Are you looking for something like rich snippets?=A0 http://googlewebmastercentral.blogspot.com/2009/05/introd= ucing-rich-snippets.html?m=3D1

On Jul 6, 2012 2:31 PM, "Paul E. Jones"= ; <paulej@packetizer.com>= ; wrote:

Folks,

=A0

I=92ve often seen people post content on social network= ing sites like Facebook and Google+ and wondered what logic went into selec= ting the graphic to use to represent the content and the picture that appea= red beside that text.=A0 Sometimes the social networking sites do a great j= ob at displaying a good summary and image, but sometimes it=92s totally wro= ng.

=A0

It=92s c= ommon to see headers like this in HTML documents:

=A0 <meta name=3D=94description=94 content=3D=94This is t= ext related to the page=94>

=A0

However,= social networking sites do not consistently use that metadata, even when p= resent.

=A0

I=92m not aware of a link relation defined specifically for such referencin= g purposes.=A0 However, something like this might work:

=A0

=A0=A0 <= ;link rel=3D=94page-graphic=94 href=3D=94picture_to_display.jpg=94>

=A0

Are ther= e existing elements social networking sites follow or should follow?=A0 Is = there value in recommending how and image and descriptive text are selected= ?

=A0

Paul<= /u>

=A0


_= ______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--e89a8f5039caaa13e104c42fee09-- From stephen.farrell@cs.tcd.ie Fri Jul 6 14:28:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D42611E811F for ; Fri, 6 Jul 2012 14:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3ONSxUNkocR for ; Fri, 6 Jul 2012 14:28:13 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E248311E808F for ; Fri, 6 Jul 2012 14:28:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 725871714FA; Fri, 6 Jul 2012 22:28:27 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341610106; bh=Xw/CcQxTU9M0v1 9n7CLdQ+3jRWVgRGi7LSQ8/1PF3nc=; b=IZP1/vlUQ9UaahoZ/wx+a2jJZ86Ud+ 9Xn8bgw4Tm5H5hKqVthZxYe012u6jEW8fG/UkF3bcobBOdiqeCt8UrcG+x04yweq IPdbCLN6riJsLq74UfDMoUltanTihtLozHK6IMYB5upNxCkB6VM3ImuePtJYNnMv sse4ZiG51naILPfa7ZXig7eZqQdrKruXdYzoPLXfvZJdOqX1/jholx/HmkhG0bFo 3y0KrTfXS1g1v1Zg7VQj5b+G7eoZAPkFjo72hEswQuoE1sdoJ0PtC8jSQjny47CT unyInKAJrgIr0XAzVB30LpexHge5NkCwttqAZ6SgJ7bAEc77vnrgXgbA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id vsCDGJs-MY8m; Fri, 6 Jul 2012 22:28:26 +0100 (IST) Received: from [10.87.48.11] (unknown [86.46.18.161]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 942E01714F9; Fri, 6 Jul 2012 22:28:25 +0100 (IST) Message-ID: <4FF75879.4050104@cs.tcd.ie> Date: Fri, 06 Jul 2012 22:28:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: SM References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <4FF4AB6B.6090803@cs.tcd.ie> <20120705141951.3ef8eec7@hetzer> <6.2.5.6.2.20120706003649.09b5fb28@resistor.net> <20120706132454.266f6e9d@hetzer> <6.2.5.6.2.20120706085825.0a1318c8@resistor.net> In-Reply-To: <6.2.5.6.2.20120706085825.0a1318c8@resistor.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Privacy considerations - draft-ietf-appsawg-http-forwarded-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 21:28:20 -0000 On 07/06/2012 07:45 PM, SM wrote: >> > > Stephen Farrell suggested some text at > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06599.html > I have been informed through the mailing list that he is an Area > Director. It has been said that Area Directors are like Greek gods. I > don't have have any inclination to doubt that. :-) The text proposed is > better. s/Greek god/Irish atheist/ :-) > At 09:59 06-07-2012, Stephen Farrell wrote: >> Issue#1: since this header can and will be used for figuring out >> the user's location (via a geo-ip database), the question >> arises as to whether the kind of handling of location that >> geopriv arrived at (see RFC 6280) is required here or not. There >> are arguments on both sides, so what's right here? > > The begs the question of whether the issue should be addressed on this > draft or in GEOPRIV. RFC 6280 discusses about the architecture for > Location-based services. I suggest some wording along the lines of "if > this header field is to collect location information about the user it > affects Geopriv" together with an informative reference to RFC 6280. I don't think an informative reference solves this. It might be useful, but I think it ought be unnecessary to refer to 6280 or else normative, depending on where the consensus ends up. The question for me boils down to whether an IP address as used here is a location object in geopriv terms or not. Personally, I'm not sure. >> Issue#2: Using a static token per user to obfuscate the address >> allows correlation of all of each user's activities, and that's >> been shown to be a significantexposure with respect to >> de-anonymizing the user. On the other hand, changing one user's >> token from instance to instance removes a significant amount >> of usefulness from the function, by NOT allowing that sort >> of correlation. Would it be worth mentioning that so that >> it's clear why a proxy would *want* the static token, and >> should an example way to generate such tokens be included in >> the draft? > > In simple terms, by trying to fix one problem the proposal created a new > problem. It's worth discussing about correlation as that static token > creates another piece of identifying information. Right. I can understand the authors preferring to say less on this rather than more. But maybe more is needed? S. From behnam@gmail.com Fri Jul 6 14:29:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204FB11E8125 for ; Fri, 6 Jul 2012 14:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.147 X-Spam-Level: X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBXZI5toBDnH for ; Fri, 6 Jul 2012 14:29:30 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 747D411E808F for ; Fri, 6 Jul 2012 14:29:21 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so15039097lbb.31 for ; Fri, 06 Jul 2012 14:29:38 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=VchS9iHn6F0WSxdSHhtgG7ggsACEydkSkOLosjOMwkU=; b=xo3pRWufOiQesDTOJtJ5BRJmG9sLVHmdeqc6Jh+Vg6dbhPsfY1oAU+qLsJLgrPhNId V+QoT3L+O/4DI9Gh8HWUbHnX0qIDug8sbYdDlv90q66COP3gLDsV7OZymbL70Xa6eBBH tk/ZCy7Es8kxyY3udqsoudP3QdWWlGo40sdOR523mAKiGVm+ph7W3m+m68JcxWrWxf8D /D6NmX3ueDDBnohtyCbo+nVGMAG8LqwnRtz6CUvi7jANdEeFuRmYbfL1BKd7jssZuXbv U15kQ6UOLDQiWjFeeiSbKLGia9UJMokDjHjb4HB1AljIx+tdzrRp6KL+/yuIaAxAnxr5 t2EA== Received: by 10.112.42.228 with SMTP id r4mr14084900lbl.4.1341610177718; Fri, 06 Jul 2012 14:29:37 -0700 (PDT) MIME-Version: 1.0 Sender: behnam@gmail.com Received: by 10.112.74.193 with HTTP; Fri, 6 Jul 2012 14:28:57 -0700 (PDT) In-Reply-To: <08e201cd5bbc$4b911130$e2b33390$@packetizer.com> References: <089b01cd5ba5$93996ed0$bacc4c70$@packetizer.com> <08e201cd5bbc$4b911130$e2b33390$@packetizer.com> From: Behnam Esfahbod Date: Fri, 6 Jul 2012 17:28:57 -0400 X-Google-Sender-Auth: 4rbl5qX0Y4WceoiItq_7Wl4CbuU Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e0cb4efe339011e8d404c42ff668 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Referencing content on social networking sites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 21:29:32 -0000 --e0cb4efe339011e8d404c42ff668 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul, OpenGraph allows the website owner to define various data to be used by social networks, like the title, normative URL, an image, etc. For example, if you look at the HTML "head" section of this NYTimes page [1] you can see that many "meta" tags are defined with their "property" attribute starting with "og:". That mean whenever a social-network likes to make a link to this page, they can use the hint and use "U.N. Affirms Internet Freedom as a Basic Right" as the title of the link (as meta og:title tag says), "http://graphics8.nytimes.com/gfx/blogs/bits/bits75.gif= " for the image (as meta og:image tag says), etc. 1: http://bits.blogs.nytimes.com/2012/07/06/so-the-united-nations-affirms-inte= rnet-freedom-as-a-basic-right-now-what/ Now, if a social website does NOT grab the best image for a link, that's because the website hasn't told the social website what image to pick. If they like to do so, they can: using the protocols I mentioned. So, is this what you are talking about? Or you are only curious about the cases that websites do NOT provide any "social data" and you are thinking about better methods to handle those cases? -Behnam On Fri, Jul 6, 2012 at 5:14 PM, Paul E. Jones wrote= : > Behnam,**** > > ** ** > > I=E2=80=99m not referring to stuff like that. What I=E2=80=99m referring= to is not really > related to social networks, per se, but that=E2=80=99s where I see the pr= oblem show > up.**** > > ** ** > > Let=E2=80=99s say you want to talk about a BBC article and post a link on= Facebook > or Google+. The article might have a picture related to the story and th= e > first paragraph might serve as good text to appear when including snippet= s > of the article and text when posting such references on social networking > sites or blogs or elsewhere.**** > > ** ** > > The problem is that these sites do not always grab the most apropos image > on the page, nor the most appropriate text. In fact, I=E2=80=99ve seen s= ome very > bad =E2=80=9Cmisses=E2=80=9D.**** > > ** ** > > So, what I=E2=80=99m thinking is that sites like the BBC, CNN, or even on= e=E2=80=99s own > personal blog should include a =E2=80=9Cdescription=E2=80=9D metadata ele= ment and a link to > an image that is appropriate for the news article or blog entry to remove > that guesswork. Perhaps the right solution is markup in the HTML documen= t > itself that flags certain content as appropriate. I don=E2=80=99t have t= he > solution, but it seems like we=E2=80=99re missing some basic elements tha= t make > embedding =E2=80=9Crich references=E2=80=9D (for lack of a better term) i= n other sites.*** > * > > ** ** > > Paul**** > > ** ** > > *From:* behnam@gmail.com [mailto:behnam@gmail.com] *On Behalf Of *Behnam > Esfahbod > *Sent:* Friday, July 06, 2012 4:50 PM > *To:* Paul E. Jones > *Cc:* apps-discuss@ietf.org > *Subject:* Re: [apps-discuss] Referencing content on social networking > sites**** > > ** ** > > Hi Paul,**** > > ** ** > > Facebook uses the Open Graph Protocol. http://ogp.me/**** > > ** ** > > *"The Open Graph protocol enables any web page to become a rich object in > a social graph. For instance, this is used on Facebook to allow any web > page to have the same functionality as any other object on Facebook."****= * > > ** ** > > OTOH, Google has been leading the development of OpenSocial protocol. > http://docs.opensocial.org/display/OS/Home**** > > ** ** > > *"OpenSocial helps [social web]sites share their social data with the > web. Applications that use the OpenSocial APIs can be embedded within a > social network itself, or access a site's social data from anywhere on th= e > web."***** > > ** ** > > Of course the good old FOAF project is providing some of > these functionalities as well, via the its extensions. > http://wiki.foaf-project.org/w/FoafExtensions**** > > ** ** > > Best,**** > > -Behnam**** > > ** ** > > ** ** > > ** ** > > On Fri, Jul 6, 2012 at 2:31 PM, Paul E. Jones > wrote:**** > > Folks,**** > > **** > > I=E2=80=99ve often seen people post content on social networking sites li= ke > Facebook and Google+ and wondered what logic went into selecting the > graphic to use to represent the content and the picture that appeared > beside that text. Sometimes the social networking sites do a great job a= t > displaying a good summary and image, but sometimes it=E2=80=99s totally w= rong.**** > > **** > > It=E2=80=99s common to see headers like this in HTML documents:**** > > **** > > **** > > However, social networking sites do not consistently use that metadata, > even when present.**** > > **** > > I=E2=80=99m not aware of a link relation defined specifically for such re= ferencing > purposes. However, something like this might work:**** > > **** > > **** > > **** > > Are there existing elements social networking sites follow or should > follow? Is there value in recommending how and image and descriptive tex= t > are selected?**** > > **** > > Paul**** > > **** > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss**** > > > > **** > > ** ** > > -- **** > > ' =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87=D8=A8= =D8=AF > ' Behnam Esfahbod > ' http://behnam.esfahbod.info > * .. Persian Internet Society > * ` * http://persian-isoc.org > * o * 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B**** > > ** ** > --=20 ' =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8= =AF ' Behnam Esfahbod ' http://behnam.esfahbod.info * .. Persian Internet Society * ` * http://persian-isoc.org * o * 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B --e0cb4efe339011e8d404c42ff668 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Paul,

OpenGraph allows the website owne= r to define various data to be used by social networks, like the title, nor= mative URL, an image, etc.

For example, if you loo= k at the HTML "head" section of this NYTimes page [1] you can see= that many "meta" tags are defined with their "property"= ; attribute starting with "og:". That mean whenever a social-netw= ork likes to make a link to this page, they can use the hint and use "= U.N. Affirms Internet Freedom as a Basic Right" as the title of the li= nk (as meta og:title tag says), "http://graphics8.nytimes.com/gfx/blogs/bits/b= its75.gif" for the image (as meta og:image tag says), etc.


Now, if a social website does NOT grab the best image f= or a link, that's because the website hasn't told the social websit= e what image to pick. If they like to do so, they can: using the protocols = I mentioned.

So, is this what you are talking about? Or you are only= curious about the cases that websites do NOT provide any "social data= " and you are thinking about better methods to handle those cases?

-Behnam


On Fri, Jul 6, 2012 at 5:14 PM, Paul E. Jones &l= t;paulej@packeti= zer.com> wrote:

Behnam,

=C2=A0

I=E2=80=99m not ref= erring to stuff like that.=C2=A0 What I=E2=80=99m referring to is not reall= y related to social networks, per se, but that=E2=80=99s where I see the pr= oblem show up.

=C2=A0

Let=E2=80=99s say y= ou want to talk about a BBC article and post a link on Facebook or Google+.= =C2=A0 The article might have a picture related to the story and the first = paragraph might serve as good text to appear when including snippets of the= article and text when posting such references on social networking sites o= r blogs or elsewhere.

=C2=A0

The problem is that= these sites do not always grab the most apropos image on the page, nor the= most appropriate text.=C2=A0 In fact, I=E2=80=99ve seen some very bad =E2= =80=9Cmisses=E2=80=9D.

=C2=A0

So, what I=E2=80=99= m thinking is that sites like the BBC, CNN, or even one=E2=80=99s own perso= nal blog should include a =E2=80=9Cdescription=E2=80=9D metadata element an= d a link to an image that is appropriate for the news article or blog entry= to remove that guesswork.=C2=A0 Perhaps the right solution is markup in th= e HTML document itself that flags certain content as appropriate.=C2=A0 I d= on=E2=80=99t have the solution, but it seems like we=E2=80=99re missing som= e basic elements that make embedding =E2=80=9Crich references=E2=80=9D (for= lack of a better term) in other sites.

=C2=A0

Paul<= /span>

=C2=A0

From: behnam@gmail.co= m [mailto:behnam@= gmail.com] On Behalf Of Behnam Esfahbod
Sent: Friday, July 06, 2012 4:50 PM
To: Paul E. Jones
<= b>Cc: apps-d= iscuss@ietf.org
Subject: Re: [apps-discuss] Referencing conte= nt on social networking sites

=C2=A0<= /u>

Hi Paul,

=C2=A0

Fa= cebook uses the Open Graph Protocol.=C2=A0http://ogp.me/

=C2=A0

"The Open Graph protocol enables any web page to b= ecome a rich object in a social graph. For instance, this is used on Facebo= ok to allow any web page to have the same functionality as any other object= on Facebook."

=C2=A0

<= p class=3D"MsoNormal">OTOH, Google has been leading the development of Open= Social protocol.=C2=A0http://docs.opensocial.org/display/OS/Home

=C2=A0

<= p class=3D"MsoNormal">"OpenSocial helps [social web]sites share the= ir social data with the web. Applications that use the OpenSocial APIs can = be embedded within a social network itself, or access a site's social d= ata from anywhere on the web."

=C2=A0

=

Of course the good old FOAF project is providing som= e of these=C2=A0functionalities as well, via the its extensions.=C2=A0http= ://wiki.foaf-project.org/w/FoafExtensions

=C2=A0

Best,

-= Behnam

=C2=A0<= /u>

=C2=A0

=C2=A0

On Fri, Jul 6, 2012 at= 2:31 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=C2=A0

I=E2=80=99ve often seen= people post content on social networking sites like Facebook and Google+ a= nd wondered what logic went into selecting the graphic to use to represent = the content and the picture that appeared beside that text.=C2=A0 Sometimes= the social networking sites do a great job at displaying a good summary an= d image, but sometimes it=E2=80=99s totally wrong.

=C2=A0

It=E2= =80=99s common to see headers like this in HTML documents:

=C2=A0 <meta name=3D=E2=80=9Ddescription=E2=80= =9D content=3D=E2=80=9DThis is text related to the page=E2=80=9D>=

=C2=A0

Howev= er, social networking sites do not consistently use that metadata, even whe= n present.

=C2=A0

=

I=E2=80=99m not aware of a link relation defined specifically for such refe= rencing purposes.=C2=A0 However, something like this might work:<= /u>

=C2=A0

=C2=A0=C2=A0 <link rel=3D=E2=80=9Dpage-graphic=E2=80=9D href=3D=E2=80= =9Dpicture_to_display.jpg=E2=80=9D>

=C2=A0

Are t= here existing elements social networking sites follow or should follow?=C2= =A0 Is there value in recommending how and image and descriptive text are s= elected?

=C2=A0

Paul

=C2=A0=


_____= __________________________________________
apps-discuss mailing list
= apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /p>



=C2=A0

--

<= div>

=C2=A0=C2=A0 =C2=A0'=C2=A0 =C2=A0=C2=A0 =D8= =A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
=C2=A0 = =C2=A0 '=C2=A0 =C2=A0=C2=A0 Behnam Esfahbod
=C2=A0=C2=A0 '=C2=A0= =C2=A0 =C2=A0 ht= tp://behnam.esfahbod.info
=C2=A0 *=C2=A0 .. =C2=A0 Persian Internet Society
=C2=A0*=C2=A0 `=C2=A0 = *=C2=A0 http://persia= n-isoc.org
=C2=A0 * o *=C2=A0=C2=A0 3E7F B4B6 6F4C A8AB 9BB9 7520 57= 01 CA40 259E 0F8B

=C2=A0




--
=C2= =A0=C2=A0 =C2=A0'=C2=A0 =C2=A0=C2=A0 =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8= =A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
=C2=A0 =C2=A0 '=C2=A0 =C2=A0=C2=A0= Behnam Esfahbod
=C2=A0=C2=A0 '=C2=A0 =C2=A0 =C2=A0 http://behnam.esfahbod.info =C2=A0 *=C2=A0 .. =C2=A0 Persian Internet Society
=C2=A0*=C2=A0 `=C2=A0 = *=C2=A0 http://persia= n-isoc.org
=C2=A0 * o *=C2=A0=C2=A0 3E7F B4B6 6F4C A8AB 9BB9 7520 57= 01 CA40 259E 0F8B

--e0cb4efe339011e8d404c42ff668-- From paulej@packetizer.com Fri Jul 6 15:04:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE3E11E80CD for ; Fri, 6 Jul 2012 15:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[AWL=-1.492, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLdwWxcuDhmz for ; Fri, 6 Jul 2012 15:04:28 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7A71511E8127 for ; Fri, 6 Jul 2012 15:04:28 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q66M4hpV017745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jul 2012 18:04:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341612284; bh=n1/zmNfK7faZoxJGnG1xtHaCc8CDbksRFsUcmyD+MI4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=q/6CE5ir2WQyuA448PeL5EczPqSCLfSpSRMeZ2jcYsDZYSj69L7ru5pqdu3URxi+0 CYZPQb4VewCGDZsTqIYB85YkFwrros7byCkrvQq8/Xu8jWVHkUhL9Cv4FWtiPbsc3M GHKP09ci1V7yrOS4Crp+g81ia4hdv+88rCoB4zQA= From: "Paul E. Jones" To: "'Behnam Esfahbod'" References: <089b01cd5ba5$93996ed0$bacc4c70$@packetizer.com> <08e201cd5bbc$4b911130$e2b33390$@packetizer.com> In-Reply-To: Date: Fri, 6 Jul 2012 18:04:55 -0400 Message-ID: <093a01cd5bc3$605c3b60$2114b220$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_093B_01CD5BA1.D94C9730" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGkKalUO1ItruTz+cg14RIwfrX7PgJPaan4Ac4amHIBdvcHj5dCj1/Q Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Referencing content on social networking sites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 22:04:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_093B_01CD5BA1.D94C9730 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Behnam, =20 Ah! Yes, that=E2=80=99s exactly it. I apologize. I assumes OG was = just to query via an API. I didn=E2=80=99t realize it also defined = certain markup. =20 Paul =20 From: behnam@gmail.com [mailto:behnam@gmail.com] On Behalf Of Behnam = Esfahbod Sent: Friday, July 06, 2012 5:29 PM To: Paul E. Jones Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Referencing content on social networking = sites =20 Paul, =20 OpenGraph allows the website owner to define various data to be used by = social networks, like the title, normative URL, an image, etc. =20 For example, if you look at the HTML "head" section of this NYTimes page = [1] you can see that many "meta" tags are defined with their "property" = attribute starting with "og:". That mean whenever a social-network likes = to make a link to this page, they can use the hint and use "U.N. Affirms = Internet Freedom as a Basic Right" as the title of the link (as meta = og:title tag says), = "http://graphics8.nytimes.com/gfx/blogs/bits/bits75.gif" for the image = (as meta og:image tag says), etc. =20 1: = http://bits.blogs.nytimes.com/2012/07/06/so-the-united-nations-affirms-in= ternet-freedom-as-a-basic-right-now-what/ =20 Now, if a social website does NOT grab the best image for a link, that's = because the website hasn't told the social website what image to pick. = If they like to do so, they can: using the protocols I mentioned. =20 So, is this what you are talking about? Or you are only curious about = the cases that websites do NOT provide any "social data" and you are = thinking about better methods to handle those cases? =20 -Behnam =20 =20 On Fri, Jul 6, 2012 at 5:14 PM, Paul E. Jones = wrote: Behnam, =20 I=E2=80=99m not referring to stuff like that. What I=E2=80=99m = referring to is not really related to social networks, per se, but = that=E2=80=99s where I see the problem show up. =20 Let=E2=80=99s say you want to talk about a BBC article and post a link = on Facebook or Google+. The article might have a picture related to the = story and the first paragraph might serve as good text to appear when = including snippets of the article and text when posting such references = on social networking sites or blogs or elsewhere. =20 The problem is that these sites do not always grab the most apropos = image on the page, nor the most appropriate text. In fact, I=E2=80=99ve = seen some very bad =E2=80=9Cmisses=E2=80=9D. =20 So, what I=E2=80=99m thinking is that sites like the BBC, CNN, or even = one=E2=80=99s own personal blog should include a = =E2=80=9Cdescription=E2=80=9D metadata element and a link to an image = that is appropriate for the news article or blog entry to remove that = guesswork. Perhaps the right solution is markup in the HTML document = itself that flags certain content as appropriate. I don=E2=80=99t have = the solution, but it seems like we=E2=80=99re missing some basic = elements that make embedding =E2=80=9Crich references=E2=80=9D (for lack = of a better term) in other sites. =20 Paul =20 From: behnam@gmail.com [mailto:behnam@gmail.com] On Behalf Of Behnam = Esfahbod Sent: Friday, July 06, 2012 4:50 PM To: Paul E. Jones Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Referencing content on social networking = sites =20 Hi Paul, =20 Facebook uses the Open Graph Protocol. http://ogp.me/ =20 "The Open Graph protocol enables any web page to become a rich object in = a social graph. For instance, this is used on Facebook to allow any web = page to have the same functionality as any other object on Facebook." =20 OTOH, Google has been leading the development of OpenSocial protocol. = http://docs.opensocial.org/display/OS/Home =20 "OpenSocial helps [social web]sites share their social data with the = web. Applications that use the OpenSocial APIs can be embedded within a = social network itself, or access a site's social data from anywhere on = the web." =20 Of course the good old FOAF project is providing some of these = functionalities as well, via the its extensions. = http://wiki.foaf-project.org/w/FoafExtensions =20 Best, -Behnam =20 =20 =20 On Fri, Jul 6, 2012 at 2:31 PM, Paul E. Jones = wrote: Folks, =20 I=E2=80=99ve often seen people post content on social networking sites = like Facebook and Google+ and wondered what logic went into selecting = the graphic to use to represent the content and the picture that = appeared beside that text. Sometimes the social networking sites do a = great job at displaying a good summary and image, but sometimes = it=E2=80=99s totally wrong. =20 It=E2=80=99s common to see headers like this in HTML documents: =20 However, social networking sites do not consistently use that metadata, = even when present. =20 I=E2=80=99m not aware of a link relation defined specifically for such = referencing purposes. However, something like this might work: =20 =20 Are there existing elements social networking sites follow or should = follow? Is there value in recommending how and image and descriptive = text are selected? =20 Paul =20 _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss =20 --=20 ' =D8=A8=D9=87=D9=86=D8=A7=D9=85 = =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF ' Behnam Esfahbod ' http://behnam.esfahbod.info * .. Persian Internet Society * ` * http://persian-isoc.org * o * 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B =20 =20 --=20 ' =D8=A8=D9=87=D9=86=D8=A7=D9=85 = =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF ' Behnam Esfahbod ' http://behnam.esfahbod.info * .. Persian Internet Society * ` * http://persian-isoc.org * o * 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B =20 ------=_NextPart_000_093B_01CD5BA1.D94C9730 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Behnam,

 

Ah!=C2=A0 Yes, that=E2=80=99s exactly it.=C2=A0 I apologize.=C2=A0 I = assumes OG was just to query via an API.=C2=A0 I didn=E2=80=99t realize = it also defined certain markup.

 

Paul

 

From:= = behnam@gmail.com [mailto:behnam@gmail.com] On Behalf Of Behnam = Esfahbod
Sent: Friday, July 06, 2012 5:29 PM
To: = Paul E. Jones
Cc: apps-discuss@ietf.org
Subject: Re: = [apps-discuss] Referencing content on social networking = sites

 

Paul,

 

OpenGraph allows the website owner to define various = data to be used by social networks, like the title, normative URL, an = image, etc.

 

For example, if you look at the HTML "head" = section of this NYTimes page [1] you can see that many "meta" = tags are defined with their "property" attribute starting with = "og:". That mean whenever a social-network likes to make a = link to this page, they can use the hint and use "U.N. Affirms = Internet Freedom as a Basic Right" as the title of the link (as = meta og:title tag says), "http://gr= aphics8.nytimes.com/gfx/blogs/bits/bits75.gif" for the image = (as meta og:image tag says), etc.

 

 

Now, if a social website does NOT grab the best image = for a link, that's because the website hasn't told the social website = what image to pick. If they like to do so, they can: using the protocols = I mentioned.

 

So, is this what you are talking about? Or you are = only curious about the cases that websites do NOT provide any = "social data" and you are thinking about better methods to = handle those cases?

 

-Behnam

 

 

On Fri, = Jul 6, 2012 at 5:14 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Behnam,

 

I=E2=80=99m not referring to stuff like that.  What I=E2=80=99m = referring to is not really related to social networks, per se, but = that=E2=80=99s where I see the problem show up.

 

Let=E2=80=99s say you want to talk about a BBC article and post a = link on Facebook or Google+.  The article might have a picture = related to the story and the first paragraph might serve as good text to = appear when including snippets of the article and text when posting such = references on social networking sites or blogs or = elsewhere.

 

The problem is that these sites do not always grab the most apropos = image on the page, nor the most appropriate text.  In fact, = I=E2=80=99ve seen some very bad = =E2=80=9Cmisses=E2=80=9D.

 

So, what I=E2=80=99m thinking is that sites like the BBC, CNN, or = even one=E2=80=99s own personal blog should include a = =E2=80=9Cdescription=E2=80=9D metadata element and a link to an image = that is appropriate for the news article or blog entry to remove that = guesswork.  Perhaps the right solution is markup in the HTML = document itself that flags certain content as appropriate.  I = don=E2=80=99t have the solution, but it seems like we=E2=80=99re missing = some basic elements that make embedding =E2=80=9Crich = references=E2=80=9D (for lack of a better term) in other = sites.

 

Paul

 

From:= = behnam@gmail.com [mailto:behnam@gmail.com] = On Behalf Of Behnam Esfahbod
Sent: Friday, July 06, = 2012 4:50 PM
To: Paul E. Jones
Cc: apps-discuss@ietf.org
Subject: Re: = [apps-discuss] Referencing content on social networking = sites

 <= /o:p>

Hi = Paul,

 <= /o:p>

Facebook = uses the Open Graph Protocol. http://ogp.me/

 <= /o:p>

"The= Open Graph protocol enables any web page to become a rich object in a = social graph. For instance, this is used on Facebook to allow any web = page to have the same functionality as any other object on = Facebook."

 <= /o:p>

OTOH, = Google has been leading the development of OpenSocial protocol. http://docs.opensocial.org/display/OS/Home

 <= /o:p>

"Ope= nSocial helps [social web]sites share their social data with the web. = Applications that use the OpenSocial APIs can be embedded within a = social network itself, or access a site's social data from anywhere on = the web."

 <= /o:p>

Of course = the good old FOAF project is providing some of = these functionalities as well, via the its extensions. http://wiki.foaf-project.org/w/FoafExtensions<= /o:p>

 <= /o:p>

Best,

-Behnam=

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Fri, Jul = 6, 2012 at 2:31 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

I=E2=80=99ve= often seen people post content on social networking sites like Facebook = and Google+ and wondered what logic went into selecting the graphic to = use to represent the content and the picture that appeared beside that = text.  Sometimes the social networking sites do a great job at = displaying a good summary and image, but sometimes it=E2=80=99s totally = wrong.

 <= /o:p>

It=E2=80=99s= common to see headers like this in HTML documents:

  = <meta name=3D=E2=80=9Ddescription=E2=80=9D content=3D=E2=80=9DThis is = text related to the page=E2=80=9D>

 <= /o:p>

However, = social networking sites do not consistently use that metadata, even when = present.

 <= /o:p>

I=E2=80=99m = not aware of a link relation defined specifically for such referencing = purposes.  However, something like this might = work:

 <= /o:p>

  = <link rel=3D=E2=80=9Dpage-graphic=E2=80=9D = href=3D=E2=80=9Dpicture_to_display.jpg=E2=80=9D>

 <= /o:p>

Are there = existing elements social networking sites follow or should follow?  = Is there value in recommending how and image and descriptive text are = selected?

 

Paul

 


______________= _________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>



 <= /o:p>

-- =

  =  '     =D8=A8=D9=87=D9=86=D8=A7=D9=85 = =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
    '  =    Behnam Esfahbod
   '      http://behnam.esfahbod.info
  *  .. =   Persian Internet Society
 *  `  *  http://persian-isoc.org
  * o = *   3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E = 0F8B

 <= /o:p>



 

-- =

    '  =    =D8=A8=D9=87=D9=86=D8=A7=D9=85 = =D8=A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
    '  =    Behnam Esfahbod
   '      http://behnam.esfahbod.info
  *  .. =   Persian Internet Society
 *  `  *  http://persian-isoc.org
  * o = *   3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E = 0F8B

 

------=_NextPart_000_093B_01CD5BA1.D94C9730-- From paulej@packetizer.com Fri Jul 6 15:07:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA2F11E8143 for ; Fri, 6 Jul 2012 15:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz7Sag+5XFUH for ; Fri, 6 Jul 2012 15:07:53 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC2811E80CD for ; Fri, 6 Jul 2012 15:07:53 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q66M896D017844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jul 2012 18:08:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341612490; bh=WcEPI0Jr5nuVGJ3IdMIPP1Y/AYdbo8RyCciLNKWgmjM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=QCikejB5A2CDx/7Q7FiBv/5A3FpCGGIJXw+Tczy4mWbjj348w+BsnutjZcN8DO0gD /n/1rJ3nflanb8IOe5xITT/86LRK4clNm90U/ZvQRCmihXEZYipQuVNRvcjDCAQBW0 1LGbObTEAzcpAs12IurdaKuhubcSu8tgdKPF1OOM= From: "Paul E. Jones" To: "'Bob Wyman'" References: <089b01cd5ba5$93996ed0$bacc4c70$@packetizer.com> In-Reply-To: Date: Fri, 6 Jul 2012 18:08:21 -0400 Message-ID: <094701cd5bc3$db272b20$91758160$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0948_01CD5BA2.54169C90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGkKalUO1ItruTz+cg14RIwfrX7PgERxzNwl2albaA= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Referencing content on social networking sites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 22:07:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0948_01CD5BA2.54169C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit No, I was looking for something like this: That's exactly the kind of thing I was looking for, but I do wonder how pervasive this will become. Is this being standardized? Paul From: Bob Wyman [mailto:bobwyman@gmail.com] Sent: Friday, July 06, 2012 5:22 PM To: Paul E. Jones Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Referencing content on social networking sites Are you looking for something like "rich snippets?" http://googlewebmastercentral.blogspot.com/2009/05/introducing-rich-snippets .html?m=1 bob wyman On Jul 6, 2012 2:31 PM, "Paul E. Jones" wrote: Folks, I've often seen people post content on social networking sites like Facebook and Google+ and wondered what logic went into selecting the graphic to use to represent the content and the picture that appeared beside that text. Sometimes the social networking sites do a great job at displaying a good summary and image, but sometimes it's totally wrong. It's common to see headers like this in HTML documents: However, social networking sites do not consistently use that metadata, even when present. I'm not aware of a link relation defined specifically for such referencing purposes. However, something like this might work: Are there existing elements social networking sites follow or should follow? Is there value in recommending how and image and descriptive text are selected? Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_0948_01CD5BA2.54169C90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, I was looking for something like this:

 

<meta property=3D"og:title" content=3D"U.N. Affirms = Internet Freedom as a Basic Right" />

 

<meta property=3D"og:type" content=3D"article" = />

 

<meta property=3D"og:url" = content=3D"http://bits.blogs.nytimes.com/2012/07/06/so-the-united-na= tions-affirms-internet-freedom-as-a-basic-right-now-what/" = /><meta property=3D"og:site_name" content=3D"Bits = Blog" />

 

<meta property=3D"og:description" content=3D"The = United Nations Human Rights Council passed a nonbinding resolution that = supports Internet freedom, leaving Internet companies to decide how much = to collaborate with government authorities in the tracking of = citizens." />

 

<meta property=3D"og:image" = content=3D"http://graphics8.nytimes.com/gfx/blogs/bits/bits75.gif&qu= ot;/>

 

That’s exactly the kind of thing I was looking for, but I do = wonder how pervasive this will become.  Is this being = standardized?

 

Paul

 

 

From:= = Bob Wyman [mailto:bobwyman@gmail.com]
Sent: Friday, July 06, = 2012 5:22 PM
To: Paul E. Jones
Cc: = apps-discuss@ietf.org
Subject: Re: [apps-discuss] Referencing = content on social networking sites

 

Are you looking for something = like "rich snippets?" http://googlewebmastercentral.blogspot.com/2009/0= 5/introducing-rich-snippets.html?m=3D1

bob = wyman

On Jul 6, 2012 2:31 PM, = "Paul E. Jones" <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

I’ve = often seen people post content on social networking sites like Facebook = and Google+ and wondered what logic went into selecting the graphic to = use to represent the content and the picture that appeared beside that = text.  Sometimes the social networking sites do a great job at = displaying a good summary and image, but sometimes it’s totally = wrong.

 <= /o:p>

It’s = common to see headers like this in HTML documents:

  = <meta name=3D”description” content=3D”This is text = related to the page”>

 <= /o:p>

However, = social networking sites do not consistently use that metadata, even when = present.

 <= /o:p>

I’m = not aware of a link relation defined specifically for such referencing = purposes.  However, something like this might = work:

 <= /o:p>

  = <link rel=3D”page-graphic” = href=3D”picture_to_display.jpg”>

 <= /o:p>

Are there = existing elements social networking sites follow or should follow?  = Is there value in recommending how and image and descriptive text are = selected?

 <= /o:p>

Paul

 <= /o:p>


______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

------=_NextPart_000_0948_01CD5BA2.54169C90-- From internet-drafts@ietf.org Fri Jul 6 16:24:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E20511E80BE; Fri, 6 Jul 2012 16:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrDWU1aOTgqB; Fri, 6 Jul 2012 16:24:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93ADA21F859E; Fri, 6 Jul 2012 16:23:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p2 Message-ID: <20120706232351.4506.97044.idtracker@ietfa.amsl.com> Date: Fri, 06 Jul 2012 16:23:51 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-jones-simple-web-discovery-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 23:24:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Simple Web Discovery (SWD) Author(s) : Michael B. Jones Yaron Y. Goland Filename : draft-jones-simple-web-discovery-03.txt Pages : 10 Date : 2012-07-06 Abstract: Simple Web Discovery (SWD) defines an HTTPS GET based mechanism to discover the location of a given type of service for a given principal starting only with a domain name. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jones-simple-web-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-jones-simple-web-discovery-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-jones-simple-web-discovery-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Jones@microsoft.com Fri Jul 6 16:37:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA7411E8093 for ; Fri, 6 Jul 2012 16:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.276 X-Spam-Level: X-Spam-Status: No, score=-5.276 tagged_above=-999 required=5 tests=[AWL=1.322, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSqDpLJ6SgNV for ; Fri, 6 Jul 2012 16:37:21 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 56C3311E8089 for ; Fri, 6 Jul 2012 16:37:21 -0700 (PDT) Received: from mail134-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 23:35:29 +0000 Received: from mail134-va3 (localhost [127.0.0.1]) by mail134-va3-R.bigfish.com (Postfix) with ESMTP id 6CF7F180322; Fri, 6 Jul 2012 23:35:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zzc85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail134-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail134-va3 (localhost.localdomain [127.0.0.1]) by mail134-va3 (MessageSwitch) id 1341617727510879_12191; Fri, 6 Jul 2012 23:35:27 +0000 (UTC) Received: from VA3EHSMHS041.bigfish.com (unknown [10.7.14.247]) by mail134-va3.bigfish.com (Postfix) with ESMTP id 6E54636005B; Fri, 6 Jul 2012 23:35:27 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS041.bigfish.com (10.7.99.51) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 23:35:27 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Fri, 6 Jul 2012 23:37:35 +0000 From: Mike Jones To: "apps-discuss@ietf.org" Thread-Topic: Updated Simple Web Discovery (SWD) Specification Thread-Index: Ac1b0EyAcPaXuGBuSOiGR3vxHnsclA== Date: Fri, 6 Jul 2012 23:37:34 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657A9F8@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436657A9F8TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Julian Reschke Subject: [apps-discuss] Updated Simple Web Discovery (SWD) Specification X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 23:37:23 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436657A9F8TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've updated the Simple Web Discovery (SWD) specification to incorporate editorial improv= ements suggested by Julian Reschke and to apply applicable editorial improv= ements also recently made to the JOSE= specifications. No normative changes were made. The updated specification is available at: * http://tools.ietf.org/html/draft-jones-simple-web-discovery-03 Changes made were: * Changed "requests use the x-www-form-urlencoded format" to "reque= sts use query parameters" and changed "an x-www-form-urlencoded form" to "a= form encoded using the application/x-www-form-urlencoded encoding algorith= m", both at the suggestion of Julian Reschke. * Updated examples to use "urn:example:" URNs rather than "urn:exam= ple.org:" URNs, also at Julian's suggestion. * Applied applicable editorial improvements from JOSE specs to SWD. * Updated references to related specifications. -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436657A9F8TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve updated the Simple Web Discovery (SWD) specification to incorporate editorial impro= vements suggested by Julian Reschke and to apply applicable editorial impro= vements also recently made to the JOSE specifications.&n= bsp; No normative changes were made.

 

The updated specification is available at:

·         http://tools.ietf.org/html/draft-jones-simpl= e-web-discovery-03

 

Changes made were:

·         Changed "requests use the x-www-form-ur= lencoded format" to "requests use query parameters" and chan= ged "an x-www-form-urlencoded form" to "a form encoded using= the application/x-www-form-urlencoded encoding algorithm", both at the suggestion of Julian Reschke.

·         Updated examples to use "urn:example:&q= uot; URNs rather than "urn:example.org:" URNs, also at Julian's s= uggestion.

·         Applied applicable editorial improvements fr= om JOSE specs to SWD.

·         Updated references to related specifications= .

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739436657A9F8TK5EX14MBXC283r_-- From sm@resistor.net Sat Jul 7 01:41:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851FC21F8541 for ; Sat, 7 Jul 2012 01:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.039 X-Spam-Level: X-Spam-Status: No, score=-102.039 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH4h4J3Ygzbg for ; Sat, 7 Jul 2012 01:41:48 -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 95F2421F84BD for ; Sat, 7 Jul 2012 01:41:48 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q678fsQ7015738; Sat, 7 Jul 2012 01:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341650521; bh=cEnGPfxSyLylkWF9JFMgaAn+Mg+iKsEwBC088WucSoQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lUVGoZwfNVmEFL3CdC4VWTWiYF0R9HTbBqIIJzbIcto2UthYOwHKS3ScJUadyMvTp YFxwIjVvPLKWjU7a16/BGWtCDYh+hbhwwgrpRkyBlMTK4a11xxzeFG7NcDlGBx9dpL v6XmSqhfzD5IFxhjbxhQwjIxt9ParFY5w1tPKrWE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341650521; i=@resistor.net; bh=cEnGPfxSyLylkWF9JFMgaAn+Mg+iKsEwBC088WucSoQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Np9b+0cZ8fVC9DAlOah/u2miGTPri3IqcWqfMI8iLWpOJ3PeN+W6U6ZiehpaXRHoQ p/wmMqXBpaEjDuhwZUwRZ+Vd4lLPpdrx2laN7SHQo/iEbZnK+9aVlQkh3Gk15MFp9d LJWiYI7SXBnuu37rdZ0aMiQX9mpzSYzz3fvxn764= Message-Id: <6.2.5.6.2.20120706182508.0809b5c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Jul 2012 19:26:21 -0700 To: Stephen Farrell From: SM In-Reply-To: <4FF75879.4050104@cs.tcd.ie> References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <4FF4AB6B.6090803@cs.tcd.ie> <20120705141951.3ef8eec7@hetzer> <6.2.5.6.2.20120706003649.09b5fb28@resistor.net> <20120706132454.266f6e9d@hetzer> <6.2.5.6.2.20120706085825.0a1318c8@resistor.net> <4FF75879.4050104@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Privacy considerations - draft-ietf-appsawg-http-forwarded-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2012 08:41:51 -0000 Hi Stephen, At 14:28 06-07-2012, Stephen Farrell wrote: >s/Greek god/Irish atheist/ :-) :-) >I don't think an informative reference solves this. It might >be useful, but I think it ought be unnecessary to refer to 6280 >or else normative, depending on where the consensus ends up. > >The question for me boils down to whether an IP address >as used here is a location object in geopriv terms or not. >Personally, I'm not sure. RFC 6280 defines a location object as: "A data unit that conveys location information together with Privacy Rules within the Geopriv architecture. A Location Object may convey geodetic location data (latitude, longitude, altitude), civic location data (street, city, state, etc.), or both." Section 3.1 of RFC 6155 mentions IP Address as an identifier. It's not clear how to equate IP address as used in this draft and the usage in Geopriv. I suggest not considering Geopriv unless someone wants to make a case for it. >Right. I can understand the authors preferring to say >less on this rather than more. But maybe more is needed? As starting text (borrowed from RFC 4941): One of the requirements for correlating seemingly unrelated activities is the use (and reuse) of an identifier that is recognizable over time within different contexts. Using the generated identifier (Section 6.3) has implications for privacy if it is not randomly generated for each request. Regards, -sm From sm@resistor.net Sat Jul 7 02:36:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746FB21F859A for ; Sat, 7 Jul 2012 02:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH6Z3b4pCpzL for ; Sat, 7 Jul 2012 02:36:34 -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 0D23421F8594 for ; Sat, 7 Jul 2012 02:36:33 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q679akBK023460 for ; Sat, 7 Jul 2012 02:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341653812; bh=ohboPEa2H7J15/VzTT9+lUboIAYrqIateoRQUMji2wA=; h=Date:To:From:Subject:Cc; b=J/FxQ4GXX7iomyaKpx2iIngbjr19qncK23NPcHqwLuo5sVH/d2U+CFyfr47upv8EL 5+MBBb1NrcVBKCwr8gnwZLlCxnfn+bUqHdazet6XqbFBuD2WQG87hwPxS0GPIpPh85 WR48yBU+6I8Bt/m6OXgsubi0rhSoTNA5es90lyh0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341653812; i=@resistor.net; bh=ohboPEa2H7J15/VzTT9+lUboIAYrqIateoRQUMji2wA=; h=Date:To:From:Subject:Cc; b=skfxxwY+tyCajX/e2g3lpHytHUr4mr5pgptDBipCLb8PjWt2QBzaKnzxmrbqGgUUM 9R2Ql/M+7BKpb411dchKkBlHF8EJ75PVF2CX8XblDlEMc3GHq3etbuutZnbJtK5IGb xL2+QI0k5i5gWb03JAkYorV7smAdZhZbvVbgciWY= Message-Id: <6.2.5.6.2.20120707015014.084dd0c0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 07 Jul 2012 02:31:10 -0700 To: apps-discuss@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] A newcomer question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2012 09:36:38 -0000 Hi APPSAWG, After reading the Tao, I am given to understand that I can approach you with a newcomer question. The APPSAWG charter mentions that: "a core team of WG participants with sufficient energy and expertise to advance the proposed work item according to the proposed schedule" as one of the factors in accepting new work. Is there any informal description of how that "energy and expertise" might be assessed for future proposals? What would be the proposed schedule for future proposals? Are there any practices the APPSAWG working group follows for acknowledgements? Regards, -sm From laurentwalter.goix@telecomitalia.it Sat Jul 7 03:43:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B947321F855B for ; Sat, 7 Jul 2012 03:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.285 X-Spam-Level: X-Spam-Status: No, score=-1.285 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4mDuI6UG8Gp for ; Sat, 7 Jul 2012 03:43:18 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id D6C7A21F855D for ; Sat, 7 Jul 2012 03:43:17 -0700 (PDT) Content-Type: multipart/mixed; boundary="_9dab6eb7-f77f-45d5-9f22-f8d2ae5e7bc4_" Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Sat, 7 Jul 2012 12:43:28 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Sat, 7 Jul 2012 12:43:27 +0200 From: Goix Laurent Walter To: William Mills , Peter Saint-Andre , Phillip Hallam-Baker Date: Sat, 7 Jul 2012 12:43:29 +0200 Thread-Topic: [apps-discuss] the need for acct (was: Re: Looking at Webfinger) Thread-Index: Ac1ZQWRfDdWcnWmlTPSnj6kw0mEkNgC6nh3g Message-ID: References: <4FF31849.6040504@stpeter.im> <1341336549.84355.YahooMailNeo@web31812.mail.mud.yahoo.com> In-Reply-To: <1341336549.84355.YahooMailNeo@web31812.mail.mud.yahoo.com> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: Mark Nottingham , IETF Apps Discuss Subject: [apps-discuss] R: the need for acct (was: Re: Looking at Webfinger) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2012 10:43:19 -0000 --_9dab6eb7-f77f-45d5-9f22-f8d2ae5e7bc4_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A16673C9GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A16673C9GRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I do think there are many potential usages of the acct: URI, besides WF. In particular there are many placeholders of IRIs already appropriate for a= cct: URIs. Atom feeds (and the related ActivityStreams), the ActivityStream= s JSON format, and even the OpenSocial API URI syntax make use of IRIs for = identifying users (or in general entities, should this be a group, a place,= etc). Originally many blogging platforms exporting rss/atom feeds have been using= the mailto: uri for identifying authors as this has been the most popular = at that time. However, most of such platforms did not offer email service a= nd sometimes email accounts provided in such feeds where actually referring= to a different domain, which is of course still acceptable. The rise of social networking services have made even more popular such use= r-related feeds where account identifiers are disjoints from the mailto nam= espace/service (or xmpp etc) and where acct: URIs are the most appropriate = identifier. walter Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Pe= r conto di William Mills Inviato: marted=EC 3 luglio 2012 19.29 A: Peter Saint-Andre; Phillip Hallam-Baker Cc: Mark Nottingham; IETF Apps Discuss Oggetto: Re: [apps-discuss] the need for acct (was: Re: Looking at Webfinge= r) For describing why we need acct: I come back to the previous discussion whe= re the point was made almost exactly that xmpp:, mailto: and others have sp= ecific contexts and in the context of Webfinger are appropriate for discove= ring information about that specific context. The acct: scheme satisfies t= he need for "I need information about this user" when it's not in the conte= xt of a specific applicaiton protocol. ________________________________ From: Peter Saint-Andre To: Phillip Hallam-Baker Cc: Mark Nottingham ; IETF Apps Discuss Sent: Tuesday, July 3, 2012 9:05 AM Subject: [apps-discuss] the need for acct (was: Re: Looking at Webfinger) On 7/3/12 8:52 AM, Phillip Hallam-Baker wrote: > The place where I would see acct: being used in WebFinger is actually > more the data structures being returned. So for example if I am > looking up my friends profile, I would probably want to see their > battle.net accounts listed there along with their other stuff. > > WebFinger would still be a way to resolve acct: URIs, but only one way > and the http: transport might only be one option. > > If I click on an acct: link in a browser I would have a range of > possible options: > * Grab the public WebFinger data > * Grab the profile data exposed to me by virtue of me being a friend. > * Attempt to connect on chat Don't we have xmpp: for that? > * Attempt to send an email Don't we have mailto: for that? You're saying that acct: would be a general identifier and that applications could attempt many different kinds of interactions with that account, using specific protocols like SMTP or XMPP. But deciding whether to attempt such interactions would depend on knowing if the service provider actually offers email service, IM service, public profiles, microblogging, etc. Presumably that information could be discovered via WebFinger (for a particular account), but I wouldn't assume that one can send email to an account simply because an acct: URI exists. > I would expect there to be a default action but that choice is > something the user would probably make. It seems that the default action would be discovery. > The place I would be using acct: identifiers is in the authentication > and authorization layer. Describing those use cases more completely would help us decide whether we really need the 'acct' URI scheme. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE53A16673C9GRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I do think there are many potential usages of the acct: URI,= besides WF.

In particular there are many placeholders of IRIs already ap= propriate for acct: URIs. Atom feeds (and the related ActivityStreams), the= ActivityStreams JSON format, and even the OpenSocial API URI syntax make use of IRIs for i= dentifying users (or in general entities, should this be a group, a place, = etc).

 

Originally many blogging platforms exporting rss/atom feeds = have been using the mailto: uri for identifying authors as this has been th= e most popular at that time. However, most of such platforms did not offer email = service and sometimes email accounts provided in such feeds where actually = referring to a different domain, which is of course still acceptable.<= /o:p>

The rise of social networking services have made even more p= opular such user-related feeds where account identifiers are disjoints from= the mailto namespace/service (or xmpp etc) and where acct: URIs are the most appropri= ate identifier.

 

walter

 

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounce= s@ietf.org] Per conto di William Mills
Inviato: marted=EC 3 luglio 2012 19.29
A: Peter Saint-Andre; Phillip Hallam-Baker
Cc: Mark Nottingham; IETF Apps Discuss
Oggetto: Re: [apps-discuss] the need for acct (was: Re: Looking at W= ebfinger)

 

For describing why we need= acct: I come back to the previous discussion where the point was made almo= st exactly that xmpp:, mailto: and others have specific contexts and in the context of Webfinger are appropriate for= discovering information about that specific context.  The acct: schem= e satisfies the need for "I need information about this user" whe= n it's not in the context of a specific applicaiton protocol.

 

From: Peter Saint-Andre <stpeter@stpeter.im>=
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>; IETF Apps Discuss <app= s-discuss@ietf.org>
Sent: Tuesday, July 3, 2012 9:05 AM
Subject: [apps-discuss] the need for acct (was: Re: Looking at Webfi= nger)


On 7/3/12 8:52 AM, Phillip Hallam-Baker wrote:

> The place where I would see acct: being used in WebFinger is actually<= br> > more the data structures being returned. So for example if I am
> looking up my friends profile, I would probably want to see their
> battle.net accounts listed there along with their other stuff.
>
> WebFinger would still be a way to resolve acct: URIs, but only one way=
> and the http: transport might only be one option.
>
> If I click on an acct: link in a browser I would have a range of
> possible options:
>    * Grab the public WebFinger data
>    * Grab the profile data exposed to me by virtue of me bei= ng a friend.
>    * Attempt to connect on chat

Don't we have xmpp: for that?

>    * Attempt to send an email

Don't we have mailto: for that?

You're saying that acct: would be a general identifier and that
applications could attempt many different kinds of interactions with
that account, using specific protocols like SMTP or XMPP. But deciding
whether to attempt such interactions would depend on knowing if the
service provider actually offers email service, IM service, public
profiles, microblogging, etc. Presumably that information could be
discovered via WebFinger (for a particular account), but I wouldn't
assume that one can send email to an account simply because an acct: URI exists.

> I would expect there to be a default action but that choice is
> something the user would probably make.

It seems that the default action would be discovery.

> The place I would be using acct: identifiers is in the authentication<= br> > and authorization layer.

Describing those use cases more completely would help us decide whether
we really need the 'acct' URI scheme.

Peter

--
Peter Saint-Andre
https://stpeter.im/



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

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A16673C9GRFMBX704BA02_-- --_9dab6eb7-f77f-45d5-9f22-f8d2ae5e7bc4_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_9dab6eb7-f77f-45d5-9f22-f8d2ae5e7bc4_-- From laurentwalter.goix@telecomitalia.it Sat Jul 7 03:58:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894D021F84B9 for ; Sat, 7 Jul 2012 03:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Log-t7RxDmal for ; Sat, 7 Jul 2012 03:58:06 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 991BF21F84B3 for ; Sat, 7 Jul 2012 03:58:05 -0700 (PDT) Content-Type: multipart/mixed; boundary="_6b7cad8e-5504-4562-a475-e4d8e10397f7_" Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Sat, 7 Jul 2012 12:58:17 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Sat, 7 Jul 2012 12:58:16 +0200 From: Goix Laurent Walter To: "Paul E. Jones" , 'Bob Wyman' Date: Sat, 7 Jul 2012 12:58:16 +0200 Thread-Topic: [apps-discuss] Referencing content on social networking sites Thread-Index: AQGkKalUO1ItruTz+cg14RIwfrX7PgERxzNwl2albaCAANQ8AA== Message-ID: References: <089b01cd5ba5$93996ed0$bacc4c70$@packetizer.com> <094701cd5bc3$db272b20$91758160$@packetizer.com> In-Reply-To: <094701cd5bc3$db272b20$91758160$@packetizer.com> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] R: Referencing content on social networking sites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2012 10:58:09 -0000 --_6b7cad8e-5504-4562-a475-e4d8e10397f7_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A16673CCGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A16673CCGRFMBX704BA02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Paul, I guess the closest specification to this is the Microformats/microdata/rdf= a effort that have been evolving for years now and is now mostly supported = by the schema.org [1] project. These are understood by the major search engines or social sites to "extrac= t" metadata from a web page, for example to display title & thumbnail when = sharing or in a search result snippet. Is it what you are looking at? walter [1] http://schema.org/ Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Pe= r conto di Paul E. Jones Inviato: sabato 7 luglio 2012 0.08 A: 'Bob Wyman' Cc: apps-discuss@ietf.org Oggetto: Re: [apps-discuss] Referencing content on social networking sites No, I was looking for something like this: That's exactly the kind of thing I was looking for, but I do wonder how per= vasive this will become. Is this being standardized? Paul From: Bob Wyman [mailto:bobwyman@gmail.com] Sent: Friday, July 06, 2012 5:22 PM To: Paul E. Jones Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Referencing content on social networking sites Are you looking for something like "rich snippets?" http://googlewebmasterc= entral.blogspot.com/2009/05/introducing-rich-snippets.html?m=3D1 bob wyman On Jul 6, 2012 2:31 PM, "Paul E. Jones" > wrote: Folks, I've often seen people post content on social networking sites like Faceboo= k and Google+ and wondered what logic went into selecting the graphic to us= e to represent the content and the picture that appeared beside that text. = Sometimes the social networking sites do a great job at displaying a good = summary and image, but sometimes it's totally wrong. It's common to see headers like this in HTML documents: However, social networking sites do not consistently use that metadata, eve= n when present. I'm not aware of a link relation defined specifically for such referencing = purposes. However, something like this might work: Are there existing elements social networking sites follow or should follow= ? Is there value in recommending how and image and descriptive text are se= lected? Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non ? necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE53A16673CCGRFMBX704BA02_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Paul,

 

I guess the closest specification to this is the Microformat= s/microdata/rdfa effort that have been evolving for years now and is now mo= stly supported by the schema.org [1] project.

These are understood by the major search engines or social s= ites to “extract” metadata from a web page, for example to disp= lay title & thumbnail when sharing or in a search result snippet.

 

Is it what you are looking at?

walter

 

[1] http://schema.org/

 

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounce= s@ietf.org] Per conto di Paul E. Jones
Inviato: sabato 7 luglio 2012 0.08
A: 'Bob Wyman'
Cc: apps-discuss@ietf.org
Oggetto: Re: [apps-discuss] Referencing content on social networking= sites

 

No, I was looking for something like this:=

 

<meta property=3D"og:title" content=3D"U.N= . Affirms Internet Freedom as a Basic Right" />

 

<meta property=3D"og:type" content=3D"arti= cle" />

 

<meta property=3D"og:url" content=3D"http:= //bits.blogs.nytimes.com/2012/07/06/so-the-united-nations-affirms-internet-= freedom-as-a-basic-right-now-what/" /><meta property=3D"og:site_name" content=3D"Bits Blo= g" />

 

<meta property=3D"og:description" content=3D&qu= ot;The United Nations Human Rights Council passed a nonbinding resolution t= hat supports Internet freedom, leaving Internet companies to decide how much to collaborate with governme= nt authorities in the tracking of citizens." />

 

<meta property=3D"og:image" content=3D"htt= p://graphics8.nytimes.com/gfx/blogs/bits/bits75.gif"/>

 

That’s exactly the kind of thing I was looking for, bu= t I do wonder how pervasive this will become.  Is this being standardi= zed?

 

Paul

 

 

From: Bob Wyman [mailto:b= obwyman@gmail.com]
Sent: Friday, July 06, 2012 5:22 PM
To: Paul E. Jones
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Referencing content on social networking= sites

 

Are you looking for something like "rich snipp= ets?" http://googlewebmastercentral.blogspot.com/2009/05/introducing-rich-snippet= s.html?m=3D1

bob wyman

On Jul 6, 2012 2:31 PM, "P= aul E. Jones" <paulej@pack= etizer.com> wrote:

Folks,

 

I’ve often seen people post content on = social networking sites like Facebook and Google+ and wondered what log= ic went into selecting the graphic to use to represent the content and the picture that appeared beside that text.  Sometime= s the social networking sites do a great job at displaying a good summary a= nd image, but sometimes it’s totally wrong.

 

It’s common to see headers like this in= HTML documents:

  <meta name=3D”descriptionR= 21; content=3D”This is text related to the page”>=

 

However, social networking sites do not consi= stently use that metadata, even when present.

 

I’m not aware of a link relation define= d specifically for such referencing purposes.  However, something like= this might work:

 

   <link rel=3D”page-graph= ic” href=3D”picture_to_display.jpg”>=

 

Are there existing elements social networking= sites follow or should follow?  Is there value in recommending how an= d image and descriptive text are selected?

 

Paul

 

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

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non è necessario.

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A16673CCGRFMBX704BA02_-- --_6b7cad8e-5504-4562-a475-e4d8e10397f7_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_6b7cad8e-5504-4562-a475-e4d8e10397f7_-- From melvincarvalho@gmail.com Sat Jul 7 04:06:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED3F21F85FC for ; Sat, 7 Jul 2012 04:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO1Mr7yxEORJ for ; Sat, 7 Jul 2012 04:06:41 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66E4621F8565 for ; Sat, 7 Jul 2012 04:06:41 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7168731vbb.31 for ; Sat, 07 Jul 2012 04:07:00 -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=1hZhN4YoqtDSTlKutqvPbV32wHN/1pgS+9bo1n2/8xg=; b=cU3Eqp9fwSihkosZr6x8WFArxOWiAfhDM3BZ75rphwj3Blr3FGbguvMeg7jtBnvFot ONO3AIZZJmlp+K6D7oIFPIQQqXiIl7gZcBfvLbwagKdOCLPm4JGR9RoqkIUB+pktxZkA bl6l2Cw4tmfEMxTwpUIeLI93CGiWRi8i/iLR5SLced6trdwhPYLcPczvaXz+epbl4EKO f5BlAn02TvaxGdicI28HJnyGJ5zOLMh5PJ5GoYpQMFHYUAYGP3rTb5m++a2UcaPFm81b A0AbgwaQidQjMABbOd2ChcD+bMG7nlufWRtjPre9HeS7JSzfDSsfES2zjpyeVSScoKCX GG9g== MIME-Version: 1.0 Received: by 10.52.28.99 with SMTP id a3mr8873530vdh.68.1341659219853; Sat, 07 Jul 2012 04:06:59 -0700 (PDT) Received: by 10.52.166.102 with HTTP; Sat, 7 Jul 2012 04:06:59 -0700 (PDT) In-Reply-To: References: <089b01cd5ba5$93996ed0$bacc4c70$@packetizer.com> <094701cd5bc3$db272b20$91758160$@packetizer.com> Date: Sat, 7 Jul 2012 13:06:59 +0200 Message-ID: From: Melvin Carvalho To: Goix Laurent Walter Content-Type: multipart/alternative; boundary=20cf3079b92035815e04c43b61b5 Cc: "apps-discuss@ietf.org" , Bob Wyman Subject: Re: [apps-discuss] R: Referencing content on social networking sites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2012 11:06:43 -0000 --20cf3079b92035815e04c43b61b5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7 July 2012 12:58, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > Hello Paul,**** > > ** ** > > I guess the closest specification to this is the > Microformats/microdata/rdfa effort that have been evolving for years now > and is now mostly supported by the schema.org [1] project.**** > > These are understood by the major search engines or social sites to > =93extract=94 metadata from a web page, for example to display title & > thumbnail when sharing or in a search result snippet. > Do note that, as of last month, (after about 5 years of work), RDFa 1.1 has become an official W3C REC. http://www.w3.org/blog/SW/2012/06/07/rdfa-core-1-1-rdfa-lite-1-1-and-xhtmlr= dfa-1-1-are-w3c-recommendation/ > **** > > ** ** > > Is it what you are looking at?**** > > walter**** > > ** ** > > [1] http://schema.org/ **** > > ** ** > > *Da:* apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] > *Per conto di *Paul E. Jones > *Inviato:* sabato 7 luglio 2012 0.08 > *A:* 'Bob Wyman' > *Cc:* apps-discuss@ietf.org > *Oggetto:* Re: [apps-discuss] Referencing content on social networking > sites**** > > ** ** > > No, I was looking for something like this:**** > > ** ** > > Basic Right" />**** > > ** ** > > **** > > ** ** > > http://bits.blogs.nytimes.com/2012/07/06/so-the-united-nations-affirms-in= ternet-freedom-as-a-basic-right-now-what/" > />**** > > ** ** > > Council passed a nonbinding resolution that supports Internet freedom, > leaving Internet companies to decide how much to collaborate with > government authorities in the tracking of citizens." />**** > > ** ** > > http://graphics8.nytimes.com/gfx/blogs/bits/bits75.gif"/>**** > > ** ** > > That=92s exactly the kind of thing I was looking for, but I do wonder how > pervasive this will become. Is this being standardized?**** > > ** ** > > Paul**** > > ** ** > > ** ** > > *From:* Bob Wyman [mailto:bobwyman@gmail.com] > *Sent:* Friday, July 06, 2012 5:22 PM > *To:* Paul E. Jones > *Cc:* apps-discuss@ietf.org > *Subject:* Re: [apps-discuss] Referencing content on social networking > sites**** > > ** ** > > Are you looking for something like "rich snippets?" > http://googlewebmastercentral.blogspot.com/2009/05/introducing-rich-snipp= ets.html?m=3D1 > **** > > bob wyman**** > > On Jul 6, 2012 2:31 PM, "Paul E. Jones" wrote:***= * > > Folks,**** > > **** > > I=92ve often seen people post content on social networking sites like > Facebook and Google+ and wondered what logic went into selecting the > graphic to use to represent the content and the picture that appeared > beside that text. Sometimes the social networking sites do a great job a= t > displaying a good summary and image, but sometimes it=92s totally wrong.*= *** > > **** > > It=92s common to see headers like this in HTML documents:**** > > **** > > **** > > However, social networking sites do not consistently use that metadata, > even when present.**** > > **** > > I=92m not aware of a link relation defined specifically for such referenc= ing > purposes. However, something like this might work:**** > > **** > > ***= * > > **** > > Are there existing elements social networking sites follow or should > follow? Is there value in recommending how and image and descriptive tex= t > are selected?**** > > **** > > Paul**** > > **** > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss**** > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not > the intended recipient, please delete this message and any attachments an= d > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa > mail se non =E8 necessario.* > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --20cf3079b92035815e04c43b61b5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 7 July 2012 12:58, Goix Laurent Walte= r <laurentwalter.goix@telecomitalia.it> wr= ote:

Hello Paul,=

=A0<= /p>

I guess th= e closest specification to this is the Microformats/microdata/rdfa effort t= hat have been evolving for years now and is now mostly supported by the schema.org [1] = project.

These are = understood by the major search engines or social sites to =93extract=94 met= adata from a web page, for example to display title & thumbnail when sharing or in a search result snippet.


Do note that, as of last month, (after about 5 years of work)= , RDFa 1.1 has become an official W3C REC.

http://www.w3.org/blog/SW/2012/06/07/rdfa-core-1-1-rdfa-= lite-1-1-and-xhtmlrdfa-1-1-are-w3c-recommendation/
=A0

=A0=

Is it what= you are looking at?

walter<= /u>

=A0=

[1] http://schema.org/ =

=A0

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] Per conto di Paul E. Jones
Inviato: sabato 7 luglio 2012 0.08
A: 'Bob Wyman'
Cc: apps-= discuss@ietf.org
Oggetto: Re: [apps-discuss] Referencing content on social networking= sites

=A0

No, I was = looking for something like this:

=A0=

<meta p= roperty=3D"og:title" content=3D"U.N. Affirms Internet Freedo= m as a Basic Right" />

=A0=

<meta p= roperty=3D"og:type" content=3D"article" />=

=A0=

<meta p= roperty=3D"og:url" content=3D"http://bits.blogs.nytimes.com/2012/= 07/06/so-the-united-nations-affirms-internet-freedom-as-a-basic-right-now-w= hat/" /><meta property=3D"og:site_name" content=3D"Bits Blo= g" />

=A0=

<meta p= roperty=3D"og:description" content=3D"The United Nations Hum= an Rights Council passed a nonbinding resolution that supports Internet fre= edom, leaving Internet companies to decide how much to collaborate with governme= nt authorities in the tracking of citizens." />

=A0=

<meta p= roperty=3D"og:image" content=3D"http://graphics8.n= ytimes.com/gfx/blogs/bits/bits75.gif"/>

=A0=

That=92s e= xactly the kind of thing I was looking for, but I do wonder how pervasive t= his will become.=A0 Is this being standardized?

=A0=

Paul

=A0=

=A0=

From: Bob Wyman [mailto:bobwyman@gmail.com]
Sent: Friday, July 06, 2012 5:22 PM
To: Paul E. Jones
Cc: apps-= discuss@ietf.org
Subject: Re: [apps-discuss] Referencing content on social networking= sites

=A0

Are you looking for something like "rich snipp= ets?" http://googlewebmastercentral.blogspot.com/2009/05/introducing-rich-snippet= s.html?m=3D1

bob wyman

On Jul 6, 2012 2:31 PM, "P= aul E. Jones" <paulej@packetizer.com> wrote:

Folks,

=A0

I=92ve often seen people post c= ontent on social networking sites like Facebook and Google+ and wondered wh= at logic went into selecting the graphic to use to represent the content and the picture that appeared beside that text.=A0 Sometimes t= he social networking sites do a great job at displaying a good summary and = image, but sometimes it=92s totally wrong.

=A0

It=92s common to see headers li= ke this in HTML documents:

=A0 <meta name=3D=94descript= ion=94 content=3D=94This is text related to the page=94>

=A0

However, social networking site= s do not consistently use that metadata, even when present.

=A0

I=92m not aware of a link relat= ion defined specifically for such referencing purposes.=A0 However, somethi= ng like this might work:

=A0

=A0=A0 <link rel=3D=94page-g= raphic=94 href=3D=94picture_to_display.jpg=94>

=A0

Are there existing elements soc= ial networking sites follow or should follow?=A0 Is there value in recommen= ding how and image and descriptive text are selected?<= /p>

=A0

Paul

=A0

=
_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /span>

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=A0is=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D=Rispetta l'ambient= e. Non stampare questa mail se non =E8 necessario.


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


--20cf3079b92035815e04c43b61b5-- From robinsgv@gmail.com Sat Jul 7 05:02:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDD221F8596 for ; Sat, 7 Jul 2012 05:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1r3LUxCRjhSC for ; Sat, 7 Jul 2012 05:02:01 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E83121F8636 for ; Sat, 7 Jul 2012 05:02:00 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so6914943wgb.13 for ; Sat, 07 Jul 2012 05:02:18 -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=n9Z9NAmzzQ9orS47lHumFFPM1RLoTkbJzO3k05DR+5g=; b=MF+hZL4i6BKJE3Saf+wYyFgaSYlUCxfcVpSMWCnvOlu8bLseFDkWCVp9Cb54xhv77Z t7MoMKuoAx+/dNMu/ArQBnoPMtbpvtzFVc9WXkHNt63YQDFfbNB2EJSbBG9oVg1VZgZx D84cK7HOfnIzjJa2MV69zVY4t95/0JTjDbSLbTtbruczEOd53tUhjffua31apaOl0whO zT/zNLfs5bxxnYATjDSMrmQx6T2ibhi7ew9icfN4gnsTLc6AvLSHK/43VbBCmYJCU88t GZR18YfEWNJZJBcX6sDyyP/glWtd6nG/QFL0waM5aLQjrHEklZoLC8SN9Gkg+L4sdxf0 jyFg== Received: by 10.216.213.226 with SMTP id a76mr12363483wep.142.1341662538636; Sat, 07 Jul 2012 05:02:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.54.100 with HTTP; Sat, 7 Jul 2012 05:01:58 -0700 (PDT) In-Reply-To: References: <089b01cd5ba5$93996ed0$bacc4c70$@packetizer.com> <094701cd5bc3$db272b20$91758160$@packetizer.com> From: Robins George Date: Sat, 7 Jul 2012 17:31:58 +0530 Message-ID: To: Melvin Carvalho Content-Type: multipart/alternative; boundary=00504502dc8806202f04c43c27be Cc: Bob Wyman , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] R: Referencing content on social networking sites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2012 12:02:02 -0000 --00504502dc8806202f04c43c27be Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, FYI: similar attempts made from vcarddav WG http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks-00 - robins On Sat, Jul 7, 2012 at 4:36 PM, Melvin Carvalho w= rote: > > > On 7 July 2012 12:58, Goix Laurent Walter < > laurentwalter.goix@telecomitalia.it> wrote: > >> Hello Paul,**** >> >> ** ** >> >> I guess the closest specification to this is the >> Microformats/microdata/rdfa effort that have been evolving for years now >> and is now mostly supported by the schema.org [1] project.**** >> >> These are understood by the major search engines or social sites to >> =93extract=94 metadata from a web page, for example to display title & >> thumbnail when sharing or in a search result snippet. >> > > Do note that, as of last month, (after about 5 years of work), RDFa 1.1 > has become an official W3C REC. > > > http://www.w3.org/blog/SW/2012/06/07/rdfa-core-1-1-rdfa-lite-1-1-and-xhtm= lrdfa-1-1-are-w3c-recommendation/ > > >> **** >> >> ** ** >> >> Is it what you are looking at?**** >> >> walter**** >> >> ** ** >> >> [1] http://schema.org/ **** >> >> ** ** >> >> *Da:* apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.or= g] >> *Per conto di *Paul E. Jones >> *Inviato:* sabato 7 luglio 2012 0.08 >> *A:* 'Bob Wyman' >> *Cc:* apps-discuss@ietf.org >> *Oggetto:* Re: [apps-discuss] Referencing content on social networking >> sites**** >> >> ** ** >> >> No, I was looking for something like this:**** >> >> ** ** >> >> > Basic Right" />**** >> >> ** ** >> >> **** >> >> ** ** >> >> > http://bits.blogs.nytimes.com/2012/07/06/so-the-united-nations-affirms-i= nternet-freedom-as-a-basic-right-now-what/" >> />**** >> >> ** ** >> >> > Council passed a nonbinding resolution that supports Internet freedom, >> leaving Internet companies to decide how much to collaborate with >> government authorities in the tracking of citizens." />**** >> >> ** ** >> >> > http://graphics8.nytimes.com/gfx/blogs/bits/bits75.gif"/>**** >> >> ** ** >> >> That=92s exactly the kind of thing I was looking for, but I do wonder ho= w >> pervasive this will become. Is this being standardized?**** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> ** ** >> >> *From:* Bob Wyman [mailto:bobwyman@gmail.com] >> *Sent:* Friday, July 06, 2012 5:22 PM >> *To:* Paul E. Jones >> *Cc:* apps-discuss@ietf.org >> *Subject:* Re: [apps-discuss] Referencing content on social networking >> sites**** >> >> ** ** >> >> Are you looking for something like "rich snippets?" >> http://googlewebmastercentral.blogspot.com/2009/05/introducing-rich-snip= pets.html?m=3D1 >> **** >> >> bob wyman**** >> >> On Jul 6, 2012 2:31 PM, "Paul E. Jones" wrote:**= * >> * >> >> Folks,**** >> >> **** >> >> I=92ve often seen people post content on social networking sites like >> Facebook and Google+ and wondered what logic went into selecting the >> graphic to use to represent the content and the picture that appeared >> beside that text. Sometimes the social networking sites do a great job = at >> displaying a good summary and image, but sometimes it=92s totally wrong.= *** >> * >> >> **** >> >> It=92s common to see headers like this in HTML documents:**** >> >> *** >> * >> >> **** >> >> However, social networking sites do not consistently use that metadata, >> even when present.**** >> >> **** >> >> I=92m not aware of a link relation defined specifically for such >> referencing purposes. However, something like this might work:**** >> >> **** >> >> **= ** >> >> **** >> >> Are there existing elements social networking sites follow or should >> follow? Is there value in recommending how and image and descriptive te= xt >> are selected?**** >> >> **** >> >> Paul**** >> >> **** >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss**** >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente >> alle persone indicate. La diffusione, copia o qualsiasi altra azione >> derivante dalla conoscenza di queste informazioni sono rigorosamente >> vietate. Qualora abbiate ricevuto questo documento per errore siete >> cortesemente pregati di darne immediata comunicazione al mittente e di >> provvedere alla sua distruzione, Grazie. >> >> *This e-mail and any attachments** is **confidential and may contain >> privileged information intended for the addressee(s) only. Dissemination= , >> copying, printing or use by anybody else is unauthorised. If you are not >> the intended recipient, please delete this message and any attachments a= nd >> advise the sender by return e-mail, Thanks.* >> *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa >> mail se non =E8 necessario.* >> >> >> _______________________________________________ >> 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 > > --=20 This is from my personal email account and any materials from this account come with personal disclaimers --00504502dc8806202f04c43c27be Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0
FYI:
similar attempts made from vcarddav WG
=A0
=A0

- robins
On Sat, Jul 7, 2012 at 4:36 PM, Melvin Carvalho = <melvincarvalho@gmail.com> wrote:


On 7 July 2012 12:58, Goix Laurent Walter <laurentwalter.goix@telecomitalia.it> wrote:

Hello Paul,

=A0

I guess the clos= est specification to this is the Microformats/microdata/rdfa effort that ha= ve been evolving for years now and is now mostly supported by the schema.org [1] project.

These are unders= tood by the major search engines or social sites to =93extract=94 metadata = from a web page, for example to display title & thumbnail when sharing = or in a search result snippet.


Do note that, as of last month, (after about 5 years of work), RDF= a 1.1 has become an official W3C REC.

http://www.w3.org/blog/SW/2012/06/07/rdfa-c= ore-1-1-rdfa-lite-1-1-and-xhtmlrdfa-1-1-are-w3c-recommendation/
=A0

=A0

Is it what you a= re looking at?

walter=

=A0

[1] http://schema.org/ <= /span>

=A0

Da: ap= ps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per c= onto di Paul E. Jones
Inviato: sabato 7 luglio 2012 0.08
A: 'Bob Wyman'<= br>Cc: ap= ps-discuss@ietf.org
Oggetto: Re: [apps-discuss] Referencing c= ontent on social networking sites

=A0

No, I was lookin= g for something like this:

=A0

<meta propert= y=3D"og:title" content=3D"U.N. Affirms Internet Freedom as a= Basic Right" />

=A0

<meta propert= y=3D"og:type" content=3D"article" />

=A0

<meta propert= y=3D"og:url" content=3D"http://bits.blogs.nytimes.com/2012/07/06/= so-the-united-nations-affirms-internet-freedom-as-a-basic-right-now-what/" /><meta property=3D"og:site_name" content=3D"= Bits Blog" />

=A0

<meta propert= y=3D"og:description" content=3D"The United Nations Human Rig= hts Council passed a nonbinding resolution that supports Internet freedom, = leaving Internet companies to decide how much to collaborate with governmen= t authorities in the tracking of citizens." />=

=A0

<meta propert= y=3D"og:image" content=3D"http://graphics8.nytimes= .com/gfx/blogs/bits/bits75.gif"/>

=A0

That=92s exactly= the kind of thing I was looking for, but I do wonder how pervasive this wi= ll become.=A0 Is this being standardized?

=A0

Paul

=A0

=A0

From: Bob Wyman [mailto:bobwyman@gmail.com]
Sent: Friday, July 06, 2012 5:22 PM
To: Paul E. Jones
<= b>Cc: apps-d= iscuss@ietf.org
Subject: Re: [apps-discuss] Referencing conte= nt on social networking sites

=A0

Are you looking for something like "rich snipp= ets?" http://googlewebmaste= rcentral.blogspot.com/2009/05/introducing-rich-snippets.html?m=3D1

bob wyman

On Jul 6, 2012 2:31 PM, "P= aul E. Jones" <paulej@packetizer.com> wrote:

Folks,

=A0

I=92ve often seen people post c= ontent on social networking sites like Facebook and Google+ and wondered wh= at logic went into selecting the graphic to use to represent the content an= d the picture that appeared beside that text.=A0 Sometimes the social netwo= rking sites do a great job at displaying a good summary and image, but some= times it=92s totally wrong.

=A0

It=92s common to see headers li= ke this in HTML documents:

=A0 <meta name=3D=94descript= ion=94 content=3D=94This is text related to the page=94>

=A0

However, social networking site= s do not consistently use that metadata, even when present.

=A0

I=92m not aware of a link relat= ion defined specifically for such referencing purposes.=A0 However, somethi= ng like this might work:

=A0

=A0=A0 <link rel=3D=94page-g= raphic=94 href=3D=94picture_to_display.jpg=94>

=A0

Are there existing elements soc= ial networking sites follow or should follow?=A0 Is there value in recommen= ding how and image and descriptive text are selected?<= /p>

=A0

Paul

=A0

_______________________________________________
apps-discuss mailing l= ist
apps-disc= uss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /span>

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbi= ate ricevuto questo documento per errore siete cortesemente pregati di darn= e immediata comunicazione al mittente e di provvedere alla sua distruzione,= Grazie.

This e-mail and any attachments=A0is=A0confidential and may contain privileged information intended for the ad= dressee(s) only. Dissemination, copying, printing or use by anybody else is= unauthorised. If you are not the intended recipient, please delete this me= ssage and any attachments and advise the sender by return e-mail, Thanks.

3D"rispetta=Rispetta l'ambiente. Non st= ampare questa mail se non =E8 necessario.=20


________________________________= _______________
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/mailm= an/listinfo/apps-discuss




--
This is from my per= sonal email account and any materials from this account come with personal = disclaimers
--00504502dc8806202f04c43c27be-- From stephen.farrell@cs.tcd.ie Sat Jul 7 05:45:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491AA21F862F for ; Sat, 7 Jul 2012 05:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p5eFucrk41A for ; Sat, 7 Jul 2012 05:45:31 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6132521F861D for ; Sat, 7 Jul 2012 05:45:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1965C1714EF; Sat, 7 Jul 2012 13:45:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341665149; bh=HJV/85edN3P/M/ y3m2TgWUFDPdYJhNRJ1BpqOz0d7eU=; b=aztZLQXFl2iMEPCavgdyboTmqxGzJK mLKu0EZiVXPv5AcDsvRWaRlUV7chjdgJoQyE/fjmPADmTXRTQNrx1REKYRyhg2pl xAogSGXZ0us1eKgbjhJseEV3ocOLzhsGAhL1RckRLyV6Gi8q31E+QG44el7UcF3W GsKpjg4ReEjc04iwLwvSzS4eP2z59C/hyg+YpBYZOQFJmbBIaqeddOClttVu4W8N bplIzEhGbSCXAaH1a5rWgfuDWKOM2EtP+QmP5F9U3V1AflXuDBTKTyAya9gOF5I7 XLJnIPaQ7C7QrYrR8E8GDzeSj/aHm3hrI8BU2xUgOZ4v64gZm+K7YmsQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 9g6RdDplkfFQ; Sat, 7 Jul 2012 13:45:49 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.52.217]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 67DE91714EE; Sat, 7 Jul 2012 13:45:48 +0100 (IST) Message-ID: <4FF82F7C.7050605@cs.tcd.ie> Date: Sat, 07 Jul 2012 13:45:48 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: SM References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <4FF4AB6B.6090803@cs.tcd.ie> <20120705141951.3ef8eec7@hetzer> <6.2.5.6.2.20120706003649.09b5fb28@resistor.net> <20120706132454.266f6e9d@hetzer> <6.2.5.6.2.20120706085825.0a1318c8@resistor.net> <4FF75879.4050104@cs.tcd.ie> <6.2.5.6.2.20120706182508.0809b5c8@resistor.net> In-Reply-To: <6.2.5.6.2.20120706182508.0809b5c8@resistor.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Privacy considerations - draft-ietf-appsawg-http-forwarded-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2012 12:45:32 -0000 On 07/07/2012 03:26 AM, SM wrote: >> The question for me boils down to whether an IP address >> as used here is a location object in geopriv terms or not. >> Personally, I'm not sure. > > RFC 6280 defines a location object as: > > "A data unit that conveys location information together with > Privacy Rules within the Geopriv architecture. A Location Object > may convey geodetic location data (latitude, longitude, altitude), > civic location data (street, city, state, etc.), or both." > > Section 3.1 of RFC 6155 mentions IP Address as an identifier. It's not > clear how to equate IP address as used in this draft and the usage in > Geopriv. I suggest not considering Geopriv unless someone wants to make > a case for it. I agree that its not clear. However, it seems to me very odd to go to a lot of trouble to control location privacy when using SIP but blithely have middleboxes forward the required information when using HTTP. >> Right. I can understand the authors preferring to say >> less on this rather than more. But maybe more is needed? > > As starting text (borrowed from RFC 4941): > > One of the requirements for correlating seemingly unrelated > activities is the use (and reuse) of an identifier that is > recognizable over time within different contexts. Using the > generated identifier (Section 6.3) has implications for > privacy if it is not randomly generated for each request. Sorry, not sure what point you're making there. Actually, I (finally:-) had a look at the rest of the document last night and turns out this is less of an issue than I thought as 6.3 already discusses random identifiers. S. > > Regards, > -sm > > > > > > From paul.hoffman@vpnc.org Sat Jul 7 10:14:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B9B21F8621 for ; Sat, 7 Jul 2012 10:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5NUQZ6rN0At for ; Sat, 7 Jul 2012 10:14:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4834221F860D for ; Sat, 7 Jul 2012 10:14:45 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q67HEx62044786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 7 Jul 2012 10:15:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 7 Jul 2012 10:14:59 -0700 Message-Id: To: Apps Discuss Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [apps-discuss] The format problem, partially being solved later this year X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2012 17:14:46 -0000 (Warning: contains a few = swear words.) This project will be done outside the IETF using very outside-the-IETF = procedures. There might be an informational RFC at the end saying what = happened. But if you're interested in solving the format problem, you = might want to follow Jason's blog and spend part of your November = helping. The project will be a great place for people who want to participate in = making applications more useful in the future. It might turn out to be = completely inconsequential, but I suspect that it will be at least as = useful in the long term across the world as typical IETF Applications = Area work, and has a good shot at being much more so. It will also be a = good place for people who want to get involved but cannot handle the = IETF process for whatever reason. --Paul Hoffman From bobwyman@gmail.com Fri Jul 6 14:21:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A5511E80F5 for ; Fri, 6 Jul 2012 14:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nUyJLJWFCdj for ; Fri, 6 Jul 2012 14:21:15 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3178011E80F3 for ; Fri, 6 Jul 2012 14:21:14 -0700 (PDT) Received: by ggnc4 with SMTP id c4so9935363ggn.31 for ; Fri, 06 Jul 2012 14:21: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=qZFxOXkxDhqmp4jhcls+A5Hke7LJQ0Hx/FlZDaPJpWE=; b=Q2P3C8zomaJvxDT4KTxJEI96DBhDPM+xE75dnY+i+oqIDUKPxuSjd1OdhbER57hqlH mibT7fRIxPiE83KaRTAs4LSmQ7sp42uDQRRfImIMmabw7PGi2HNa+VNxfYJOz3fmTi/4 9A/lMCyq3eR1aI6XvUN3uBQSjbp7k7SBoRwoSynrAc+OCqLHnKPSH1gs9EhSclupQ/Xq LpdB+NH1DDDWT9KlSmeVdNAH+tRaOhmIgF108Us/6K6Y+HwQ5qoFIdCriwmcKO227tzt ytGoCyS6rmszzSYHItUZ0EfouNgP+bHYFs5GtsnmCZLQNAkpyCQucxtCRwOo4AFSTnsF h6gw== MIME-Version: 1.0 Received: by 10.236.78.200 with SMTP id g48mr36848757yhe.124.1341609692080; Fri, 06 Jul 2012 14:21:32 -0700 (PDT) Received: by 10.101.64.5 with HTTP; Fri, 6 Jul 2012 14:21:31 -0700 (PDT) Received: by 10.101.64.5 with HTTP; Fri, 6 Jul 2012 14:21:31 -0700 (PDT) In-Reply-To: <089b01cd5ba5$93996ed0$bacc4c70$@packetizer.com> References: <089b01cd5ba5$93996ed0$bacc4c70$@packetizer.com> Date: Fri, 6 Jul 2012 17:21:31 -0400 Message-ID: From: Bob Wyman To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf300fb3071faa1104c42fd974 X-Mailman-Approved-At: Sat, 07 Jul 2012 10:33:16 -0700 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Referencing content on social networking sites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2012 21:21:16 -0000 --20cf300fb3071faa1104c42fd974 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Are you looking for something like "rich snippets?" http://googlewebmastercentral.blogspot.com/2009/05/introducing-rich-snippet= s.html?m=3D1 bob wyman On Jul 6, 2012 2:31 PM, "Paul E. Jones" wrote: > Folks,**** > > ** ** > > I=92ve often seen people post content on social networking sites like > Facebook and Google+ and wondered what logic went into selecting the > graphic to use to represent the content and the picture that appeared > beside that text. Sometimes the social networking sites do a great job a= t > displaying a good summary and image, but sometimes it=92s totally wrong.*= *** > > ** ** > > It=92s common to see headers like this in HTML documents:**** > > **** > > ** ** > > However, social networking sites do not consistently use that metadata, > even when present.**** > > ** ** > > I=92m not aware of a link relation defined specifically for such referenc= ing > purposes. However, something like this might work:**** > > ** ** > > ***= * > > ** ** > > Are there existing elements social networking sites follow or should > follow? Is there value in recommending how and image and descriptive tex= t > are selected?**** > > ** ** > > Paul**** > > ** ** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --20cf300fb3071faa1104c42fd974 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Are you looking for something like "rich snippets?"= ; http://googlewebmastercentral.blogspot.com/2009/= 05/introducing-rich-snippets.html?m=3D1

bob wyman

On Jul 6, 2012 2:31 PM, "Paul E. Jones"= ; <paulej@packetizer.com>= ; wrote:

Folks,

=A0

I=92ve often seen people post content on social network= ing sites like Facebook and Google+ and wondered what logic went into selec= ting the graphic to use to represent the content and the picture that appea= red beside that text.=A0 Sometimes the social networking sites do a great j= ob at displaying a good summary and image, but sometimes it=92s totally wro= ng.

=A0

It=92s c= ommon to see headers like this in HTML documents:

=A0 <meta name=3D=94description=94 content=3D=94This is t= ext related to the page=94>

=A0

However,= social networking sites do not consistently use that metadata, even when p= resent.

=A0

I=92m not aware of a link relation defined specifically for such referencin= g purposes.=A0 However, something like this might work:

=A0

=A0=A0 <= ;link rel=3D=94page-graphic=94 href=3D=94picture_to_display.jpg=94>

=A0

Are ther= e existing elements social networking sites follow or should follow?=A0 Is = there value in recommending how and image and descriptive text are selected= ?

=A0

Paul<= /u>

=A0


_= ______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--20cf300fb3071faa1104c42fd974-- From sm@resistor.net Sat Jul 7 10:54:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF04121F8639 for ; Sat, 7 Jul 2012 10:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLcA1cbjlyow for ; Sat, 7 Jul 2012 10:54:51 -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 46E6921F8638 for ; Sat, 7 Jul 2012 10:54:51 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q67Hslmd018454; Sat, 7 Jul 2012 10:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341683694; bh=0Rlph9FB+g4XTj1M4U7fJxgdZHyXVbzABhzwC9gVP1c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=EOo4mwNSgYV1ULhtHd0ryBZpukst0sfMerj9Vk0Sb6lqw/441ZNuWjAsiYtQyOXpI hAmP+ryBogpCyQabTpETUUIYsUAoyyC5E9AfuT+K6uBxpQVcjrpb6D/pzO5hsqqF/q RvQ3zc1oSxRl1YN6b/B8LzvG88Ysz2ZCbi1wbJbM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341683694; i=@resistor.net; bh=0Rlph9FB+g4XTj1M4U7fJxgdZHyXVbzABhzwC9gVP1c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NSKGuTiepvMPmerZVjfaQlpM+WanErNMvpbnY2OFr1OncZ8n5so1+GvtaFTBVw2u6 C3gpCib3NpjlTTT27s1ZM2G5HphDVh5hyv9zBob+8cMXwqkz/7mLzBxgWmYMruW0fu zl+dWQdMhy8yBHvDG4Gu4jvT+yrp4lhm4DeTeQF0= Message-Id: <6.2.5.6.2.20120707080646.083ad1b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 07 Jul 2012 10:34:44 -0700 To: Stephen Farrell From: SM In-Reply-To: <4FF82F7C.7050605@cs.tcd.ie> References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <4FF4AB6B.6090803@cs.tcd.ie> <20120705141951.3ef8eec7@hetzer> <6.2.5.6.2.20120706003649.09b5fb28@resistor.net> <20120706132454.266f6e9d@hetzer> <6.2.5.6.2.20120706085825.0a1318c8@resistor.net> <4FF75879.4050104@cs.tcd.ie> <6.2.5.6.2.20120706182508.0809b5c8@resistor.net> <4FF82F7C.7050605@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Privacy considerations - draft-ietf-appsawg-http-forwarded-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2012 17:54:55 -0000 Hi Stephen, At 05:45 07-07-2012, Stephen Farrell wrote: >However, it seems to me very odd to go to a lot of trouble >to control location privacy when using SIP but blithely have >middleboxes forward the required information when using HTTP. Yes. > > As starting text (borrowed from RFC 4941): > > > > One of the requirements for correlating seemingly unrelated > > activities is the use (and reuse) of an identifier that is > > recognizable over time within different contexts. Using the > > generated identifier (Section 6.3) has implications for > > privacy if it is not randomly generated for each request. > >Sorry, not sure what point you're making there. The point is that if you are not using a randomly generated identifier per request, you end up creating yet another identifier for tracking [1]. >Actually, I (finally:-) had a look at the rest of the document >last night and turns out this is less of an issue than I >thought as 6.3 already discusses random identifiers. Ok. Regards, -sm 1. http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html From superuser@gmail.com Sat Jul 7 19:59:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4689921F8596 for ; Sat, 7 Jul 2012 19:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLVpbVj--t2v for ; Sat, 7 Jul 2012 19:59:26 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 149BD21F85CE for ; Sat, 7 Jul 2012 19:59:25 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id go11so16048709lbb.31 for ; Sat, 07 Jul 2012 19:59:46 -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 :content-type; bh=D8YdP209HsV5CE53XHZKf++feCqDKofZMiX0lyjcNRc=; b=KnUqAI10egU31/sdptXzFmges8HqO0DW5NCGEy9dRHbU5wI5aIw7LYcqtccN7LXV0R VasZl4HJ3QVINgews0PemSPW8rOZBSYsDmqFev4r3xlUaX7/8OkPhxX4lCRs5UbRzkj7 gGr+u4JIZuEWOMd+xP19Vq7MYArW/HCWdzmjLRx7TzkAlYQPOLE5R0OPuCKfsGs0u6ak TsVcDSQBt3lDu32X6pGIeQSRUL9m6OdyWCyhHaLC/GWyPRiOHg6RHcIqNgMDWPsSyE/d iq+d5tjcsMdopV1eTZWzM2FDtq6aRyi6Prvr8dUTXGsdrrka90JHYOyqjwQw3NzV+29v BOFQ== MIME-Version: 1.0 Received: by 10.112.101.196 with SMTP id fi4mr3207978lbb.67.1341716386671; Sat, 07 Jul 2012 19:59:46 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sat, 7 Jul 2012 19:59:46 -0700 (PDT) In-Reply-To: <20120706211533.3449.10225.idtracker@ietfa.amsl.com> References: <20120706211533.3449.10225.idtracker@ietfa.amsl.com> Date: Sat, 7 Jul 2012 19:59:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d0401682b9dec5c04c448b0fb Subject: [apps-discuss] Fwd: NomCom 2012-13 Call for Volunteers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2012 02:59:27 -0000 --f46d0401682b9dec5c04c448b0fb Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: NomCom Chair Date: Fri, Jul 6, 2012 at 2:15 PM Subject: NomCom 2012-13 Call for Volunteers To: IETF Announcement List The IETF nominating committee process for 2012-13 has begun. The IETF nominating committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. The 10 nominating committee members are selected randomly from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 3777. To be eligible, volunteers for the nomcom need to have attended 3 of the past 5 IETF meetings as of the time this announcement goes out. That is, 3 meetings from IETF 79 (Beijing) - IETF 83 (Paris). If you qualify, and if you will not be seeking appointment to any of the open positions that this nomcom will be filling, please consider volunteering. The list of people whose terms end with the March 2013 IETF meeting, and thus the positions for which the nominating committee is responsible for filling, are as follows: IAOC: -------- Dave Crocker IAB: -------- Alissa Cooper Joel Halpern David Kessens Danny McPherson Jon Peterson Dave Thaler IESG: -------- Russ Housley (General Area) Pete Resnick (Applications Area) Ralph Droms (Internet Area) Ronald Bonica (Operations and Management Area) Robert Sparks (Real-Time Applications and Infrastructure Area) Adrian Farrel (Routing Area) Stephen Farrell (Security Area) Wesley Eddy (Transport Area) The primary activity for this nomcom will begin in August 2012 and should be completed in January 2013. The nomcom will be collecting requirements from the community, as well as talking to candidates and obtaining feedback from community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email before 11:59 pm EDT (UTC - 4 hours) August 5, 2012 as follows: To: mlepinski.ietf@gmail.com Subject: Nomcom 2012-13 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing toward that goal. I will be publishing a more detailed timetable for nomcom activities, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you, Matthew Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org --f46d0401682b9dec5c04c448b0fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------<= br>From: NomCom Chair &= lt;nomcom-chair@ietf.org>
Date: Fri, Jul 6, 2012 at 2:15 PM
Subject: NomCom 2012-13 Call for Volun= teers
To: IETF Announcement List <ietf-announce@ietf.org>


The IETF nominating commit= tee process for 2012-13 has begun. The IETF
nominating committee appoints folks to fill the open slots on the
IAOC, the IAB, and the IESG. The 10 nominating committee members are
selected randomly from a pool of volunteers. The more volunteers, the
better chance we have of choosing a random yet representative cross
section of the IETF population. =A0The details of the operation of the
nomcom can be found in RFC 3777.

To be eligible, volunteers for the nomcom need to have attended 3 of
the past 5 IETF meetings as of the time this announcement goes out.
That is, 3 meetings from IETF 79 (Beijing) - IETF 83 (Paris). If you
qualify, and if you will not be seeking appointment to any of the open
positions that this nomcom will be filling, please consider
volunteering.

The list of people whose terms end with the March 2013 IETF meeting,
and thus the positions for which the nominating committee is
responsible for filling, are as follows:

IAOC:
--------
Dave Crocker

IAB:
--------
Alissa Cooper
Joel Halpern
David Kessens
Danny McPherson
Jon Peterson
Dave Thaler

IESG:
--------
Russ Housley (General Area)
Pete Resnick (Applications Area)
Ralph Droms (Internet Area)
Ronald Bonica (Operations and Management Area)
Robert Sparks (Real-Time Applications and Infrastructure Area)
Adrian Farrel (Routing Area)
Stephen Farrell (Security Area)
Wesley Eddy (Transport Area)

The primary activity for this nomcom will begin in August 2012 and
should be completed in January 2013. The nomcom will be collecting
requirements from the community, as well as talking to candidates and
obtaining feedback from community members about candidates. There will
be regularly scheduled conference calls to ensure progress. Thus,
being a nomcom member does require some time commitment.

Please volunteer by sending an email before 11:59 pm EDT (UTC - 4
hours) August 5, 2012 as follows:

To: mlepinski.ietf@gmail.com
Subject: Nomcom 2012-13 Volunteer

Please include the following information in the body:

<Your Full Name> =A0// As you enter in the IETF Registration Form, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // First/Given name followed by Las= t/Family Name
<Current Primary Affiliation>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // typically what goes in the Company field=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // =A0in the IETF Registration Form
[<all email addresses used to Register for the past 5 IETF meetings>]=
<Preferred email address> =A0//
<Telephone number> =A0 =A0 =A0 =A0 // For confirmation if selected
Please expect an email response from me within 3 business days stating
whether or not you are qualified. =A0If you don't receive a response, please re-send your email with the tag "RESEND:" added to the sub= ject
line.

If you are not yet sure you would like to volunteer, please consider
that nomcom members play a very important role in shaping the
leadership of the IETF. =A0Ensuring the leadership of the IETF is fair
and balanced and comprised of those who can lead the IETF in the right
direction is an important responsibility that rests on the IETF
participants at large. Volunteering for the nomcom is a good way of
contributing toward that goal.

I will be publishing a more detailed timetable for nomcom activities,
as well as details of the randomness seeds to be used for the RFC 3797
selection process, within the next couple weeks.

Thank you,
Matthew Lepinski
mlepinski.ietf@gmail.com nomcom-chair@ietf.org

--f46d0401682b9dec5c04c448b0fb-- From superuser@gmail.com Sat Jul 7 20:39:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADC021F85AA for ; Sat, 7 Jul 2012 20:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmX8OOIn+l4v for ; Sat, 7 Jul 2012 20:39:57 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4147B21F85A4 for ; Sat, 7 Jul 2012 20:39:57 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so16064948lbb.31 for ; Sat, 07 Jul 2012 20:40: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; bh=PiJWRJHrnM9S8pG+Q76B415JISDgDiUxmR5NbBZ4pDY=; b=wKOcwuUAH2ZPMpkusoWEcN5+4x2MLAu7RNnNT50vQXpfcFgOJc+dY4y5zCUWBg7sql zMTNn38H9xgHhQSOKD4mP26fNzXgpEOXf4XW3D+wd9z+ViLutrvT9GFSVA2w0jrbKFH0 iybiX1oYpR06pGM0/2WNZYCgMEX36OSy1W8xbwahqHfGP3BvEzSv8IewKaSuxVD8uUT+ w5/Uhjw51c0qr1zTw+9o8dt6wsitxwdEUFnnpJzIEPxvql7uOD2g+ppu4yYKJsx2Q+jg DQP+//iXuIFm5ayw2/7ew1/Lfyjqz9bzPCMohD6oivhmxGxpRPbM61dGyle4gJ2Rzt6b OpPQ== MIME-Version: 1.0 Received: by 10.152.104.47 with SMTP id gb15mr35296736lab.45.1341718817118; Sat, 07 Jul 2012 20:40:17 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sat, 7 Jul 2012 20:40:17 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120707015014.084dd0c0@elandnews.com> References: <6.2.5.6.2.20120707015014.084dd0c0@elandnews.com> Date: Sat, 7 Jul 2012 20:40:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: multipart/alternative; boundary=f46d0421824d7b9a2104c44941bf Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] A newcomer question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2012 03:39:59 -0000 --f46d0421824d7b9a2104c44941bf Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 7, 2012 at 2:31 AM, SM wrote: > Hi APPSAWG, > > After reading the Tao, I am given to understand that I can approach you > with a newcomer question. Hello SM, and welcome to the IETF! > The APPSAWG charter mentions that: > > "a core team of WG participants with sufficient energy and > expertise to advance the proposed work item according to the > proposed schedule" > > as one of the factors in accepting new work. > > Is there any informal description of how that "energy and expertise" might > be assessed for future proposals? > We don't have a hard-and-fast rule. It is typically left to the discretion of working group chairs and the participants to determine whether that kind of support for new work exists. > What would be the proposed schedule for future proposals? > We're in the process of adopting a new plan to select a milestone for completion of any new work APPSAWG takes on, as well as selecting such milestones for existing documents. This will be put in place soon, possibly during the upcoming Vancouver meeting. > Are there any practices the APPSAWG working group follows for > acknowledgements? > Are you referring here to Acknowledgements sections of RFCs, or something else? -MSK, APPSAWG co-chair --f46d0421824d7b9a2104c44941bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jul 7, 2012 at 2:31 AM, SM <sm@resistor.net> wrote:
Hi APPSAWG,

After reading the Tao, I am given to understand that I can approach you wit= h a newcomer question.

Hello SM, and welcome to the IE= TF!
=A0
=A0The APPSAWG charter mentions that:

=A0 "a core team of WG participants with sufficient energy and
=A0 =A0expertise to advance the proposed work item according to the
=A0 =A0proposed schedule"

as one of the factors in accepting new work.

Is there any informal description of how that "energy and expertise&qu= ot; might be assessed for future proposals?

We don= 't have a hard-and-fast rule.=A0 It is typically left to the discretion= of working group chairs and the participants to determine whether that kin= d of support for new work exists.
=A0
What would be the proposed schedule for future proposals?
<= div>
We're in the process of adopting a new plan to select a milesto= ne for completion of any new work APPSAWG takes on, as well as selecting su= ch milestones for existing documents.=A0 This will be put in place soon, po= ssibly during the upcoming Vancouver meeting.
=A0
Are there any practices the APPSAWG working group follows for acknowledgeme= nts?

Are you referring here to Acknowledgements se= ctions of RFCs, or something else?

-MSK, APPSAWG co-chair
--f46d0421824d7b9a2104c44941bf-- From jasnell@gmail.com Sat Jul 7 22:55:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E32F21F8522 for ; Sat, 7 Jul 2012 22:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[AWL=-1.733, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQXxl0JnTJ1H for ; Sat, 7 Jul 2012 22:55:45 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 682D321F850C for ; Sat, 7 Jul 2012 22:55:45 -0700 (PDT) Received: by were53 with SMTP id e53so1355787wer.31 for ; Sat, 07 Jul 2012 22:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=1keuVRO4KcJyKqk5y3pmiDWhO8efp1P34TmaztT2Ozo=; b=P772sh7jtkt5q4FyZd2KR5BRi17QZ5X+32Ck6DwpZv53RunD8yzhJE9Uho+i8wiEQ2 gdlZttldsDJTKqSLKyxQSSQzxhuq5YgqHpAh6z2HADZ/0l9YDO44Afo2A0G16l73iM7N fuozoxuu5HAOWhNfDexkyvB1OMLP9Raebqnmn13eUotL70A+OySFc2Fm8qKgX1KNYS5D nlrd2DYF+ySqkWcXyL64mdbdUg2VZ80SsynFVHJdilHZyzRir+dEBuWL3C/rIpfGjQi2 LOtCHVfgVNzoxaeKqx8mFBGzMjx3jas7veGrvY9G3AwD7vlYGe+vjSm28+vUvNPaRhzB SCKA== Received: by 10.180.86.106 with SMTP id o10mr19782556wiz.22.1341726965897; Sat, 07 Jul 2012 22:56:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.67 with HTTP; Sat, 7 Jul 2012 22:55:45 -0700 (PDT) From: James M Snell Date: Sat, 7 Jul 2012 22:55:45 -0700 Message-ID: To: IETF Apps Discuss Content-Type: text/plain; charset=UTF-8 Subject: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and Simple Web Discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2012 05:55:46 -0000 Figured it would be easier to write this up as an I-D... http://www.ietf.org/id/draft-snell-web-index-00.txt - James From superuser@gmail.com Sat Jul 7 23:18:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F5D21F854D for ; Sat, 7 Jul 2012 23:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dY1A7ddTxYu for ; Sat, 7 Jul 2012 23:18:03 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3303221F84FD for ; Sat, 7 Jul 2012 23:18:02 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so16126304lbb.31 for ; Sat, 07 Jul 2012 23:18:23 -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=GL2yRPMCC318eqoYT29U6Wcfx2fvA3iHT9xxdgSu2a8=; b=oDBIggVZDGL1oBbx3ZhmKcE5FZmBVsnf5zLIQoq8trZga9Lnh60l9V2BKNr/i1MQWh ekGcUlUtpO0B9CXEUOiEXW1zRWNA0FEyMPDdKzaxRBEjARlyNB4lKWZAkv2tEEsB0zrk kceTfDmDgm4fxjWcarUHc/UXSCbl/eVHdoTPpZ0Owcdyvrxy3N9GS1T98WKuF2Slz5+J M8uwvPqd+fxsmdna6a8UiN5FpkJyuEm2fa0sfs3qyQwlZGIOC+5IYtD1kUiNAPzRD9f7 qHNA3Ov8bQFgqSRGUYeHoYRcFxLsAvtm7KwSjq3G88OUiR6LG7/XmEoQYQhVqeHKIteI 1UeQ== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr35583482lab.47.1341728303352; Sat, 07 Jul 2012 23:18:23 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sat, 7 Jul 2012 23:18:23 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436657A9F8@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436657A9F8@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sat, 7 Jul 2012 23:18:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mike Jones Content-Type: multipart/alternative; boundary=f46d0435c1d2e80c3e04c44b7695 Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Updated Simple Web Discovery (SWD) Specification X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2012 06:18:09 -0000 --f46d0435c1d2e80c3e04c44b7695 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Jul 6, 2012 at 4:37 PM, Mike Jones wro= te: > I=92ve updated the Simple Web Discovery (SWD)specification to incorporate editorial im= provements suggested by Julian > Reschke and to apply applicable editorial improvements also recently made > to the JOSE specifications. No > normative changes were made.**** > > ** ** > > The updated specification is available at:**** > > **=B7 ** > http://tools.ietf.org/html/draft-jones-simple-web-discovery-03**** > > **[...] > Hi Mike, Does this mean anything with respect to the convergence of Webfinger and SWD? I was a little surprised to see this separate update. -MSK --f46d0435c1d2e80c3e04c44b7695 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Jul 6, 2012 at 4:37 PM, Mike Jones <Michael.Jones@micros= oft.com> wrote:

I=92ve updated the Simple Web Discovery (SWD) specification to incorporate editorial impro= vements suggested by Julian Reschke and to apply applicable editorial impro= vements also recently made to the JOSE= specifications.=A0 No normative changes were made.

=A0

The updated specification is available at:=

=B7=A0=A0=A0=A0=A0=A0=A0=A0 http://tools.ietf.org/html/dr= aft-jones-simple-web-discovery-03

[...]


Hi= Mike,

Does this mean anything with respect to the convergence of We= bfinger and SWD?=A0 I was a little surprised to see this separate update.
-MSK

--f46d0435c1d2e80c3e04c44b7695-- From michiel@unhosted.org Sun Jul 8 00:46:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D83221F8517 for ; Sun, 8 Jul 2012 00:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n-nLJsuVKMO for ; Sun, 8 Jul 2012 00:46:56 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1B121F84FD for ; Sun, 8 Jul 2012 00:46:56 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so17743952pbc.31 for ; Sun, 08 Jul 2012 00:47:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=6W8ujLKs3lJ0kksNy+Ol0FIeEW4Fc0hnm0Sr/p557Oo=; b=EJitB5wEgLQNZ14Kl/rKPL1Q4TqUMlALgOyhZqSILqhVxdKzcSuWnjkrLHN9/6R3xz VWg7OHQTcpM+yHw964R/IrEXpwMY0qFgxv3TXfnvIKVn0eqzuIdLH3d14sgtiCxRX8t4 uRuvp1GlP+5McazhzfKSx22TdtDpyJi6vrj7rrDaVZERLkaGKh1CZJ8ATVt00bMLAGjN a1qJ5YJqHTWmTI8EdacZYjrIQLOGxYHtF0wqIH4q57H+OgS/PIAZBB6qG2wefo2g6MwU 0w95JfStsgBZOpE4XEzKM8RHRY02ptmTyGeiHax23vpRkWN5ZA4hiIcYofjI7rWhJLLT 2EFg== MIME-Version: 1.0 Received: by 10.66.9.2 with SMTP id v2mr57048813paa.65.1341733637490; Sun, 08 Jul 2012 00:47:17 -0700 (PDT) Received: by 10.142.10.4 with HTTP; Sun, 8 Jul 2012 00:47:17 -0700 (PDT) X-Originating-IP: [94.65.228.114] In-Reply-To: References: Date: Sun, 8 Jul 2012 10:47:17 +0300 Message-ID: From: Michiel de Jong To: James M Snell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnbn1VBuQufz1myUH5mvVMzpAPAWfOeHCPKx5HzENQMF1aymUQY5Su45f/EbEXDH9XVNx+M Cc: IETF Apps Discuss Subject: Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and Simple Web Discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2012 07:46:57 -0000 Hi James, Interesting read, especially the use case you describe. I think it can be improved upon by already adding a user-entered password at the first step. I think webfinger's original motivation was much more related to fedsocweb than to configuring a freshly unpacked device, but it would be nice if we can do both. However, in the device-configuring use case i would assume the user inputs both their user address and their password, so we get a sort of resource owner password credentials flow, which IMHO changes the requirements (and in an interesting way). On Sun, Jul 8, 2012 at 8:55 AM, James M Snell wrote: > Figured it would be easier to write this up as an I-D... > > http://www.ietf.org/id/draft-snell-web-index-00.txt > > - James > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From sm@resistor.net Sun Jul 8 03:56:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF5621F86A7 for ; Sun, 8 Jul 2012 03:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz51-djTefYO for ; Sun, 8 Jul 2012 03:56:16 -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 C80BC21F869E for ; Sun, 8 Jul 2012 03:56:16 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q68AuXwK007284 for ; Sun, 8 Jul 2012 03:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341744997; bh=1Xfuiqf3kp5u0ROm9EVhZa9mnBhDyU+HxG9JTiU1RSg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=yLdnzHkYzzgkPmHD/LEDDe3iG84080ekF/3l2cf5O8nxMN87EPJ2iRinGnR5vVRyS ijkcWqyc196F1xH49C1XPeaUxD63m3Z7VIaW/uUS/agTSth0cbTdFttdigoIKiblqc 9tSZNLwvluwIbYlpPUskRhg87siscRXLU9F2DCZs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341744997; i=@resistor.net; bh=1Xfuiqf3kp5u0ROm9EVhZa9mnBhDyU+HxG9JTiU1RSg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=QECmYL6gZEyrtuP9PGZHwfTMqjcibL2gM0p9hR8ppmQKwfhFISZca16oxm/7dpI3l wIGaySHX/nCSNbcUao51avIDhVLJZI2gPQj5zi5ziqSpbmYl3562BxDfnORec17bhc SZxOyxGGBIEOIA8KvqnI59gkRWbEcYjjD4e5V1f4= Message-Id: <6.2.5.6.2.20120708012348.0963c2d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 08 Jul 2012 03:52:10 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: References: <6.2.5.6.2.20120707015014.084dd0c0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] A newcomer question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2012 10:56:19 -0000 Hi Murray, At 20:40 07-07-2012, Murray S. Kucherawy wrote: >Hello SM, and welcome to the IETF! Thank you. :-) >We don't have a hard-and-fast rule. It is typically left to the >discretion of working group chairs and the participants to determine >whether that kind of support for new work exists. I was looking at this in terms of energy and expertise instead of support for new work. >We're in the process of adopting a new plan to select a milestone >for completion of any new work APPSAWG takes on, as well as >selecting such milestones for existing documents. This will be put >in place soon, possibly during the upcoming Vancouver meeting. As an example, one of the drafts being discussed took around six months from the initial adoption by APPSAWG to working group Last Call. That's not a long time. The participants in the discussion over the last months were: Andreas Petersson (one of the authors) Willy Tarreau Ben Niven-Jenkins Martin Thomson Julian Reschke (Applications Area Directorate) Alexey Melnikov (Working Group Chair) Stephen Farrell (Area Director) Barry Leiba (Area Director) Alissa Cooper (IAB member) If I remove people with an IETF role from the above list (it's not a good measure) there are three individuals left. My conclusion is that the draft would not be ready for a Last Call without the contribution of Willy Tarreau, Ben Niven-Jenkins and Martin Thomson. >Are you referring here to Acknowledgements sections of RFCs, or >something else? I was referring to the Acknowledgment section of RFCs. Regards, -sm From barryleiba.mailing.lists@gmail.com Sun Jul 8 09:20:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6902121F85C0 for ; Sun, 8 Jul 2012 09:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.135 X-Spam-Level: X-Spam-Status: No, score=-103.135 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovdn4bglE8w8 for ; Sun, 8 Jul 2012 09:20:23 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2904521F852E for ; Sun, 8 Jul 2012 09:20:22 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so16446397lbb.31 for ; Sun, 08 Jul 2012 09:20:44 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tk8IoQ4rkIW+QUYbVGTq1nFvjYVdiF6k5TZyffoaTCU=; b=n46nDe8/yLrz6ME6wMxYRN9xsDkAUdqMLkcFQvg8PjYQ6pkjtPM0XlW6CXKZACK/vZ cEUqC0f3JeJ29zfWaAkRnL3CTJ5v82IXf1eGtrz66twLf4rcUsrtX+IJ4RckLfpOIwSB WGH4mN+jXsSuOTCJOJd8SjwuhUDL3XDGvdIuj/9875KC+qA+BYSGLxH088HzgNPx06Ia YmhEOM1SXrBefZk+1KR36O99nW52IdEhFKfrsR4FEXNT6P3EHoYquCCnbd0NRFNckOCn JQjSFLD0VDjFH//galAZ5Sb/3jV80arg+cpeQ6fqOrwIaYZT1tOuegMmcIvD1cUz9TT2 siSw== MIME-Version: 1.0 Received: by 10.112.44.163 with SMTP id f3mr16744629lbm.59.1341764444646; Sun, 08 Jul 2012 09:20:44 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Sun, 8 Jul 2012 09:20:44 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120708012348.0963c2d8@resistor.net> References: <6.2.5.6.2.20120707015014.084dd0c0@elandnews.com> <6.2.5.6.2.20120708012348.0963c2d8@resistor.net> Date: Sun, 8 Jul 2012 12:20:44 -0400 X-Google-Sender-Auth: icNXXOY1x1UmShfVZw0AliIUO9w Message-ID: From: Barry Leiba To: SM Content-Type: multipart/alternative; boundary=bcaec554d23e186e5a04c453e1b6 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] A newcomer question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2012 16:20:24 -0000 --bcaec554d23e186e5a04c453e1b6 Content-Type: text/plain; charset=ISO-8859-1 > > > We don't have a hard-and-fast rule. It is typically left to the >> discretion of working group chairs and the participants to determine >> whether that kind of support for new work exists. >> > > I was looking at this in terms of energy and expertise instead of support > for new work. There's no difference in the answer; I think Murray covered your question. As an example, one of the drafts being discussed took around six months > from the initial adoption by APPSAWG to working group Last Call. That's > not a long time. The participants in the discussion over the last months > were: > > Andreas Petersson (one of the authors) > Willy Tarreau > Ben Niven-Jenkins > Martin Thomson > Julian Reschke (Applications Area Directorate) > Alexey Melnikov (Working Group Chair) > Stephen Farrell (Area Director) > Barry Leiba (Area Director) > Alissa Cooper (IAB member) > > If I remove people with an IETF role from the above list (it's not a good > measure) I very strongly disagree. The fact that some people take on role of leadership or responsibility doesn't mean that our work on documents doesn't count. You might reasonably say that Alexey, as chair, and I, as responsible AD, performed ex oficio roles and not contributor roles, but Julian, Stephen, Alissa, and Andreas were very much involved in the document, and their work absolutely "counts" as we tally the contributions. I find it rather amazing that you would even suggest that just because someone is on a directorate or the IAB, they don't get counted in a count of energy and expertise involved in working on a document! Further: > My conclusion is that the draft would not be ready for a Last Call > without the contribution of Willy Tarreau, Ben Niven-Jenkins and Martin > Thomson. I think that's absolutely correct: those three individuals' contributions were important to bringing the document to where it is. That's not a *problem*, but is exactly how the IETF works, and we're in a better position for their contributions. > Are you referring here to Acknowledgements sections of RFCs, or something >> else? >> > > I was referring to the Acknowledgment section of RFCs. I don't see what you're asking here. I don't think appsawg has any special rules for acknowledgments that differ from anything done elsewhere in the IETF, and i don't think it would be appropriate to have any. Barry --bcaec554d23e186e5a04c453e1b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

We don't have a hard-and-fast rule. =A0It is typically left to the disc= retion of working group chairs and the participants to determine whether th= at kind of support for new work exists.

I was looking at this in terms of energy and expertise instead of support f= or new work.

There's no difference in t= he answer; I think Murray covered your question.

As an example, one of the drafts being discussed took around six months fro= m the initial adoption by APPSAWG to working group Last Call. =A0That's= not a long time. =A0The participants in the discussion over the last month= s were:

=A0 Andreas Petersson (one of the authors)
=A0 Willy Tarreau
=A0 Ben Niven-Jenkins
=A0 Martin Thomson
=A0 Julian Reschke (Applications Area Directorate)
=A0 Alexey Melnikov (Working Group Chair)
=A0 Stephen Farrell (Area Director)
=A0 Barry Leiba (Area Director)
=A0 Alissa Cooper (IAB member)

If I remove people with an IETF role from the above list (it's not a go= od measure)
I very strongly disagree. =A0The fact that some people take on r= ole of leadership or responsibility doesn't mean that our work on docum= ents doesn't count. =A0You might reasonably say that Alexey, as chair, = and I, as responsible AD, performed ex oficio roles and not contributor rol= es, but Julian, Stephen, Alissa, and Andreas were very much involved in the= document, and their work absolutely "counts" as we tally the con= tributions. =A0I find it rather amazing that you would even suggest that ju= st because someone is on a directorate or the IAB, they don't get count= ed in a count of energy and expertise involved in working on a document!

Further:
=A0
=A0My conclusion is that the draft would not be ready for a Last Call w= ithout the contribution of Willy Tarreau, Ben Niven-Jenkins and Martin Thom= son.

I think that's absolutely correct: those three indi= viduals' contributions were important to bringing the document to where= it is. =A0That's not a *problem*, but is exactly how the IETF works, a= nd we're in a better position for their contributions.
=A0
Are you referring here to Acknowledgements sections of RFCs, or something e= lse?

I was referring to the Acknowledgment section of RFCs.
I don't see what you're asking here. =A0I don't thi= nk appsawg has any special rules for acknowledgments that differ from anyth= ing done elsewhere in the IETF, and i don't think it would be appropria= te to have any.

Barry=A0
--bcaec554d23e186e5a04c453e1b6-- From dhc@dcrocker.net Sun Jul 8 10:21:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D3621F85BB for ; Sun, 8 Jul 2012 10:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyG3afP6h+O5 for ; Sun, 8 Jul 2012 10:21:58 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C940121F85AA for ; Sun, 8 Jul 2012 10:21:58 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q68HMKwa020020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Jul 2012 10:22:20 -0700 Message-ID: <4FF9C1C0.7010004@dcrocker.net> Date: Sun, 08 Jul 2012 10:22:08 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20120707015014.084dd0c0@elandnews.com> <6.2.5.6.2.20120708012348.0963c2d8@resistor.net> In-Reply-To: <6.2.5.6.2.20120708012348.0963c2d8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 08 Jul 2012 10:22:21 -0700 (PDT) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] A newcomer question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 17:21:59 -0000 On 7/8/2012 3:52 AM, SM wrote: > Hi Murray, > At 20:40 07-07-2012, Murray S. Kucherawy wrote: >> Hello SM, and welcome to the IETF! > > Thank you. :-) > >> We don't have a hard-and-fast rule. It is typically left to the >> discretion of working group chairs and the participants to determine >> whether that kind of support for new work exists. > > I was looking at this in terms of energy and expertise instead of > support for new work. Permit me the cautious suggestion that the search isn't worth the effort. The text isn't a specification and the process isn't mechanical. The text attempts to give a basic sense of things and, I think, it does. Beyond that, everything is subjective and approximate. If some insists on more, we should just fall back to the practice of assessing rough consensus. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john-ietf@jck.com Sun Jul 8 10:55:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0143A21F85A4 for ; Sun, 8 Jul 2012 10:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8lPDH9f9QxE for ; Sun, 8 Jul 2012 10:55:51 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6B08221F859F for ; Sun, 8 Jul 2012 10:55:51 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SnvdH-000FZW-1m; Sun, 08 Jul 2012 13:50:55 -0400 X-Vipre-Scanned: 046DC2CC002C31046DC419-TDI Date: Sun, 08 Jul 2012 13:56:08 -0400 From: John C Klensin To: Barry Leiba , SM Message-ID: In-Reply-To: References: <6.2.5.6.2.20120707015014.084dd0c0@elandnews.com> <6.2.5.6.2.20120708012348.0963c2d8@resistor.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 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] A newcomer question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2012 17:55:52 -0000 --On Sunday, July 08, 2012 12:20 -0400 Barry Leiba wrote: >... >> If I remove people with an IETF role from the above list >> (it's not a good measure) > > > I very strongly disagree. The fact that some people take on > role of leadership or responsibility doesn't mean that our > work on documents doesn't count. You might reasonably say > that Alexey, as chair, and I, as responsible AD, performed ex > oficio roles and not contributor roles, but Julian, Stephen, > Alissa, and Andreas were very much involved in the document, > and their work absolutely "counts" as we tally the > contributions. I find it rather amazing that you would even > suggest that just because someone is on a directorate or the > IAB, they don't get counted in a count of energy and expertise > involved in working on a document! Let me try a different point of view. The calculation SM is trying to do does demonstrate one thing, which is almost certainly true across the IETF and most (or all) other SDOs. That is that, for a given document, the number of people actually doing significant work is fairly small. Certainly it would be nice to change that although I have no idea how to do it. Certainly proposals for measures that optimize the time of those people (i.e., not wasting any more of it than necessary) should be taken seriously. We should also be cautious that any given effort does not suffer from a too-narrow perspective. Beyond that, I don't see a problem that needs solving. I don't want to go so far as to suggest that initiating this discussion involves precisely the waste of time I suggest above that we should avoid. But I think we should recognize that risk. best, john From w@1wt.eu Sun Jul 8 11:06:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DFF21F85A4 for ; Sun, 8 Jul 2012 11:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[AWL=-2.526, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJ5zhi0cmDXq for ; Sun, 8 Jul 2012 11:06:38 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 5B53721F84A1 for ; Sun, 8 Jul 2012 11:06:38 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q68I6ucY011834; Sun, 8 Jul 2012 20:06:56 +0200 Date: Sun, 8 Jul 2012 20:06:56 +0200 From: Willy Tarreau To: SM Message-ID: <20120708180656.GA11524@1wt.eu> References: <6.2.5.6.2.20120707015014.084dd0c0@elandnews.com> <6.2.5.6.2.20120708012348.0963c2d8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120708012348.0963c2d8@resistor.net> User-Agent: Mutt/1.4.2.3i Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] A newcomer question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2012 18:06:39 -0000 Hi SM, since I'm cited, let me tell you my point of view :-) On Sun, Jul 08, 2012 at 03:52:10AM -0700, SM wrote: > If I remove people with an IETF role from the above list (it's not a > good measure) there are three individuals left. It is an error to see it this way. People with an IETF role are even more involved than other ones. Everyone participates with the amount of time he/she can devote and depending on the perceived importance of this participation. > My conclusion is > that the draft would not be ready for a Last Call without the > contribution of Willy Tarreau, Ben Niven-Jenkins and Martin Thomson. I disagree. The draft would be ready whatever the contributors. It would just probably be slightly different. But most of the work always comes from the author. The rest generally is just "fine tuning" and is of much less importance. > >Are you referring here to Acknowledgements sections of RFCs, or > >something else? > > I was referring to the Acknowledgment section of RFCs. I personally don't mind not being cited there considering that my contribution was fairly limited here! I think you should not take importance about this aspect. Many contributors are happy once they can implement something well designed and for most of us that's more important than being acknowledged for this. Regards, Willy From barryleiba@gmail.com Sun Jul 8 11:48:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E8521F859B for ; Sun, 8 Jul 2012 11:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.131 X-Spam-Level: X-Spam-Status: No, score=-103.131 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKad9zKuSaGy for ; Sun, 8 Jul 2012 11:48:45 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A333221F859A for ; Sun, 8 Jul 2012 11:48:45 -0700 (PDT) Received: by qadz3 with SMTP id z3so1203024qad.10 for ; Sun, 08 Jul 2012 11:49:08 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bP1H72qS/f0EHH7DLQEJsEGSUEcs1vzrIfpcfhQO9e8=; b=0myunmTTxsea1XeOO0Qg2h/Y9cdO93FOEoAU/jYjg4WuxEw8bFGNfuFH62ZZ1tpCbj yeb4kyMrqcEJOkuFeUtg5uNHD2Z1//rjn5w80aM8NTeNYOjM721lWPoRTTJFUCRuOLRD rhGTISK6Qb22xNNrxfdeMbWsy2n8N4Pg9c6plK7RyixxNj43IJFRKw/fj2Ep5zo4p0X6 H6H3GpmyvBX/RHF9dGA3vR3js6ZemIrYDt4ytFhG3YjZEGWAxQzLLsufObOFwnKezmVG vFqFUn8VMQw+Pu3HJutlxVdvKwmkkJvQTiry7f/7imve9hpapVWbXGSC7YO9M/MaE2lw 9ukQ== MIME-Version: 1.0 Received: by 10.229.137.72 with SMTP id v8mr19344544qct.79.1341773347914; Sun, 08 Jul 2012 11:49:07 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Sun, 8 Jul 2012 11:49:07 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20120707015014.084dd0c0@elandnews.com> <6.2.5.6.2.20120708012348.0963c2d8@resistor.net> Date: Sun, 8 Jul 2012 14:49:07 -0400 X-Google-Sender-Auth: uPWhRglVB9PdqFRmHMmi4ExOyKU Message-ID: From: Barry Leiba To: John C Klensin Content-Type: multipart/alternative; boundary=00235452fe24c5861504c455f36f Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] A newcomer question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2012 18:48:46 -0000 --00235452fe24c5861504c455f36f Content-Type: text/plain; charset=ISO-8859-1 > Let me try a different point of view. The calculation SM is > trying to do does demonstrate one thing, which is almost > certainly true across the IETF and most (or all) other SDOs. > That is that, for a given document, the number of people > actually doing significant work is fairly small. Yes. It also demonstrates another thing: that a significant group of people get involved in many aspects of the organization, so we see people with a number of roles, of which one is "contributor". Both are things that are common to most (or all) SDOs. I see roughly three levels of involvement: - Those who participate in very many aspects and very many work areas and work items. - Those who participate in one or a few focus areas, often being active in many work items in those areas, but in little outside them. - Those who are around for one or a few specific documents they're interested in. People sometimes shift from one of those groups to another, as their other commitments and their interests allow. We look at the first group as "the usual suspects", the "greybeards", or, perhaps more skeptically, the "old boy network". We think of the second group as having some subject-matter experts. But all three groups, including the third, are important to the technology development process. > We should also be cautious that any > given effort does not suffer from a too-narrow perspective. Quite so, which is where Murray's answer comes in. > Beyond that, I don't see a problem that needs solving. Indeed. > I don't want to go so far as to suggest that initiating this > discussion involves precisely the waste of time I suggest above > that we should avoid. But I think we should recognize that risk. Indeed........ Barry --00235452fe24c5861504c455f36f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Let me try a different point of= view. =A0The calculation SM is
> trying to do does demonstrate one t= hing, which is almost
> certainly true across the IETF and most (or a= ll) other SDOs.
> That is that, for a given document, the number of people
> actua= lly doing significant work is fairly small.

Yes. =A0It also demonstrates another thing: that a significant group o= f people get involved in many aspects of the organization, so we see people= with a number of roles, of which one is "contributor". =A0Both a= re things that are common to most (or all) SDOs.

I see roughly three levels of involvement:
- Those who participa= te in very many aspects and very many work areas and work items.
- Those who participate in one = or a few focus areas, often being active in many work items in those areas,= but in little outside them.
- Those who are around for one or a few specific documents they&#= 39;re interested in.

People sometimes shift from one of those grou= ps to another, as their other commitments and their interests allow.=

We look at the first group as "the usual= suspects", the "greybeards", or, perhaps more skeptically, = the "old boy network". =A0We think of the second group as having = some subject-matter experts. =A0But all three groups, including the third, = are important to the technology development process.

> We should also be cautious that any
<= /span>> given effort does not suf= fer from a too-narrow perspective.

Quite so, whic= h is where Murray's answer comes in.

> Beyond that, I don't see a problem that needs solving.

Indeed.

> I don't want to go so far as to suggest that in= itiating this
> discussion involves precisely the waste of time I sug= gest above
> that we should avoid. =A0But I think we should recognize= that risk.

Indeed......= ..

Barry
--00235452fe24c5861504c455f36f-- From ve7jtb@ve7jtb.com Sun Jul 8 13:26:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A9821F86DF for ; Sun, 8 Jul 2012 13:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iREXUdj+GS7d for ; Sun, 8 Jul 2012 13:26:52 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA1C921F86DB for ; Sun, 8 Jul 2012 13:26:51 -0700 (PDT) Received: by yenq13 with SMTP id q13so10484282yen.31 for ; Sun, 08 Jul 2012 13:27:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=3spaYnN+CzcS+I/pkuINQL0hIKPAhJ1eVAALoTENjUQ=; b=bRm4aFzrlUsqNyde0eIYjAUicxmJpIy9ozLKNg70xw9kr3nTNJ5GsKJzHIhUPmtWaA SHi9Wid2Yf8lCNdPFFh8aATZKiRWjuuV3da2VV5txQz3lzRdrMYjIu2fJPCccTxQURSH RLcZHRWDisHss/h1kt3Poe4i/hNdptMC80AUJ57whDW93yHKYV2WzHXpNQIltbEO6tkD rrxKlOKuPzHmC97UWWT73rfml8DvXE6HlHeJqRsPKqrydTL/F6DeOU53cv8Y1UlcWsLs TgQKhl2AbiKLXfcc1KINC9ZGvX9ssNfupdNEp10xpWct+z53+4spr0kxpQ/k2FEl0Czx BfEA== Received: by 10.100.228.3 with SMTP id a3mr12726568anh.4.1341779234466; Sun, 08 Jul 2012 13:27:14 -0700 (PDT) Received: from [192.168.1.211] (190-20-53-250.baf.movistar.cl. [190.20.53.250]) by mx.google.com with ESMTPS id e5sm28244279ani.18.2012.07.08.13.27.11 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 13:27:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_4BECEB0A-E302-4408-8930-91B4B99C9C26"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Sun, 8 Jul 2012 16:18:10 -0400 Message-Id: <7A30763F-06BB-498E-BB89-477512F9416F@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739436657A9F8@TK5EX14MBXC283.redmond.corp.microsoft.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmCccq8UMseOx6GlmfrcrTSGQotF6M7ArnmDAt6OoUWRDx40IOjikpUrp8mLDK7QmohpmYT Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Updated Simple Web Discovery (SWD) Specification X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2012 20:26:52 -0000 --Apple-Mail=_4BECEB0A-E302-4408-8930-91B4B99C9C26 Content-Type: multipart/alternative; boundary="Apple-Mail=_901F8222-5357-47C6-9D5B-4BBE763C5BAE" --Apple-Mail=_901F8222-5357-47C6-9D5B-4BBE763C5BAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 OpenID Connect still references SWD. Until a decision to switch to a = different discovery spec is taken SWD needs to be kept up to date with = changes in JOSE and be kept from expiring. The update is more a artifact of the IETF process, than a statement = about convergence one way or the other. John B. On 2012-07-08, at 2:18 AM, Murray S. Kucherawy wrote: > On Fri, Jul 6, 2012 at 4:37 PM, Mike Jones = wrote: > I=92ve updated the Simple Web Discovery (SWD) specification to = incorporate editorial improvements suggested by Julian Reschke and to = apply applicable editorial improvements also recently made to the JOSE = specifications. No normative changes were made. >=20 > =20 >=20 > The updated specification is available at: >=20 > =B7 = http://tools.ietf.org/html/draft-jones-simple-web-discovery-03 >=20 > [...] >=20 >=20 > Hi Mike, >=20 > Does this mean anything with respect to the convergence of Webfinger = and SWD? I was a little surprised to see this separate update. >=20 > -MSK >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_901F8222-5357-47C6-9D5B-4BBE763C5BAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Fri, Jul 6, 2012 at 4:37 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

I=92ve updated the Simple Web Discovery (SWD) specification to incorporate editorial = improvements suggested by Julian Reschke and to apply applicable = editorial improvements also recently made to the JOSE specifications.  No normative changes = were made.

 

The = updated specification is available at:

=B7         http://tools.ietf.org/html/draft-jones-simple-web-discov= ery-03

[...]


Hi = Mike,

Does this mean anything with respect to the convergence of = Webfinger and SWD?  I was a little surprised to see this separate = update.

-MSK

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

= --Apple-Mail=_901F8222-5357-47C6-9D5B-4BBE763C5BAE-- --Apple-Mail=_4BECEB0A-E302-4408-8930-91B4B99C9C26 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw ODIwMTgxMVowIwYJKoZIhvcNAQkEMRYEFPJxqkXsQFv066j9AfKRVsdXkJ04MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AJEm6xM2VB5d6ZNcNat1BVNoVgXANnBhvrl62CDiLw7yUSn+c/bzDt67D+4ZK9wOKb32JNMhWRUU 6ke71fbxv5/HfRkpitb5oyZSi37E4RxP6m2hjpDAAym2kxvyfHhwA+ckgSbbVGS25e7ZzK5zRIru pGgA/sP5tFQ+jVT8I6lOOYSWzWFG3nAxrU/V2xMlc0L0Ia7WVMqfdK4guzMDqkWjFDrNwQJ9ezYu doES8B4on1cptD5d5YGmZIyM2L5JFHwZV2ShAqSLTgK/volnKPHaLJI+EKMDmgqYfWIDoICtOxB3 PgL9h5+CSQWcTgbEFeM6VdCkzblPZUSRLihJIu8AAAAAAAA= --Apple-Mail=_4BECEB0A-E302-4408-8930-91B4B99C9C26-- From sm@resistor.net Sun Jul 8 16:26:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E4721F877E for ; Sun, 8 Jul 2012 16:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIRtJPPh5oKY for ; Sun, 8 Jul 2012 16:26:37 -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 E243621F86F7 for ; Sun, 8 Jul 2012 16:26:34 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q68NQgs7020926; Sun, 8 Jul 2012 16:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341790008; bh=4dwDBN1W2t37ZHSka5MiiEn30KhbFjvdnGvqXdwL1bQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=CRyrzRFtfQ5EOjlj6Zn6wIO3RdjzW9tsNTd1xOU4I9IVjLfavBJ5e9rgr+tYD2e0p 3wZiYUxB1rHIg3H3j7d1bRZL2ttlTK9KvxFZWsOoAaSLCuTe7QzbrO/yhl8h4CEnfx AB8fzbDshJE52tuoLq3awAQh120saxYQD9AzEDXc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341790008; i=@resistor.net; bh=4dwDBN1W2t37ZHSka5MiiEn30KhbFjvdnGvqXdwL1bQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=f22UVVqO14dtFbfHcVEsdg5mhflBZUn/AqJJi3lBj6oRUR25OLoXd/Sfz3EeQR7gy mPokZX6d3nNXkLxsANcfAHcDk9icvikcKsAAJEe6jIBjbfj1cFQ2RSEsGh4ZA8MJ89 Andh0hM7WNm5s7zNfFFux7fsBwsklSz091z2nS/I= Message-Id: <6.2.5.6.2.20120708145321.098c0cf8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 08 Jul 2012 16:12:32 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: References: <6.2.5.6.2.20120707015014.084dd0c0@elandnews.com> <6.2.5.6.2.20120708012348.0963c2d8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Barry Leiba , dcrocker@bbiw.net Subject: Re: [apps-discuss] A newcomer question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2012 23:26:40 -0000 Hi All, At 09:20 08-07-2012, Barry Leiba wrote: >I very strongly disagree. The fact that some people take on role of >leadership or responsibility doesn't mean that our work on documents >doesn't count. You might reasonably say that Alexey, as chair, and >I, as responsible AD, performed ex oficio roles and not contributor >roles, but Julian, Stephen, Alissa, and Andreas were very much The persons in roles of leadership or responsibility already know how the IETF works. They already contribute as individuals to drafts in APPSAWG and in other working groups. I am aware of the contributions of the chair and responsible AD. They may have contributed even if they were not performing ex-officio roles. That applies to Julian, Stephen and Alissa too. > involved in the document, and their work absolutely "counts" as we > tally the contributions. I find it rather amazing that you would > even suggest that just because someone is on a directorate or the > IAB, they don't get counted in a count of energy and expertise > involved in working on a document! I was not tallying the contributions or what "counts". More comments below. >I think that's absolutely correct: those three individuals' >contributions were important to bringing the document to where it >is. That's not a *problem*, but is exactly how the IETF works, and >we're in a better position for their contributions. Yes. >I don't see what you're asking here. I don't think appsawg has any >special rules for acknowledgments that differ from anything done >elsewhere in the IETF, and i don't think it would be appropriate to have any. I mentioned practices (not rules) ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06614.html ). As a newcomer it's difficult to figure out what the practices are. At 10:22 08-07-2012, Dave Crocker wrote: >Permit me the cautious suggestion that the search isn't worth the >effort. The text isn't a specification and the process isn't mechanical. Yes. >If some insists on more, we should just fall back to the practice of >assessing rough consensus. No, that was not the aim. I was thinking of a message you sent to a mailing list about history when I wrote the message. At 10:56 08-07-2012, John C Klensin wrote: >Let me try a different point of view. The calculation SM is >trying to do does demonstrate one thing, which is almost >certainly true across the IETF and most (or all) other SDOs. >That is that, for a given document, the number of people >actually doing significant work is fairly small. Certainly it Yes. >would be nice to change that although I have no idea how to do >it. Certainly proposals for measures that optimize the time of >those people (i.e., not wasting any more of it than necessary) >should be taken seriously. We should also be cautious that any >given effort does not suffer from a too-narrow perspective. >Beyond that, I don't see a problem that needs solving. I am not looking at all this as a problem. Some things are nice to have but that's not going to happen. If I had to look at all this, it would be "what could be done to make it easier for people bringing in such work". At 11:06 08-07-2012, Willy Tarreau wrote: >since I'm cited, let me tell you my point of view :-) I appreciate the view as you took the time to explain it. :-) At 11:49 08-07-2012, Barry Leiba wrote: >matter experts. But all three groups, including the third, are >important to the technology development process. Yes. Regards, -sm From Michael.Jones@microsoft.com Sun Jul 8 18:12:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D279F21F87A2 for ; Sun, 8 Jul 2012 18:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.793 X-Spam-Level: X-Spam-Status: No, score=-3.793 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1WhD9lmZWIF for ; Sun, 8 Jul 2012 18:12:17 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id B0D9521F8687 for ; Sun, 8 Jul 2012 18:12:16 -0700 (PDT) Received: from mail64-am1-R.bigfish.com (10.3.201.238) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Jul 2012 01:10:24 +0000 Received: from mail64-am1 (localhost [127.0.0.1]) by mail64-am1-R.bigfish.com (Postfix) with ESMTP id 66F0DE0149; Mon, 9 Jul 2012 01:10:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zz98dI9371I936eIc85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail64-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail64-am1 (localhost.localdomain [127.0.0.1]) by mail64-am1 (MessageSwitch) id 1341796221172975_30837; Mon, 9 Jul 2012 01:10:21 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.228]) by mail64-am1.bigfish.com (Postfix) with ESMTP id D386E46004A; Mon, 9 Jul 2012 01:10:20 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Jul 2012 01:10:20 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0309.003; Mon, 9 Jul 2012 01:12:27 +0000 From: Mike Jones To: John Bradley , "Murray S. Kucherawy" Thread-Topic: [apps-discuss] Updated Simple Web Discovery (SWD) Specification Thread-Index: Ac1b0EyAcPaXuGBuSOiGR3vxHnsclABAS2aAAB1UPwAACiuyEA== Date: Mon, 9 Jul 2012 01:12:26 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657C5AD@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436657A9F8@TK5EX14MBXC283.redmond.corp.microsoft.com> <7A30763F-06BB-498E-BB89-477512F9416F@ve7jtb.com> In-Reply-To: <7A30763F-06BB-498E-BB89-477512F9416F@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436657C5ADTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Updated Simple Web Discovery (SWD) Specification X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2012 01:12:19 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436657C5ADTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with John's characterization. Until such time as it's clear that a= n Apps Area discovery specification has stabilized, is simple and efficient= enough, and is headed for approval, I believe that the consensus among the= OpenID Connect working group is to stick with Simple Web Discovery. This = draft refreshed the SWD spec, since the -02 draft had expired. -- Mike From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Sunday, July 08, 2012 1:18 PM To: Murray S. Kucherawy Cc: Mike Jones; Julian Reschke; apps-discuss@ietf.org Subject: Re: [apps-discuss] Updated Simple Web Discovery (SWD) Specificatio= n OpenID Connect still references SWD. Until a decision to switch to a diff= erent discovery spec is taken SWD needs to be kept up to date with changes = in JOSE and be kept from expiring. The update is more a artifact of the IETF process, than a statement about c= onvergence one way or the other. John B. On 2012-07-08, at 2:18 AM, Murray S. Kucherawy wrote: On Fri, Jul 6, 2012 at 4:37 PM, Mike Jones > wrote: I've updated the Simple Web Discovery (SWD) specification to incorporate editorial improv= ements suggested by Julian Reschke and to apply applicable editorial improv= ements also recently made to the JOSE= specifications. No normative changes were made. The updated specification is available at: * http://tools.ietf.org/html/draft-jones-simple-web-discovery-03 [...] Hi Mike, Does this mean anything with respect to the convergence of Webfinger and SW= D? I was a little surprised to see this separate update. -MSK _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_000_4E1F6AAD24975D4BA5B16804296739436657C5ADTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with John’s= characterization.  Until such time as it’s clear that an Apps A= rea discovery specification has stabilized, is simple and efficient enough, and is headed for approval, I believe that the consensus among the OpenID = Connect working group is to stick with Simple Web Discovery.  This dra= ft refreshed the SWD spec, since the -02 draft had expired.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: John Bra= dley [mailto:ve7jtb@ve7jtb.com]
Sent: Sunday, July 08, 2012 1:18 PM
To: Murray S. Kucherawy
Cc: Mike Jones; Julian Reschke; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Updated Simple Web Discovery (SWD) Speci= fication

 

OpenID Connect still references SWD.   Until a = decision to switch to a different discovery spec is taken SWD needs to be k= ept up to date with changes in JOSE and be kept from expiring.

 

The update is more a artifact of the IETF process, t= han a statement about convergence one way or the other.

 

John B.

 

On 2012-07-08, at 2:18 AM, Murray S. Kucherawy wrote= :



On Fri, Jul 6, 2012 at 4:37 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

I’ve updated the Simple Web Discovery (SWD) specification to incorporate editorial impro= vements suggested by Julian Reschke and to apply applicable editorial impro= vements also recently made to the JOSE= specifications.  No normative changes were made.

 

The updated specification is available at:

·         http://tools.ietf.org/html/draft-jones-simple-web-= discovery-03

[...]


Hi Mike,

Does this mean anything with respect to the convergence of Webfinger and SW= D?  I was a little surprised to see this separate update.

-MSK

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436657C5ADTK5EX14MBXC283r_-- From internet-drafts@ietf.org Mon Jul 9 06:57:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DB221F8616; Mon, 9 Jul 2012 06:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouP9i54escUJ; Mon, 9 Jul 2012 06:57:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEEC11E8079; Mon, 9 Jul 2012 06:57:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p2 Message-ID: <20120709135722.20538.74124.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 06:57:22 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2012 13:57:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Forwarded HTTP Extension Author(s) : Andreas Petersson Martin Nilsson Filename : draft-ietf-appsawg-http-forwarded-06.txt Pages : 17 Date : 2012-07-09 Abstract: This document standardizes an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. Given a trusted path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-http-forwarded-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Mon Jul 9 09:28:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72BA11E811F; Mon, 9 Jul 2012 09:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSWeqP0lLc3c; Mon, 9 Jul 2012 09:28:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CCD21F8637; Mon, 9 Jul 2012 09:28:50 -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: 4.30p3 Message-ID: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 09:28:48 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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: Mon, 09 Jul 2012 16:28:53 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Forwarded HTTP Extension' as Proposed Standard 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 2012-07-23. 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 This document standardizes an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. Given a trusted path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/ No IPR declarations have been submitted directly on this I-D. ==================================== A specific point for Last Call discussion, please: During AD Evaluation, the registration policy for the new "HTTP Forwarded parameters" registry (see Section 9) was changed to "Specification Required" from "RFC Required". This needs further review during Last Call, for two reasons: 1. While RFC Required forces new registrations through the IETF RFC process, and might discourage registrations from individuals or organizations that are unfamiliar with or averse to that process, Specification Required necessitates the appointment of a Designated Expert to review the requests and associated specifications. Each of these policies comes with baggage, and we have to make sure we're weighing it down with the *right* baggage. 2. If we stay with Specification Required we should include a short paragraph with rough guidelines for the Designated Expert: what to consider when approving registration requests. If we want the DE to approve most requests, just checking the associated specifications for sanity, we need to say that. If we want the DE to put some judgment into deciding whether the requested parameters make sense and fit into the usage model, or whatever, we should say something about that. Comments and proposed text for this are encouraged. ==================================== From acooper@cdt.org Mon Jul 9 11:27:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2681811E811E; Mon, 9 Jul 2012 11:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1tAXrdxrOcO; Mon, 9 Jul 2012 11:27:28 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1CE11E8119; Mon, 9 Jul 2012 11:27:28 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Mon, 9 Jul 2012 14:27:51 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> Date: Mon, 9 Jul 2012 14:27:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> To: IETF Discussion Mailing List X-Mailer: Apple Mail (2.1084) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2012 18:27:29 -0000 (incorporating some responses to = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06599.html = as a LC comment) It would be helpful if this document could further motivate the need for = proxies to generate static obfuscated tokens. These two lines in = particular, from 6.3 and 8.3, respectively, seem a bit weak: "The identifiers can be randomly generated for each request and do not need to be statically assigned to resources." "When using such tokens, a static token per user would increase the possibility for external organizations to track separate users." Is it possible to recommend that generated tokens have limited lifetimes = (per-request or otherwise), and make the static case the exception? The = first statement above gets at this, but it seems to me that the middle = ground between random generation per request and permanent unique token = is worth emphasizing if there will be proxies that want to keep = per-client identifiers around for some limited amount of time that isn't = forever. It's also worth noting that the second statement above is equally true = for statically provisioned client IP addresses. Also, this statement in 8.3 is not really true and probably better left = out: "Proxies using this extension will preserve the information of a direct connection, which has an end-user privacy impact, if the end- user or deployer does not know or expect that this is the case." There can certainly be a privacy impact whether the user or deployer has = awareness/expectation or not.=20 Alissa On Jul 9, 2012, at 12:28 PM, The IESG wrote: >=20 > The IESG has received a request from the Applications Area Working = Group > WG (appsawg) to consider the following document: > - 'Forwarded HTTP Extension' > as Proposed Standard >=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 2012-07-23. 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. >=20 > Abstract >=20 >=20 > This document standardizes an HTTP extension header field that = allows > proxy components to disclose information lost in the proxying > process, for example, the originating IP address of a request or IP > address of the proxy on the user-agent-facing interface. Given a > trusted path of proxying components, this makes it possible to > arrange it so that each subsequent component will have access to, = for > example, all IP addresses used in the chain of proxied HTTP = requests. >=20 > This document also specifies guidelines for a proxy administrator to > anonymize the origin of a request. >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ >=20 > IESG discussion can be tracked via > = http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > A specific point for Last Call discussion, please: > During AD Evaluation, the registration policy for the new "HTTP > Forwarded parameters" registry (see Section 9) was changed to > "Specification Required" from "RFC Required". This needs further > review during Last Call, for two reasons: >=20 > 1. While RFC Required forces new registrations through the IETF RFC > process, and might discourage registrations from individuals or > organizations that are unfamiliar with or averse to that process, > Specification Required necessitates the appointment of a Designated > Expert to review the requests and associated specifications. Each of > these policies comes with baggage, and we have to make sure we're > weighing it down with the *right* baggage. >=20 > 2. If we stay with Specification Required we should include a short > paragraph with rough guidelines for the Designated Expert: what to > consider when approving registration requests. If we want the DE to > approve most requests, just checking the associated specifications for > sanity, we need to say that. If we want the DE to put some judgment > into deciding whether the requested parameters make sense and fit into > the usage model, or whatever, we should say something about that.=20 > Comments and proposed text for this are encouraged. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 From sm@resistor.net Mon Jul 9 14:22:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086A411E8173; Mon, 9 Jul 2012 14:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJXwMGFq2ulp; Mon, 9 Jul 2012 14:21:57 -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 B4BCA11E80E4; Mon, 9 Jul 2012 14:21:57 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q69LLx7m017297; Mon, 9 Jul 2012 14:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341868925; bh=sQcyKrJ7hAmWjwTfm63Thdab5jqyPxDj7kbudVysXB8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Tokl53q1VxLDXSsTzhsNZwPJ4Nlp9jVwFdxuWWnauSs/RXKIYmeVWI2FHKYgk38y6 4GGp+xSwfls4CbOVJoFubTV646b+W/UJfy6HEyHPnBePU0xuEdcK8ZUC6FXxb4CasZ hchDhXNHycJYUfVCiEGvItnXhf8lQxTTkSzv2SdM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341868925; i=@resistor.net; bh=sQcyKrJ7hAmWjwTfm63Thdab5jqyPxDj7kbudVysXB8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=nGacxioge+UP4ZG5j5QRjkTzcBshZcNwxrqIBcO+7R/hXbs8dkw7op7x/ND+u1Jwo 8Doy5nyuolYxLBzL6gFcy8cIG10rSNN/Fxy6pn5QJnSMKLaSQ5HVkRdcvc6V7jmDn/ 51IBZvmDDsXVngdLAGmL+SOsfzID0NGFgyXQ5+Wk= Message-Id: <6.2.5.6.2.20120709134136.0ad9ae18@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 Jul 2012 13:59:43 -0700 To: IETF Discussion Mailing List From: SM In-Reply-To: <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2012 21:22:01 -0000 At 11:27 09-07-2012, Alissa Cooper wrote: >Is it possible to recommend that generated tokens have limited >lifetimes (per-request or otherwise), and make the static case the >exception? The first statement above gets at this, but it seems to >me that the middle ground between random generation per request and >permanent unique token is worth emphasizing if there will be proxies >that want to keep per-client identifiers around for some limited >amount of time that isn't forever. Yes. >It's also worth noting that the second statement above is equally >true for statically provisioned client IP addresses. > >Also, this statement in 8.3 is not really true and probably better left out: > >"Proxies using this extension will preserve the information of a > direct connection, which has an end-user privacy impact, if the end- > user or deployer does not know or expect that this is the case." I suggest removing that statement. The wording is not entirely clear. I read it as diluting end-user privacy impact. In Section 6.3: 'To distinguish the obfuscated identifier from other identifiers, it MUST have a leading underscore "_".' I suggest removing the requirement and using "can". The implementer can decide what to put in that field. Regards, -sm From stephen.farrell@cs.tcd.ie Mon Jul 9 14:48:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49F211E80D1; Mon, 9 Jul 2012 14:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9APYT-dVnkz; Mon, 9 Jul 2012 14:48:36 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 0D60611E80CD; Mon, 9 Jul 2012 14:48:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id BD5911714F8; Mon, 9 Jul 2012 22:49:00 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341870540; bh=+DywMSR6z98hRJ F3D95Q1Q+d7NWe/iYIhuv4ZoRiefk=; b=hb4Nqv36nJWvP1mP0z/6iAHIEGmJLH 0Cotx7bBMK3gYJZTvui2lXovJoCcjsrTaxkZkwIHeNQtYlGRMRdw1SPbDmzckIL2 y/+YR73HKZGd2+nw7AB3kBxypmo/U+fd2Pg/CrYaVumYMhWWNtklWBJE4Do9r0QS 8YTXiH6ObGDMF8zRfjCA9RfmiJDma2rUwTS8JYbFcqvKL6BVwDVWgaTrZTs9xQKQ rJghL7Iv4ouMwdZfPS+/A3gJvYj3LinnWWsGTiHwe4nQivQ3hT3EW2WD/gxrNw8x U3TwUiBraZV7UNryaaAYJ2M/0R/Y/SXSzylz8PQURlpmm7IeHlke9Jpw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id imNGqDbZg-Sg; Mon, 9 Jul 2012 22:49:00 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.25.143]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C8E5B1714F7; Mon, 9 Jul 2012 22:48:59 +0100 (IST) Message-ID: <4FFB51CB.2070608@cs.tcd.ie> Date: Mon, 09 Jul 2012 22:48:59 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: ietf@ietf.org References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> In-Reply-To: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2012 21:48:38 -0000 So I have a question about this draft that wasn't resolved on apps-discuss and is maybe more suited for IETF LC anyway. With geopriv, we've gone to a lot of trouble to support end-users having some control over their location privacy. This HTTP header will be used by proxies to forward on the IP address of a client, and that will be used via geo-ip services to locate the HTTP client. But in this case, there's no control whatsoever for the end user, nor are they even told that its happened. That seems to me to be quite a disconnect, but I'm not sure what if anything ought be done about it, since in this case, there's a non-standard header that's widely deployed that does this. So if we did try encourage taking the geopriv approach we'd presumably just be ignored. Any ideas? Ta, S. On 07/09/2012 05:28 PM, The IESG wrote: > > The IESG has received a request from the Applications Area Working Group > WG (appsawg) to consider the following document: > - 'Forwarded HTTP Extension' > as Proposed Standard > > 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 2012-07-23. 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 > > > This document standardizes an HTTP extension header field that allows > proxy components to disclose information lost in the proxying > process, for example, the originating IP address of a request or IP > address of the proxy on the user-agent-facing interface. Given a > trusted path of proxying components, this makes it possible to > arrange it so that each subsequent component will have access to, for > example, all IP addresses used in the chain of proxied HTTP requests. > > This document also specifies guidelines for a proxy administrator to > anonymize the origin of a request. > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > ==================================== > A specific point for Last Call discussion, please: > During AD Evaluation, the registration policy for the new "HTTP > Forwarded parameters" registry (see Section 9) was changed to > "Specification Required" from "RFC Required". This needs further > review during Last Call, for two reasons: > > 1. While RFC Required forces new registrations through the IETF RFC > process, and might discourage registrations from individuals or > organizations that are unfamiliar with or averse to that process, > Specification Required necessitates the appointment of a Designated > Expert to review the requests and associated specifications. Each of > these policies comes with baggage, and we have to make sure we're > weighing it down with the *right* baggage. > > 2. If we stay with Specification Required we should include a short > paragraph with rough guidelines for the Designated Expert: what to > consider when approving registration requests. If we want the DE to > approve most requests, just checking the associated specifications for > sanity, we need to say that. If we want the DE to put some judgment > into deciding whether the requested parameters make sense and fit into > the usage model, or whatever, we should say something about that. > Comments and proposed text for this are encouraged. > ==================================== > > From wwwrun@rfc-editor.org Mon Jul 9 17:07:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B411E812A; Mon, 9 Jul 2012 17:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.908 X-Spam-Level: X-Spam-Status: No, score=-101.908 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7r9plz9-7KPS; Mon, 9 Jul 2012 17:07:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id CC51A11E8120; Mon, 9 Jul 2012 17:07:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6BF59B1E006; Mon, 9 Jul 2012 17:07:54 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120710000754.6BF59B1E006@rfc-editor.org> Date: Mon, 9 Jul 2012 17:07:54 -0700 (PDT) Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 6657 on Update to MIME regarding "charset" Parameter Handling in Textual Media Types X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 00:07:34 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6657 Title: Update to MIME regarding "charset" Parameter Handling in Textual Media Types Author: A. Melnikov, J. Reschke Status: Standards Track Stream: IETF Date: July 2012 Mailbox: Alexey.Melnikov@isode.com, julian.reschke@greenbytes.de Pages: 6 Characters: 10111 Updates: RFC2046 I-D Tag: draft-ietf-appsawg-mime-default-charset-04.txt URL: http://www.rfc-editor.org/rfc/rfc6657.txt This document changes RFC 2046 rules regarding default "charset" parameter values for "text/*" media types to better align with common usage by existing clients and servers. [STANDARDS-TRACK] This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From sm@resistor.net Mon Jul 9 17:10:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D4711E8148 for ; Mon, 9 Jul 2012 17:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thC5WQXc9ij9 for ; Mon, 9 Jul 2012 17:10:47 -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 1A8E111E8153 for ; Mon, 9 Jul 2012 17:10:47 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6A0AseU001350; Mon, 9 Jul 2012 17:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341879059; bh=FBv32pvqT86uQIxHj9yU/WC0q4EIe+M/6po2cYwQm6E=; h=Date:To:From:Subject:Cc; b=z9ZnHQVfDa21N/xAhSZMAONpFzZdYNTq6zmOgpZeeXBa1UDmdmo0y+NeLsIpFt/rI /R2ZXWSDI+7Je5sKbTBgi6K9Fjm2P231dhODbJb6eXDbOC8lCsHPuROvJsjPqX92AS pkKjMctarZ9GOn9CZx+K7OfOFfVhWd7fDilLmmlY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341879059; i=@resistor.net; bh=FBv32pvqT86uQIxHj9yU/WC0q4EIe+M/6po2cYwQm6E=; h=Date:To:From:Subject:Cc; b=y3AkfBVW21AYbKbnYKTMAl20SCnwe6k7awnGIoIZ6CHtnqT76WPlWghsDOZIEqn44 X6QEDAybXoDW71Qv9VDVd0rIGUBJMe+r/ZuPLDqxSoU8T2pXc7HQi8+ZHD492LeYSx hIO3k75v6nEDtTVPAoStH1bz1FAoWXksyPDkGUig= Message-Id: <6.2.5.6.2.20120709155447.05cf1c18@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 Jul 2012 17:09:01 -0700 To: Hannes Tschofenig From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: [apps-discuss] Comments on draft-tschofenig-hourglass-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 00:10:51 -0000 Hi Hannes, [Cc to apps-discuss as it seems like an Area subject] I read draft-tschofenig-hourglass-00. I found it interesting. In Section 7: "The author is, however, struggling with the question whether there is enough evidence to conclude that every protocol design today shall build on HTTP/HTTPS (rather than voluntarily using to use HTTP/HTTPS because of its properties)." I wondered how many IETF specifications are voluntarily being built over HTTP/HTTPS. During the HYBI discussions there was the usual debate about whether to leapfrog over HTTP. MILE used HTTPS on a different port (needs a fact check). WEIRDS seems to be following the HTTP path, do does REPUTE. XMPP has a HTTP angle (Peter, please correct me). RTCWEB followed the HTTP angle. HTTP seems like the "de facto" standard. That would be similar to IP. You used the word "voluntarily". Isn't it like low-hanging fruit? The port is open. There is a wide choice of freely available code. There is experience in getting around middleboxes constraints. The user already has the basic software. Regards, -sm From paulej@packetizer.com Mon Jul 9 20:31:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A17F11E8137 for ; Mon, 9 Jul 2012 20:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5kX+Ys1GOkc for ; Mon, 9 Jul 2012 20:31:56 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC8211E8139 for ; Mon, 9 Jul 2012 20:31:56 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q6A3WLHV015840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Jul 2012 23:32:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341891141; bh=cRaWZ4CYcIW/lx4ds9H6DWDSal6gJYRkvIvxkBOum7o=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=X/ZL3KVahBsMz3MTgdf1stDVAW6lEquxx7Adi557PuyjHPgh4eHNiI6XA4qXSsosO 2TFBBNSZaDCAKIJzTmYBIHhn33BNw7AmZi9mrEQMTSvNloj6vq5mVMQho1WSD0BC5u d/BFeBSFjTHZr0G56xNe2IKsvRxPnSNJFjPUC1vU= From: "Paul E. Jones" To: "'James M Snell'" , "'IETF Apps Discuss'" References: In-Reply-To: Date: Mon, 9 Jul 2012 23:32:25 -0400 Message-ID: <0bfa01cd5e4c$9ff2fe40$dfd8fac0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIESQ8ibvH5DCcy0bSWDNtRTuLHcZaz6I+Q Content-Language: en-us Subject: Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and Simple Web Discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 03:31:57 -0000 James, Allow me to comment on your draft w.r.t. the parts related to WebFinger. WebFinger did built upon the host-meta spec, which is that we see the "two step" process. However, the "resource" parameter MUST be supported by WebFinger servers. As such, this eliminates most of the complexity issues on the client side. To your comments specifically, 1) XRD and JRD support: this is only required on the server. The client can choose what it wants. This is largely historical, but I'm not shy to say that I favor XML. I respect that some prefer JSON, though. 2) Two-step HTTP request process: Requests could be a single step. No client is required to implement a two-step request, ever. The two-step option exists, since WebFinger is an extension of RFC 6415, but the "resource" makes the query a one-step operation. 3) There are several sub-parts: 3a) The WebFinger protocol defines normative dependencies on no fewer than ten separate specifications: that's being a bit unfair. We tried to be thorough with documenting material. We could perhaps make .well-known, web linking, URI syntax, and mailto URI informative. We could discuss where those references should live, but HTTP and XRD/JRD are really the core part of WebFinger. It's not so complex as you suggest here. 3b) A WebFinger client needs to not only be capable of sending HTTP requests; but capable of parsing XML or JSON: They must parse one of the two. This is pretty basic. 3c) Capable of understanding the specific XRD and JRD vocabularies: there are no "specific" vocabularies, just XRD and JRD syntax. Both are simple and a client picks what it wants. 3d) Capable of processing URL Templates: since "resource" is mandatory, a client does not need to deal with templates 3e) Capable of processing XML digital signatures included within an XRD document: yeah, if HTTPS is not used. I doubt anybody will use signatures in favor of HTTPS. I suspect no client will process the signatures, either. (There is "standards completeness" and reality.) 4) WebFinger uses email-like identifiers and this is a privacy concern: email-like IDs are suggested to make WebFinger easy to use *by humans*, but there is definitely no requirement that one MUST use "acct:paulej@packetizer.com". One can use any valid URI. An enterprise could use some cryptic URI. The recommendation to use paulej@packetizer.com, for example, it to make your life easier if you want to learn more about me. What is actually exposed and what is accessible is a matter of the publisher of that content and can be secured using standard web security mechanisms. Note that use of HTTPS also hides the email-like ID, too, so it's not seen on the wire, so I'm really not sure why you're concerned with this. Those who want security will use TLS. So just to reiterate, a WebFinger request for this URL: https://packetizer.com/.well-known/host-meta.json?resource=acct:paulej@packe tizer.com Typically looks like this: GET /.well-known/host-meta.json?resource=acct:paulej@packetizer.com HTTP/1.1 Host: packetizer.com The reply might have this body: { "subject" : "acct:paulej@packetizer.com", "links" : [ { "rel" : "http://webfinger.net/rel/avatar", "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg" }, { "rel" : "http://specs.openid.net/auth/2.0/provider", "href" : "https://openid.packetizer.com/paulej" }, { "rel" : "http://webfinger.net/rel/profile-page", "href" : "http://www.packetizer.com/people/paulej/" }, { "rel" : "vcard", "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" }, { "rel" : "http://schemas.google.com/g/2010#updates-from", "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml" } ] } That's a fairly simple request / response, IMO. Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of James M Snell > Sent: Sunday, July 08, 2012 1:56 AM > To: IETF Apps Discuss > Subject: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and > Simple Web Discovery > > Figured it would be easier to write this up as an I-D... > > http://www.ietf.org/id/draft-snell-web-index-00.txt > > - James > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From jasnell@gmail.com Mon Jul 9 22:16:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A927621F8599 for ; Mon, 9 Jul 2012 22:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.139 X-Spam-Level: X-Spam-Status: No, score=-5.139 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTfNdyAxiv0w for ; Mon, 9 Jul 2012 22:16:49 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD4321F8598 for ; Mon, 9 Jul 2012 22:16:48 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so8339992wgb.13 for ; Mon, 09 Jul 2012 22:17:15 -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=3OPvR+OrVAmPNl15Lvs0DMT+TVlZRdkCP2ZCS09XwpI=; b=G+F86a/cl2LNKzWabLi3QLrMhOsLF3zSw89ONe1AqcHhEmSyPzamsJdUazA/hpjsMm gXopi6fjnD40rZwb7gQ5/MxYzd4NuI2ha8n8V1566CFBQMMVKXF6h8Hf7gJP9MaWt8+o ngaYf9AmwdupmVQ5tfwvXh7/FwT8P7MTN9qfqbAsJVFn7ysHuIhRwXaLCN/31vyBSH1D XnKzKUoi1GTC9rAIvGqtLgaluwQ+MBcMJvoNyCJlFn2bok4/dMjazAHwEjzZMdlPL111 r7Kls5eCuLbpI5Axnnox0EXoh3pHqFpo/27Q1tBZdBKkp0JCHFSncMwZ69TU+sFVFt5y 4U4Q== Received: by 10.216.240.10 with SMTP id d10mr1292248wer.157.1341897435138; Mon, 09 Jul 2012 22:17:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.67 with HTTP; Mon, 9 Jul 2012 22:16:54 -0700 (PDT) In-Reply-To: <0bfa01cd5e4c$9ff2fe40$dfd8fac0$@packetizer.com> References: <0bfa01cd5e4c$9ff2fe40$dfd8fac0$@packetizer.com> From: James M Snell Date: Mon, 9 Jul 2012 22:16:54 -0700 Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and Simple Web Discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 05:16:50 -0000 Hey Paul, I definitely appreciate the detailed response. Perhaps I was a bit harsh in my criticisms but the overall points still remain... A few comments inline... On Mon, Jul 9, 2012 at 8:32 PM, Paul E. Jones wrote: > James, > > Allow me to comment on your draft w.r.t. the parts related to WebFinger. > WebFinger did built upon the host-meta spec, which is that we see the "two > step" process. However, the "resource" parameter MUST be supported by > WebFinger servers. As such, this eliminates most of the complexity issues > on the client side. > > To your comments specifically, > > 1) XRD and JRD support: this is only required on the server. The client can > choose what it wants. This is largely historical, but I'm not shy to say > that I favor XML. I respect that some prefer JSON, though. > Why should there be a choice at all? Just choose one and be done with it... preferably the least complicated of the two (http://www.xprogramming.com/Practices/PracSimplest.html) > 2) Two-step HTTP request process: Requests could be a single step. No > client is required to implement a two-step request, ever. The two-step > option exists, since WebFinger is an extension of RFC 6415, but the > "resource" makes the query a one-step operation. > Yup... I made sure to point this out clearly in my note. If, as you say, clients are not ever required to implement the two-step flow, then why is it defined at all? Why add the additional complexity? This was one of the main points of my document and my counter proposal for /.well-known/index ... the RFC6415 requirement seems entirely superfluous to achieving the goal. > 3) There are several sub-parts: > > 3a) The WebFinger protocol defines normative dependencies on no fewer than > ten separate specifications: that's being a bit unfair. We tried to be > thorough with documenting material. We could perhaps make .well-known, web > linking, URI syntax, and mailto URI informative. We could discuss where > those references should live, but HTTP and XRD/JRD are really the core part > of WebFinger. It's not so complex as you suggest here. > > 3b) A WebFinger client needs to not only be capable of sending HTTP > requests; but capable of parsing XML or JSON: They must parse one of the > two. This is pretty basic. > > 3c) Capable of understanding the specific XRD and JRD vocabularies: there > are no "specific" vocabularies, just XRD and JRD syntax. Both are simple and > a client picks what it wants. > > 3d) Capable of processing URL Templates: since "resource" is mandatory, a > client does not need to deal with templates I think you may have missed the key point I was making: XML, JSON, XRD, JRD, URL templates, Digital Signatures, host-meta.. these are all things that WebFinger says are required without providing any reasonable justification as to WHY they are required. Both the Simple Web Discovery draft and my /.well-known/index examples illustrate that we can easily solve the fundamental problem with a whole lot less than what WebFinger defines... even if those things are -- by your own statement -- only there for "spec completeness". > > 3e) Capable of processing XML digital signatures included within an XRD > document: yeah, if HTTPS is not used. I doubt anybody will use signatures in > favor of HTTPS. I suspect no client will process the signatures, either. > (There is "standards completeness" and reality.) > > 4) WebFinger uses email-like identifiers and this is a privacy concern: > email-like IDs are suggested to make WebFinger easy to use *by humans*, but > there is definitely no requirement that one MUST use > "acct:paulej@packetizer.com". One can use any valid URI. An enterprise > could use some cryptic URI. The recommendation to use > paulej@packetizer.com, for example, it to make your life easier if you want > to learn more about me. What is actually exposed and what is accessible is > a matter of the publisher of that content and can be secured using standard > web security mechanisms. Note that use of HTTPS also hides the email-like > ID, too, so it's not seen on the wire, so I'm really not sure why you're > concerned with this. Those who want security will use TLS. Several things with this one... 1. All of the examples that deal with people show the use of acct identifiers. From experience, I know that developers will generally look at the examples in the spec before they look at the spec text itself and they will generally follow whatever pattern is illustrated... Simply saying that "some cryptic URI" could be used does not sufficiently deal with the issue. Support for hashed or otherwise obfuscated identifiers within the request URI should be made explicit .. either via clear example or by normative requirement. 2. The use of SSL/TLS does not prevent request URIs from being recorded in log files, exposed in browsers, or compromised in a variety of unforeseen ways. Yes, it protects the data in transit but protects nothing when the data is at rest. > > So just to reiterate, a WebFinger request for this URL: > > https://packetizer.com/.well-known/host-meta.json?resource=acct:paulej@packe > tizer.com > > Typically looks like this: > > GET /.well-known/host-meta.json?resource=acct:paulej@packetizer.com HTTP/1.1 > Host: packetizer.com > > The reply might have this body: > > { > "subject" : "acct:paulej@packetizer.com", > "links" : > [ > { > "rel" : "http://webfinger.net/rel/avatar", > "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg" > }, > { > "rel" : "http://specs.openid.net/auth/2.0/provider", > "href" : "https://openid.packetizer.com/paulej" > }, > { > "rel" : "http://webfinger.net/rel/profile-page", > "href" : "http://www.packetizer.com/people/paulej/" > }, > { > "rel" : "vcard", > "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" > }, > { > "rel" : "http://schemas.google.com/g/2010#updates-from", > "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml" > } > ] > } > > That's a fairly simple request / response, IMO. > And an alternative approach would look like.. (the numbers are the sha-256 digest of the acct id) GET /.well-known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d7f8 HTTP/1.1 Host: packetizer.com HTTP/1.1 300 Multiple Choices Link: ; rel="http://webfinger.net/rel/avatar", ; rel="http://specs.openid.net/auth/2.0/provider", ; rel="http://webfinger.net/rel/profile.page", ; rel="vcard", ; rel="http://schemas.google.com/g/2010#updates-from" And if all I want is the location of the avatar, for instance, it could be even easier... GET /.well-known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d7f8/avatar HTTP/1.1 Host: packetizer.com HTTP/1.1 302 Found Location: /people/paulej/images/paulej.jpg Why should I, as the client, ever have to worry about XRD/JRD at all? This is an important question that I have not yet seen an adequate answer for. Anyone who has worked with me before on things knows that with solid examples and a reasonable explanation I can be swayed to see the light and the error of my ways. So far, however, I am just not seeing it here. - James > Paul > >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] >> On Behalf Of James M Snell >> Sent: Sunday, July 08, 2012 1:56 AM >> To: IETF Apps Discuss >> Subject: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and >> Simple Web Discovery >> >> Figured it would be easier to write this up as an I-D... >> >> http://www.ietf.org/id/draft-snell-web-index-00.txt >> >> - James >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > From jasnell@gmail.com Mon Jul 9 22:18:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A39621F85A2 for ; Mon, 9 Jul 2012 22:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.985 X-Spam-Level: X-Spam-Status: No, score=-4.985 tagged_above=-999 required=5 tests=[AWL=-1.386, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cs8da8U1D-6F for ; Mon, 9 Jul 2012 22:18:24 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A57321F85DD for ; Mon, 9 Jul 2012 22:18:23 -0700 (PDT) Received: by were53 with SMTP id e53so2680968wer.31 for ; Mon, 09 Jul 2012 22:18:50 -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=HA8HpAbmWCkBmyTjSKKdqBR86K4gwxzZvU7oftgqHFU=; b=zqSQ2ZsqfAiuhmY2vnw0xR1+fqwjtUtEaI822pYJwUBv2VP6GzKV7v4ci8uSEXxA+U er+C8suFYnL1hWIGcLmubMjq0zGkQKJQ8MwWlH1xty924YKOTT0UlJUzuSwRDRpLTAE1 Epzj0Z8x9IzedXjHj6oV7ABJuGjEd6J+S4R41YO4hZIO5UyIfEUqsS90DNrkmyRQfN5S qnBycW8ME1fwdVbZyvoUovYRsTRSIXll++V9vAOVO1ClF0NeSZ6JsVxpi2s/dKkREu3L kYUW22V4Po4VfABxx62jSf8sYkf3GlQvH8/gcnfnNTJq/N0PI8XQQfX0f66sW3p57me3 FTYw== Received: by 10.216.240.10 with SMTP id d10mr1294331wer.157.1341897530005; Mon, 09 Jul 2012 22:18:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.67 with HTTP; Mon, 9 Jul 2012 22:18:29 -0700 (PDT) In-Reply-To: <0bfa01cd5e4c$9ff2fe40$dfd8fac0$@packetizer.com> References: <0bfa01cd5e4c$9ff2fe40$dfd8fac0$@packetizer.com> From: James M Snell Date: Mon, 9 Jul 2012 22:18:29 -0700 Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and Simple Web Discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 05:18:25 -0000 Hey Paul, I definitely appreciate the detailed response. Perhaps I was a bit harsh in my criticisms but the overall points still remain... A few comments inline... On Mon, Jul 9, 2012 at 8:32 PM, Paul E. Jones wrote: > James, > > Allow me to comment on your draft w.r.t. the parts related to WebFinger. > WebFinger did built upon the host-meta spec, which is that we see the "two > step" process. However, the "resource" parameter MUST be supported by > WebFinger servers. As such, this eliminates most of the complexity issues > on the client side. > > To your comments specifically, > > 1) XRD and JRD support: this is only required on the server. The client can > choose what it wants. This is largely historical, but I'm not shy to say > that I favor XML. I respect that some prefer JSON, though. > Why should there be a choice at all? Just choose one and be done with it... preferably the least complicated of the two (http://www.xprogramming.com/Practices/PracSimplest.html) > 2) Two-step HTTP request process: Requests could be a single step. No > client is required to implement a two-step request, ever. The two-step > option exists, since WebFinger is an extension of RFC 6415, but the > "resource" makes the query a one-step operation. > Yup... I made sure to point this out clearly in my note. If, as you say, clients are not ever required to implement the two-step flow, then why is it defined at all? Why add the additional complexity? This was one of the main points of my document and my counter proposal for /.well-known/index ... the RFC6415 requirement seems entirely superfluous to achieving the goal. > 3) There are several sub-parts: > > 3a) The WebFinger protocol defines normative dependencies on no fewer than > ten separate specifications: that's being a bit unfair. We tried to be > thorough with documenting material. We could perhaps make .well-known, web > linking, URI syntax, and mailto URI informative. We could discuss where > those references should live, but HTTP and XRD/JRD are really the core part > of WebFinger. It's not so complex as you suggest here. > > 3b) A WebFinger client needs to not only be capable of sending HTTP > requests; but capable of parsing XML or JSON: They must parse one of the > two. This is pretty basic. > > 3c) Capable of understanding the specific XRD and JRD vocabularies: there > are no "specific" vocabularies, just XRD and JRD syntax. Both are simple and > a client picks what it wants. > > 3d) Capable of processing URL Templates: since "resource" is mandatory, a > client does not need to deal with templates I think you may have missed the key point I was making: XML, JSON, XRD, JRD, URL templates, Digital Signatures, host-meta.. these are all things that WebFinger says are required without providing any reasonable justification as to WHY they are required. Both the Simple Web Discovery draft and my /.well-known/index examples illustrate that we can easily solve the fundamental problem with a whole lot less than what WebFinger defines... even if those things are -- by your own statement -- only there for "spec completeness". > > 3e) Capable of processing XML digital signatures included within an XRD > document: yeah, if HTTPS is not used. I doubt anybody will use signatures in > favor of HTTPS. I suspect no client will process the signatures, either. > (There is "standards completeness" and reality.) > > 4) WebFinger uses email-like identifiers and this is a privacy concern: > email-like IDs are suggested to make WebFinger easy to use *by humans*, but > there is definitely no requirement that one MUST use > "acct:paulej@packetizer.com". One can use any valid URI. An enterprise > could use some cryptic URI. The recommendation to use > paulej@packetizer.com, for example, it to make your life easier if you want > to learn more about me. What is actually exposed and what is accessible is > a matter of the publisher of that content and can be secured using standard > web security mechanisms. Note that use of HTTPS also hides the email-like > ID, too, so it's not seen on the wire, so I'm really not sure why you're > concerned with this. Those who want security will use TLS. Several things with this one... 1. All of the examples that deal with people show the use of acct identifiers. From experience, I know that developers will generally look at the examples in the spec before they look at the spec text itself and they will generally follow whatever pattern is illustrated... Simply saying that "some cryptic URI" could be used does not sufficiently deal with the issue. Support for hashed or otherwise obfuscated identifiers within the request URI should be made explicit .. either via clear example or by normative requirement. 2. The use of SSL/TLS does not prevent request URIs from being recorded in log files, exposed in browsers, or compromised in a variety of unforeseen ways. Yes, it protects the data in transit but does nothing when the data is at rest. For example, an unrelated but similar problem to this is the use of API Ke > > So just to reiterate, a WebFinger request for this URL: > > https://packetizer.com/.well-known/host-meta.json?resource=acct:paulej@packe > tizer.com > > Typically looks like this: > > GET /.well-known/host-meta.json?resource=acct:paulej@packetizer.com HTTP/1.1 > Host: packetizer.com > > The reply might have this body: > > { > "subject" : "acct:paulej@packetizer.com", > "links" : > [ > { > "rel" : "http://webfinger.net/rel/avatar", > "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg" > }, > { > "rel" : "http://specs.openid.net/auth/2.0/provider", > "href" : "https://openid.packetizer.com/paulej" > }, > { > "rel" : "http://webfinger.net/rel/profile-page", > "href" : "http://www.packetizer.com/people/paulej/" > }, > { > "rel" : "vcard", > "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" > }, > { > "rel" : "http://schemas.google.com/g/2010#updates-from", > "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml" > } > ] > } > > That's a fairly simple request / response, IMO. > > Paul > >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] >> On Behalf Of James M Snell >> Sent: Sunday, July 08, 2012 1:56 AM >> To: IETF Apps Discuss >> Subject: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and >> Simple Web Discovery >> >> Figured it would be easier to write this up as an I-D... >> >> http://www.ietf.org/id/draft-snell-web-index-00.txt >> >> - James >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > From jasnell@gmail.com Mon Jul 9 22:27:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2D811E813E for ; Mon, 9 Jul 2012 22:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.859 X-Spam-Level: X-Spam-Status: No, score=-4.859 tagged_above=-999 required=5 tests=[AWL=-1.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrZQxlSCxYdE for ; Mon, 9 Jul 2012 22:27:39 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F11A11E814E for ; Mon, 9 Jul 2012 22:27:33 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so8344155wgb.13 for ; Mon, 09 Jul 2012 22:27:59 -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=fvTuZaFprZ6TiCSlMf5Qc/P8vcLIGx/iz/p/bL6H/9U=; b=ic7p2M92NA+gom4Eeh7Wyz9CujA9hy811XOXBEaATaWwleCY7AT17crt7/udp8crNC qDYlXbXXYAw3viciH/VR+Cpwd3IEr7dcWvJVkz3I4fySBK5ocDxCafydtBygFIBIQPDC MExF1CJbJKctH/DVVXlKFdYbCnsq5dvhGNEZta2n7Buwwropc6KDbQGEWBPlqRbYd+eO 7RhGLxehbhTW1JceLWNYDVvF1bp2IuWakx0wyMBghXhqL8jnY7tggGCfr4bT64R7lwQ1 NnUISwIBRj/ZvkQUuDFWpNVS/dVJq3KH9yVYtzBeQvCKInoILXvIOiBCYfMt6/PUuLjt 63qw== Received: by 10.216.240.10 with SMTP id d10mr1306910wer.157.1341898079492; Mon, 09 Jul 2012 22:27:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.67 with HTTP; Mon, 9 Jul 2012 22:27:39 -0700 (PDT) In-Reply-To: References: <0bfa01cd5e4c$9ff2fe40$dfd8fac0$@packetizer.com> From: James M Snell Date: Mon, 9 Jul 2012 22:27:39 -0700 Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and Simple Web Discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 05:27:40 -0000 I apologize for the duplicate post... looks like gmail and my internet connection weren't getting along there for a second... not sure how it ended up sending out a partial version of my response... On Mon, Jul 9, 2012 at 10:18 PM, James M Snell wrote: > Hey Paul, > > I definitely appreciate the detailed response. Perhaps I was a bit > harsh in my criticisms but the overall points still remain... A few > comments inline... > > On Mon, Jul 9, 2012 at 8:32 PM, Paul E. Jones wrote: >> James, >> >> Allow me to comment on your draft w.r.t. the parts related to WebFinger. >> WebFinger did built upon the host-meta spec, which is that we see the "two >> step" process. However, the "resource" parameter MUST be supported by >> WebFinger servers. As such, this eliminates most of the complexity issues >> on the client side. >> >> To your comments specifically, >> >> 1) XRD and JRD support: this is only required on the server. The client can >> choose what it wants. This is largely historical, but I'm not shy to say >> that I favor XML. I respect that some prefer JSON, though. >> > > Why should there be a choice at all? Just choose one and be done with > it... preferably the least complicated of the two > (http://www.xprogramming.com/Practices/PracSimplest.html) > >> 2) Two-step HTTP request process: Requests could be a single step. No >> client is required to implement a two-step request, ever. The two-step >> option exists, since WebFinger is an extension of RFC 6415, but the >> "resource" makes the query a one-step operation. >> > > Yup... I made sure to point this out clearly in my note. If, as you > say, clients are not ever required to implement the two-step flow, > then why is it defined at all? Why add the additional complexity? This > was one of the main points of my document and my counter proposal for > /.well-known/index ... the RFC6415 requirement seems entirely > superfluous to achieving the goal. > >> 3) There are several sub-parts: >> >> 3a) The WebFinger protocol defines normative dependencies on no fewer than >> ten separate specifications: that's being a bit unfair. We tried to be >> thorough with documenting material. We could perhaps make .well-known, web >> linking, URI syntax, and mailto URI informative. We could discuss where >> those references should live, but HTTP and XRD/JRD are really the core part >> of WebFinger. It's not so complex as you suggest here. >> >> 3b) A WebFinger client needs to not only be capable of sending HTTP >> requests; but capable of parsing XML or JSON: They must parse one of the >> two. This is pretty basic. >> >> 3c) Capable of understanding the specific XRD and JRD vocabularies: there >> are no "specific" vocabularies, just XRD and JRD syntax. Both are simple and >> a client picks what it wants. >> >> 3d) Capable of processing URL Templates: since "resource" is mandatory, a >> client does not need to deal with templates > > I think you may have missed the key point I was making: XML, JSON, > XRD, JRD, URL templates, Digital Signatures, host-meta.. these are all > things that WebFinger says are required without providing any > reasonable justification as to WHY they are required. Both the Simple > Web Discovery draft and my /.well-known/index examples illustrate that > we can easily solve the fundamental problem with a whole lot less than > what WebFinger defines... even if those things are -- by your own > statement -- only there for "spec completeness". > >> >> 3e) Capable of processing XML digital signatures included within an XRD >> document: yeah, if HTTPS is not used. I doubt anybody will use signatures in >> favor of HTTPS. I suspect no client will process the signatures, either. >> (There is "standards completeness" and reality.) >> >> 4) WebFinger uses email-like identifiers and this is a privacy concern: >> email-like IDs are suggested to make WebFinger easy to use *by humans*, but >> there is definitely no requirement that one MUST use >> "acct:paulej@packetizer.com". One can use any valid URI. An enterprise >> could use some cryptic URI. The recommendation to use >> paulej@packetizer.com, for example, it to make your life easier if you want >> to learn more about me. What is actually exposed and what is accessible is >> a matter of the publisher of that content and can be secured using standard >> web security mechanisms. Note that use of HTTPS also hides the email-like >> ID, too, so it's not seen on the wire, so I'm really not sure why you're >> concerned with this. Those who want security will use TLS. > > Several things with this one... > > 1. All of the examples that deal with people show the use of acct > identifiers. From experience, I know that developers will generally > look at the examples in the spec before they look at the spec text > itself and they will generally follow whatever pattern is > illustrated... Simply saying that "some cryptic URI" could be used > does not sufficiently deal with the issue. Support for hashed or > otherwise obfuscated identifiers within the request URI should be made > explicit .. either via clear example or by normative requirement. > > 2. The use of SSL/TLS does not prevent request URIs from being > recorded in log files, exposed in browsers, or compromised in a > variety of unforeseen ways. Yes, it protects the data in transit but > does nothing when the data is at rest. For example, an unrelated but > similar problem to this is the use of API Ke > >> >> So just to reiterate, a WebFinger request for this URL: >> >> https://packetizer.com/.well-known/host-meta.json?resource=acct:paulej@packe >> tizer.com >> >> Typically looks like this: >> >> GET /.well-known/host-meta.json?resource=acct:paulej@packetizer.com HTTP/1.1 >> Host: packetizer.com >> >> The reply might have this body: >> >> { >> "subject" : "acct:paulej@packetizer.com", >> "links" : >> [ >> { >> "rel" : "http://webfinger.net/rel/avatar", >> "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg" >> }, >> { >> "rel" : "http://specs.openid.net/auth/2.0/provider", >> "href" : "https://openid.packetizer.com/paulej" >> }, >> { >> "rel" : "http://webfinger.net/rel/profile-page", >> "href" : "http://www.packetizer.com/people/paulej/" >> }, >> { >> "rel" : "vcard", >> "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" >> }, >> { >> "rel" : "http://schemas.google.com/g/2010#updates-from", >> "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml" >> } >> ] >> } >> >> That's a fairly simple request / response, IMO. >> >> Paul >> >>> -----Original Message----- >>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] >>> On Behalf Of James M Snell >>> Sent: Sunday, July 08, 2012 1:56 AM >>> To: IETF Apps Discuss >>> Subject: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and >>> Simple Web Discovery >>> >>> Figured it would be easier to write this up as an I-D... >>> >>> http://www.ietf.org/id/draft-snell-web-index-00.txt >>> >>> - James >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >> From w@1wt.eu Mon Jul 9 23:08:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A2621F86A5; Mon, 9 Jul 2012 23:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.421 X-Spam-Level: X-Spam-Status: No, score=-4.421 tagged_above=-999 required=5 tests=[AWL=-2.378, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3NIQLFDDiZ7; Mon, 9 Jul 2012 23:08:54 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 8E36621F8646; Mon, 9 Jul 2012 23:08:53 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q6A69CDQ021452; Tue, 10 Jul 2012 08:09:12 +0200 Date: Tue, 10 Jul 2012 08:09:12 +0200 From: Willy Tarreau To: Stephen Farrell Message-ID: <20120710060912.GA19405@1wt.eu> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <4FFB51CB.2070608@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFB51CB.2070608@cs.tcd.ie> User-Agent: Mutt/1.4.2.3i Cc: ietf@ietf.org, Apps Discuss Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 06:08:55 -0000 On Mon, Jul 09, 2012 at 10:48:59PM +0100, Stephen Farrell wrote: > > So I have a question about this draft that wasn't > resolved on apps-discuss and is maybe more suited > for IETF LC anyway. > > With geopriv, we've gone to a lot of trouble to > support end-users having some control over their > location privacy. > > This HTTP header will be used by proxies to forward > on the IP address of a client, and that will be used > via geo-ip services to locate the HTTP client. In practice, the real use for the header is in the reverse-proxy chain, as many people already disable x-forwarded-for on outgoing proxies for privacy concerns. And server-side generally ignores the untrustable x-forwarded-for provided by clients anyway. In the abstract, the draft says it's for use between trusted proxies, which generally means either the client-side proxy chain for logging purposes, where the last one will remove the info, or more generally the server side where everyone appends itself. Maybe a small paragraph on this might emphasize the intended purpose and suggest use cases as well as software options to add/ignore/remove the header depending on the proxy location in the chain. Regards, Willy From James.H.Manger@team.telstra.com Mon Jul 9 23:17:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC0421F86C7 for ; Mon, 9 Jul 2012 23:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.213 X-Spam-Level: X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMzqFyp8+9ln for ; Mon, 9 Jul 2012 23:17:53 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC2021F86CA for ; Mon, 9 Jul 2012 23:17:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,558,1336312800"; d="scan'208";a="86572084" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 10 Jul 2012 16:18:12 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6767"; a="76052933" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcbni.tcif.telstra.com.au with ESMTP; 10 Jul 2012 16:18:11 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Tue, 10 Jul 2012 16:18:10 +1000 From: "Manger, James H" To: James M Snell , "Paul E. Jones" Date: Tue, 10 Jul 2012 16:18:09 +1000 Thread-Topic: draft-snell-web-index-00: hash of user-id Thread-Index: Ac1eY8a0ab+/OteVQy6vrExeGobWAQ== Message-ID: <255B9BB34FB7D647A506DC292726F6E114F79777E6@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IETF Apps Discuss Subject: [apps-discuss] draft-snell-web-index-00: hash of user-id X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 06:17:54 -0000 SmFtZXMsDQoNCj4gQW5kIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNoIHdvdWxkIGxvb2sgbGlrZS4u ICh0aGUgbnVtYmVycyBhcmUgdGhlDQo+IHNoYS0yNTYgZGlnZXN0IG9mIHRoZSBhY2N0IGlkKQ0K PiANCj4gR0VUIC8ud2VsbC1rbm93bi9pbmRleC80NTY0YjRlY2ZjMzk0ZDZlZGE5ODg0YzBjZDdk MmQ5OTI3OWI3MmI5Yzk2NjE4MTE1ZTg3NjdhYTk3YjFkN2Y4DQo+IEhUVFAvMS4xDQo+IEhvc3Q6 IHBhY2tldGl6ZXIuY29tDQo+IA0KPiBIVFRQLzEuMSAzMDAgTXVsdGlwbGUgQ2hvaWNlcw0KPiBM aW5rOiA8L3Blb3BsZS9wYXVsZWovaW1hZ2VzL3BhdWxlai5qcGc+OyByZWw9Imh0dHA6Ly93ZWJm aW5nZXIubmV0L3JlbC9hdmF0YXIiDQoNCg0KVXNpbmcgYSBoYXNoIGluc3RlYWQgb2YgYSB1c2Vy LWlkIGFkZHMgYSBsaXR0bGUgcHJpdmFjeSwgYnV0IGl0IGRvZXMgcmVxdWlyZSB0aGF0IGJvdGgg ZW5kcyBub3JtYWxpemUgdGhlIHVzZXItaWQgcHJlY2lzZWx5IHRoZSBzYW1lIHdheS4gQXJlIHlv dSBjb25maWRlbnQgdGhhdCB3b3VsZG4ndCBiZSBhIHByb2JsZW0gaW4gcHJhY3RpY2U/DQoNCkZv ciBpbnN0YW5jZSwgYWxsIHRoZSBmb2xsb3dpbmcgYXJlIGRpZmZlcmVudCAoYW5kIG5vbmUgYXJl IDQ1NjRi4oCmN2Y4KToNCjEuIFNIQS0yNTYoInBhdWxlaiIpDQoyLiBTSEEtMjU2KCJwYXVsZWpA cGFja2V0aXplci5jb20iKQ0KMy4gU0hBLTI1NigiYWNjdDpwYXVsZWpAcGFja2V0aXplci5jb20i KQ0KNC4gU0hBLTI1NigiQUNDVDpwYXVsZWpAcGFja2V0aXplci5jb20iKQ0KNS4gU0hBLTI1Nigi YWNjdDpwYXVsZWpAUEFDS0VUSVpFUi5DT00iKQ0KNi4gU0hBLTI1NigiYWNjdDpQYXVsRUpAcGFj a2V0aXplci5jb20iKQ0KNy4gU0hBLTI1NigiYWNjdDpww6R1bMOpakBwYWNrZXRpemVyLmNvbSIp DQo4LiBTSEEtMjU2KCJhY2N0OnAlQzMlQTR1bCVDMyVBOWpAcGFja2V0aXplci5jb20iKQ0KOS4g U0hBLTI1NigiYWNjdDpwJWMzJWE0dWwlYzMlYTlqQHBhY2tldGl6ZXIuY29tIikNCjEwLiDigKYN Cg0KTWFueSBvZiB0aGUgYWJvdmUgYXJlIDEwMCUgdmFsaWQgZXhhY3QgZXF1aXZhbGVudHMgKGVn IC5jb20gdnMgLkNPTSkuIE90aGVycyBhcmUgdXN1YWxseSBlcXVpdmFsZW50IGluIHByYWN0aWNl IChlZyBQYXVsRUogdnMgcGF1bGVqKS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCg== From Hannes.Tschofenig@gmx.net Tue Jul 10 00:10:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0730911E8149 for ; Tue, 10 Jul 2012 00:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPN9q3vavO23 for ; Tue, 10 Jul 2012 00:10:09 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D50E111E8122 for ; Tue, 10 Jul 2012 00:10:08 -0700 (PDT) Received: (qmail invoked by alias); 10 Jul 2012 07:10:34 -0000 Received: from unknown (EHLO [10.255.134.171]) [194.251.119.201] by mail.gmx.net (mp027) with SMTP; 10 Jul 2012 09:10:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+NccYz0eONWUnzKeeoP9vwialVRYSVl0o05mUCfv oItNXNsg90Z4NZ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Hannes Tschofenig In-Reply-To: <6.2.5.6.2.20120709155447.05cf1c18@elandnews.com> Date: Tue, 10 Jul 2012 10:10:32 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20120709155447.05cf1c18@elandnews.com> To: SM X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-tschofenig-hourglass-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 07:10:10 -0000 Hi SM,=20 thanks for looking at the document.=20 By voluntary I mean that protocol designers have a choice and I = understand that they want to use HTTP because it offers features they = want and of course they are familiar with. If you pick HTTP then nobody = will ask questions. If you develop your own protocol then it will raise = eyebrows. You see the same happening with the shift from ASN.1 to XML = and now to JSON as well.=20 It is good that people re-use protocols. I use HTTP/HTTPS in protocol = designs as well.=20 If people just use HTTP because of its features that's one story but if = they use it to get through firewalls then that's a different aspect. = This story is a bit more complicated.=20 There are obviously different networks that vary in their packet = filtering behavior. For enterprise networks where your end device is = under the control of the administrator neither HTTP nor HTTPS will get = you through firewalls, if the administrator does not like it. For the = public Internet we are lacking data as to the degree of filtering. There = are some papers available, and I cite them in the draft, but that isn't = really a lot to conclude that you need HTTP or even HTTPS to avoid = filtering of your data by intermediaries.=EF=BB=BF Ciao Hannes PS: In your list below you mention RTCWEB and it is quite different than = the rest of the protocols since it not only relies on HTTP but it = heavily focuses on JavaScript to provide the necessary functionality.=20 On Jul 10, 2012, at 3:09 AM, SM wrote: > Hi Hannes, >=20 > [Cc to apps-discuss as it seems like an Area subject] >=20 > I read draft-tschofenig-hourglass-00. I found it interesting. In = Section 7: >=20 > "The author is, however, struggling with the question whether there = is > enough evidence to conclude that every protocol design today shall > build on HTTP/HTTPS (rather than voluntarily using to use HTTP/HTTPS > because of its properties)." >=20 > I wondered how many IETF specifications are voluntarily being built = over HTTP/HTTPS. During the HYBI discussions there was the usual debate = about whether to leapfrog over HTTP. MILE used HTTPS on a different = port (needs a fact check). WEIRDS seems to be following the HTTP path, = do does REPUTE. XMPP has a HTTP angle (Peter, please correct me). = RTCWEB followed the HTTP angle. >=20 > HTTP seems like the "de facto" standard. That would be similar to IP. = You used the word "voluntarily". Isn't it like low-hanging fruit? The = port is open. There is a wide choice of freely available code. There = is experience in getting around middleboxes constraints. The user = already has the basic software. >=20 > Regards, > -sm >=20 From James.H.Manger@team.telstra.com Tue Jul 10 00:28:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8696621F8656 for ; Tue, 10 Jul 2012 00:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.962 X-Spam-Level: X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-0bWe8boP8C for ; Tue, 10 Jul 2012 00:28:01 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id B049221F8599 for ; Tue, 10 Jul 2012 00:28:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,558,1336312800"; d="scan'208";a="86584300" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 10 Jul 2012 17:28:28 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6767"; a="23744954" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcani.tcif.telstra.com.au with ESMTP; 10 Jul 2012 17:28:26 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Tue, 10 Jul 2012 17:28:26 +1000 From: "Manger, James H" To: James M Snell , IETF Apps Discuss Date: Tue, 10 Jul 2012 17:28:24 +1000 Thread-Topic: redirects in draft-snell-web-index/WebFinger/SWD Thread-Index: Ac1ebZdwjBexuPD7TWKll5mjW1TbAQ== Message-ID: <255B9BB34FB7D647A506DC292726F6E114F797793C@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [apps-discuss] redirects in draft-snell-web-index/WebFinger/SWD X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 07:28:01 -0000 VmFyaW91cyBwZW9wbGUgaGF2ZSBzYWlkIHRoYXQgbWFueSAoYmlnPykgc2l0ZXMgd2lsbCBub3Qg d2FudCB0byBzZXJ2ZSBwZXItdXNlciBkaXNjb3ZlcnkgZGV0YWlscyBmcm9tIHRoZWlyIHRvcC1k b21haW4uIEZvciBleGFtcGxlLCB0aGV5IHdpbGwgc2VydmUgaXQgZnJvbSBodHRwczovL2lkLmV4 YW1wbGUuY29tLywgbm90IGh0dHBzOi8vZXhhbXBsZS5jb20vLg0KDQpSZWRpcmVjdGluZyBhbGwg ZGlzY292ZXJ5IHJlcXVlc3QgZnJvbSBleGFtcGxlLmNvbSB0byBpZC5leGFtcGxlLmNvbSB3b3Jr cywgYnV0IGl0IGRvZXMgYWRkIGEgcm91bmQgdHJpcC4gSWYgY2xpZW50cyBjYW4gZGV0ZXJtaW5l IHRoYXQgdGhlIHJlZGlyZWN0aW9uIHdpbGwgYXBwbHkgdG8gYWxsIGZ1dHVyZSBkaXNjb3Zlcnkg cmVxdWVzdHMsIG5vdCBqdXN0IHRoZSBzcGVjaWZpYyBvbmUgdGhleSBhcmUgY3VycmVudGx5IG1h a2luZywgdGhlbiB0aGUgZXh0cmEgcm91bmQgdHJpcCBpcyBhIG9uY2Utb2ZmIHRoYXQgY2FuIGJl IGlnbm9yZWQuDQoNClNXRCBzb2x2ZXMgdGhpcyB3aXRoIGl0cyBjb250ZW50LWxheWVyIFNXRF9z ZXJ2aWNlX3JlZGlyZWN0Lg0KDQpXZWJGaW5nZXItd2l0aG91dC1yZXNvdXJjZS1wYXJhbWV0ZXIg c29sdmVzIHRoaXMgYnkgcHJvdmlkaW5nIGEgdGVtcGxhdGUgZm9yIHBlci11c2VyIGRldGFpbHMg dGhhdCBjYW4gdXNlIGFub3RoZXIgZG9tYWluLCBlZyBodHRwczovL2lkLmV4YW1wbGUuY29tL3Vz ZXI/dT17dXJpfTsgb3IgYnkgcmVkaXJlY3RpbmcgdGhlIChub24tdXNlci1zcGVjaWZpYykgaW5p dGlhbCByZXF1ZXN0Lg0KDQpXZWJGaW5nZXItd2l0aC1hLXJlc291cmNlLXBhcmFtZXRlciBhbmQg ZHJhZnQtc25lbGwtd2ViLWluZGV4IGRvbid0IHNvbHZlIHRoaXMgaXNzdWUuDQoNCklkZWFsbHks IHdlIHNob3VsZCBzb2x2ZSB0aGlzIGF0IHRoZSBIVFRQIGxheWVyLiBBbiBIVFRQIDN4eCByZXNw b25zZSBzaG91bGQgYmUgYWJsZSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBzYW1lIHJlc3BvbnNlIGFw cGxpZXMgdG8gYWxsIFVSSXMgd2l0aCBhIGdpdmVuIHByZWZpeC4gSG93IGFib3V0Og0KDQogIEhU VFAvMS4xIDMwNyBNb3ZlZA0KICBMb2NhdGlvbjogaHR0cHM6Ly9pZC5leGFtcGxlLmNvbS91c2Vy P3U9YWNjdDpwYXVsZWpAcGFja2V0aXplci5jb20NCiAgUmVkaXJlY3Q6IC8ud2VsbC1rbm93bi9m aW5nZXIgaHR0cHM6Ly9pZC5leGFtcGxlLmNvbS91c2VyDQoNClRoZSAiUmVkaXJlY3QiIGhlYWRl ciBpbmNsdWRlcyBhIHBhdGgtcHJlZml4IGFuZCBkZXN0aW5hdGlvbiBVUkkuIFRoZSBzYW1lIHJl ZGlyZWN0IGFwcGxpZXMgdG8gYW55IHJlcXVlc3Qgd2hvc2UgcGF0aCBzdGFydHMgd2l0aCBwYXRo LXByZWZpeC4gVGhlIHBhcnQgb2YgdGhlIHJlcXVlc3QgYWZ0ZXIgdGhlIHBhdGgtcHJlZml4IGlz IGFwcGVuZGVkIHRvIHRoZSBkZXN0aW5hdGlvbiBVUkkgdG8gZ2V0IHRoZSBuZXcgbG9jYXRpb24u DQpJdCBpcyBwb3RlbnRpYWxseSBkYW5nZXJvdXMgKGEgcmVzcG9uc2UgZnJvbSBhbnkgcmVzb3Vy Y2Ugb24gYSBzaXRlIGNhbiByZWRpcmVjdCByZXF1ZXN0cyB0byBhbGwgb3RoZXIgcmVzb3VyY2Vz IG9uIHRoZSBzaXRlKSwgYnV0IHRoYXQgbWlnaHQgYmUgc29sdmFibGUuDQoNCi0tDQpKYW1lcyBN YW5nZXINCg0KDQo= From julian.reschke@gmx.de Tue Jul 10 01:00:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB4811E80B7 for ; Tue, 10 Jul 2012 01:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.816 X-Spam-Level: X-Spam-Status: No, score=-104.816 tagged_above=-999 required=5 tests=[AWL=-2.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuY-S800v49u for ; Tue, 10 Jul 2012 01:00:03 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0134511E808E for ; Tue, 10 Jul 2012 01:00:02 -0700 (PDT) Received: (qmail invoked by alias); 10 Jul 2012 08:00:28 -0000 Received: from p54BB3690.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.54.144] by mail.gmx.net (mp035) with SMTP; 10 Jul 2012 10:00:28 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18WON1Hq+AWGCrSFEaZo5iFkA0sqsRVFgJXNW0N1n TuOg/I0w1Q9sXO Message-ID: <4FFBE114.4090003@gmx.de> Date: Tue, 10 Jul 2012 10:00:20 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E114F797793C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F797793C@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] redirects in draft-snell-web-index/WebFinger/SWD X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 08:00:04 -0000 On 2012-07-10 09:28, Manger, James H wrote: > Various people have said that many (big?) sites will not want to serve per-user discovery details from their top-domain. For example, they will serve it from https://id.example.com/, not https://example.com/. > > Redirecting all discovery request from example.com to id.example.com works, but it does add a round trip. If clients can determine that the redirection will apply to all future discovery requests, not just the specific one they are currently making, then the extra round trip is a once-off that can be ignored. > > SWD solves this with its content-layer SWD_service_redirect. > > WebFinger-without-resource-parameter solves this by providing a template for per-user details that can use another domain, eg https://id.example.com/user?u={uri}; or by redirecting the (non-user-specific) initial request. > > WebFinger-with-a-resource-parameter and draft-snell-web-index don't solve this issue. > > Ideally, we should solve this at the HTTP layer. An HTTP 3xx response should be able to indicate that the same response applies to all URIs with a given prefix. How about: > > HTTP/1.1 307 Moved > Location: https://id.example.com/user?u=acct:paulej@packetizer.com > Redirect: /.well-known/finger https://id.example.com/user > > The "Redirect" header includes a path-prefix and destination URI. The same redirect applies to any request whose path starts with path-prefix. The part of the request after the path-prefix is appended to the destination URI to get the new location. > It is potentially dangerous (a response from any resource on a site can redirect requests to all other resources on the site), but that might be solvable. > ... Sounds like the Redirect-Ref response header defined in (which gets away with a single URI or URI-reference). Best regards, Julian From stephen.farrell@cs.tcd.ie Tue Jul 10 01:55:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF8321F859A for ; Tue, 10 Jul 2012 01:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 635WgWYAWrSD for ; Tue, 10 Jul 2012 01:55:13 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id BE18921F8595 for ; Tue, 10 Jul 2012 01:55:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E32511714F0; Tue, 10 Jul 2012 09:55:30 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341910528; bh=RceKZwbb2/fDbm hE9SRnqmbxasQ31rw90pQJhC7aSAY=; b=Y/qezHlJMNPNMEaGRQE6ekuHw90KPa 2+R+NrhUJ9hqbwAn1lIi6Iw/VA74/yKMW4bJVHu6ONJ6PpTy4vumCBWGT0cUga1Z QDgqbsddrH9Of7TOva2CiJD+j4cvNNfT1ib1+nJ2Y8Ss3wB/hbu/Z0ywdsYZxTfo J6yePDhF77Het9yByX4c+GF2CTMFVATUDwzRhAd8B5DMySOSPjZAEUYOYwION8lC ig8iBuwQIaX5MJIHYRs93RU6peAF+JMkNlM2OnQSQwGY3/GkXoOWbEkotNR59gEg 9+sT8523sPpz/g3kKVhpTdWBfvvePWxnhlRiBT+6zR96IwWQn0JNaIYA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id us56I+ceUfS8; Tue, 10 Jul 2012 09:55:28 +0100 (IST) Received: from [IPv6:2001:770:10:203:c94:de62:d898:da45] (unknown [IPv6:2001:770:10:203:c94:de62:d898:da45]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0156C17147E; Tue, 10 Jul 2012 09:55:23 +0100 (IST) Message-ID: <4FFBEDFB.7010808@cs.tcd.ie> Date: Tue, 10 Jul 2012 09:55:23 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E114F79777E6@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F79777E6@WSMSG3153V.srv.dir.telstra.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-snell-web-index-00: hash of user-id X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 08:55:14 -0000 So without prejudice to webfinger/swd/snell... If using a hash of the acct URI in the query, then... 1) Be good to put the hash function you're using into the URL, e.g. sha-256, in case new functions are needed later 2) Be good to use the URL segment form from draft-farrell-decade-ni (section 5), e.g. sha-256;1hlsmNC2xoyZMaLcHqzuVYrhFmmBGUj63yez2zJnrD4 That uses base64url, but that's arguably a bit better 3) I think truncated hashes are fine here and if you do the above, that's easy, e.g. sha-256-32;1hlsmA 4) Going further, if we'd like to increase privacy then really really truncated hashes might be even better, and its fine for this application if there are collisions, so long as the server can return the N colliding records. Should be easy enough to manage so as to keep the number of records returned small and the client knows the one it wants. (There may be a separate argument for multiple records in the response anyway.) I also agree with James about canonicalisation of the acct URI, but that can just be defined in the definition of that URI scheme. The hashes above are over "acct:paulej@packetizer.com" (or else I mucked up:-). Cheers, S. On 07/10/2012 07:18 AM, Manger, James H wrote: > James, > >> And an alternative approach would look like.. (the numbers are the >> sha-256 digest of the acct id) >> >> GET /.well-known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d7f8 >> HTTP/1.1 >> Host: packetizer.com >> >> HTTP/1.1 300 Multiple Choices >> Link: ; rel="http://webfinger.net/rel/avatar" > > > Using a hash instead of a user-id adds a little privacy, but it does require that both ends normalize the user-id precisely the same way. Are you confident that wouldn't be a problem in practice? > > For instance, all the following are different (and none are 4564b…7f8): > 1. SHA-256("paulej") > 2. SHA-256("paulej@packetizer.com") > 3. SHA-256("acct:paulej@packetizer.com") > 4. SHA-256("ACCT:paulej@packetizer.com") > 5. SHA-256("acct:paulej@PACKETIZER.COM") > 6. SHA-256("acct:PaulEJ@packetizer.com") > 7. SHA-256("acct:päuléj@packetizer.com") > 8. SHA-256("acct:p%C3%A4ul%C3%A9j@packetizer.com") > 9. SHA-256("acct:p%c3%a4ul%c3%a9j@packetizer.com") > 10. … > > Many of the above are 100% valid exact equivalents (eg .com vs .COM). Others are usually equivalent in practice (eg PaulEJ vs paulej). > > -- > James Manger > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From sm@resistor.net Tue Jul 10 03:59:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E30E21F8775 for ; Tue, 10 Jul 2012 03:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBU-BhJ3vWt1 for ; Tue, 10 Jul 2012 03: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 BE80C21F8742 for ; Tue, 10 Jul 2012 03:59:17 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6AAxaTi000413; Tue, 10 Jul 2012 03:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341917981; bh=l0IQqCe+TkX8oWYQW41/qIoG3+RGEnSs2avwtRUEXNc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=m5/rJwWEJp6UM6AyDCoeGzYfsi00IIK+9si+mEmAYLCRbh2u9xqJQnaUotOZaEi2z KdHpUtSNy9kaIihlrJ/lLoLRAxOW7wqjj3s9cMNrkoxuEq1gZpcZ09i/ARSTQsM1Zh eaE+RZMHAo/F+it2+njXnstDjrKhwVcf9gsDgGLc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341917981; i=@resistor.net; bh=l0IQqCe+TkX8oWYQW41/qIoG3+RGEnSs2avwtRUEXNc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mRrzbupqQKBlDSxMqi7SgN7tH6dhDc5R7ShNkUVyXuLgwKaaFccEVYmdgB8JTpFpT XP+rIMkActK5OJxtcFKB2cGxaB0zKEwE0JmOsztn+1PEtprsK/HfuaBXpSeT4ss8ad et1SErQnxeRZQkt7izj54i1biWtomUPKWks1GUs0= Message-Id: <6.2.5.6.2.20120710003717.09e42dd8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Jul 2012 02:13:58 -0700 To: Hannes Tschofenig From: SM In-Reply-To: References: <6.2.5.6.2.20120709155447.05cf1c18@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-tschofenig-hourglass-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 10:59:20 -0000 Hi Hannes, At 00:10 10-07-2012, Hannes Tschofenig wrote: >PS: In your list below you mention RTCWEB and it is quite different >than the rest of the protocols since it not only relies on HTTP but >it heavily focuses on JavaScript to provide the necessary functionality. I'll comment quickly on this. I glossed over the details as I wrote that list. It's not a good comparison of protocols. The Rich Web client [1] could be used as an argument for RTCWEB. I am not referring to the working group. ICSI Netalyzr has been used by the IETF community to test for the usual caveats [2]. One US dollar per user [3] is a significant incentive to influence what the public Internet [4] should be like. Regards, -sm 1. http://www.w3.org/2006/rwc/Activity.html 2. http://netalyzr.icsi.berkeley.edu/restore/id=example-session 3. http://www.icir.org/christian/publications/2011-foci-dns.pdf 4. It's a complex story. Ecosystem might be a better fit. From andreas@sbin.se Tue Jul 10 04:27:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E97121F877C; Tue, 10 Jul 2012 04:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9SjoQi7l89n; Tue, 10 Jul 2012 04:27:58 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id CC65721F8778; Tue, 10 Jul 2012 04:27:57 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q6ABS4VC027449; Tue, 10 Jul 2012 11:28:04 GMT Date: Tue, 10 Jul 2012 13:27:56 +0200 From: Andreas Petersson To: Alissa Cooper Message-ID: <20120710132756.4dac582d@hetzer> In-Reply-To: <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/cQ7oiqjeycRSnTQwYVporRt"; protocol="application/pgp-signature" Cc: IETF Discussion Mailing List , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 11:27:59 -0000 --Sig_/cQ7oiqjeycRSnTQwYVporRt Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 9 Jul 2012 14:27:49 -0400 Alissa Cooper wrote: > (incorporating some responses to http://www.ietf.org/mail-archive/web/app= s-discuss/current/msg06599.html as a LC comment) >=20 > It would be helpful if this document could further motivate the need for = proxies to generate static obfuscated tokens. These two lines in particular= , from 6.3 and 8.3, respectively, seem a bit weak: >=20 > "The identifiers can > be randomly generated for each request and do not need to be > statically assigned to resources." >=20 > "When using such tokens, a static token per user would increase the > possibility for external organizations to track separate users." Well, I think it gives a good hint to use dynamically assigned tokens. > Is it possible to recommend that generated tokens have limited lifetimes = (per-request or otherwise), and make the static case the exception? I guess so. > The first statement above gets at this, but it seems to me that the > middle ground between random generation per request and permanent > unique token is worth emphasizing if there will be proxies that want > to keep per-client identifiers around for some limited amount of time > that isn't forever. >=20 > It's also worth noting that the second statement above is equally true fo= r statically provisioned client IP addresses. >=20 > Also, this statement in 8.3 is not really true and probably better left o= ut: >=20 > "Proxies using this extension will preserve the information of a > direct connection, which has an end-user privacy impact, if the end- > user or deployer does not know or expect that this is the case." >=20 > There can certainly be a privacy impact whether the user or deployer has = awareness/expectation or not.=20 Can you give some proof or at least some arguments for this statement? Cheers, Andreas --Sig_/cQ7oiqjeycRSnTQwYVporRt Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJP/BG8AAoJEEaYRbQUWNleLVEQAInv6B5HHjmH3y2JPWdu9MkL /Zevq1r0fn/BvZOQzpv3fUCo+DH53ojogEfq5zVN8+dDT8yvFWn974s1GAmOi0vn b/Ek/kJ00SwUOIu5K3Jhx6IrUq9yWx/PiqS8lZ5TzHV4PfxNYTS+FIjNvgQi9TYb 82hFoPJDbU5r1TwpfayGlddoRfp2St6We+kmRj32u1rTsJZ5zV4io7nH5bIyWydE Kj7aMbLgMqxUEPOcEpltFZLtzpFikhLooufelOnPPDnuAkTE1mgKweC+acKAgqL5 9jFo7xPt5SJouyDSz932rAf2kEptPacLTKwfHBQolYwZsvM5Z/+LFBySpDf6CBK/ B52gm/qCaRHjPDKVYRbfGt2oI4/kqb0r2CBE+1RRf+/KC/nCSkQn3aN5WWKcBzFU L0/oTroRYKmdxdHQEwqWeTkuQ2amkNM57x6vTa81OXnkPEtJfyxKwmRVhUPZ6bUA PpiaDqpIzfsHcBVBREPxJ3KQ8GHTd6DCg9jqu1ygP2bXINZoq/RlijJpyLIq7a/B sj8kxK9ZF83jKjhTsaKDmjLPGxvLYvaRHqloLdsk7mjegMeCGZ8zRLQUdjwt5aCe 6C0f/px5YWdKHjNM6Kf2qq/zci/UqSWOqMloWOK+EMQZnruh2luWw+QQdnO8nC+M dtGufStm8LhsxSKK3iMl =+E08 -----END PGP SIGNATURE----- --Sig_/cQ7oiqjeycRSnTQwYVporRt-- From andreas@sbin.se Tue Jul 10 04:28:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D784C21F86E5; Tue, 10 Jul 2012 04:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auXTmqOtmwgZ; Tue, 10 Jul 2012 04:28:07 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 869A921F8533; Tue, 10 Jul 2012 04:28:05 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q6ABSUcP027586; Tue, 10 Jul 2012 11:28:31 GMT Date: Tue, 10 Jul 2012 13:28:25 +0200 From: Andreas Petersson To: SM Message-ID: <20120710132825.5141babe@hetzer> In-Reply-To: <6.2.5.6.2.20120709134136.0ad9ae18@resistor.net> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org> <6.2.5.6.2.20120709134136.0ad9ae18@resistor.net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/x./DVWCrO2BOpqozsj9whkc"; protocol="application/pgp-signature" Cc: IETF Discussion Mailing List , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 11:28:08 -0000 --Sig_/x./DVWCrO2BOpqozsj9whkc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 09 Jul 2012 13:59:43 -0700 SM wrote: > >Also, this statement in 8.3 is not really true and probably better left = out: > > > >"Proxies using this extension will preserve the information of a > > direct connection, which has an end-user privacy impact, if the end- > > user or deployer does not know or expect that this is the case." >=20 > I suggest removing that statement. The wording is not entirely=20 > clear. I read it as diluting end-user privacy impact. I interpret it the other way around.=20 It makes a deployer aware that there is also end user expectations to take into considerations. Removing it may work as well, but I think that less well reflects the discussion on the apps-list. > In Section 6.3: >=20 > 'To distinguish the obfuscated identifier from other identifiers, > it MUST have a leading underscore "_".' >=20 > I suggest removing the requirement and using "can". The implementer=20 > can decide what to put in that field. I think that will make parsing harder, and give no benefit at all. Cheers, Andreas --Sig_/x./DVWCrO2BOpqozsj9whkc Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJP/BHZAAoJEEaYRbQUWNleNmkP/R8EUtKqr2HnFZ9uLcF8CgX8 4tdKhbWVWwe1cc9iWM4IUMxHb5lIeNhguRXCQDlxDBGcxiy82y/G1TwNxsSBNNnk xnFkrRf+lL6B8DXxsjr/fH1m+3lpCzVM53lVoImQW9dA0wR0yHs3yEffAMSXlBzE mBcVgcajMtxUZmdZcm65uW8rmSS18kDABgQ2r8VzQOLz60j066oERaqoh8DerMOs Ht9/Q5I0iLKckV4yppej/bRT9eLlhxVwHU2itL0lbHcUNtsLFs+cg8YVkIfvf20U b4+7Sn6LoH6WzWN4kJtzjLX8K28TMDtO5ei5+eT3Qdi6lbqKyeP3fPjjVQpK7fAH Sz59Bkci6jT+ve443rtY3b28VGTt5MD2CO/0wAzQHOHtXukWF814QCDRVMM1dPgd q2thFK+Eq7Xfsi0TRHUKzGsNQtjS1cStJ8Bba373b4DfRfzuVU+BIInBFZi8SbVU EpqQzZ+dM9O9Gn8yVGUgkhDXgc8M/t1BKJL8NXhl2oASUeSqLzxmS4S+S9zSnhw7 zP6hEZFXaehZSbV9KULNJ/6tRQtaUdxKUqprpBFCub+Y6b1O3T/7eQ65pavYgnYt NpXJ2I/cuKW2r+x9MhCuAmK99un5/3eznHBJqoLst6pXNbcjfvfYlTcSBpRO/qE3 Qt8DJmLjXemuiI5tQjMa =4dg6 -----END PGP SIGNATURE----- --Sig_/x./DVWCrO2BOpqozsj9whkc-- From andreas@sbin.se Tue Jul 10 04:28:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB89921F8724; Tue, 10 Jul 2012 04:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxufe8XOj792; Tue, 10 Jul 2012 04:28:23 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 448C621F8778; Tue, 10 Jul 2012 04:28:20 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q6ABScLb027714; Tue, 10 Jul 2012 11:28:39 GMT Date: Tue, 10 Jul 2012 13:28:33 +0200 From: Andreas Petersson To: Stephen Farrell Message-ID: <20120710132833.0d6d6b02@hetzer> In-Reply-To: <4FFB51CB.2070608@cs.tcd.ie> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <4FFB51CB.2070608@cs.tcd.ie> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_//79PAU7YFrxOLtK521R19Cn"; protocol="application/pgp-signature" Cc: ietf@ietf.org, Apps Discuss Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 11:28:24 -0000 --Sig_//79PAU7YFrxOLtK521R19Cn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 09 Jul 2012 22:48:59 +0100 Stephen Farrell wrote: >=20 > So I have a question about this draft that wasn't > resolved on apps-discuss and is maybe more suited > for IETF LC anyway. >=20 > With geopriv, we've gone to a lot of trouble to > support end-users having some control over their > location privacy. "Location Object (LO): An object used to convey location information together with Privacy Rules. Geopriv supports both geodetic location data (latitude, longitude, altitude, etc.) and civic location data (street, city, state, etc.). Either or both types of location information may be present in a single LO (see the considerations in [5] for LOs containing multiple locations). Location Objects typically include some sort of identifier of the Target." I'm not really sure that an IP address fits into that description. If the geopriv thought that an IP address is a LO, they should have written so in the document. But more important; I think it would be really unfortunate if the IETF would encourage people to use IP addresses as location objects, it is done already, and it works bad and breaks lot of stuff. > This HTTP header will be used by proxies to forward > on the IP address of a client, and that will be used > via geo-ip services to locate the HTTP client. IP addresses are also forwarded by ISP's routers, I am not convinced about the big difference here. It may also be relevant to note that a proxy may not proxy HTTPS-requests, so in those cases it would be enough to inline an element served over HTTPS to get the client IP address. Is that also a privacy issue? > But in this case, there's no control whatsoever > for the end user, nor are they even told that > its happened. Since it is non-trivial for end users to protect their privacy, I think education of the end users are the only way to go. This education is, however, not within the scope of this document. My point is: privacy and anonymization is hard and hairy, and an uneducated end user will "never" get this right. > That seems to me to be quite a disconnect, but > I'm not sure what if anything ought be done about > it, since in this case, there's a non-standard > header that's widely deployed that does this. >=20 > So if we did try encourage taking the geopriv > approach we'd presumably just be ignored. Yes. Cheers, Andreas --Sig_//79PAU7YFrxOLtK521R19Cn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJP/BHhAAoJEEaYRbQUWNle4qwP/0HL1PSqEG0bo2T0eD2fshN0 NrUKejPJIVlBL3I1R4G5dyvYI8xHb4hqCXAEl25gqd7g8ycKCf12VR/RkLHs/FMT ugqa5+Pd9yyt0oVxuO3gmw2rWCXH3IbAEKpdQ/CtH5w2E078dKRM8eDTuSIxHyVu 6foHbpKGngCMBqY5StKsZ4xXyC8W5F1Y/qgGDHmO4YmChBtV4icDwNSsinMxnXua VJ3Y4Lfj7oTkF34KOa8OmYUXX2VlvVICWUPLDH5uwzxsuOsUrUhxwn3dDPZmcWk2 y+N2iucVi+EjvJ607gXT2/oaLPM2YIihqMtwFhK0QjwWLLbtJcul/B2q+YZGGPW4 lcoByweLQtaHbiWzEiXTY32SSLh33VWAF4RzOC8nJsftWh1PYRaRSQrIIO/t+hj1 K0Gic3YJAq74TNbULF8dztxv+GF65uE9EpA46cz6/enyquP/caMg+GNqy2jPv9BB hbCv6KJfboa2WBndlEAsmY3mkOwlDA/cKDbjzC9KgpSDuZl17j5DlMEJrASlZWKi 3QKe8XYImi95cbJaALog1W9C+DlpDwYu5fDqFE8CV8avt29QHVBhxGXrZG8S68Ua +5kjIj33fqkZYquHnmTQAGFi2QdJg0finkOO9pyV1GXto4lQGgknWzVUxOcnm1/G h+nI8ZUFivt5/Ak8RAOV =NIuv -----END PGP SIGNATURE----- --Sig_//79PAU7YFrxOLtK521R19Cn-- From andreas@sbin.se Tue Jul 10 05:08:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD13D21F8554; Tue, 10 Jul 2012 05:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEjB7eKVOhvC; Tue, 10 Jul 2012 05:08:04 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id ACA3521F8557; Tue, 10 Jul 2012 05:08:03 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q6AC8Twk010427; Tue, 10 Jul 2012 12:08:29 GMT Date: Tue, 10 Jul 2012 14:08:24 +0200 From: Andreas Petersson To: apps-discuss@ietf.org Message-ID: <20120710140824.3c8b3b3d@hetzer> In-Reply-To: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/wVINaOYuz0h+C0VyMGBWLpf"; protocol="application/pgp-signature" Cc: ietf@ietf.org Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 12:08:05 -0000 --Sig_/wVINaOYuz0h+C0VyMGBWLpf Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 09 Jul 2012 09:28:48 -0700 The IESG wrote: > 1. While RFC Required forces new registrations through the IETF RFC > process, and might discourage registrations from individuals or > organizations that are unfamiliar with or averse to that process, > Specification Required necessitates the appointment of a Designated > Expert to review the requests and associated specifications. Each of > these policies comes with baggage, and we have to make sure we're > weighing it down with the *right* baggage. >=20 > 2. If we stay with Specification Required we should include a short > paragraph with rough guidelines for the Designated Expert: what to > consider when approving registration requests. If we want the DE to > approve most requests, just checking the associated specifications for > sanity, we need to say that. If we want the DE to put some judgment > into deciding whether the requested parameters make sense and fit into > the usage model, or whatever, we should say something about that.=20 > Comments and proposed text for this are encouraged. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D After some discussion with Barry, he suggested the following text: "To keep the registration process uncomplicated and to encourage parameters that are in use to be registered, the designated expert should set a low bar for new registrations, confirming mostly that the specification is reasonably stable, readily available, and sufficient to create interoperable implementations. The parameter name ought to make sense for the requested usage, being short but sufficiently specific. The specification needs to comply with this document and the general HTTP specifications, and should address security and privacy implications of the requested parameter." I think that sounds good so that is what I suggest that we go with. Cheers, Andreas --Sig_/wVINaOYuz0h+C0VyMGBWLpf Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJP/Bs4AAoJEEaYRbQUWNlexycP/jRgICrKMv0ncwwGs1TtD8/+ J83umxpKtDlB0rLRUT8CWbeU2evgBxLFIQQnfGHoy7XgEgbu1iTDYAeenJ+lQBvE IzvEDCYgrloc5qy8gqN9seFGkPBUzP+qrnnXEkA9SXv4XRMys2wGY0bG7pgFZzVu Fx11f9RA0eazGVvVkExMF6yOl33VhmqVt+8IxhNcYWy0lpfOGbVZx3OKHOTsFoMS hviop2q9Nrk9rIVmHVes9w/m6Bch74P3HQUzBoN8i01rr3iOIP4SU3TxY/JeXltn UPOC3AOwEqJCwdWhzuIg+RQXzTjoPByQ35ZARPXiq6now171ocwn8lql76LmCFlA 83NP/nX/W17VTg6ftTmKSRG8Zt/uZt59CiqxzzQOslQUcNYCkgT+Ui6TevvYZzGA XemYdCTdFEqnhxm1vDkhfr/k9OaFQEEGZPZT/Wlhn2jWgg9GfqX+up1V7JkmWR1v YtyWTweEn4736qnDivLm2hmfqevv4ypDdSIqdngcCzrkIwrK6r1Iuk7pTCxl98yP vEY8poT52cylZsAnwgapOj2hhcyW+Gm9bnBqwFDtMZFKEzHciImX/WoKRgpY16uP fNlYU7rr0AfbEFxBWxEsq1gRfi4sGt1lu6fdsxXeyM+Rsl/LOsJKuakwx8fB+zM+ iKMw8WLPL2EQnI1ihzvw =y4qy -----END PGP SIGNATURE----- --Sig_/wVINaOYuz0h+C0VyMGBWLpf-- From michiel@unhosted.org Tue Jul 10 05:49:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9F021F86AB for ; Tue, 10 Jul 2012 05:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+Xa-PoyZfjX for ; Tue, 10 Jul 2012 05:49:37 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D528C21F869C for ; Tue, 10 Jul 2012 05:49:37 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so274291pbc.31 for ; Tue, 10 Jul 2012 05:50:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=BYIQ3edNTFJjQ8jBULsAHc39c3+oDD/Mmq5lkY44U+0=; b=JkunK6PEtesSlNmkJPlj+C8SwiHsoQVs8rMh03Gzb4NRO0GVHsKXNtE8mS8XAGvotp VucW+X8ZbSqlXnxJ4PXIenlQIaGtZKKjMbE+Ua4YCF/XfhEI7s/aHKdPqUhD+qq0QCxd m0LDbZ5a1c88ZDGMjp/qmovTesnMlHjvj1kKMmLyLtee1nQ7eEWdEVjl8px3BD5BkEQ7 ImIYZhjHUiFR8qyRG4541Qo1tuxzhqSFnrI3lotGslRH2RvsIWat2vdWM4muueqDAoKo Hp44P6Pg3s8u8hne9OjyoPvG7MaEr0gh47nFzr6IGkdofPtiRWekWxKrSELtoW2z2wPx tfCA== MIME-Version: 1.0 Received: by 10.68.200.232 with SMTP id jv8mr68377809pbc.161.1341924605417; Tue, 10 Jul 2012 05:50:05 -0700 (PDT) Received: by 10.142.10.4 with HTTP; Tue, 10 Jul 2012 05:50:05 -0700 (PDT) X-Originating-IP: [94.65.241.58] In-Reply-To: <6.2.5.6.2.20120710003717.09e42dd8@resistor.net> References: <6.2.5.6.2.20120709155447.05cf1c18@elandnews.com> <6.2.5.6.2.20120710003717.09e42dd8@resistor.net> Date: Tue, 10 Jul 2012 15:50:05 +0300 Message-ID: From: Michiel de Jong To: SM Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn6DgtRT4K8tqQuFMCTvATiPQ/yMN77s5ZlPewONGsKhkhag7XMXsjSlzJm0tfsXqKy7J73 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-tschofenig-hourglass-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 12:49:38 -0000 Hi, very interesting article; i don't have much experience as a protocol designer yet, but i do study this topic a lot. I feel it's more a case of applications moving into the browser (or the 'web runtime' as it's sometimes called when used for running client-side app) than necessarily specifically moving onto http: - Since two years with CORS it's possible to do cross-origin http calls from inside the web runtime. - Since one year we have websockets. - This year we'll have webrtc. That makes the "waist" for the web as an app platform wider than just http(s) itself. What this means for designing protocols for in-browser apps is, i think: - http(s) by itself is fine for delayed delivery of content that rarely changes (web pages). Having a server in between the sending client and the receiving client actually adds value here, both for decoupling the clients in time, and to make one-to-many delivery cheaper on the sending client (with the server basically taking the hit of repeated retrieval of a document). - http(s)+cors is useful for generic remote storage of in-app user data (we based the remoteStorage protocol on this). Unlike http(s) by itself, which only allows the client-side application 1 specific server to connect to, with cors, the application can connect to whichever server the user chooses at runtime (not just a server chosen by the application provider). - when latency is important, sending data from a sending client, up to a server, and then down to a receiving client, http(s)+cors is good for the upload, but not for the download. Http was not designed for server-initiated transfer. Long-polling has been used to work around this, but websockets are the proper way to do this. since it has only been a year since websockets are available in browsers, i think a lot of application-level protocol will start using websockets instead of http now. - when bandwidth is high (e.g. video streaming), it's advantageous to use PeerConnection, as included by the WebRTC stack, and establish (after handshake, ice, stun and turn if i understood it correctly) a route directly between the two clients, this saving server costs. That is why i think the 'hourglass waist' we are moving towards may prove to be: http(s)+cors, websockets, PeerConnection Of course, this is only talking about client-to-client communication. In server-to-server communication, http(s) is popular for the other reasons that were mentioned. I think the main problem we need to solve now in this space, is so to speak the "Where is Bob?" problem. If Alice wants to contact Bob, then where should she connect to? She needs to either consult a central directory server, or Bob needs to run his own server at his own DNS domain name which he dials into. I am not sure whether it will be enough to wait for mobile IPv6 (co-located care-of addresses) to be widely supported, or whether this is a problem that still needs extra attention. I definitely agree that the security model of the browser will also need more research, specifically how users experience the gestures of 'visiting', 'bookmarking' and 'installing' a web app. Having said all that, i think the move of applications into browser apps is definitely happening, especially in the last 18 months, and i think it's a big win. IMHO, javascript and the web runtime as an 'hourglass waist' constitute the 'cross-platform application platform' that we hoped java would be. My 2ct, Michiel From jasnell@gmail.com Tue Jul 10 05:52:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F32621F86AB for ; Tue, 10 Jul 2012 05:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.754 X-Spam-Level: X-Spam-Status: No, score=-4.754 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahD6H9rLq+Rg for ; Tue, 10 Jul 2012 05:52:48 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4B8521F869C for ; Tue, 10 Jul 2012 05:52:47 -0700 (PDT) Received: by were53 with SMTP id e53so2986402wer.31 for ; Tue, 10 Jul 2012 05:53:14 -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=kccBW1n/x7vkiyNOo4vYzSJm5CBo0GYk0h78lFwBbys=; b=SJSvfzqx79TKeeANkncM/JuM2fdjwTeCAok3k65nGhTZSjJfHfMbLSWokXQI5WAkZD wy7lWWTXbE9cxAr1kp5U3FM7NMGjpX0tFn3yNMmIj5vFUMzKrDtlpbWaHkTc+LtnioRx upIYLnfyB4Knwdp/qdaIder4DDjofGboIzlIkhpWyQfnaTX/McARyIvm4AELX7EJ9SR/ 4QisvyjNxvuDhwWG5UVZaVwtZMcyf1uEWNO8gx/kyIdmrajeUOlRmjBVEmVwxL5CCopX RnFuB9vonx7dLSRpHyRXn3PusP/vMPIs49fAMkoWbkhZlM8AP+56wiG5S1Pq5/R3gKnC 4JVg== Received: by 10.180.105.163 with SMTP id gn3mr38153457wib.2.1341924794692; Tue, 10 Jul 2012 05:53:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.67 with HTTP; Tue, 10 Jul 2012 05:52:54 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F797793C@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F797793C@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Tue, 10 Jul 2012 05:52:54 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] redirects in draft-snell-web-index/WebFinger/SWD X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 12:52:48 -0000 This could certainly work but it does make me nervous precisely because of the potential danger you point out. For this to work in practice, we would need a mechanism for the user-agent to verify the Redirect header. Should definitely be solvable tho... and definitely something that would be useful outside resource discovery. On Tue, Jul 10, 2012 at 12:28 AM, Manger, James H wrote: [snip] > > WebFinger-with-a-resource-parameter and draft-snell-web-index don't solve this issue. > > Ideally, we should solve this at the HTTP layer. An HTTP 3xx response should be able to indicate that the same response applies to all URIs with a given prefix. How about: > > HTTP/1.1 307 Moved > Location: https://id.example.com/user?u=acct:paulej@packetizer.com > Redirect: /.well-known/finger https://id.example.com/user > > The "Redirect" header includes a path-prefix and destination URI. The same redirect applies to any request whose path starts with path-prefix. The part of the request after the path-prefix is appended to the destination URI to get the new location. > It is potentially dangerous (a response from any resource on a site can redirect requests to all other resources on the site), but that might be solvable. > > -- > James Manger > > From jasnell@gmail.com Tue Jul 10 06:28:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148CA21F86BE for ; Tue, 10 Jul 2012 06:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=-2.569, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NnIS6a6cUYc for ; Tue, 10 Jul 2012 06:28:49 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8EA421F86C1 for ; Tue, 10 Jul 2012 06:28:48 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so3286167wib.13 for ; Tue, 10 Jul 2012 06:29:15 -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:content-transfer-encoding; bh=XUw/C4TYQIpB8cBCVNR8dmBJc5BLaW1oHB572smQf3g=; b=DF4nleZ+ITpI2Y4qemRGe4ewfGNoYIn7dou5rGgWF047UnAz7I2Ku82O+DcG5gc5GP zLNrcZLUPkPFa7Wr39ljQ4235oxNxH3Y++7aWb4V0fQn8WHQzSRbtdHooGRjeVkxsOZ1 KGu6Fi8GoAKs1/c5ShNUKGKQv/n69b90zc9TA5fSerQ4h79R9JoSW0b8Jb4J2KubdXu5 CBjd04iHdHChkzCaoVovUXa5Q/Cg3gExPO0RLI5n4d0N/WKvwsnYOZag3+uabsDGyFUX nOHiKmuX+NUuvUR2Agx3FIjqDQ4HMA63LVFkgX7wVryFlDR4d7JHiq8wqg51R2HrHxY5 f3QA== Received: by 10.216.50.144 with SMTP id z16mr523925web.14.1341926955589; Tue, 10 Jul 2012 06:29:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.67 with HTTP; Tue, 10 Jul 2012 06:28:55 -0700 (PDT) In-Reply-To: <4FFBEDFB.7010808@cs.tcd.ie> References: <255B9BB34FB7D647A506DC292726F6E114F79777E6@WSMSG3153V.srv.dir.telstra.com> <4FFBEDFB.7010808@cs.tcd.ie> From: James M Snell Date: Tue, 10 Jul 2012 06:28:55 -0700 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-snell-web-index-00: hash of user-id X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 13:28:50 -0000 On Tue, Jul 10, 2012 at 1:55 AM, Stephen Farrell wrote: > > So without prejudice to webfinger/swd/snell... > > If using a hash of the acct URI in the query, then... > > 1) Be good to put the hash function you're using into the URL, > e.g. sha-256, in case new functions are needed later > > 2) Be good to use the URL segment form from draft-farrell-decade-ni > (section 5), e.g. sha-256;1hlsmNC2xoyZMaLcHqzuVYrhFmmBGUj63yez2zJnrD4 > That uses base64url, but that's arguably a bit better > +1... much better, in fact, since it gives us an escape hatch in cases where not using a hash is perfectly acceptable... (I did not mean to imply that hashes should be mandatory always...) for instance... GET /.well-known/index/sha-256-32;1hlsmA HTTP/1.1 GET /.well-known/index/acct:paulej@packetizer.com HTTP/1.1 GET /.well-known/index/{some-other-opaque-identifier} HTTP/1.1 One bit of complexity that my proposal does not yet resolve is how a user-agent determines which hash methods are supported by the server. The proposal to use the hash url segment from the draft-farrell-decade-ni draft makes that significantly easier in that a server can simply return a 404 if a user-agent uses an unsupported hash function. > 3) I think truncated hashes are fine here and if you do > the above, that's easy, e.g. sha-256-32;1hlsmA > > 4) Going further, if we'd like to increase privacy then really > really truncated hashes might be even better, and its fine for > this application if there are collisions, so long as the server > can return the N colliding records. Should be easy enough to > manage so as to keep the number of records returned small and > the client knows the one it wants. (There may be a separate > argument for multiple records in the response anyway.) > +0.5 ... truncated hashes should, at least in theory, be fine here as long as collisions were kept to an absolute minimum. I would rather avoid, if possible, the added complexity of requiring the user-agent to select through multiple results. > I also agree with James about canonicalisation of the acct > URI, but that can just be defined in the definition of that > URI scheme. The hashes above are over "acct:paulej@packetizer.com" > (or else I mucked up:-). > To be certain, some degree of normalization and c18n of the identifier is certainly going to be generally required regardless of whether hashing is used. Unless I missed it, neither WebFinger/RFC6415 or the Simple Web Discovery draft deal with resource ID equivalence for the sake of matching. For example, are these equivalent requests in WebFinger? GET /.well-known/host-meta.json?resource=3Dacct:paulej@packetizer.com HTTP/= 1.1 GET /.well-known/host-meta.json?resource=3DACCT:p%c3%a4ul%c3%a9j@packetizer= .com HTTP/1.1 The spec, as currently written, does not appear to say. - James S. > Cheers, > S. > > On 07/10/2012 07:18 AM, Manger, James H wrote: >> James, >> >>> And an alternative approach would look like.. (the numbers are the >>> sha-256 digest of the acct id) >>> >>> GET /.well-known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c9661811= 5e8767aa97b1d7f8 >>> HTTP/1.1 >>> Host: packetizer.com >>> >>> HTTP/1.1 300 Multiple Choices >>> Link: ; rel=3D"http://webfinger.net/r= el/avatar" >> >> >> Using a hash instead of a user-id adds a little privacy, but it does req= uire that both ends normalize the user-id precisely the same way. Are you c= onfident that wouldn't be a problem in practice? >> >> For instance, all the following are different (and none are 4564b=E2=80= =A67f8): >> 1. SHA-256("paulej") >> 2. SHA-256("paulej@packetizer.com") >> 3. SHA-256("acct:paulej@packetizer.com") >> 4. SHA-256("ACCT:paulej@packetizer.com") >> 5. SHA-256("acct:paulej@PACKETIZER.COM") >> 6. SHA-256("acct:PaulEJ@packetizer.com") >> 7. SHA-256("acct:p=C3=A4ul=C3=A9j@packetizer.com") >> 8. SHA-256("acct:p%C3%A4ul%C3%A9j@packetizer.com") >> 9. SHA-256("acct:p%c3%a4ul%c3%a9j@packetizer.com") >> 10. =E2=80=A6 >> >> Many of the above are 100% valid exact equivalents (eg .com vs .COM). Ot= hers are usually equivalent in practice (eg PaulEJ vs paulej). >> >> -- >> James Manger >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > From stephen.farrell@cs.tcd.ie Tue Jul 10 06:41:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51CF21F86EC for ; Tue, 10 Jul 2012 06:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiqlXayGN3Nn for ; Tue, 10 Jul 2012 06:41:17 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 0163821F86C7 for ; Tue, 10 Jul 2012 06:41:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6AC4C17150D; Tue, 10 Jul 2012 14:41:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341927703; bh=N9NOeqMHWAAgmG 44O6Oga380aiAYtsMwFmsIBvY7Gpo=; b=uRZUHqPJRg0iJaVs0ATIt+z3BECVlT jj//tOBlJeHB4PFP0BUq+yM1SprIVRnKP3H6ZjiCNv8woYUGpqlie5WZ6aMNC/ft hIKO/nhhpPt6a/in/jwiwyJoPxTukbOKw6WmlKzNQAX29SKixUftTdLn3QRgN6nG z+SdeFQU0ZQtYuO1I+4hQ0B0gzGL+iN9m0JD9xTMirt69pWrSikrkJLpUMflJM7F NmrQz/cUNQyO0e7Q8K6fnTbkOOn+yVE60n9TGzxVsIL+adTEO6JYwmWpbd1RdwTc A4MQrux0nX3dtXeaEEGAHQVs7V3lLiFmfRighhsPivxNBMk+cVII1/Og== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id B4He-V0hndr4; Tue, 10 Jul 2012 14:41:43 +0100 (IST) Received: from [IPv6:2001:770:10:203:c94:de62:d898:da45] (unknown [IPv6:2001:770:10:203:c94:de62:d898:da45]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id BE3631714EA; Tue, 10 Jul 2012 14:41:37 +0100 (IST) Message-ID: <4FFC3111.8080007@cs.tcd.ie> Date: Tue, 10 Jul 2012 14:41:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: James M Snell References: <255B9BB34FB7D647A506DC292726F6E114F79777E6@WSMSG3153V.srv.dir.telstra.com> <4FFBEDFB.7010808@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-snell-web-index-00: hash of user-id X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 13:41:18 -0000 On 07/10/2012 02:28 PM, James M Snell wrote: > +0.5 ... truncated hashes should, at least in theory, be fine here as > long as collisions were kept to an absolute minimum. I would rather > avoid, if possible, the added complexity of requiring the user-agent > to select through multiple results. Yeah, probably. I guess to get any privacy enhancement you'd need to be getting loads of records back. OTOH, that's sort of what safe web browsing does, so there's a precedent that's not that different. But that could be looked at later I guess. S. From jasnell@gmail.com Tue Jul 10 06:42:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6612E21F86C7 for ; Tue, 10 Jul 2012 06:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.665 X-Spam-Level: X-Spam-Status: No, score=-4.665 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZ1NE47G0pir for ; Tue, 10 Jul 2012 06:42:15 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FACB21F86EE for ; Tue, 10 Jul 2012 06:42:15 -0700 (PDT) Received: by were53 with SMTP id e53so3026508wer.31 for ; Tue, 10 Jul 2012 06:42: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=uR2mQiq1ZkOoPm1DUN9ltamAh4lSQsAxDWB+PER/Oak=; b=mBlat1ChKUDrAgGYudfg5FQ1xM6VOCXTonmTUf7kIq2cZyx90X4QClcPirI5prEbdj 7oiE9ugBy8gRyzd+jdDIds7AElQ1+SfExo3UFlt/mPLdlnqzJ7TU2Du8aAIVhUnUAStF wZDV8WQ/EKkYQZcOpB/TizhnaYj7PjKP+YGHBA6u0kfuYa4HHMqluxUzWPBxe+8RwfNi vnJIUOCXLBispD+Bu+0+9CfwUi209Mie5htV3EFMj9ZrRfsdVRUp86U7YiTx14mopxp8 PuIyAJkvw3ip5RQtcl3yzkMrcii5lcL/DmBFK6iQ9Fco942p36w8tUAVoD4aWI8xxqVr pOVg== Received: by 10.180.105.163 with SMTP id gn3mr38498837wib.2.1341927762509; Tue, 10 Jul 2012 06:42:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.67 with HTTP; Tue, 10 Jul 2012 06:42:22 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E114F797793C@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Tue, 10 Jul 2012 06:42:22 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] redirects in draft-snell-web-index/WebFinger/SWD X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 13:42:16 -0000 Then again... thinking about it further... why wouldn't a reverse proxy work here? It would certainly be safer... (of course... I may need to put the laptop down and go get more coffee too) On Tue, Jul 10, 2012 at 5:52 AM, James M Snell wrote: > This could certainly work but it does make me nervous precisely > because of the potential danger you point out. For this to work in > practice, we would need a mechanism for the user-agent to verify the > Redirect header. Should definitely be solvable tho... and definitely > something that would be useful outside resource discovery. > > On Tue, Jul 10, 2012 at 12:28 AM, Manger, James H > wrote: > [snip] >> >> WebFinger-with-a-resource-parameter and draft-snell-web-index don't solve this issue. >> >> Ideally, we should solve this at the HTTP layer. An HTTP 3xx response should be able to indicate that the same response applies to all URIs with a given prefix. How about: >> >> HTTP/1.1 307 Moved >> Location: https://id.example.com/user?u=acct:paulej@packetizer.com >> Redirect: /.well-known/finger https://id.example.com/user >> >> The "Redirect" header includes a path-prefix and destination URI. The same redirect applies to any request whose path starts with path-prefix. The part of the request after the path-prefix is appended to the destination URI to get the new location. >> It is potentially dangerous (a response from any resource on a site can redirect requests to all other resources on the site), but that might be solvable. >> >> -- >> James Manger >> >> From acooper@cdt.org Tue Jul 10 07:54:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001C911E8088; Tue, 10 Jul 2012 07:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyAz-EizSDH1; Tue, 10 Jul 2012 07:54:30 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 31B3111E807F; Tue, 10 Jul 2012 07:54:28 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 10 Jul 2012 10:54:54 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <20120710132756.4dac582d@hetzer> Date: Tue, 10 Jul 2012 10:54:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org> <20120710132756.4dac582d@hetzer> To: Andreas Petersson X-Mailer: Apple Mail (2.1084) Cc: IETF Discussion Mailing List , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 14:54:32 -0000 Hi Andreas, On Jul 10, 2012, at 7:27 AM, Andreas Petersson wrote: >> The first statement above gets at this, but it seems to me that the >> middle ground between random generation per request and permanent >> unique token is worth emphasizing if there will be proxies that want >> to keep per-client identifiers around for some limited amount of time >> that isn't forever. >>=20 >> It's also worth noting that the second statement above is equally = true for statically provisioned client IP addresses. >>=20 >> Also, this statement in 8.3 is not really true and probably better = left out: >>=20 >> "Proxies using this extension will preserve the information of a >> direct connection, which has an end-user privacy impact, if the = end- >> user or deployer does not know or expect that this is the case." >>=20 >> There can certainly be a privacy impact whether the user or deployer = has awareness/expectation or not.=20 >=20 > Can you give some proof or at least some arguments for this statement? >=20 If the deployer has awareness/expectation but users do not, then users' = expectations that their client addresses will not be shared will be = violated. But even if users have awareness/expectation that their client addresses = will be shared, the implications of that sharing may not be obvious, and = there is nothing preventing remote servers that receive the information = from abusing it. Examples: a user who doesn't know that his address is = static and can be used by a remote server to track and correlate all of = his activity; a user who doesn't know that his ISP maintains records of = customer identity tied to client addresses that may become subject to = law enforcement request; a service that combines static addresses or = tokens received via the header with other collected identifiers and = shares them with other servers to enable more pervasive tracking. The first half of the statement is basically a refinement of the = previous sentence in the section ("The Forwarded HTTP header field, by = design, exposes information that some users consider privacy = sensitive"), so I don't see what is lost by eliminating it. Alissa =20 >=20 > Cheers, > Andreas From graham.klyne@zoo.ox.ac.uk Tue Jul 10 01:41:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555AF21F85E4 for ; Tue, 10 Jul 2012 01:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL+RfyCiZYJo for ; Tue, 10 Jul 2012 01:41:36 -0700 (PDT) Received: from relay1.mail.ox.ac.uk (relay1.mail.ox.ac.uk [129.67.1.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6398121F85E6 for ; Tue, 10 Jul 2012 01:41:35 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay1.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1SoW1C-0007Rp-3a for apps-discuss@ietf.org; Tue, 10 Jul 2012 09:42:02 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SoW1B-0001Kp-7u for apps-discuss@ietf.org; Tue, 10 Jul 2012 09:42:02 +0100 Message-ID: <4FFBE454.1020601@zoo.ox.ac.uk> Date: Tue, 10 Jul 2012 09:14:12 +0100 From: Graham Klyne Organization: Zoology, Oxford University User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20120710000754.6BF59B1E006@rfc-editor.org> In-Reply-To: <20120710000754.6BF59B1E006@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 X-Mailman-Approved-At: Tue, 10 Jul 2012 08:11:32 -0700 Subject: Re: [apps-discuss] RFC 6657 on Update to MIME regarding "charset" Parameter Handling in Textual Media Types X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 08:41:37 -0000 On 10/07/2012 01:07, rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6657 > > Title: Update to MIME regarding "charset" > Parameter Handling in Textual Media Types I didn't see this one coming. I'm a bit confused by the specification. If we define a media type that is *always* UTF-8, does this count as transporting its own charset information? Should we say that the media type SHOULD NOT be included, or that it SHOULD be included with value UTF-8? Section 3 implies the latter, but it also talks about media types defining their own default encoding. (This is not an academic question - a W3C group I'm involved with is about to submit a registration for a UTF-8 only text/... media type) #g -- > Author: A. Melnikov, J. Reschke > Status: Standards Track > Stream: IETF > Date: July 2012 > Mailbox: Alexey.Melnikov@isode.com, > julian.reschke@greenbytes.de > Pages: 6 > Characters: 10111 > Updates: RFC2046 > > I-D Tag: draft-ietf-appsawg-mime-default-charset-04.txt > > URL: http://www.rfc-editor.org/rfc/rfc6657.txt > > This document changes RFC 2046 rules regarding default "charset" > parameter values for "text/*" media types to better align with common > usage by existing clients and servers. [STANDARDS-TRACK] > > This document is a product of the Applications Area Working Group Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From mateusz.karcz@interia.eu Tue Jul 10 07:04:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4038821F85FF for ; Tue, 10 Jul 2012 07:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.067 X-Spam-Level: * X-Spam-Status: No, score=1.067 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, TVD_RATWARE_MSGID_02=0.581] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPOyGibZ6F31 for ; Tue, 10 Jul 2012 07:04:47 -0700 (PDT) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.206]) by ietfa.amsl.com (Postfix) with ESMTP id 6B18421F8724 for ; Tue, 10 Jul 2012 07:04:47 -0700 (PDT) Date: Tue, 10 Jul 2012 16:05:12 +0200 From: Mateusz Karcz To: apps-discuss@ietf.org X-Mailer: interia.pl/pf09 X-Originating-IP: 31.61.129.253 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1341929113; bh=FxPM7l56lTmuA6oAOPPRxOYksUghf9+p8Ekn+ZCtWow=; h=Date:From:Subject:To:X-Mailer:X-Originating-IP:Message-Id: MIME-Version:Content-Type:Content-Transfer-Encoding; b=LLV4GKrkP5oejsk2zshQ48+Hr16GF92eg80rFCUVEcCI1uZj6225TVz64SrG9Cypp 0VdUmpFCaYLbKoRaDl/p2ZDM56dlApBn1mahyXu3ZPKA5F/bZsGP4XvIdnBar8OTuD hxNl47vxa2l+7MsE/Jf+cdIVC5Cb/+fG8MJZOP7M= X-Mailman-Approved-At: Tue, 10 Jul 2012 08:11:51 -0700 Subject: [apps-discuss] Unified User-Agent String X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 14:04:48 -0000 Good afternoon! I'm Mateusz Karcz. I'm author of "Unified User-Agent String= (UUAS)" I-D (draft-karcz-uuas-00). I had sent it to RFC Editor as Independ= ent Submission, but after I got suggestion from ISB to publicate it by apps= awg, because it extends application layer protocol (HTTP) header. Can I dev= elop that draft with You? Sincerelly Mateusz Karcz From andreas@sbin.se Tue Jul 10 09:07:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3980F21F8600; Tue, 10 Jul 2012 09:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHPQpXOCrWe8; Tue, 10 Jul 2012 09:07:27 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 096A521F85FD; Tue, 10 Jul 2012 09:07:26 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q6AG7YXi021441; Tue, 10 Jul 2012 16:07:34 GMT Date: Tue, 10 Jul 2012 18:07:29 +0200 From: Andreas Petersson To: Alissa Cooper Message-ID: <20120710180729.42712860@hetzer> In-Reply-To: References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org> <20120710132756.4dac582d@hetzer> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Ud9QdQTJVCQg_8F3d+zl=li"; protocol="application/pgp-signature" Cc: IETF Discussion Mailing List , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 16:07:33 -0000 --Sig_/Ud9QdQTJVCQg_8F3d+zl=li Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 10 Jul 2012 10:54:53 -0400 Alissa Cooper wrote: > Hi Andreas, >=20 > On Jul 10, 2012, at 7:27 AM, Andreas Petersson wrote: > >> The first statement above gets at this, but it seems to me that the > >> middle ground between random generation per request and permanent > >> unique token is worth emphasizing if there will be proxies that want > >> to keep per-client identifiers around for some limited amount of time > >> that isn't forever. > >>=20 > >> It's also worth noting that the second statement above is equally true= for statically provisioned client IP addresses. > >>=20 > >> Also, this statement in 8.3 is not really true and probably better lef= t out: > >>=20 > >> "Proxies using this extension will preserve the information of a > >> direct connection, which has an end-user privacy impact, if the end- > >> user or deployer does not know or expect that this is the case." > >>=20 > >> There can certainly be a privacy impact whether the user or deployer h= as awareness/expectation or not.=20 > >=20 > > Can you give some proof or at least some arguments for this statement? > >=20 >=20 > If the deployer has awareness/expectation but users do not, then users' e= xpectations that their client addresses will not be shared will be violated. I interpret the statement "which has an end-user privacy impact" to be true if any of "end user" or "deployer" does not know about it. So that should cover the case when the deployer knows, but not the end user. > But even if users have awareness/expectation that their client addresses = will be shared, the implications of that sharing may not be obvious, and th= ere is nothing preventing remote servers that receive the information from = abusing it. Examples: a user who doesn't know that his address is static an= d can be used by a remote server to track and correlate all of his activity= ; a user who doesn't know that his ISP maintains records of customer identi= ty tied to client addresses that may become subject to law enforcement requ= est; a service that combines static addresses or tokens received via the he= ader with other collected identifiers and shares them with other servers to= enable more pervasive tracking. Thanks for explaining. Yes, I can agree on this. I do not think that this header changes real life affect on end users privacy very much, though. The big issue here is that there is quite a lot of things that the end user are aware of. > The first half of the statement is basically a refinement of the previous= sentence in the section ("The Forwarded HTTP header field, by design, expo= ses information that some users consider privacy sensitive"), so I don't se= e what is lost by eliminating it. See my answer to SM. I think it better explains that the expectations of the end user are important to consider, even if these expectations are wrong. I don't think that text will have much impact on how the header field is used in practice though, or any technical impact, so removing it is fine with me. It would be interesting to hear what Stephen Farrell thinks about it, since he wrote that text. Cheers, Andreas --Sig_/Ud9QdQTJVCQg_8F3d+zl=li Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJP/FNBAAoJEEaYRbQUWNleQBwP/ROOAhhQcvRKlCfYGwcKFHRk mkRAozQPgC9tBLOoX/Q4Cfhw+Qj+K2bnGZPvZNnKT9KuBXZq+l14CrJkQRTkpbZu TDxvnAqklc9AaHd1N4FfOTFeZHRnkJQrS93YTmngXgSVYbMeo49tRo+ly6ksBiY7 sYbdjqobzSNI3laO0JgRSzjJWc37ZZ66rqGRFC0stfJbS58Zse5fMmLUorNQRjbV Gy6TsLAdlYDQpstsMxHAiqcfEefMojwggtfjvIhz7OdryBr2rTN2g5+mhdArLGC8 yzRtWYCVqiMYk/mDpJURcxIOWuE4ivxQXJaEt61yK/GiSo0hTzbEDiXxgg3RPMGY VPjlGnCNZJUTJFD4eYCWVx0CUbHMejomHaSANu93or3lTQ14CsNjl2sntbRGxE0F E2XIcnpFbE4x31FKze4nY1PKdoajzCobMD3qOG2dmBdxtxySb3hAPMNORoJIi9HP 4YtuOFPRyiYMB1xiIQQcPUSjphmi6J+y6jFoZ3PCTPhvqLVBl8oawCTkfdskawWK wZZGYgUFSPpXh3QXi9lEgEioSKWGXeDROupj6eiVTDPm4FwaiqqEl12SQBE/mUzO wdTJk12nCqx3yhCHUVKteY3Y+bwETZ+akfrQ505mG2L3qCc9LllP6eOfrq8u1ex9 1SDDZV89Kht4eNEJUs8L =bmit -----END PGP SIGNATURE----- --Sig_/Ud9QdQTJVCQg_8F3d+zl=li-- From alexey.melnikov@isode.com Tue Jul 10 09:19:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF14121F8682 for ; Tue, 10 Jul 2012 09:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.627 X-Spam-Level: X-Spam-Status: No, score=-102.627 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YU9XjP8IylT for ; Tue, 10 Jul 2012 09:19:06 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id CE52521F8644 for ; Tue, 10 Jul 2012 09:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1341937188; d=isode.com; s=selector; i=@isode.com; bh=HcJmNQOBG+8mu/VIZM+3HQkpJduAeI7qjHL+H2TOqb0=; 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=diTH64VoYXJEoLpAHGlN6Ltfcc3/Ey2NPd2QfiEUKrFsndt2g4Q/8b7p6N/euLzNwGjl5q qxaS0J/vJynfmqFZRLp8FzlK0o48hBYeE+JEuDd00kmj+XCeuvP5/7e9QW2w6NPiPyPePM WcD24yo1qbkKbW8S+CE9Ovrc2kqQw3g=; Received: from [172.16.11.4] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 10 Jul 2012 17:19:48 +0100 Message-ID: <4FFC561F.7070205@isode.com> Date: Tue, 10 Jul 2012 17:19:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 To: Graham Klyne References: <20120710000754.6BF59B1E006@rfc-editor.org> <4FFBE454.1020601@zoo.ox.ac.uk> In-Reply-To: <4FFBE454.1020601@zoo.ox.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC 6657 on Update to MIME regarding "charset" Parameter Handling in Textual Media Types X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 16:19:07 -0000 Hi Graham, On 10/07/2012 09:14, Graham Klyne wrote: > On 10/07/2012 01:07, rfc-editor@rfc-editor.org wrote: >> >> A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 6657 >> >> Title: Update to MIME regarding "charset" >> Parameter Handling in Textual Media Types > > I didn't see this one coming. I'm a bit confused by the specification. > > If we define a media type that is *always* UTF-8, does this count as > transporting its own charset information? Should we say that the > media type I think you meant the "charset" parameter. > SHOULD NOT be included, or that it SHOULD be included with value > UTF-8? Section 3 implies the latter, but it also talks about media > types defining their own default encoding. For backward compatibility with RFC 2045 it would be better to require explicit 'charset="utf-8"', but not allowing the charset parameter and saying that the payload for your text/foo media type is always in UTF-8 is fine. > (This is not an academic question - a W3C group I'm involved with is > about to submit a registration for a UTF-8 only text/... media type) > > #g > -- > >> Author: A. Melnikov, J. Reschke >> Status: Standards Track >> Stream: IETF >> Date: July 2012 >> Mailbox: Alexey.Melnikov@isode.com, >> julian.reschke@greenbytes.de >> Pages: 6 >> Characters: 10111 >> Updates: RFC2046 >> >> I-D Tag: draft-ietf-appsawg-mime-default-charset-04.txt >> >> URL: http://www.rfc-editor.org/rfc/rfc6657.txt >> >> This document changes RFC 2046 rules regarding default "charset" >> parameter values for "text/*" media types to better align with common >> usage by existing clients and servers. [STANDARDS-TRACK] >> >> This document is a product of the Applications Area Working Group >> Working Group of the IETF. >> >> This is now a Proposed Standard Protocol. >> >> STANDARDS TRACK: This document specifies an Internet standards track >> protocol for the Internet community,and requests discussion and >> suggestions >> for improvements. Please refer to the current edition of the Internet >> Official Protocol Standards (STD 1) for the standardization state and >> status of this protocol. Distribution of this memo is unlimited. >> >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> http://www.ietf.org/mailman/listinfo/ietf-announce >> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >> >> For searching the RFC series, see >> http://www.rfc-editor.org/rfcsearch.html. >> For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >> >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >> specifically noted otherwise on the RFC itself, all RFCs are for >> unlimited distribution. >> >> >> The RFC Editor Team >> Association Management Solutions, LLC From acooper@cdt.org Tue Jul 10 09:31:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8830B11E8199; Tue, 10 Jul 2012 09:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.381 X-Spam-Level: X-Spam-Status: No, score=-102.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1wzI4lCKouW; Tue, 10 Jul 2012 09:31:43 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id C2A2F11E8187; Tue, 10 Jul 2012 09:31:42 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 10 Jul 2012 12:32:09 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <20120710180729.42712860@hetzer> Date: Tue, 10 Jul 2012 12:32:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <62148A5F-B5F0-4915-8064-F33A0ADCB311@cdt.org> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org> <20120710132756.4dac582d@hetzer> <20120710180729.42712860@hetzer> To: Andreas Petersson X-Mailer: Apple Mail (2.1084) Cc: IETF Discussion Mailing List , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 16:31:43 -0000 On Jul 10, 2012, at 12:07 PM, Andreas Petersson wrote: >> The first half of the statement is basically a refinement of the = previous sentence in the section ("The Forwarded HTTP header field, by = design, exposes information that some users consider privacy = sensitive"), so I don't see what is lost by eliminating it. >=20 > See my answer to SM. I think it better explains that the expectations > of the end user are important to consider, even if these expectations > are wrong. Right, I'm not saying that user expectations are unimportant. I think = characterizing their role accurately should be the goal. If there is a = desire to leave this in, I would suggest something more along the lines = of: Proxies using this extension will preserve the information of a direct = connection. In some cases, the user's and/or deployer's knowledge or = expectation that this will occur can help to mitigate the associated = privacy impact. >=20 > I don't think that text will have much impact on how the header field > is used in practice though, or any technical impact, so removing it is > fine with me. Even if that's the case having accurate documentation of the privacy = implications can't hurt. Alissa >=20 > It would be interesting to hear what Stephen Farrell thinks about it, > since he wrote that text. >=20 >=20 > Cheers, > Andreas From sm@resistor.net Tue Jul 10 09:52:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BDD21F8634; Tue, 10 Jul 2012 09:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0utcqN2F868; Tue, 10 Jul 2012 09:52:32 -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 F0A8821F8645; Tue, 10 Jul 2012 09:52:31 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6AGqpjG004164; Tue, 10 Jul 2012 09:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341939178; bh=mZPx3PeuH+bsY8/6i8Q9ReQPixfSnCVngOTlCFC4g48=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HUPVA5ygycSVm/Vkphj4tJIWoocS0uvgK/mo/aTzpxuUofkxRFS5Pvew0SiIj596f fYn/efZLpA6vO4FKNlGB36ZWt7dqF7xrI4Oet38Oj9ktkfVcI4OVN5NHBquGdH2PAt wbJYUvA/aGBVzpRbriqIEuD4I/Srg+HlhwEgisEk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341939178; i=@resistor.net; bh=mZPx3PeuH+bsY8/6i8Q9ReQPixfSnCVngOTlCFC4g48=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UEhpWh2ADvZXDdl/p1BYr/wLXq/6Ex+e+r1lDzoZlWAwFMLZYtd0re3Wd6D4Dcs6f DnEn4wKOJZdU+ZmcGAGcwUmALaFMJeeQRhdsLz+7I/Py9MkY3BRfWuNVCMluKDDaLT sQWlUYSBpTlDOFWnCNCWxX07KtEP60GZrzkKQxLM= Message-Id: <6.2.5.6.2.20120710081323.08c9bcf8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Jul 2012 08:43:43 -0700 To: Andreas Petersson From: SM In-Reply-To: <20120710132825.5141babe@hetzer> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org> <6.2.5.6.2.20120709134136.0ad9ae18@resistor.net> <20120710132825.5141babe@hetzer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: IETF Discussion Mailing List , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 16:52:37 -0000 Hi Andreas, At 04:28 10-07-2012, Andreas Petersson wrote: >I interpret it the other way around. >It makes a deployer aware that there is also end user expectations >to take into considerations. >Removing it may work as well, but I think that less well reflects the >discussion on the apps-list. There is a thread at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06592.html of the working group discussions. There were views from three persons. I am in agreement with Alissa on that text. I'll "+1" her message at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06664.html >I think that will make parsing harder, and give no benefit at all. It allows for more random bits of information. Regards, -sm From ned.freed@mrochek.com Tue Jul 10 10:42:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3F121F87D0 for ; Tue, 10 Jul 2012 10:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJsU5-4uKQo5 for ; Tue, 10 Jul 2012 10:42:42 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id AAD3521F8763 for ; Tue, 10 Jul 2012 10:42:41 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHOK4VZEXS0053N5@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 10 Jul 2012 10:38:05 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHLKS3CK340006TF@mauve.mrochek.com>; Tue, 10 Jul 2012 10:38:01 -0700 (PDT) Message-id: <01OHOK4TIDIW0006TF@mauve.mrochek.com> Date: Tue, 10 Jul 2012 10:18:38 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 10 Jul 2012 09:14:12 +0100" <4FFBE454.1020601@zoo.ox.ac.uk> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20120710000754.6BF59B1E006@rfc-editor.org> <4FFBE454.1020601@zoo.ox.ac.uk> To: Graham Klyne Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC 6657 on Update to MIME regarding "charset" Parameter Handling in Textual Media Types X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 17:42:43 -0000 > On 10/07/2012 01:07, rfc-editor@rfc-editor.org wrote: > > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 6657 > > > > Title: Update to MIME regarding "charset" > > Parameter Handling in Textual Media Types > I didn't see this one coming. It was discussed at considerable length both here and on the IETF list. > I'm a bit confused by the specification. You need to keep in mind that this only applies to subtypes of text. > If we define a media type that is *always* UTF-8, does this count as > transporting its own charset information? That's one approach you can use. The alternatives are to allow or require a charset parameter, always with the value utf-8. The best approach depends on the specifics of the type. > Should we say that the media type > SHOULD NOT be included, or that it SHOULD be included with value UTF-8? Included where? Within the content? If so, that's up to the registration to say. There are plenty of utf-8 based formats that don't provide for inclusion of media type information - and that includes some that use XML syntax. > Section > 3 implies the latter, but it also talks about media types defining their own > default encoding. Relying on defaults is discouraged for historical reasons - they don't work very well. As such, if it's possible for the type to explicitly say what the charset is, that's probably the best way to do it. If the type isn't capable of that for whatever reason, your options are to simply say it's always utf-8 or alternately allow or require a charset parameter with utf-8 as the only value. The best approach depends on the situation, which is why the document is full of SHOULDs, not MUSTs. > (This is not an academic question - a W3C group I'm involved with is about to > submit a registration for a UTF-8 only text/... media type) Does this type actually meet the criteria for text specified in RFC 2046 section 4.1? I rather suspect it doesn't. If not, it really has no business being a text subtype, and all of this is moot. Ned From vkg@bell-labs.com Tue Jul 10 13:28:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EA321F84B6; Tue, 10 Jul 2012 13:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.932 X-Spam-Level: X-Spam-Status: No, score=-107.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDb3ByVshYGV; Tue, 10 Jul 2012 13:28:14 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D1FE011E80A6; Tue, 10 Jul 2012 13:28:11 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q6AKSaQ3023022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jul 2012 15:28:36 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6AKSae4005549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Jul 2012 15:28:36 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q6AKSZq0009388; Tue, 10 Jul 2012 15:28:35 -0500 (CDT) Message-ID: <4FFC91DC.9060304@bell-labs.com> Date: Tue, 10 Jul 2012 15:34:36 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: apps-discuss@ietf.org, draft-sandlund-rfc4996bis@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: IESG IESG Subject: [apps-discuss] APPSDIR review of draft-sandlund-rfc4996bis-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 20:28:14 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-sandlund-rfc4996bis-02 Title: RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) Reviewer: Vijay K. Gurbani Review Date: Jul-10-2012 IETF Last Call Date: Jun-29-2012 IESG Telechat Date: Jul-19-2012 Summary: This draft is ready for publication as an Proposed Standard. Major issues: 0 Minor issues: 0 Major issues: 0 Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From anwaruddin.hamdan@gmail.com Tue Jul 10 14:01:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C97C21F85E0 for ; Tue, 10 Jul 2012 14:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO7Q4ncrsMGL for ; Tue, 10 Jul 2012 14:01:35 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 92CC921F85DB for ; Tue, 10 Jul 2012 14:01:32 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so3983036wgb.1 for ; Tue, 10 Jul 2012 14:02:00 -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 :content-type; bh=FIJHYM2v7ZPwkARjAU5ho1eue5EshOJYKLs6QnOU06E=; b=WQDUUhiyU6fwa8HSDFwMwsTWtutAaJgdLDUfgsqbXn7lENTZK4dWKFgtBaNWGrXwlU cGzn00JAwZ2jXkU6W/GABSYwjEJ3SL0L5vvZe8ApxvhdFN8/+PKjOyr/8DSyKNq/8UFb IH3MZiUcy2ZT17ukk6/s/xliH+IhbDS5ZojfR4tmwrkxdmzQRRQjU3bSSrNR0BFcL2N5 UEAOeI7wYyPIOc1N18y6FLYDKE+kO7ZCHdSOq/Zo5+dgsLkbX0NvAXeNJtuOuSdjXq1j tRRuqFOsFevZvyBHTUIrHnJEeJb1wGkkHIqUZzpliz4jkkzFsAmN8+eplbRb58StRmfO NLsA== MIME-Version: 1.0 Received: by 10.216.132.25 with SMTP id n25mr1550957wei.25.1341954120302; Tue, 10 Jul 2012 14:02:00 -0700 (PDT) Received: by 10.180.79.42 with HTTP; Tue, 10 Jul 2012 14:02:00 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Jul 2012 05:02:00 +0800 Message-ID: From: Anwaruddin Hamdan To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=0016e6dd8d69a5421b04c4800ab7 Subject: Re: [apps-discuss] apps-discuss Digest, Vol 54, Issue 57 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 21:01:36 -0000 --0016e6dd8d69a5421b04c4800ab7 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 11, 2012 at 3:00 AM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/apps-discuss > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send apps-discuss mailing list submissions to > apps-discuss@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/apps-discuss > or, via email, send a message with subject or body 'help' to > apps-discuss-request@ietf.org > > You can reach the person managing the list at > apps-discuss-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of apps-discuss digest..." > > > Today's Topics: > > 1. Re: RFC 6657 on Update to MIME regarding "charset" Parameter > Handling in Textual Media Types (Ned Freed) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 10 Jul 2012 10:18:38 -0700 (PDT) > From: Ned Freed > To: Graham Klyne > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] RFC 6657 on Update to MIME regarding > "charset" Parameter Handling in Textual Media Types > Message-ID: <01OHOK4TIDIW0006TF@mauve.mrochek.com> > Content-Type: TEXT/PLAIN; Format=flowed > > > On 10/07/2012 01:07, rfc-editor@rfc-editor.org wrote: > > > > > > A new Request for Comments is now available in online RFC libraries. > > > > > > > > > RFC 6657 > > > > > > Title: Update to MIME regarding "charset" > > > Parameter Handling in Textual Media Types > > > I didn't see this one coming. > > It was discussed at considerable length both here and on the IETF list. > > > I'm a bit confused by the specification. > > You need to keep in mind that this only applies to subtypes of text. > > > If we define a media type that is *always* UTF-8, does this count as > > transporting its own charset information? > > That's one approach you can use. The alternatives are to allow or require > a charset parameter, always with the value utf-8. The best approach depends > on the specifics of the type. > > > Should we say that the media type > > SHOULD NOT be included, or that it SHOULD be included with value UTF-8? > > Included where? Within the content? If so, that's up to the registration to > say. There are plenty of utf-8 based formats that don't provide for > inclusion > of media type information - and that includes some that use XML syntax. > > > Section > > 3 implies the latter, but it also talks about media types defining their > own > > default encoding. > > Relying on defaults is discouraged for historical reasons - they don't work > very well. As such, if it's possible for the type to explicitly say what > the > charset is, that's probably the best way to do it. If the type isn't > capable of > that for whatever reason, your options are to simply say it's always utf-8 > or > alternately allow or require a charset parameter with utf-8 as the only > value. > The best approach depends on the situation, which is why the document is > full > of SHOULDs, not MUSTs. > > > (This is not an academic question - a W3C group I'm involved with is > about to > > submit a registration for a UTF-8 only text/... media type) > > Does this type actually meet the criteria for text specified in RFC 2046 > section 4.1? I rather suspect it doesn't. If not, it really has no business > being a text subtype, and all of this is moot. > testing > > Ned > > > ------------------------------ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > End of apps-discuss Digest, Vol 54, Issue 57 > ******************************************** > --0016e6dd8d69a5421b04c4800ab7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 11, 2012 at 3:00 AM, <apps-discuss-request@ietf.org> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

https://www.ietf.org/mailman/listinfo/apps-discuss

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =A0You can set this option
globally for all the list digests you receive at this point.



Send apps-discuss mailing list submissions to
=A0 =A0 =A0 =A0 apps-discuss@ietf.= org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/apps-discuss
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0 apps-discu= ss-request@ietf.org

You can reach the person managing the list at
=A0 =A0 =A0 =A0 apps-discuss= -owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of apps-discuss digest..."


Today's Topics:

=A0 =A01. Re: =A0RFC 6657 on Update to MIME regarding "charset" P= arameter
=A0 =A0 =A0 Handling in Textual Media Types (Ned Freed)


----------------------------------------------------------------------

Message: 1
Date: Tue, 10 Jul 2012 10:18:38 -0700 (PDT)
From: Ned Freed <ned.freed@mroc= hek.com>
To: Graham Klyne <graham.kl= yne@zoo.ox.ac.uk>
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] RFC 6657 on Update to MIME regarding
=A0 =A0 =A0 =A0 "charset" Parameter Handling in Textual Media Typ= es
Message-ID: <01O= HOK4TIDIW0006TF@mauve.mrochek.com>
Content-Type: TEXT/PLAIN; Format=3Dflowed

> On 10/07/2012 01:07, rfc-= editor@rfc-editor.org wrote:
> >
> > A new Request for Comments is now available in online RFC librari= es.
> >
> >
> > =A0 =A0 =A0 =A0 =A0RFC 6657
> >
> > =A0 =A0 =A0 =A0 =A0Title: =A0 =A0 =A0Update to MIME regarding &qu= ot;charset"
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Parameter Handling in = Textual Media Types

> I didn't see this one coming.

It was discussed at considerable length both here and on the IETF list.

> =A0I'm a bit confused by the specification.

You need to keep in mind that this only applies to subtypes of text.

> If we define a media type that is *always* UTF-8, does this count as > transporting its own charset information?

That's one approach you can use. The alternatives are to allow or requi= re
a charset parameter, always with the value utf-8. The best approach depends=
on the specifics of the type.

> =A0Should we say that the media type
> SHOULD NOT be included, or that it SHOULD be included with value UTF-8= ?

Included where? Within the content? If so, that's up to the registratio= n to
say. There are plenty of utf-8 based formats that don't provide for inc= lusion
of media type information - and that includes some that use XML syntax.

> Section
> 3 implies the latter, but it also talks about media types defining the= ir own
> default encoding.

Relying on defaults is discouraged for historical reasons - they don't = work
very well. As such, if it's possible for the type to explicitly say wha= t the
charset is, that's probably the best way to do it. If the type isn'= t capable of
that for whatever reason, your options are to simply say it's always ut= f-8 or
alternately allow or require a charset parameter with utf-8 as the only val= ue.
The best approach depends on the situation, which is why the document is fu= ll
of SHOULDs, not MUSTs.

> (This is not an academic question - a W3C group I'm involved with = is about to
> submit a registration for a UTF-8 only text/... media type)

Does this type actually meet the criteria for text specified in RFC 2046 section 4.1? I rather suspect it doesn't. If not, it really has no busi= ness
being a text subtype, and all of this is moot.

testing=A0

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ned


------------------------------

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


End of apps-discuss Digest, Vol 54, Issue 57
********************************************

--0016e6dd8d69a5421b04c4800ab7-- From paulej@packetizer.com Tue Jul 10 16:23:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D058721F8543 for ; Tue, 10 Jul 2012 16:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fcgv1Hw1dzC for ; Tue, 10 Jul 2012 16:23:06 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 29E0E21F8541 for ; Tue, 10 Jul 2012 16:23:06 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q6ANNWVJ016523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Jul 2012 19:23:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341962613; bh=ese1+9iDXdSW/+5tQedTY1SYbtXJQKGhm/s3E+ZKZcc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WE9QjKIPEM4QvZp0dW4WlIx4ist8xgv3AckjIXPiRI3Ga20VrllrNIcXO0D4MDZrO Bc+rlYxD6iCy2hoETYrMJL5HIPC3yaO1cSJ4uE0ABS9qE1lUZQfB9Nok6qFbdb8tzV PO33Y6NAt/rbNFXKO9urHQd5wR+DMyuIhL2sUgZ4= From: "Paul E. Jones" To: "'James M Snell'" References: <0bfa01cd5e4c$9ff2fe40$dfd8fac0$@packetizer.com> In-Reply-To: Date: Tue, 10 Jul 2012 19:23:38 -0400 Message-ID: <0d8401cd5ef3$09872c90$1c9585b0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIESQ8ibvH5DCcy0bSWDNtRTuLHcQHrVckpAT77RpuWm/mFwA== Content-Language: en-us Cc: 'IETF Apps Discuss' Subject: Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and Simple Web Discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 23:23:08 -0000 James, > On Mon, Jul 9, 2012 at 8:32 PM, Paul E. Jones > wrote: > > James, > > > > Allow me to comment on your draft w.r.t. the parts related to = WebFinger. > > WebFinger did built upon the host-meta spec, which is that we see = the > > "two step" process. However, the "resource" parameter MUST be > > supported by WebFinger servers. As such, this eliminates most of = the > > complexity issues on the client side. > > > > To your comments specifically, > > > > 1) XRD and JRD support: this is only required on the server. The > > client can choose what it wants. This is largely historical, but = I'm > > not shy to say that I favor XML. I respect that some prefer JSON, > though. > > >=20 > Why should there be a choice at all? Just choose one and be done with > it... preferably the least complicated of the two > (http://www.xprogramming.com/Practices/PracSimplest.html) This is due to the relatively recent shift in the "preferred syntax de = jour". When the work on WebFinger and host-meta started, XML was = considered the lingua franca of the Internet. Interest in JSON was = growing, but still had not reached critical mass. By the time RFC 6415 = was nearing publication, interest in JSON had grown to a point where the = authors felt it needed inclusion, so a JSON version of XRD (called JRD) = was defined in RFC 6415.=20 They're both trivial syntaxes. Since JSON lacks a formal syntax = specification, JRD is defined with respect to XRD, which is in turn = defined using XML Schema. JRD is definitely most interesting to people = right now, but XRD is already implemented in the wild. Personally, I = prefer XRD and see no particular advantage in using JRD. (JSON works = well in JavaScript applications, so I appreciate why people would like = to use it. In C++, though, present roughly the same work to utilize.) XRD and JRD are defined in RFC 6415. They exist and so I do not see any = reason to exclude one in favor of the other. Writing the server code to = support both is a trivial exercise, so why remove one arguing that it's = complex? It's not. =20 > > 2) Two-step HTTP request process: Requests could be a single step. = No > > client is required to implement a two-step request, ever. The > > two-step option exists, since WebFinger is an extension of RFC 6415, > > but the "resource" makes the query a one-step operation. > > >=20 > Yup... I made sure to point this out clearly in my note. If, as you = say, > clients are not ever required to implement the two-step flow, then why = is > it defined at all? Why add the additional complexity? This was one of = the > main points of my document and my counter proposal for = /.well-known/index > ... the RFC6415 requirement seems entirely superfluous to achieving = the > goal. Host-Meta / WebFinger allows for one to query information related to a = host and to specific resources controlled by that host. So, a client = can make a query and learn something about the host. One can then make = a second query and learn about a particular resource at that host. = Alternatively, if information about the host is not of interest, one can = make a single query and ask for information about the resource directly. We could re-write RFC 6415 and say that if the "resource" parameter is = not there, only return host-specific link relations (versus URI = templates). However, there is no point in re-writing writing what is = defined and implemented. That's especially true given how simple and = consistent the logic is when implementing the host-meta / WebFinger = server code. > > 3) There are several sub-parts: > > > > 3a) The WebFinger protocol defines normative dependencies on no = fewer > > than ten separate specifications: that's being a bit unfair. We = tried > > to be thorough with documenting material. We could perhaps make > > .well-known, web linking, URI syntax, and mailto URI informative. = We > > could discuss where those references should live, but HTTP and = XRD/JRD > > are really the core part of WebFinger. It's not so complex as you > suggest here. > > > > 3b) A WebFinger client needs to not only be capable of sending HTTP > > requests; but capable of parsing XML or JSON: They must parse one of > > the two. This is pretty basic. > > > > 3c) Capable of understanding the specific XRD and JRD vocabularies: > > there are no "specific" vocabularies, just XRD and JRD syntax. Both > > are simple and a client picks what it wants. > > > > 3d) Capable of processing URL Templates: since "resource" is > > mandatory, a client does not need to deal with templates >=20 > I think you may have missed the key point I was making: XML, JSON, = XRD, > JRD, URL templates, Digital Signatures, host-meta.. these are all = things > that WebFinger says are required without providing any reasonable > justification as to WHY they are required. Both the Simple Web = Discovery > draft and my /.well-known/index examples illustrate that we can easily > solve the fundamental problem with a whole lot less than what = WebFinger > defines... even if those things are -- by your own statement -- only = there > for "spec completeness". Your draft and SWD just use a different syntax. They do not eliminate = syntax. One way or the other, we must have syntax. XRD and JRD are required, because RFC 6415 (which is the basis for = WebFinger) defined XRD and JRD. RFC 6415 is something this group just = completed in October 2011, I'll note. Signatures on XRD are optional and I doubt anybody will do it, anyway. = I suspect the folks in OASIS did that just for completeness. I'm = certainly not going to ever bother with them. People should use HTTPS = and be done with it. URI templates are useful to RFC 6415 and those who elect to not use the = "resource" parameter. Using the "resource" parameter, one never sees = URI templates. However, they exist because they are defined in RFC 6415 = to allow for querying resource-specific link relations. So what does it take to create a WebFinger server? It's so trivial, I = can do it with static files. When one can do that, that means it's not = that complex. See here for an example: http://www.packetizer.com/webfinger/server.html > > 3e) Capable of processing XML digital signatures included within an > > XRD > > document: yeah, if HTTPS is not used. I doubt anybody will use > > signatures in favor of HTTPS. I suspect no client will process the > signatures, either. > > (There is "standards completeness" and reality.) > > > > 4) WebFinger uses email-like identifiers and this is a privacy = concern: > > email-like IDs are suggested to make WebFinger easy to use *by > > humans*, but there is definitely no requirement that one MUST use > > "acct:paulej@packetizer.com". One can use any valid URI. An > > enterprise could use some cryptic URI. The recommendation to use > > paulej@packetizer.com, for example, it to make your life easier if = you > > want to learn more about me. What is actually exposed and what is > > accessible is a matter of the publisher of that content and can be > > secured using standard web security mechanisms. Note that use of > > HTTPS also hides the email-like ID, too, so it's not seen on the = wire, > > so I'm really not sure why you're concerned with this. Those who = want > security will use TLS. >=20 > Several things with this one... >=20 > 1. All of the examples that deal with people show the use of acct > identifiers. From experience, I know that developers will generally = look > at the examples in the spec before they look at the spec text itself = and > they will generally follow whatever pattern is illustrated... Simply > saying that "some cryptic URI" could be used does not sufficiently = deal > with the issue. Support for hashed or otherwise obfuscated identifiers > within the request URI should be made explicit .. either via clear = example > or by normative requirement. Not all examples use "acct", though most certainly do. There are three = examples using "http" and one using a fictitious "device". If one uses TLS, this is a non-issue, anyway. When TLS is used, = identifiers are never seen outside the application. Even if TLS was not = used, I'm still not sure why hiding one's identifier is a concern when = we're also perfectly OK with returning information about people in the = clear or making it public in the first place :-) > 2. The use of SSL/TLS does not prevent request URIs from being = recorded in > log files, exposed in browsers, or compromised in a variety of = unforeseen > ways. Yes, it protects the data in transit but protects nothing when = the > data is at rest. The server that would be responding to requests would be the one that = would be recording stuff in log files when using TLS. It already knows = about these IDs and could certainly translate an obfuscated value into a = real value and log requests that way. Exposed in browsers? Users will = type in "paulej@packetizer.com", so it's already in a browser. If one = wants to use something with WF that does not look like an email address, = they can. =20 > > So just to reiterate, a WebFinger request for this URL: > > > > = https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paulej > > @packe > > tizer.com > > > > Typically looks like this: > > > > GET = /.well-known/host-meta.json?resource=3Dacct:paulej@packetizer.com > > HTTP/1.1 > > Host: packetizer.com > > > > The reply might have this body: > > > > { > > "subject" : "acct:paulej@packetizer.com", > > "links" : > > [ > > { > > "rel" : "http://webfinger.net/rel/avatar", > > "href" : > "http://www.packetizer.com/people/paulej/images/paulej.jpg" > > }, > > { > > "rel" : "http://specs.openid.net/auth/2.0/provider", > > "href" : "https://openid.packetizer.com/paulej" > > }, > > { > > "rel" : "http://webfinger.net/rel/profile-page", > > "href" : "http://www.packetizer.com/people/paulej/" > > }, > > { > > "rel" : "vcard", > > "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" > > }, > > { > > "rel" : "http://schemas.google.com/g/2010#updates-from", > > "href" : = "http://www.packetizer.com/people/paulej/blog/blog.xml" > > } > > ] > > } > > > > That's a fairly simple request / response, IMO. > > >=20 > And an alternative approach would look like.. (the numbers are the > sha-256 digest of the acct id) >=20 > GET /.well- > = known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d= 7 > f8 > HTTP/1.1 > Host: packetizer.com >=20 > HTTP/1.1 300 Multiple Choices > Link: ; > rel=3D"http://webfinger.net/rel/avatar", > ; > rel=3D"http://specs.openid.net/auth/2.0/provider", > ; rel=3D"http://webfinger.net/rel/profile.page", > ; rel=3D"vcard", > ; > rel=3D"http://schemas.google.com/g/2010#updates-from" This is just another syntax, as I said. Also, I personally find this = more challenging to deal with since it's in the headers, not the = payload. Might the web server itself want to introduce a Link header or perhaps a = web proxy? One might get back information that was not strictly about = the resource being queried. (For example, a link to a copyright = statement or "authorized users" statement or other.) =20 > And if all I want is the location of the avatar, for instance, it = could be > even easier... >=20 > GET /.well- > = known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d= 7 > f8/avatar > HTTP/1.1 > Host: packetizer.com >=20 > HTTP/1.1 302 Found > Location: /people/paulej/images/paulej.jpg So, I get a 302 and don't know why. Am I being redirected because the = user's information moved or because the information I seek is located = there? Web browsers will not even tell me about 302s when writing = JavaScript code, AFAIK. So, I might issue a query to get several things = (e.g., calendar and avatar), but only an avatar exists. The server = returns a 302 and I get a payload with a picture and have no idea what = it is for. Or would you return a 200 in that case with a single "Link:" = href/rel pair? =20 > Why should I, as the client, ever have to worry about XRD/JRD at all? > This is an important question that I have not yet seen an adequate = answer > for. Anyone who has worked with me before on things knows that with = solid > examples and a reasonable explanation I can be swayed to see the light = and > the error of my ways. So far, however, I am just not seeing it here. Because this is a very simple and consistent syntax that nicely packages = up a set of link relations and properties. I might also provided with a = list of aliases for the user/target. We had a separate dialog about how we could use the JRD syntax to convey = provisioning information related to mail servers. I'm not sure if = anyone would do that, but having the ability to include additional = properties is nice, since it allows for a richer set of information to = be conveyed. Lastly, having an XRD or JRD in hand allows that document to be passed = "down the line" for processing. Headers in HTTP could, too, but as I = said, it's an alternate syntax that is less complete and I personally = find dealing with a returned payload simpler than putting valuable = response information in headers. Paul From paulej@packetizer.com Tue Jul 10 20:19:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EB811E80C1 for ; Tue, 10 Jul 2012 20:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVslmZ7ETYYm for ; Tue, 10 Jul 2012 20:19:25 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9A95311E8079 for ; Tue, 10 Jul 2012 20:19:25 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q6B3JpuM022005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Jul 2012 23:19:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341976793; bh=MjUxwb8m5WoNKGOSXTZ54slj3UjAzUyfk0QuKasHuGI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=izYQAk1oBmEK6jL+0P3EdTjtaoTCEN7EHZ5uQ7Wb4/xY+xRYOdxcJplkO4Nal6dna mfa70EDtIP7bm2WdbkGBpfHRf37+izngOfZl+uoRmj1aOPnGwyJws1j07W7ssnUwUe fDc0ftvdmzSy9iNovAkQveuHMKYPOe+9b1sre6fQ= From: "Paul E. Jones" To: "'Manger, James H'" , "'James M Snell'" , "'IETF Apps Discuss'" References: <255B9BB34FB7D647A506DC292726F6E114F797793C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F797793C@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 10 Jul 2012 23:19:57 -0400 Message-ID: <0de201cd5f14$0dcc9b70$2965d250$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM8jMPY0typOTnX3235UES6z4/+z5RFDdBw Content-Language: en-us Subject: Re: [apps-discuss] redirects in draft-snell-web-index/WebFinger/SWD X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 03:19:26 -0000 James, If it is true that large sites will always host LRDD content at a separate location, then perhaps if the first query to such a site results in a 3xx redirection then the client interested in optimizing queries should issue a subsequent query without the "resource" parameter to discover the location of the LRDD resource. I like the thinking proposed of introducing a new HTTP header, but that could be of general interest outside of WebFinger. Further, one might want to use URI templates (RFC 6570) with such a new HTTP header. Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of Manger, James H > Sent: Tuesday, July 10, 2012 3:28 AM > To: James M Snell; IETF Apps Discuss > Subject: [apps-discuss] redirects in draft-snell-web-index/WebFinger/SWD > > Various people have said that many (big?) sites will not want to serve > per-user discovery details from their top-domain. For example, they will > serve it from https://id.example.com/, not https://example.com/. > > Redirecting all discovery request from example.com to id.example.com > works, but it does add a round trip. If clients can determine that the > redirection will apply to all future discovery requests, not just the > specific one they are currently making, then the extra round trip is a > once-off that can be ignored. > > SWD solves this with its content-layer SWD_service_redirect. > > WebFinger-without-resource-parameter solves this by providing a template > for per-user details that can use another domain, eg > https://id.example.com/user?u={uri}; or by redirecting the (non-user- > specific) initial request. > > WebFinger-with-a-resource-parameter and draft-snell-web-index don't solve > this issue. > > Ideally, we should solve this at the HTTP layer. An HTTP 3xx response > should be able to indicate that the same response applies to all URIs with > a given prefix. How about: > > HTTP/1.1 307 Moved > Location: https://id.example.com/user?u=acct:paulej@packetizer.com > Redirect: /.well-known/finger https://id.example.com/user > > The "Redirect" header includes a path-prefix and destination URI. The same > redirect applies to any request whose path starts with path-prefix. The > part of the request after the path-prefix is appended to the destination > URI to get the new location. > It is potentially dangerous (a response from any resource on a site can > redirect requests to all other resources on the site), but that might be > solvable. > > -- > James Manger > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ned.freed@mrochek.com Tue Jul 10 22:46:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA5311E80BA for ; Tue, 10 Jul 2012 22:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ70WfRTKPNe for ; Tue, 10 Jul 2012 22:46:00 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 58B3311E8073 for ; Tue, 10 Jul 2012 22:45:59 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHP9J99HVK0054FL@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 10 Jul 2012 22:45:53 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHLKS3CK340006TF@mauve.mrochek.com>; Tue, 10 Jul 2012 22:45:50 -0700 (PDT) Message-id: <01OHP9J7BTNM0006TF@mauve.mrochek.com> Date: Tue, 10 Jul 2012 22:44:54 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 10 Jul 2012 23:58:29 +0100" <4FFCB395.9030400@zoo.ox.ac.uk> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <20120710000754.6BF59B1E006@rfc-editor.org> <4FFBE454.1020601@zoo.ox.ac.uk> <01OHOK4TIDIW0006TF@mauve.mrochek.com> <4FFCB395.9030400@zoo.ox.ac.uk> To: Graham Klyne Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC 6657 on Update to MIME regarding "charset" Parameter Handling in Textual Media Types X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 05:46:00 -0000 > On 10/07/2012 18:18, Ned Freed wrote: > >> On 10/07/2012 01:07, rfc-editor@rfc-editor.org wrote: > >> > > >> > A new Request for Comments is now available in online RFC libraries. > >> > > >> > > >> > RFC 6657 > >> > > >> > Title: Update to MIME regarding "charset" > >> > Parameter Handling in Textual Media Types > > > >> I didn't see this one coming. > > > > It was discussed at considerable length both here and on the IETF list. > Sure, I just meant that I missed it. > >> I'm a bit confused by the specification. > > > > You need to keep in mind that this only applies to subtypes of text. > Ack. > >> If we define a media type that is *always* UTF-8, does this count as > >> transporting its own charset information? > > > > That's one approach you can use. The alternatives are to allow or require > > a charset parameter, always with the value utf-8. The best approach depends > > on the specifics of the type. > > > >> Should we say that the media type > >> SHOULD NOT be included, or that it SHOULD be included with value UTF-8? > > > > Included where? Within the content? If so, that's up to the registration to > > say. There are plenty of utf-8 based formats that don't provide for inclusion > > of media type information - and that includes some that use XML syntax. > Doh... I meant media type "charset" parameter. > There's no character encoding information in the content. > >> Section > >> 3 implies the latter, but it also talks about media types defining their own > >> default encoding. > > > > Relying on defaults is discouraged for historical reasons - they don't work > > very well. As such, if it's possible for the type to explicitly say what the > > charset is, that's probably the best way to do it. If the type isn't capable of > > that for whatever reason, your options are to simply say it's always utf-8 or > > alternately allow or require a charset parameter with utf-8 as the only value. > > The best approach depends on the situation, which is why the document is full > > of SHOULDs, not MUSTs. > Yeah, one of those. I expect it will come up for review very soon, so you can > comment if we've made the wrong call. > >> (This is not an academic question - a W3C group I'm involved with is about to > >> submit a registration for a UTF-8 only text/... media type) > > > > Does this type actually meet the criteria for text specified in RFC 2046 > > section 4.1? I rather suspect it doesn't. If not, it really has no business > > being a text subtype, and all of this is moot. > I believe it does. We're not talking XML or anything like that. It's a textual > notation for provenance information, intended for human and occasional machine > consumption. Then my suggestion would be to make the charset parameter mandatory, with the only legal value being utf-8. The alternative would be to omit it and specify utf-8 as the default, but as I said, that's not likely to interoperate well. Ned From andreas@sbin.se Wed Jul 11 02:43:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8D521F8608 for ; Wed, 11 Jul 2012 02:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxJbfc3pvEIn for ; Wed, 11 Jul 2012 02:43:52 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id DE40821F8601 for ; Wed, 11 Jul 2012 02:43:51 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q6B9iJBa012979; Wed, 11 Jul 2012 09:44:19 GMT Date: Wed, 11 Jul 2012 11:44:11 +0200 From: Andreas Petersson To: Mateusz Karcz Message-ID: <20120711114411.694627c5@hetzer> In-Reply-To: References: X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/vEOvGDP/Zl4bN9aw1Rv.JVL"; protocol="application/pgp-signature" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 09:43:52 -0000 --Sig_/vEOvGDP/Zl4bN9aw1Rv.JVL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 10 Jul 2012 16:05:12 +0200 Mateusz Karcz wrote: > Good afternoon! I'm Mateusz Karcz. I'm author of "Unified User-Agent Stri= ng (UUAS)" I-D (draft-karcz-uuas-00). I had sent it to RFC Editor as Indepe= ndent Submission, but after I got suggestion from ISB to publicate it by ap= psawg, because it extends application layer protocol (HTTP) header. Can I d= evelop that draft with You? > Sincerelly > Mateusz Karcz Some quick comments on the draft: 1. Is this supposed to be put as value in the current "User-Agent"-header field, or is this a new header field? If this is to be put in the "User-Agent"-field, how does this relate to Section 10.10 of draft-ietf-httpbis-p2-semantics-19 or 14.43 of RFC2616? 2. I think the use of sub-sub-sub-sections make the structure a bit... strange. :-) 3. What is security level? How is it used? References? Should it be possible to extend the values? 4. I think it would be better if you use productions from RFC5234, instead of specifying ranges of hexadecimal-values. I also believe that you can write: uuas =3D agent [ SP engine ]=20 instead of: uuas =3D agent *1(SP engine) 5. RFC2068 is listed as a normative reference, but it is not mentioned in the text. Further, it is obsoleted by RFC2616 since like over ten years ago. :-) RFC2616 is also to be obsoleted by httpbis pretty soon, I assume. Best regards, Andreas --Sig_/vEOvGDP/Zl4bN9aw1Rv.JVL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJP/UrrAAoJEEaYRbQUWNle+3gP/jB6jV5qFBG83o4mugo5ozVy +Q+OsvvLEUFli9/7rgacoPC9e4mMc9xOKNnRoQGyh+K4TyWKtPb5mLYxwX47pswt +ad8JD2G3TvK457BuyC+tuvwJE3U9MO4DPcQ8uceD0MK+67OVrJkoY6upGt78aO2 YcI/ZL9qxy7qe2XDQcYTIefDLDve2e3/jNvcFmQ8o6rMd513myfogrGggvo36lgW b/wN5/hn61ybfVMhvalYrQOC7lDQm3G74+GDkMzVP6yWbyLIkv75oAY4BvSbcL+n PEHIN5Bfv2LxKPvQdRcnNkjifRLGKMvGKPxr4iEBDR3kPMvo8ijChY9Q7TyJCtX2 OT69HC5YP8saAEJ709AA+uJrUFZNY2g7F+6tHBGRNG6Sw+UlZaGAoHjkKVLp3nw0 84xkyJHrr2w+yPREE+/o1RUaYyVbhUCz+BnqJ9ibpCHy8zTeeZ1OW0wMzl2r96ds 7vi36jPN2kWknZ3TAcVRbUbCCnDYjuoFSI3kFSvHRewET06OfWf9SlFfBychWq8E FbJZOz5b4mr48/pon4XNKWznQiY4D410ofJ3+/HLuI7ObHSYF1Tocx1YGikbJqEP E5Mcj/I+0BwFLDPl37USAgn2admULIgsHFoVepyR3lpuXVNIlFpL3K7VZgAs2JhE 3MrM03YLc1yU+N5sCVu9 =DvwQ -----END PGP SIGNATURE----- --Sig_/vEOvGDP/Zl4bN9aw1Rv.JVL-- From julian.reschke@gmx.de Wed Jul 11 03:05:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E7221F8616 for ; Wed, 11 Jul 2012 03:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.462 X-Spam-Level: X-Spam-Status: No, score=-104.462 tagged_above=-999 required=5 tests=[AWL=-1.863, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI0B-t5CD9UF for ; Wed, 11 Jul 2012 03:05:24 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7975321F8513 for ; Wed, 11 Jul 2012 03:05:23 -0700 (PDT) Received: (qmail invoked by alias); 11 Jul 2012 10:05:52 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp040) with SMTP; 11 Jul 2012 12:05:52 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/dh7NT37fdS7l6SvbIV1FqyMwwpzEJvHjuALu+ju 5GCPNg32XxCn/Z Message-ID: <4FFD5000.8010908@gmx.de> Date: Wed, 11 Jul 2012 12:05:52 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Andreas Petersson References: <20120711114411.694627c5@hetzer> In-Reply-To: <20120711114411.694627c5@hetzer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Mateusz Karcz , apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 10:05:25 -0000 On 2012-07-11 11:44, Andreas Petersson wrote: > On Tue, 10 Jul 2012 16:05:12 +0200 > Mateusz Karcz wrote: > >> Good afternoon! I'm Mateusz Karcz. I'm author of "Unified User-Agent String (UUAS)" I-D (draft-karcz-uuas-00). I had sent it to RFC Editor as Independent Submission, but after I got suggestion from ISB to publicate it by appsawg, because it extends application layer protocol (HTTP) header. Can I develop that draft with You? >> Sincerelly >> Mateusz Karcz > > Some quick comments on the draft: > > 1. Is this supposed to be put as value in the current > "User-Agent"-header field, or is this a new header field? > If this is to be put in the "User-Agent"-field, how does > this relate to Section 10.10 of draft-ietf-httpbis-p2-semantics-19 > or 14.43 of RFC2616? Indeed. You can't update the definition of a header field that is already widely deployed by something experimental. Another point: Security is truly believed to be irrelevant to this document. This indicated that you may not have done sufficient research on the use of "User-Agent" :-) Best regards, Julian From jonm@jjmoore.net Wed Jul 11 03:14:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C334121F863E for ; Wed, 11 Jul 2012 03:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW0MgB1rfs87 for ; Wed, 11 Jul 2012 03:14:04 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE5AC21F85A8 for ; Wed, 11 Jul 2012 03:14:01 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1074156ggn.31 for ; Wed, 11 Jul 2012 03:14:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=J8lSJV0lk8i6y1jKIncMDSe769rbpA7C+hhyN/hzFgY=; b=bwP9gS93KzGEDG2rYxgw7mZLJla7CQ6L/L67b56gKe6ls7DpwMbgAJ9a9PCjQ6f6qB 8E7wpni6FOSVXnJA/Z/QYugy3LtiO52gb3cujSwiOZaShxhErRnH9/9jsRPo71xr+fKS z13uBuyC994gLUZG+RKUQTygKvCFDThW64JV4nUS0RXrekXYCg6CsVYwOxheA6yARDzH FGUK3Nw1XRzHxP508c8DfupT3CD7F2Qb3L7qZzmos0CpitDQ/Jf+YxV4dCykqpgiTbvS t/tQrXfmtiGuuFzmTBy/+6ngQiBzkW+sMshGx0MylICj6sl/OVXcuU1/BkeaGRMJPMHa CfVQ== MIME-Version: 1.0 Received: by 10.50.100.129 with SMTP id ey1mr13729082igb.35.1342001671813; Wed, 11 Jul 2012 03:14:31 -0700 (PDT) Received: by 10.64.137.200 with HTTP; Wed, 11 Jul 2012 03:14:31 -0700 (PDT) X-Originating-IP: [68.32.29.233] Date: Wed, 11 Jul 2012 06:14:31 -0400 Message-ID: From: Jon Moore To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmTiAqX455T+3yIZhC9WP82ivUHTwrqYzDY5ihJxK6kBAhVxAaajVrYcdnS2bRtcOvTRx1v Subject: [apps-discuss] registering a text/diff format? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 10:14:06 -0000 Hi folks, Given the arrival of HTTP PATCH in RFC 5789[1], it seems like registering a media type for the output of the 'diff' utility would be a good idea. I'd like to start by documenting a "text/diff" format to capture the unified diff format that's in common use. Often, diff outputs something that would be a text/* type, although not always, so perhaps there is a need for application/diff instead of or in addition to text/diff. I'd like to see this registered in the IANA standard media type tree, so I'd like to see this captured as an RFC. I've started working on an Internet-Draft (https://github.com/jonm/text-diff) and have attracted a couple of folks interested in helping out. Would this WG be willing to take this work track on? Thanks, Jon ........ Jon Moore From stefan.guggisberg@gmail.com Wed Jul 11 05:38:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD4C21F8582 for ; Wed, 11 Jul 2012 05:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzOHkwZr-+ZL for ; Wed, 11 Jul 2012 05:38:43 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A34921F8579 for ; Wed, 11 Jul 2012 05:38:43 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1666832obb.31 for ; Wed, 11 Jul 2012 05:39:13 -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=E4cIArImop1t3UAtZOFVlDbIBVPAdSUArO4tvnlxRq8=; b=pYQQxHklOrtYU9k1Cyy6hbyhJ2r0cAmZmbtI7LvuG/lXlthql6s5KbwC8E3frUiPD+ MecMvjuWFJe+LN4rgsZtua0uMa4gYyTgna2gLGmeDMvGidnc0mRvUMdehQ1X33XFb7AL 7lBPjVjyb20KYhiBhgQpyqjfFfsEXidurA8N2i8YJQYqLu4bLjNtLkkEJsonGnCA15je rlGtqK+PFK2jNmGisX1dYNdNKOZ7QrYTpYdSxi2bgGpJYXGTxf5/idcl5ou2ZFOrx1x2 2tA4OLpp102GfbkP3uFDLbt4iM4vBhtj5NT3vOViz7eU/r8LQ3SeByQRXWV61KFDXy0g SEgg== MIME-Version: 1.0 Received: by 10.182.43.71 with SMTP id u7mr33176339obl.13.1342010353561; Wed, 11 Jul 2012 05:39:13 -0700 (PDT) Received: by 10.76.101.139 with HTTP; Wed, 11 Jul 2012 05:39:13 -0700 (PDT) Date: Wed, 11 Jul 2012 14:39:13 +0200 Message-ID: From: Stefan Guggisberg To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 12:38:44 -0000 hi, disclaimer: i am new to the IETF and this is my first post on this list. please forgive my ignorance if i've missed something obvious. here's my feedback: 4.6. test "If values are or contain objects or arrays, they must be identical (i.e. same order of elements, with the same values)." the last sentence in brackets is IMO misleading since it only applies to arrays. for object comparison the order of elements is irrelevant, i.e. two objects are identical if they contain the exact same set of elements with the same values. 5.0 Error Handling "... and application of the entire patch document SHALL NOT be deemed successful." does that mean that any changes caused by preceding successful operations within the same patch document MUST be reverted, i.e. the application of the patch document is always an all-or-nothing operation? Appendix A. Examples. all examples except for "A.6. Moving a Value" deal with shallow json objects. i think it would be good to add an example for adding a nested member object, e.g. Adding a nested Member Object An example target JSON document: { "foo": "bar" } A JSON Patch document: [ { "add": "/child", "value": { "grandchild": { } } } ] The resulting JSON document: { "foo": "bar", "child": { "grandchild": { } } } cheers stefan From andreas@sbin.se Wed Jul 11 06:41:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D789C21F868A; Wed, 11 Jul 2012 06:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAgLYFxp3XCL; Wed, 11 Jul 2012 06:41:36 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id D9F1121F8610; Wed, 11 Jul 2012 06:41:35 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q6BDg3U0016854; Wed, 11 Jul 2012 13:42:03 GMT Date: Wed, 11 Jul 2012 15:41:58 +0200 From: Andreas Petersson To: SM Message-ID: <20120711154158.60f6ecf0@hetzer> In-Reply-To: <6.2.5.6.2.20120710081323.08c9bcf8@resistor.net> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org> <6.2.5.6.2.20120709134136.0ad9ae18@resistor.net> <20120710132825.5141babe@hetzer> <6.2.5.6.2.20120710081323.08c9bcf8@resistor.net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/24HaJ_VUi=WtQuc0yxNxZLi"; protocol="application/pgp-signature" Cc: IETF Discussion Mailing List , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 13:41:37 -0000 --Sig_/24HaJ_VUi=WtQuc0yxNxZLi Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 10 Jul 2012 08:43:43 -0700 SM wrote: >>> In Section 6.3: >>>=20 >>> 'To distinguish the obfuscated identifier from other identifiers, >>> it MUST have a leading underscore "_".' >>>=20 >>> I suggest removing the requirement and using "can". The implementer=20 >>> can decide what to put in that field. =20 >At 04:28 10-07-2012, Andreas Petersson wrote: >>I think that will make parsing harder, and give no benefit at all. >=20 > It allows for more random bits of information. >=20 (adding context again) Hi, Can you substantiate a bit on this statement? How is it "random bits of information" when the specifications says that it MUST be underscore? As far as I can think of, the only thing that it will tell is that the implementation is following this specification. So, on the contrary; the more "degrees of freedom" that is given to the implementation, the easier it would be to do fingerprinting. Cheers, Andreas --Sig_/24HaJ_VUi=WtQuc0yxNxZLi Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJP/YKmAAoJEEaYRbQUWNleOrQP/3KbagZ5LLcXfHOrU9akrOiW HE9mffoJXI5DDUNC0UKN0aFVB+3MYP8CnmewpvVCrSJqNhlt7rSgryTAaSRCyg2v /pvW1RHPfiBLoQ17WoF5zSHmHgIMHRw4+TCyhZ6KSbWlANvOVz7dcDU918080u6u eKLorbDfiZK/fRybBb10s+WDk5ju1YyFHyGGEXujymP5dI1iCrF6BA1Oy6FnPcwX /N+1Wfx6g4hyFiuRKH4sWIsm1P2gcUng2+I1A0nNHom1XyVAfpuOk8rW/h9DrTPh xcxtfqWzBk7+G3PGDyLALUOlxbfZXIpYn9imzpM347qwnwgXMYS/p9OOlpUxhUsU r5sdqc7R+561DEmdhEI1LNFSr4e2D6+kAkAL1L985lYIMfVbV6259q/FU5l0ixqx G/+kC8fg9iRj1tMKvTNOyICUiuKXoNI43EKv0mVOjfxFXMrksxMxGD2JJJomGqTo U7Bf57qQPlbdNFY2g90lP473rFEHJZYgi8M5eHZ4cxG8EUkpWF6TCPCrokk4shwq YueW61Ke/umE/UEjSF6LDJPnXiTyEkuePfTMrdXPCN/tOMw9kHUoaAhW/cFL1Tbt aUXnC1W2k8rsN3dGrBgKEcDZV/zcZKd7sRHD6i1+QGcbO1KSZkHlqh4tbbTT8/ol eXMNjqK8+3gfMKx+3W9j =5zpM -----END PGP SIGNATURE----- --Sig_/24HaJ_VUi=WtQuc0yxNxZLi-- From andreas@sbin.se Wed Jul 11 07:41:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398AF21F86C2; Wed, 11 Jul 2012 07:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3d3NxI2FZLE; Wed, 11 Jul 2012 07:41:14 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 521DF21F86A1; Wed, 11 Jul 2012 07:41:14 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q6BEfOQQ004292; Wed, 11 Jul 2012 14:41:25 GMT Date: Wed, 11 Jul 2012 16:41:11 +0200 From: Andreas Petersson To: Alissa Cooper Message-ID: <20120711164111.1b9e86d5@hetzer> In-Reply-To: <62148A5F-B5F0-4915-8064-F33A0ADCB311@cdt.org> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org> <20120710132756.4dac582d@hetzer> <20120710180729.42712860@hetzer> <62148A5F-B5F0-4915-8064-F33A0ADCB311@cdt.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/N.7js2fI0g5=4i9GE9p/OfJ"; protocol="application/pgp-signature" Cc: IETF Discussion Mailing List , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 14:41:15 -0000 --Sig_/N.7js2fI0g5=4i9GE9p/OfJ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 10 Jul 2012 12:32:08 -0400 Alissa Cooper wrote: > On Jul 10, 2012, at 12:07 PM, Andreas Petersson wrote: > >> The first half of the statement is basically a refinement of the previ= ous sentence in the section ("The Forwarded HTTP header field, by design, e= xposes information that some users consider privacy sensitive"), so I don't= see what is lost by eliminating it. > >=20 > > See my answer to SM. I think it better explains that the expectations > > of the end user are important to consider, even if these expectations > > are wrong. >=20 > Right, I'm not saying that user expectations are unimportant. I think cha= racterizing their role accurately should be the goal. If there is a desire = to leave this in, I would suggest something more along the lines of: >=20 > Proxies using this extension will preserve the information of a direct co= nnection. In some cases, the user's and/or deployer's knowledge or expectat= ion that this will occur can help to mitigate the associated privacy impact. Off-list discussion with Alissa resulted in this suggestion: "Proxies using this extension will preserve the information of a direct connection. This has an end-user privacy impact regardless of whether the end-user or deployer knows or expects that this is the case." Cheers, Andreas --Sig_/N.7js2fI0g5=4i9GE9p/OfJ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJP/ZCHAAoJEEaYRbQUWNleuyUQAMBhA6j3m1PwcQZ1ggSPHvLR U3MqV01Xc8n6Wv0c2tCbDyV9B6vos8UxAaS3etvfNO1pR5pJVAidvdPho+04hxKm 4dL2wndkkphCLV/7Na9UeR/WkH2ZZ+XQ7wt1UyMvHMP0Qp6R0dZiscgO3hzJKZoF 8c92gsaIJwEN2SPRU898dUR7AkKn8PLr5cLWqD829I3frtsTJgaUfW+ogmJrP2iN 72DBXUIbwe/3O/nr3fkIcD5PeFAa62swPgAQYyEgWlmx0weWzuRc8u8GoN+WMH3V oIs/KV3uBxpPgCZkA6hqfsX0wbRNfTuFZJbqd9zXXMKmT6HXfTPpYk4A5BwhHc1k 7X2GznToRILFNZcKzYdamcP6TsXUWP9sZBmB26w7/tFD5Fw4oPT9s7MufDPZ/vza vM15ZGH8eeHR9jZPReTdc32q7V5ZZZnVbsMrXRwORbCPRR9WSu0mVBpSJXr3I2Jl 6YgIcDlfwCIgJgWUekAHXO1KV4icdOFoMJb6AZVXfmsMRC8mHfBliZyaaCkpycqQ aonjHb8K6fGSHFS5+s+/idvV8QlEcIW/tUECg08PEHSUt7h5IMf3mPkMbQvFrDA0 CQz8hNI3xpG9wBI4uF4Qq/bnBm4PkKfvDKOprmGX0HWhNhNvamPHQx51wdXz6tcb HwjnxJvz/zV0VBidbUx6 =XFt3 -----END PGP SIGNATURE----- --Sig_/N.7js2fI0g5=4i9GE9p/OfJ-- From dhc@dcrocker.net Wed Jul 11 08:08:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F284C21F866A for ; Wed, 11 Jul 2012 08:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F-4nq-GstNB for ; Wed, 11 Jul 2012 08:08:44 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6637F21F8691 for ; Wed, 11 Jul 2012 08:08:44 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6BF9BQk028847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Jul 2012 08:09:12 -0700 Message-ID: <4FFD9713.7060006@dcrocker.net> Date: Wed, 11 Jul 2012 08:09:07 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Julian Reschke References: <20120711114411.694627c5@hetzer> <4FFD5000.8010908@gmx.de> In-Reply-To: <4FFD5000.8010908@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 11 Jul 2012 08:09:12 -0700 (PDT) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 15:08:46 -0000 On 7/11/2012 3:05 AM, Julian Reschke wrote: > On 2012-07-11 11:44, Andreas Petersson wrote: > Indeed. You can't update the definition of a header field that is > already widely deployed by something experimental. To quote an under-appreciated engineer who was once President of the United States: we could do it, but it would be wrong. > Another point: > > Security is truly believed to be irrelevant to this document. > > This indicated that you may not have done sufficient research on the use > of "User-Agent" :-) Indeed. Given that web sites often behave very differently for different browsers, this would seem to have a great deal of potential security effects. In general, the proposal lacks clear motivation. As a theoretical topic, it seems reasonable to standardize the meta-data describing the user agent serving as the client. However standardization at this stage of operational history requires documenting the specific problems or other needs that will drive the design. That is: 1) what existing difficulties in client/server interaction are currently related to this string or would be mitigated by standardizing it? 2) what is the evidence that client and server implementers will adopt a standard string? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned.freed@mrochek.com Wed Jul 11 08:28:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396F321F84AE for ; Wed, 11 Jul 2012 08:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hoq7UlbyPhXi for ; Wed, 11 Jul 2012 08:28:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8155621F861F for ; Wed, 11 Jul 2012 08:28:02 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHPTPB3FZK004N21@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 11 Jul 2012 08:23:26 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHLKS3CK340006TF@mauve.mrochek.com>; Wed, 11 Jul 2012 08:23:20 -0700 (PDT) Message-id: <01OHPTP7PS260006TF@mauve.mrochek.com> Date: Wed, 11 Jul 2012 08:19:17 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 11 Jul 2012 08:09:07 -0700" <4FFD9713.7060006@dcrocker.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20120711114411.694627c5@hetzer> <4FFD5000.8010908@gmx.de> <4FFD9713.7060006@dcrocker.net> To: Dave Crocker Cc: Julian Reschke , apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 15:28:03 -0000 I'm in agreement with everything Dave says below. That said, a document that first discusses the issues with this field fully and completely, then justifies (not standardizes) specification of a new format, and finally proceeds to define that format, could turn out to be a Good Thing. FWIW, the way I'd do it is to separate the issue intrinsic to the use of the field in any way from the issues that arise from inconsistent use of field values. The former are unresolvable, and may actually be made worse by a consistent format, but the latter are the thing a consistent format would address. Ned > On 7/11/2012 3:05 AM, Julian Reschke wrote: > > On 2012-07-11 11:44, Andreas Petersson wrote: > > Indeed. You can't update the definition of a header field that is > > already widely deployed by something experimental. > To quote an under-appreciated engineer who was once President of the > United States: we could do it, but it would be wrong. > > Another point: > > > > Security is truly believed to be irrelevant to this document. > > > > This indicated that you may not have done sufficient research on the use > > of "User-Agent" :-) > Indeed. Given that web sites often behave very differently for > different browsers, this would seem to have a great deal of potential > security effects. > In general, the proposal lacks clear motivation. As a theoretical > topic, it seems reasonable to standardize the meta-data describing the > user agent serving as the client. However standardization at this stage > of operational history requires documenting the specific problems or > other needs that will drive the design. > That is: > 1) what existing difficulties in client/server interaction are currently > related to this string or would be mitigated by standardizing it? > 2) what is the evidence that client and server implementers will adopt a > standard string? > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From Graham.Klyne@zoo.ox.ac.uk Tue Jul 10 10:34:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585A621F869F for ; Tue, 10 Jul 2012 10:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUG39BpOVmeL for ; Tue, 10 Jul 2012 10:34:32 -0700 (PDT) Received: from relay1.mail.ox.ac.uk (relay1.mail.ox.ac.uk [129.67.1.165]) by ietfa.amsl.com (Postfix) with ESMTP id 630D321F8694 for ; Tue, 10 Jul 2012 10:34:27 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay1.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1SoeKs-0001Es-5b; Tue, 10 Jul 2012 18:34:54 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SoeKs-0002V4-16; Tue, 10 Jul 2012 18:34:54 +0100 Message-ID: <4FFC626F.2040705@zoo.ox.ac.uk> Date: Tue, 10 Jul 2012 18:12:15 +0100 From: Graham Klyne Organization: Oxford University User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Alexey Melnikov References: <20120710000754.6BF59B1E006@rfc-editor.org> <4FFBE454.1020601@zoo.ox.ac.uk> <4FFC561F.7070205@isode.com> In-Reply-To: <4FFC561F.7070205@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 X-Mailman-Approved-At: Wed, 11 Jul 2012 09:06:08 -0700 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC 6657 on Update to MIME regarding "charset" Parameter Handling in Textual Media Types X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 17:34:33 -0000 Alexey, thanks. #g -- On 10/07/2012 17:19, Alexey Melnikov wrote: > Hi Graham, > > On 10/07/2012 09:14, Graham Klyne wrote: >> On 10/07/2012 01:07, rfc-editor@rfc-editor.org wrote: >>> >>> A new Request for Comments is now available in online RFC libraries. >>> >>> >>> RFC 6657 >>> >>> Title: Update to MIME regarding "charset" >>> Parameter Handling in Textual Media Types >> >> I didn't see this one coming. I'm a bit confused by the specification. >> >> If we define a media type that is *always* UTF-8, does this count as >> transporting its own charset information? Should we say that the media type > > I think you meant the "charset" parameter. > >> SHOULD NOT be included, or that it SHOULD be included with value UTF-8? >> Section 3 implies the latter, but it also talks about media types defining >> their own default encoding. > > For backward compatibility with RFC 2045 it would be better to require explicit > 'charset="utf-8"', but not allowing the charset parameter and saying that the > payload for your text/foo media type is always in UTF-8 is fine. > >> (This is not an academic question - a W3C group I'm involved with is about to >> submit a registration for a UTF-8 only text/... media type) >> >> #g >> -- >> >>> Author: A. Melnikov, J. Reschke >>> Status: Standards Track >>> Stream: IETF >>> Date: July 2012 >>> Mailbox: Alexey.Melnikov@isode.com, >>> julian.reschke@greenbytes.de >>> Pages: 6 >>> Characters: 10111 >>> Updates: RFC2046 >>> >>> I-D Tag: draft-ietf-appsawg-mime-default-charset-04.txt >>> >>> URL: http://www.rfc-editor.org/rfc/rfc6657.txt >>> >>> This document changes RFC 2046 rules regarding default "charset" >>> parameter values for "text/*" media types to better align with common >>> usage by existing clients and servers. [STANDARDS-TRACK] >>> >>> This document is a product of the Applications Area Working Group Working >>> Group of the IETF. >>> >>> This is now a Proposed Standard Protocol. >>> >>> STANDARDS TRACK: This document specifies an Internet standards track >>> protocol for the Internet community,and requests discussion and suggestions >>> for improvements. Please refer to the current edition of the Internet >>> Official Protocol Standards (STD 1) for the standardization state and >>> status of this protocol. Distribution of this memo is unlimited. >>> >>> This announcement is sent to the IETF-Announce and rfc-dist lists. >>> To subscribe or unsubscribe, see >>> http://www.ietf.org/mailman/listinfo/ietf-announce >>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >>> >>> For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. >>> For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >>> >>> Requests for special distribution should be addressed to either the >>> author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >>> specifically noted otherwise on the RFC itself, all RFCs are for >>> unlimited distribution. >>> >>> >>> The RFC Editor Team >>> Association Management Solutions, LLC > > From Graham.Klyne@zoo.ox.ac.uk Tue Jul 10 16:25:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BF311E80FE for ; Tue, 10 Jul 2012 16:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHTKvHipxb1O for ; Tue, 10 Jul 2012 16:25:14 -0700 (PDT) Received: from relay8.mail.ox.ac.uk (relay8.mail.ox.ac.uk [129.67.1.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9654511E80E0 for ; Tue, 10 Jul 2012 16:25:13 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay8.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1SojoI-0007nZ-RF; Wed, 11 Jul 2012 00:25:38 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SojoI-0003FN-3P; Wed, 11 Jul 2012 00:25:38 +0100 Message-ID: <4FFCB395.9030400@zoo.ox.ac.uk> Date: Tue, 10 Jul 2012 23:58:29 +0100 From: Graham Klyne Organization: Oxford University User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Ned Freed References: <20120710000754.6BF59B1E006@rfc-editor.org> <4FFBE454.1020601@zoo.ox.ac.uk> <01OHOK4TIDIW0006TF@mauve.mrochek.com> In-Reply-To: <01OHOK4TIDIW0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 X-Mailman-Approved-At: Wed, 11 Jul 2012 09:06:20 -0700 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC 6657 on Update to MIME regarding "charset" Parameter Handling in Textual Media Types X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2012 23:25:16 -0000 On 10/07/2012 18:18, Ned Freed wrote: >> On 10/07/2012 01:07, rfc-editor@rfc-editor.org wrote: >> > >> > A new Request for Comments is now available in online RFC libraries. >> > >> > >> > RFC 6657 >> > >> > Title: Update to MIME regarding "charset" >> > Parameter Handling in Textual Media Types > >> I didn't see this one coming. > > It was discussed at considerable length both here and on the IETF list. Sure, I just meant that I missed it. >> I'm a bit confused by the specification. > > You need to keep in mind that this only applies to subtypes of text. Ack. >> If we define a media type that is *always* UTF-8, does this count as >> transporting its own charset information? > > That's one approach you can use. The alternatives are to allow or require > a charset parameter, always with the value utf-8. The best approach depends > on the specifics of the type. > >> Should we say that the media type >> SHOULD NOT be included, or that it SHOULD be included with value UTF-8? > > Included where? Within the content? If so, that's up to the registration to > say. There are plenty of utf-8 based formats that don't provide for inclusion > of media type information - and that includes some that use XML syntax. Doh... I meant media type "charset" parameter. There's no character encoding information in the content. >> Section >> 3 implies the latter, but it also talks about media types defining their own >> default encoding. > > Relying on defaults is discouraged for historical reasons - they don't work > very well. As such, if it's possible for the type to explicitly say what the > charset is, that's probably the best way to do it. If the type isn't capable of > that for whatever reason, your options are to simply say it's always utf-8 or > alternately allow or require a charset parameter with utf-8 as the only value. > The best approach depends on the situation, which is why the document is full > of SHOULDs, not MUSTs. Yeah, one of those. I expect it will come up for review very soon, so you can comment if we've made the wrong call. >> (This is not an academic question - a W3C group I'm involved with is about to >> submit a registration for a UTF-8 only text/... media type) > > Does this type actually meet the criteria for text specified in RFC 2046 > section 4.1? I rather suspect it doesn't. If not, it really has no business > being a text subtype, and all of this is moot. I believe it does. We're not talking XML or anything like that. It's a textual notation for provenance information, intended for human and occasional machine consumption. #g -- From mateusz.karcz@interia.eu Wed Jul 11 09:39:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8646821F85C3 for ; Wed, 11 Jul 2012 09:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.067 X-Spam-Level: * X-Spam-Status: No, score=1.067 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, TVD_RATWARE_MSGID_02=0.581] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFmtCXTEggT2 for ; Wed, 11 Jul 2012 09:39:39 -0700 (PDT) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.206]) by ietfa.amsl.com (Postfix) with ESMTP id 7C65C11E807F for ; Wed, 11 Jul 2012 09:39:39 -0700 (PDT) Date: Wed, 11 Jul 2012 18:40:07 +0200 From: Mateusz Karcz To: Ned Freed X-Mailer: interia.pl/pf09 In-Reply-To: <01OHPTP7PS260006TF@mauve.mrochek.com> References: <20120711114411.694627c5@hetzer> <4FFD5000.8010908@gmx.de> <4FFD9713.7060006@dcrocker.net> <01OHPTP7PS260006TF@mauve.mrochek.com> X-Originating-IP: 31.61.131.253 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1342024808; bh=ItH8gT3dc49LmLJIm38uUyhRGVFL7riWgvzZwBGkpYw=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=eyDykLb2Rjchqc6Zwhtv+PdSb4UO18OZdsWYtFVYJo+zKw9PD1CqT3ilEdFc5Hq0J K4xWT32ClnY4X5KwD2SDS46KvUE24eCIlgLrf6B/rvJEjCiyMMaDimiVCA1wrjFTLH AffW5ImOagyHCKjh1ZuWibNlNb/EXPzFK8VkFb0M= Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 16:39:40 -0000 So I had to: 1. Add references to HTTP specification. 2. Simply syntax definition. 3. Separate issue definition and actual problems definition. 4. Write Security Considerations. 5. Change form of draft from standarising to proposing. 6. Find examples of errors, which are result of ambiguous strings. 7. Change order of elements in draft. 8. Think two times about sense of that project. From jasnell@gmail.com Wed Jul 11 16:02:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678D011E814A for ; Wed, 11 Jul 2012 16:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=-2.468, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcJI7UiDczYt for ; Wed, 11 Jul 2012 16:02:55 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4213B11E815F for ; Wed, 11 Jul 2012 16:02:54 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so4643182wib.13 for ; Wed, 11 Jul 2012 16:03: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=l/TEIpAiiywM6FnifY0cRXyD0AuR84UGOJYA9kLpGLw=; b=fhTqJA3eau3pM8KLduignB7NDIZrie79SL4WmCWkFoJeDYDSzu1qjRkJ3GiSgTWz6j cQG6O2M6R7hkCFSwzSbVKV9/DfhkpvGB3EbalUxrDEG2OYM57dcNxGh4MNThky80+VEP af87u3O+DjmRqpH6yhMjxWveL3VohBV6zqmJnTtyqS5NPLmZs9wArSLfr5pmVSP2rQYW OsG30py5FO9wXF6jyzWpjBA6LOX1g9f1OIxoHpqkriH64ieMHotbEKVOG8DYHf07DT8v 2WqB2pt/Rge80/BmnBTQpgcWr5kMO4XbDbougFzQ/S7jg5WSuJQ8eZkg/ZLYx/yDZ0Oa cYrw== Received: by 10.216.237.193 with SMTP id y43mr21980892weq.75.1342047805837; Wed, 11 Jul 2012 16:03:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.171.72 with HTTP; Wed, 11 Jul 2012 16:03:05 -0700 (PDT) In-Reply-To: <0d8401cd5ef3$09872c90$1c9585b0$@packetizer.com> References: <0bfa01cd5e4c$9ff2fe40$dfd8fac0$@packetizer.com> <0d8401cd5ef3$09872c90$1c9585b0$@packetizer.com> From: James M Snell Date: Wed, 11 Jul 2012 16:03:05 -0700 Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and Simple Web Discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2012 23:02:57 -0000 Paul, for most of this we'll apparently have to simply disagree and leave it at that as I've got no intention or desire to try to convince you to change your opinion. The intent of my memo was to solely to document that I feel there's an even easier way of accomplishing the same task with fewer moving parts. I believe I provided an adequate example that proves that point. I still do not see why parsing *any* XML or JSON should be a requirement, however, as I do not see what particular benefit they provide. I've asked several times but have not yet seen a clear answer to this very basic question: *Why* are they *required*? What benefits do those dependencies provide that are critical to solving the basic problem? Are they simply something that would be nice to have? I don't need yet another explanation as to why you think it's just trivial so why am I bothering to ask... I want to know why those dependencies are *required*. Note, fwiw, that the /.well-known/index proposal is not contrary to the possible use of XRD/LRDD... for instance, one could easily do something like... GET /.well-known/index/{some-opaque-id}/lrdd HTTP/1.1 Host: example.org And get back a... HTTP/1.1 302 Found Location: /lrdd/?uri=3Dacct:bob@example.org - James On Tue, Jul 10, 2012 at 4:23 PM, Paul E. Jones wrot= e: > James, > >> On Mon, Jul 9, 2012 at 8:32 PM, Paul E. Jones >> wrote: >> > James, >> > >> > Allow me to comment on your draft w.r.t. the parts related to WebFinge= r. >> > WebFinger did built upon the host-meta spec, which is that we see the >> > "two step" process. However, the "resource" parameter MUST be >> > supported by WebFinger servers. As such, this eliminates most of the >> > complexity issues on the client side. >> > >> > To your comments specifically, >> > >> > 1) XRD and JRD support: this is only required on the server. The >> > client can choose what it wants. This is largely historical, but I'm >> > not shy to say that I favor XML. I respect that some prefer JSON, >> though. >> > >> >> Why should there be a choice at all? Just choose one and be done with >> it... preferably the least complicated of the two >> (http://www.xprogramming.com/Practices/PracSimplest.html) > > This is due to the relatively recent shift in the "preferred syntax de jo= ur". When the work on WebFinger and host-meta started, XML was considered = the lingua franca of the Internet. Interest in JSON was growing, but still= had not reached critical mass. By the time RFC 6415 was nearing publicati= on, interest in JSON had grown to a point where the authors felt it needed = inclusion, so a JSON version of XRD (called JRD) was defined in RFC 6415. > > They're both trivial syntaxes. Since JSON lacks a formal syntax specific= ation, JRD is defined with respect to XRD, which is in turn defined using X= ML Schema. JRD is definitely most interesting to people right now, but XRD= is already implemented in the wild. Personally, I prefer XRD and see no p= articular advantage in using JRD. (JSON works well in JavaScript applicati= ons, so I appreciate why people would like to use it. In C++, though, pres= ent roughly the same work to utilize.) > > XRD and JRD are defined in RFC 6415. They exist and so I do not see any = reason to exclude one in favor of the other. Writing the server code to su= pport both is a trivial exercise, so why remove one arguing that it's compl= ex? It's not. > >> > 2) Two-step HTTP request process: Requests could be a single step. No >> > client is required to implement a two-step request, ever. The >> > two-step option exists, since WebFinger is an extension of RFC 6415, >> > but the "resource" makes the query a one-step operation. >> > >> >> Yup... I made sure to point this out clearly in my note. If, as you say, >> clients are not ever required to implement the two-step flow, then why i= s >> it defined at all? Why add the additional complexity? This was one of th= e >> main points of my document and my counter proposal for /.well-known/inde= x >> ... the RFC6415 requirement seems entirely superfluous to achieving the >> goal. > > Host-Meta / WebFinger allows for one to query information related to a ho= st and to specific resources controlled by that host. So, a client can mak= e a query and learn something about the host. One can then make a second q= uery and learn about a particular resource at that host. Alternatively, if= information about the host is not of interest, one can make a single query= and ask for information about the resource directly. > > We could re-write RFC 6415 and say that if the "resource" parameter is no= t there, only return host-specific link relations (versus URI templates). = However, there is no point in re-writing writing what is defined and implem= ented. That's especially true given how simple and consistent the logic is= when implementing the host-meta / WebFinger server code. > >> > 3) There are several sub-parts: >> > >> > 3a) The WebFinger protocol defines normative dependencies on no fewer >> > than ten separate specifications: that's being a bit unfair. We tried >> > to be thorough with documenting material. We could perhaps make >> > .well-known, web linking, URI syntax, and mailto URI informative. We >> > could discuss where those references should live, but HTTP and XRD/JRD >> > are really the core part of WebFinger. It's not so complex as you >> suggest here. >> > >> > 3b) A WebFinger client needs to not only be capable of sending HTTP >> > requests; but capable of parsing XML or JSON: They must parse one of >> > the two. This is pretty basic. >> > >> > 3c) Capable of understanding the specific XRD and JRD vocabularies: >> > there are no "specific" vocabularies, just XRD and JRD syntax. Both >> > are simple and a client picks what it wants. >> > >> > 3d) Capable of processing URL Templates: since "resource" is >> > mandatory, a client does not need to deal with templates >> >> I think you may have missed the key point I was making: XML, JSON, XRD, >> JRD, URL templates, Digital Signatures, host-meta.. these are all things >> that WebFinger says are required without providing any reasonable >> justification as to WHY they are required. Both the Simple Web Discovery >> draft and my /.well-known/index examples illustrate that we can easily >> solve the fundamental problem with a whole lot less than what WebFinger >> defines... even if those things are -- by your own statement -- only the= re >> for "spec completeness". > > Your draft and SWD just use a different syntax. They do not eliminate sy= ntax. One way or the other, we must have syntax. > > XRD and JRD are required, because RFC 6415 (which is the basis for WebFin= ger) defined XRD and JRD. RFC 6415 is something this group just completed = in October 2011, I'll note. > > Signatures on XRD are optional and I doubt anybody will do it, anyway. I= suspect the folks in OASIS did that just for completeness. I'm certainly = not going to ever bother with them. People should use HTTPS and be done wi= th it. > > URI templates are useful to RFC 6415 and those who elect to not use the "= resource" parameter. Using the "resource" parameter, one never sees URI te= mplates. However, they exist because they are defined in RFC 6415 to allow= for querying resource-specific link relations. > > So what does it take to create a WebFinger server? It's so trivial, I ca= n do it with static files. When one can do that, that means it's not that = complex. See here for an example: > http://www.packetizer.com/webfinger/server.html > >> > 3e) Capable of processing XML digital signatures included within an >> > XRD >> > document: yeah, if HTTPS is not used. I doubt anybody will use >> > signatures in favor of HTTPS. I suspect no client will process the >> signatures, either. >> > (There is "standards completeness" and reality.) >> > >> > 4) WebFinger uses email-like identifiers and this is a privacy concern= : >> > email-like IDs are suggested to make WebFinger easy to use *by >> > humans*, but there is definitely no requirement that one MUST use >> > "acct:paulej@packetizer.com". One can use any valid URI. An >> > enterprise could use some cryptic URI. The recommendation to use >> > paulej@packetizer.com, for example, it to make your life easier if you >> > want to learn more about me. What is actually exposed and what is >> > accessible is a matter of the publisher of that content and can be >> > secured using standard web security mechanisms. Note that use of >> > HTTPS also hides the email-like ID, too, so it's not seen on the wire, >> > so I'm really not sure why you're concerned with this. Those who want >> security will use TLS. >> >> Several things with this one... >> >> 1. All of the examples that deal with people show the use of acct >> identifiers. From experience, I know that developers will generally look >> at the examples in the spec before they look at the spec text itself and >> they will generally follow whatever pattern is illustrated... Simply >> saying that "some cryptic URI" could be used does not sufficiently deal >> with the issue. Support for hashed or otherwise obfuscated identifiers >> within the request URI should be made explicit .. either via clear examp= le >> or by normative requirement. > > Not all examples use "acct", though most certainly do. There are three e= xamples using "http" and one using a fictitious "device". > > If one uses TLS, this is a non-issue, anyway. When TLS is used, identifi= ers are never seen outside the application. Even if TLS was not used, I'm = still not sure why hiding one's identifier is a concern when we're also per= fectly OK with returning information about people in the clear or making it= public in the first place :-) > >> 2. The use of SSL/TLS does not prevent request URIs from being recorded = in >> log files, exposed in browsers, or compromised in a variety of unforesee= n >> ways. Yes, it protects the data in transit but protects nothing when the >> data is at rest. > > The server that would be responding to requests would be the one that wou= ld be recording stuff in log files when using TLS. It already knows about = these IDs and could certainly translate an obfuscated value into a real val= ue and log requests that way. Exposed in browsers? Users will type in "pa= ulej@packetizer.com", so it's already in a browser. If one wants to use so= mething with WF that does not look like an email address, they can. > >> > So just to reiterate, a WebFinger request for this URL: >> > >> > https://packetizer.com/.well-known/host-meta.json?resource=3Dacct:paul= ej >> > @packe >> > tizer.com >> > >> > Typically looks like this: >> > >> > GET /.well-known/host-meta.json?resource=3Dacct:paulej@packetizer.com >> > HTTP/1.1 >> > Host: packetizer.com >> > >> > The reply might have this body: >> > >> > { >> > "subject" : "acct:paulej@packetizer.com", >> > "links" : >> > [ >> > { >> > "rel" : "http://webfinger.net/rel/avatar", >> > "href" : >> "http://www.packetizer.com/people/paulej/images/paulej.jpg" >> > }, >> > { >> > "rel" : "http://specs.openid.net/auth/2.0/provider", >> > "href" : "https://openid.packetizer.com/paulej" >> > }, >> > { >> > "rel" : "http://webfinger.net/rel/profile-page", >> > "href" : "http://www.packetizer.com/people/paulej/" >> > }, >> > { >> > "rel" : "vcard", >> > "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" >> > }, >> > { >> > "rel" : "http://schemas.google.com/g/2010#updates-from", >> > "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml" >> > } >> > ] >> > } >> > >> > That's a fairly simple request / response, IMO. >> > >> >> And an alternative approach would look like.. (the numbers are the >> sha-256 digest of the acct id) >> >> GET /.well- >> known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1= d7 >> f8 >> HTTP/1.1 >> Host: packetizer.com >> >> HTTP/1.1 300 Multiple Choices >> Link: ; >> rel=3D"http://webfinger.net/rel/avatar", >> ; >> rel=3D"http://specs.openid.net/auth/2.0/provider", >> ; rel=3D"http://webfinger.net/rel/profile.page", >> ; rel=3D"vcard", >> ; >> rel=3D"http://schemas.google.com/g/2010#updates-from" > > This is just another syntax, as I said. Also, I personally find this mor= e challenging to deal with since it's in the headers, not the payload. > > Might the web server itself want to introduce a Link header or perhaps a = web proxy? One might get back information that was not strictly about the = resource being queried. (For example, a link to a copyright statement or "= authorized users" statement or other.) > >> And if all I want is the location of the avatar, for instance, it could = be >> even easier... >> >> GET /.well- >> known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1= d7 >> f8/avatar >> HTTP/1.1 >> Host: packetizer.com >> >> HTTP/1.1 302 Found >> Location: /people/paulej/images/paulej.jpg > > So, I get a 302 and don't know why. Am I being redirected because the us= er's information moved or because the information I seek is located there? = Web browsers will not even tell me about 302s when writing JavaScript code= , AFAIK. So, I might issue a query to get several things (e.g., calendar a= nd avatar), but only an avatar exists. The server returns a 302 and I get = a payload with a picture and have no idea what it is for. Or would you ret= urn a 200 in that case with a single "Link:" href/rel pair? > >> Why should I, as the client, ever have to worry about XRD/JRD at all? >> This is an important question that I have not yet seen an adequate answe= r >> for. Anyone who has worked with me before on things knows that with soli= d >> examples and a reasonable explanation I can be swayed to see the light a= nd >> the error of my ways. So far, however, I am just not seeing it here. > > Because this is a very simple and consistent syntax that nicely packages = up a set of link relations and properties. I might also provided with a li= st of aliases for the user/target. > > We had a separate dialog about how we could use the JRD syntax to convey = provisioning information related to mail servers. I'm not sure if anyone w= ould do that, but having the ability to include additional properties is ni= ce, since it allows for a richer set of information to be conveyed. > > Lastly, having an XRD or JRD in hand allows that document to be passed "d= own the line" for processing. Headers in HTTP could, too, but as I said, i= t's an alternate syntax that is less complete and I personally find dealing= with a returned payload simpler than putting valuable response information= in headers. > > Paul > From sm@resistor.net Wed Jul 11 17:08:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE3311E8126; Wed, 11 Jul 2012 17:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMfCPE4hZM6f; Wed, 11 Jul 2012 17:08:33 -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 0574211E80C6; Wed, 11 Jul 2012 17:08:32 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6C08uE6014693; Wed, 11 Jul 2012 17:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1342051743; bh=8w6mO/YQXx3NYsLSfj//f0S5H46KAMSfu2Mq5v3xCno=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pwycZV4ND2GWWVnF8oA0NLrwFb82XuZxk8V8y94fuBwxfyqtsXbOx639mZw7HDWq2 K+TVSL0AUWfW4VkfNQ9+ful+H8UYZrIDKtgzzUfGfXsaJGvimEYksLeHo4E8bqDTf3 HoiOiNZWqyePiXHltTidKgzUWiS3NtmdoHmTV0HI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1342051743; i=@resistor.net; bh=8w6mO/YQXx3NYsLSfj//f0S5H46KAMSfu2Mq5v3xCno=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uZLyimhvx1eGhBHzzjLnPfgnsximRhfXir6pX3K4vQHLfxeLDu7gVsMRJXQvcPUBA qrBYIQtWwC+2ONfq44r66yQ8O63E4tzTzv+cnMl6DN7ec5ZjQg/+s5f3DSxNf1eLnN aLSyedRHmU2zYuSrRkLz5OLiDFYtPOA+DJFsBITE= Message-Id: <6.2.5.6.2.20120711154825.09f09be8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Jul 2012 16:48:19 -0700 To: Andreas Petersson From: SM In-Reply-To: <20120711154158.60f6ecf0@hetzer> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org> <6.2.5.6.2.20120709134136.0ad9ae18@resistor.net> <20120710132825.5141babe@hetzer> <6.2.5.6.2.20120710081323.08c9bcf8@resistor.net> <20120711154158.60f6ecf0@hetzer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: IETF Discussion Mailing List , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2012 00:08:37 -0000 Hi Andreas, At 06:41 11-07-2012, Andreas Petersson wrote: >How is it "random bits of information" when the specifications says >that it MUST be underscore? > >As far as I can think of, the only thing that it will tell is that the >implementation is following this specification. >So, on the contrary; the more "degrees of freedom" that is given to the >implementation, the easier it would be to do fingerprinting. I could use a hash. If the hash has to begin with an underscore, I have to reserve storage space for it. The ease for fingerprinting depends on how Section 6.3 is implemented (see reference I posted on WG mailing list about browser identification). I am ok if you want to keep the requirement. Regards, -sm From mnot@mnot.net Wed Jul 11 17:26:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68EE11E814F for ; Wed, 11 Jul 2012 17:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.162 X-Spam-Level: X-Spam-Status: No, score=-105.162 tagged_above=-999 required=5 tests=[AWL=-2.563, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf6vKYVPFVwb for ; Wed, 11 Jul 2012 17:26:08 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 21D2D11E8138 for ; Wed, 11 Jul 2012 17:26:08 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6745F22E1F4; Wed, 11 Jul 2012 20:26:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Thu, 12 Jul 2012 10:26:28 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stefan Guggisberg X-Mailer: Apple Mail (2.1278) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2012 00:26:09 -0000 On 11/07/2012, at 10:39 PM, Stefan Guggisberg wrote: > hi, >=20 > disclaimer: i am new to the IETF and this is my first post > on this list. please forgive my ignorance if i've missed > something obvious. Hi Stefan, Welcome :) > here's my feedback: >=20 > 4.6. test >=20 > "If values are or contain objects or arrays, they must be > identical (i.e. same order of elements, with the same values)." >=20 > the last sentence in brackets is IMO misleading since it > only applies to arrays. for object comparison the order of > elements is irrelevant, i.e. two objects are identical if they > contain the exact same set of elements with the same values. Good point; I've added this as = . Note that we have an open issue regarding whether we keep test - see = . > 5.0 Error Handling >=20 > "... and application of the entire patch document SHALL > NOT be deemed successful." >=20 > does that mean that any changes caused by preceding > successful operations within the same patch document > MUST be reverted, i.e. the application of the patch > document is always an all-or-nothing operation? PATCH requires it to be atomic; see = . I've added a small note = to this effect to remind people. > Appendix A. Examples. >=20 > all examples except for "A.6. Moving a Value" deal > with shallow json objects. i think it would be good > to add an example for adding a nested member object, > e.g. >=20 > Adding a nested Member Object >=20 > An example target JSON document: >=20 > { > "foo": "bar" > } >=20 > A JSON Patch document: >=20 > [ > { "add": "/child", "value": { "grandchild": { } } } > ] >=20 > The resulting JSON document: >=20 > { > "foo": "bar", > "child": { > "grandchild": { > } > } > } Thanks, I've added this to the next draft. Regards, -- Mark Nottingham http://www.mnot.net/ From melvincarvalho@gmail.com Thu Jul 12 01:29:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196FB21F8796 for ; Thu, 12 Jul 2012 01:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBVsYrfmm3Fv for ; Thu, 12 Jul 2012 01:29:32 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7FE21F8799 for ; Thu, 12 Jul 2012 01:29:32 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1420915vbb.31 for ; Thu, 12 Jul 2012 01:30:04 -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=gcjT9kXq+HelrTOTFaJeEkXZv+4Yx/yqi6wzF1LH2DI=; b=yNSzURi9HpaPgasIHytjCFmRDW6KMgvLmmiM+SWBI8orUG3l9k7hx1abuVPKs3fSYs cWfQg35uCZd2omi9Bt2I4D/FK8PmCjQUpeYo5cObu7CwxXCP9vs3eeEsN7ygmeB708Z1 NpJNTPJ1xt/9ZKFQs3kBYjPQT6VD6bP6DNTo4vm4KPcXbkYGAXovU4k/t8e2EXEpxMM5 V9O6o9XUuAhFA3xFmorcLR06BqHPFRBTKoWx5jjaI1ciMry6rkuQ68Z5RsfAGpS/on48 AOkXfpzjAjMm6cQZ5rrwDS8+FqSj3DOkcwD24Aq0Q1BbYv9YMzBq7o514UglkVk1AXWn +IPw== MIME-Version: 1.0 Received: by 10.52.155.193 with SMTP id vy1mr20840871vdb.123.1342081804175; Thu, 12 Jul 2012 01:30:04 -0700 (PDT) Received: by 10.52.166.102 with HTTP; Thu, 12 Jul 2012 01:30:04 -0700 (PDT) In-Reply-To: <0d8401cd5ef3$09872c90$1c9585b0$@packetizer.com> References: <0bfa01cd5e4c$9ff2fe40$dfd8fac0$@packetizer.com> <0d8401cd5ef3$09872c90$1c9585b0$@packetizer.com> Date: Thu, 12 Jul 2012 10:30:04 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=bcaec53ae9ee32884e04c49dc5b2 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and Simple Web Discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2012 08:29:35 -0000 --bcaec53ae9ee32884e04c49dc5b2 Content-Type: text/plain; charset=ISO-8859-1 On 11 July 2012 01:23, Paul E. Jones wrote: > James, > > > On Mon, Jul 9, 2012 at 8:32 PM, Paul E. Jones > > wrote: > > > James, > > > > > > Allow me to comment on your draft w.r.t. the parts related to > WebFinger. > > > WebFinger did built upon the host-meta spec, which is that we see the > > > "two step" process. However, the "resource" parameter MUST be > > > supported by WebFinger servers. As such, this eliminates most of the > > > complexity issues on the client side. > > > > > > To your comments specifically, > > > > > > 1) XRD and JRD support: this is only required on the server. The > > > client can choose what it wants. This is largely historical, but I'm > > > not shy to say that I favor XML. I respect that some prefer JSON, > > though. > > > > > > > Why should there be a choice at all? Just choose one and be done with > > it... preferably the least complicated of the two > > (http://www.xprogramming.com/Practices/PracSimplest.html) > > This is due to the relatively recent shift in the "preferred syntax de > jour". When the work on WebFinger and host-meta started, XML was > considered the lingua franca of the Internet. Interest in JSON was > growing, but still had not reached critical mass. By the time RFC 6415 was > nearing publication, interest in JSON had grown to a point where the > authors felt it needed inclusion, so a JSON version of XRD (called JRD) was > defined in RFC 6415. > > They're both trivial syntaxes. Since JSON lacks a formal syntax > specification I think JSON does have a formal syntax specification: http://json.org/ Or did you mean that JRD? > , JRD is defined with respect to XRD, which is in turn defined using XML > Schema. JRD is definitely most interesting to people right now, but XRD is > already implemented in the wild. Personally, I prefer XRD and see no > particular advantage in using JRD. (JSON works well in JavaScript > applications, so I appreciate why people would like to use it. In C++, > though, present roughly the same work to utilize.) > > XRD and JRD are defined in RFC 6415. They exist and so I do not see any > reason to exclude one in favor of the other. Writing the server code to > support both is a trivial exercise, so why remove one arguing that it's > complex? It's not. > > > > 2) Two-step HTTP request process: Requests could be a single step. No > > > client is required to implement a two-step request, ever. The > > > two-step option exists, since WebFinger is an extension of RFC 6415, > > > but the "resource" makes the query a one-step operation. > > > > > > > Yup... I made sure to point this out clearly in my note. If, as you say, > > clients are not ever required to implement the two-step flow, then why is > > it defined at all? Why add the additional complexity? This was one of the > > main points of my document and my counter proposal for /.well-known/index > > ... the RFC6415 requirement seems entirely superfluous to achieving the > > goal. > > Host-Meta / WebFinger allows for one to query information related to a > host and to specific resources controlled by that host. So, a client can > make a query and learn something about the host. One can then make a > second query and learn about a particular resource at that host. > Alternatively, if information about the host is not of interest, one can > make a single query and ask for information about the resource directly. > > We could re-write RFC 6415 and say that if the "resource" parameter is not > there, only return host-specific link relations (versus URI templates). > However, there is no point in re-writing writing what is defined and > implemented. That's especially true given how simple and consistent the > logic is when implementing the host-meta / WebFinger server code. > > > > 3) There are several sub-parts: > > > > > > 3a) The WebFinger protocol defines normative dependencies on no fewer > > > than ten separate specifications: that's being a bit unfair. We tried > > > to be thorough with documenting material. We could perhaps make > > > .well-known, web linking, URI syntax, and mailto URI informative. We > > > could discuss where those references should live, but HTTP and XRD/JRD > > > are really the core part of WebFinger. It's not so complex as you > > suggest here. > > > > > > 3b) A WebFinger client needs to not only be capable of sending HTTP > > > requests; but capable of parsing XML or JSON: They must parse one of > > > the two. This is pretty basic. > > > > > > 3c) Capable of understanding the specific XRD and JRD vocabularies: > > > there are no "specific" vocabularies, just XRD and JRD syntax. Both > > > are simple and a client picks what it wants. > > > > > > 3d) Capable of processing URL Templates: since "resource" is > > > mandatory, a client does not need to deal with templates > > > > I think you may have missed the key point I was making: XML, JSON, XRD, > > JRD, URL templates, Digital Signatures, host-meta.. these are all things > > that WebFinger says are required without providing any reasonable > > justification as to WHY they are required. Both the Simple Web Discovery > > draft and my /.well-known/index examples illustrate that we can easily > > solve the fundamental problem with a whole lot less than what WebFinger > > defines... even if those things are -- by your own statement -- only > there > > for "spec completeness". > > Your draft and SWD just use a different syntax. They do not eliminate > syntax. One way or the other, we must have syntax. > > XRD and JRD are required, because RFC 6415 (which is the basis for > WebFinger) defined XRD and JRD. RFC 6415 is something this group just > completed in October 2011, I'll note. > > Signatures on XRD are optional and I doubt anybody will do it, anyway. I > suspect the folks in OASIS did that just for completeness. I'm certainly > not going to ever bother with them. People should use HTTPS and be done > with it. > > URI templates are useful to RFC 6415 and those who elect to not use the > "resource" parameter. Using the "resource" parameter, one never sees URI > templates. However, they exist because they are defined in RFC 6415 to > allow for querying resource-specific link relations. > > So what does it take to create a WebFinger server? It's so trivial, I can > do it with static files. When one can do that, that means it's not that > complex. See here for an example: > http://www.packetizer.com/webfinger/server.html > > > > 3e) Capable of processing XML digital signatures included within an > > > XRD > > > document: yeah, if HTTPS is not used. I doubt anybody will use > > > signatures in favor of HTTPS. I suspect no client will process the > > signatures, either. > > > (There is "standards completeness" and reality.) > > > > > > 4) WebFinger uses email-like identifiers and this is a privacy concern: > > > email-like IDs are suggested to make WebFinger easy to use *by > > > humans*, but there is definitely no requirement that one MUST use > > > "acct:paulej@packetizer.com". One can use any valid URI. An > > > enterprise could use some cryptic URI. The recommendation to use > > > paulej@packetizer.com, for example, it to make your life easier if you > > > want to learn more about me. What is actually exposed and what is > > > accessible is a matter of the publisher of that content and can be > > > secured using standard web security mechanisms. Note that use of > > > HTTPS also hides the email-like ID, too, so it's not seen on the wire, > > > so I'm really not sure why you're concerned with this. Those who want > > security will use TLS. > > > > Several things with this one... > > > > 1. All of the examples that deal with people show the use of acct > > identifiers. From experience, I know that developers will generally look > > at the examples in the spec before they look at the spec text itself and > > they will generally follow whatever pattern is illustrated... Simply > > saying that "some cryptic URI" could be used does not sufficiently deal > > with the issue. Support for hashed or otherwise obfuscated identifiers > > within the request URI should be made explicit .. either via clear > example > > or by normative requirement. > > Not all examples use "acct", though most certainly do. There are three > examples using "http" and one using a fictitious "device". > > If one uses TLS, this is a non-issue, anyway. When TLS is used, > identifiers are never seen outside the application. Even if TLS was not > used, I'm still not sure why hiding one's identifier is a concern when > we're also perfectly OK with returning information about people in the > clear or making it public in the first place :-) > > > 2. The use of SSL/TLS does not prevent request URIs from being recorded > in > > log files, exposed in browsers, or compromised in a variety of unforeseen > > ways. Yes, it protects the data in transit but protects nothing when the > > data is at rest. > > The server that would be responding to requests would be the one that > would be recording stuff in log files when using TLS. It already knows > about these IDs and could certainly translate an obfuscated value into a > real value and log requests that way. Exposed in browsers? Users will > type in "paulej@packetizer.com", so it's already in a browser. If one > wants to use something with WF that does not look like an email address, > they can. > > > > So just to reiterate, a WebFinger request for this URL: > > > > > > https://packetizer.com/.well-known/host-meta.json?resource=acct:paulej > > > @packe > > > tizer.com > > > > > > Typically looks like this: > > > > > > GET /.well-known/host-meta.json?resource=acct:paulej@packetizer.com > > > HTTP/1.1 > > > Host: packetizer.com > > > > > > The reply might have this body: > > > > > > { > > > "subject" : "acct:paulej@packetizer.com", > > > "links" : > > > [ > > > { > > > "rel" : "http://webfinger.net/rel/avatar", > > > "href" : > > "http://www.packetizer.com/people/paulej/images/paulej.jpg" > > > }, > > > { > > > "rel" : "http://specs.openid.net/auth/2.0/provider", > > > "href" : "https://openid.packetizer.com/paulej" > > > }, > > > { > > > "rel" : "http://webfinger.net/rel/profile-page", > > > "href" : "http://www.packetizer.com/people/paulej/" > > > }, > > > { > > > "rel" : "vcard", > > > "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" > > > }, > > > { > > > "rel" : "http://schemas.google.com/g/2010#updates-from", > > > "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml" > > > } > > > ] > > > } > > > > > > That's a fairly simple request / response, IMO. > > > > > > > And an alternative approach would look like.. (the numbers are the > > sha-256 digest of the acct id) > > > > GET /.well- > > > known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d7 > > f8 > > HTTP/1.1 > > Host: packetizer.com > > > > HTTP/1.1 300 Multiple Choices > > Link: ; > > rel="http://webfinger.net/rel/avatar", > > ; > > rel="http://specs.openid.net/auth/2.0/provider", > > ; rel="http://webfinger.net/rel/profile.page", > > ; rel="vcard", > > ; > > rel="http://schemas.google.com/g/2010#updates-from" > > This is just another syntax, as I said. Also, I personally find this more > challenging to deal with since it's in the headers, not the payload. > > Might the web server itself want to introduce a Link header or perhaps a > web proxy? One might get back information that was not strictly about the > resource being queried. (For example, a link to a copyright statement or > "authorized users" statement or other.) > > > And if all I want is the location of the avatar, for instance, it could > be > > even easier... > > > > GET /.well- > > > known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d7 > > f8/avatar > > HTTP/1.1 > > Host: packetizer.com > > > > HTTP/1.1 302 Found > > Location: /people/paulej/images/paulej.jpg > > So, I get a 302 and don't know why. Am I being redirected because the > user's information moved or because the information I seek is located > there? Web browsers will not even tell me about 302s when writing > JavaScript code, AFAIK. So, I might issue a query to get several things > (e.g., calendar and avatar), but only an avatar exists. The server returns > a 302 and I get a payload with a picture and have no idea what it is for. > Or would you return a 200 in that case with a single "Link:" href/rel pair? > > > Why should I, as the client, ever have to worry about XRD/JRD at all? > > This is an important question that I have not yet seen an adequate answer > > for. Anyone who has worked with me before on things knows that with solid > > examples and a reasonable explanation I can be swayed to see the light > and > > the error of my ways. So far, however, I am just not seeing it here. > > Because this is a very simple and consistent syntax that nicely packages > up a set of link relations and properties. I might also provided with a > list of aliases for the user/target. > > We had a separate dialog about how we could use the JRD syntax to convey > provisioning information related to mail servers. I'm not sure if anyone > would do that, but having the ability to include additional properties is > nice, since it allows for a richer set of information to be conveyed. > > Lastly, having an XRD or JRD in hand allows that document to be passed > "down the line" for processing. Headers in HTTP could, too, but as I said, > it's an alternate syntax that is less complete and I personally find > dealing with a returned payload simpler than putting valuable response > information in headers. > > Paul > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --bcaec53ae9ee32884e04c49dc5b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 11 July 2012 01:23, Paul E. Jones <paulej@packetizer.com> wrote:
James,

> On Mon, Jul 9, 2012 at 8:32 PM, Paul E. Jones <paulej@packetizer.com>
> wrote:
> > James,
> >
> > Allow me to comment on your draft w.r.t. the parts related to Web= Finger.
> > WebFinger did built upon the host-meta spec, which is that we see= the
> > "two step" process. =A0However, the "resource"= ; parameter MUST be
> > supported by WebFinger servers. =A0As such, this eliminates most = of the
> > complexity issues on the client side.
> >
> > To your comments specifically,
> >
> > 1) XRD and JRD support: this is only required on the server. The<= br> > > client can choose what it wants. =A0This is largely historical, b= ut I'm
> > not shy to say that I favor XML. =A0I respect that some prefer JS= ON,
> though.
> >
>
> Why should there be a choice at all? Just choose one and be done with<= br> > it... preferably the least complicated of the two
> (http://www.xprogramming.com/Practices/PracSimplest.html)

This is due to the relatively recent shift in the "preferred syn= tax de jour". =A0When the work on WebFinger and host-meta started, XML= was considered the lingua franca of the Internet. =A0Interest in JSON was = growing, but still had not reached critical mass. =A0By the time RFC 6415 w= as nearing publication, interest in JSON had grown to a point where the aut= hors felt it needed inclusion, so a JSON version of XRD (called JRD) was de= fined in RFC 6415.

They're both trivial syntaxes. =A0Since JSON lacks a formal syntax spec= ification
, JRD is defined with respect to XRD, which is in turn defined= using XML Schema. =A0JRD is definitely most interesting to people right no= w, but XRD is already implemented in the wild. =A0Personally, I prefer XRD = and see no particular advantage in using JRD. =A0(JSON works well in JavaSc= ript applications, so I appreciate why people would like to use it. =A0In C= ++, though, present roughly the same work to utilize.)

XRD and JRD are defined in RFC 6415. =A0They exist and so I do not see any = reason to exclude one in favor of the other. =A0Writing the server code to = support both is a trivial exercise, so why remove one arguing that it's= complex? =A0It's not.

> > 2) Two-step HTTP request process: Requests could be a single step= . =A0No
> > client is required to implement a two-step request, ever. =A0The<= br> > > two-step option exists, since WebFinger is an extension of RFC 64= 15,
> > but the "resource" makes the query a one-step operation= .
> >
>
> Yup... I made sure to point this out clearly in my note. If, as you sa= y,
> clients are not ever required to implement the two-step flow, then why= is
> it defined at all? Why add the additional complexity? This was one of = the
> main points of my document and my counter proposal for /.well-known/in= dex
> ... the RFC6415 requirement seems entirely superfluous to achieving th= e
> goal.

Host-Meta / WebFinger allows for one to query information related to = a host and to specific resources controlled by that host. =A0So, a client c= an make a query and learn something about the host. =A0One can then make a = second query and learn about a particular resource at that host. =A0Alterna= tively, if information about the host is not of interest, one can make a si= ngle query and ask for information about the resource directly.

We could re-write RFC 6415 and say that if the "resource" paramet= er is not there, only return host-specific link relations (versus URI templ= ates). =A0However, there is no point in re-writing writing what is defined = and implemented. =A0That's especially true given how simple and consist= ent the logic is when implementing the host-meta / WebFinger server code.

> > 3) There are several sub-parts:
> >
> > 3a) The WebFinger protocol defines normative dependencies on no f= ewer
> > than ten separate specifications: that's being a bit unfair. = We tried
> > to be thorough with documenting material. =A0We could perhaps mak= e
> > .well-known, web linking, URI syntax, and mailto URI informative.= =A0We
> > could discuss where those references should live, but HTTP and XR= D/JRD
> > are really the core part of WebFinger. =A0It's not so complex= as you
> suggest here.
> >
> > 3b) A WebFinger client needs to not only be capable of sending HT= TP
> > requests; but capable of parsing XML or JSON: They must parse one= of
> > the two. This is pretty basic.
> >
> > 3c) Capable of understanding the specific XRD and JRD vocabularie= s:
> > there are no "specific" vocabularies, just XRD and JRD = syntax. Both
> > are simple and a client picks what it wants.
> >
> > 3d) Capable of processing URL Templates: since "resource&quo= t; is
> > mandatory, a client does not need to deal with templates
>
> I think you may have missed the key point I was making: XML, JSON, XRD= ,
> JRD, URL templates, Digital Signatures, host-meta.. these are all thin= gs
> that WebFinger says are required without providing any reasonable
> justification as to WHY they are required. Both the Simple Web Discove= ry
> draft and my /.well-known/index examples illustrate that we can easily=
> solve the fundamental problem with a whole lot less than what WebFinge= r
> defines... even if those things are -- by your own statement -- only t= here
> for "spec completeness".

Your draft and SWD just use a different syntax. =A0They do not elimin= ate syntax. =A0One way or the other, we must have syntax.

XRD and JRD are required, because RFC 6415 (which is the basis for WebFinge= r) defined XRD and JRD. =A0RFC 6415 is something this group just completed = in October 2011, I'll note.

Signatures on XRD are optional and I doubt anybody will do it, anyway. =A0I= suspect the folks in OASIS did that just for completeness. =A0I'm cert= ainly not going to ever bother with them. =A0People should use HTTPS and be= done with it.

URI templates are useful to RFC 6415 and those who elect to not use the &qu= ot;resource" parameter. =A0Using the "resource" parameter, o= ne never sees URI templates. =A0However, they exist because they are define= d in RFC 6415 to allow for querying resource-specific link relations.

So what does it take to create a WebFinger server? =A0It's so trivial, = I can do it with static files. =A0When one can do that, that means it's= not that complex. =A0See here for an example:
http://www.packetizer.com/webfinger/server.html

> > 3e) Capable of processing XML digital signatures included within = an
> > XRD
> > document: yeah, if HTTPS is not used. I doubt anybody will use > > signatures in favor of HTTPS. =A0I suspect no client will process= the
> signatures, either.
> > (There is "standards completeness" and reality.)
> >
> > 4) WebFinger uses email-like identifiers and this is a privacy co= ncern:
> > email-like IDs are suggested to make WebFinger easy to use *by > > humans*, but there is definitely no requirement that one MUST use=
> > "acct:paulej= @packetizer.com". =A0One can use any valid URI. =A0An
> > enterprise could use some cryptic URI. =A0The recommendation to u= se
> > paulej@packetizer.com, for example, it to make your life easier if you
> > want to learn more about me. =A0What is actually exposed and what= is
> > accessible is a matter of the publisher of that content and can b= e
> > secured using standard web security mechanisms. =A0Note that use = of
> > HTTPS also hides the email-like ID, too, so it's not seen on = the wire,
> > so I'm really not sure why you're concerned with this. = =A0Those who want
> security will use TLS.
>
> Several things with this one...
>
> 1. All of the examples that deal with people show the use of acct
> identifiers. From experience, I know that developers will generally lo= ok
> at the examples in the spec before they look at the spec text itself a= nd
> they will generally follow whatever pattern is illustrated... Simply > saying that "some cryptic URI" could be used does not suffic= iently deal
> with the issue. Support for hashed or otherwise obfuscated identifiers=
> within the request URI should be made explicit .. either via clear exa= mple
> or by normative requirement.

Not all examples use "acct", though most certainly do= . =A0There are three examples using "http" and one using a fictit= ious "device".

If one uses TLS, this is a non-issue, anyway. =A0When TLS is used, identifi= ers are never seen outside the application. =A0Even if TLS was not used, I&= #39;m still not sure why hiding one's identifier is a concern when we&#= 39;re also perfectly OK with returning information about people in the clea= r or making it public in the first place :-)

> 2. The use of SSL/TLS does not prevent request URIs from being recorde= d in
> log files, exposed in browsers, or compromised in a variety of unfores= een
> ways. Yes, it protects the data in transit but protects nothing when t= he
> data is at rest.

The server that would be responding to requests would be the one that= would be recording stuff in log files when using TLS. =A0It already knows = about these IDs and could certainly translate an obfuscated value into a re= al value and log requests that way. =A0Exposed in browsers? =A0Users will t= ype in "paulej@packetizer.com= ", so it's already in a browser. =A0If one wants to use someth= ing with WF that does not look like an email address, they can.

> > So just to reiterate, a WebFinger request for this URL:
> >
> > https://packetizer.com/.well-known/ho= st-meta.json?resource=3Dacct:paulej
> > @packe
> > tizer.com
> >
> > Typically looks like this:
> >
> > GET /.well-known/host-meta.json?resource=3Dacct:paulej@packetizer.com
> > HTTP/1.1
> > Host: packeti= zer.com
> >
> > The reply might have this body:
> >
> > {
> > =A0 "subject" : "acct:paulej@packetizer.com",
> > =A0 "links" :
> > =A0 [
> > =A0 =A0 {
> > =A0 =A0 =A0 "rel" : "http://webfinger.net/rel/avatar",=
> > =A0 =A0 =A0 "href" :
> "http://www.packetizer.com/people/paulej/images/paul= ej.jpg"
> > =A0 =A0 },
> > =A0 =A0 {
> > =A0 =A0 =A0 "rel" : "http://specs.openid.net/auth/2.0= /provider",
> > =A0 =A0 =A0 "href" : "https://openid.packetizer.com/paulej= "
> > =A0 =A0 },
> > =A0 =A0 {
> > =A0 =A0 =A0 "rel" : "http://webfinger.net/rel/profile-pag= e",
> > =A0 =A0 =A0 "href" : "http://www.packetizer.com/people= /paulej/"
> > =A0 =A0 },
> > =A0 =A0 {
> > =A0 =A0 =A0 "rel" : "vcard",
> > =A0 =A0 =A0 "href" : "http://www.packetizer.= com/people/paulej/paulej.vcf"
> > =A0 =A0 },
> > =A0 =A0 {
> > =A0 =A0 =A0 "rel" : "http://schemas.google.com/g/= 2010#updates-from",
> > =A0 =A0 =A0 "href" : "http://www.packetiz= er.com/people/paulej/blog/blog.xml"
> > =A0 =A0 }
> > =A0 ]
> > }
> >
> > That's a fairly simple request / response, IMO.
> >
>
> And an alternative approach would look like.. (the numbers are the
> sha-256 digest of the acct id)
>
> GET /.well-
> known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97= b1d7
> f8
> HTTP/1.1
> Host: packetizer.c= om
>
> HTTP/1.1 300 Multiple Choices
> Link: </people/paulej/images/paulej.jpg>;
> rel=3D"http://webfinger.net/rel/avatar",
> =A0 <https://openid.packetizer.com/paulej>;
> rel=3D"http://specs.openid.net/auth/2.0/provider",
> =A0 </people/paulej/>; rel=3D"http://webfinger.net/rel/profile.pag= e",
> =A0 </people/paulej/paulej.vcf>; rel=3D"vcard",
> =A0 </people/paulej/blog/blog.xml>;
> rel=3D"http://schemas.google.com/g/2010#updates-from"
This is just another syntax, as I said. =A0Also, I personally f= ind this more challenging to deal with since it's in the headers, not t= he payload.

Might the web server itself want to introduce a Link header or perhaps a we= b proxy? =A0One might get back information that was not strictly about the = resource being queried. =A0(For example, a link to a copyright statement or= "authorized users" statement or other.)

> And if all I want is the location of the avatar, for instance, it coul= d be
> even easier...
>
> GET /.well-
> known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97= b1d7
> f8/avatar
> HTTP/1.1
> Host: packetizer.c= om
>
> HTTP/1.1 302 Found
> Location: /people/paulej/images/paulej.jpg

So, I get a 302 and don't know why. =A0Am I being redirected beca= use the user's information moved or because the information I seek is l= ocated there? =A0Web browsers will not even tell me about 302s when writing= JavaScript code, AFAIK. =A0So, I might issue a query to get several things= (e.g., calendar and avatar), but only an avatar exists. =A0The server retu= rns a 302 and I get a payload with a picture and have no idea what it is fo= r. =A0Or would you return a 200 in that case with a single "Link:"= ; href/rel pair?

> Why should I, as the client, ever have to worry about XRD/JRD at all?<= br> > This is an important question that I have not yet seen an adequate ans= wer
> for. Anyone who has worked with me before on things knows that with so= lid
> examples and a reasonable explanation I can be swayed to see the light= and
> the error of my ways. So far, however, I am just not seeing it here.
Because this is a very simple and consistent syntax that nicely packa= ges up a set of link relations and properties. =A0I might also provided wit= h a list of aliases for the user/target.

We had a separate dialog about how we could use the JRD syntax to convey pr= ovisioning information related to mail servers. =A0I'm not sure if anyo= ne would do that, but having the ability to include additional properties i= s nice, since it allows for a richer set of information to be conveyed.

Lastly, having an XRD or JRD in hand allows that document to be passed &quo= t;down the line" for processing. =A0Headers in HTTP could, too, but as= I said, it's an alternate syntax that is less complete and I personall= y find dealing with a returned payload simpler than putting valuable respon= se information in headers.

Paul

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

--bcaec53ae9ee32884e04c49dc5b2-- From alexey.melnikov@isode.com Thu Jul 12 03:09:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8042B21F87B8 for ; Thu, 12 Jul 2012 03:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.986 X-Spam-Level: X-Spam-Status: No, score=-102.986 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVJTdtyNal0Z for ; Thu, 12 Jul 2012 03:09:09 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id A3BF821F87B7 for ; Thu, 12 Jul 2012 03:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342087781; d=isode.com; s=selector; i=@isode.com; bh=Nev2CyRu95Kau3bAN3/WTcHrOGRAGOOtxkdyNTx+zMI=; 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=ZadmGVLt98LeBgrhWC2/3OyziTN0o+L5msfaQeOGP9G82UcgqRMjBkpSBH9mz/CKsLl8Q2 Yy9iwJzwZ8QnI2h6NEQaQ5Wliy9QTecvruxbP/Ad2maxWk+prWdDeBvvzLMrf0UqC/r5/B ejNJKtGlyfPd25l0uMYIe3MRLhIsPsQ=; Received: from [192.168.1.144] ((unknown) [62.3.217.253]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 12 Jul 2012 11:09:41 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING Message-ID: <4FFEA279.5020909@isode.com> Date: Thu, 12 Jul 2012 11:10:01 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Joseph Yee References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, draft-melnikov-smtp-priority-tunneling.all@tools.ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-melnikov-smtp-priority-tunneling-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2012 10:09:10 -0000 Hi Joseph, Thank you for the review and sorry for the late response. On 22/06/2012 22:48, Joseph Yee wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate > ). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-melnikov-smtp-priority-tunneling-02 > Title: Tunneling of Message Transfer Priorities > Reviewer: Joseph Yee > Review Date: 2012-06-22 > > Summary: > > This draft is ready for publication as an Experimental RFC. > > Major Issues: > > none > > Minor Issues: > > none > > Nits: > > (1) > At section 1 Introduction, the text in third paragraph talks > about unextended MUA in scenario 2, but in the detailed description at > 5th paragraph, it says "The client is extended via a plugin.....". > Although the text meant many MUA plugin do not cover SMTP protocol > features, the word "extended" in detailed description has some > confusion. Suggest to change it to "The client is extendable via > ...." Thanks, changed. > (2) > Section 1 Introduction, 3rd paragraph, typo > s/scenarious/scenarios/ Fixed, thanks. > (3) > Several references (Normative References) were not used. > Although some textes "touched" keywords like 'MSA', it did not cite > specific rules or concepts. So either add the reference back in text > or remove the references work, IMHO. > - [RFC2034] > - [RFC5321] > - [RFC5248] > - [RFC6409] Good point. I will eliminate some of these and will reference the others. From laurentwalter.goix@telecomitalia.it Thu Jul 12 21:54:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C8C21F865A; Thu, 12 Jul 2012 21:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.232 X-Spam-Level: X-Spam-Status: No, score=-0.232 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUdq+CxPzyZR; Thu, 12 Jul 2012 21:54:44 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id C34CA21F864E; Thu, 12 Jul 2012 21:54:43 -0700 (PDT) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Fri, 13 Jul 2012 06:55:16 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Fri, 13 Jul 2012 06:55:16 +0200 From: Goix Laurent Walter To: "apps-discuss@ietf.org" , "enum@ietf.org" Date: Fri, 13 Jul 2012 06:55:04 +0200 Thread-Topic: Enum service registration for acct: URI Thread-Index: Ac1gs7F4kwPzV7JaQq2sw0jvbygeHw== Message-ID: <31BE8A42-33A2-48FC-B787-F6338A9B8481@telecomitalia.it> Accept-Language: en-US, it-IT Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [apps-discuss] Enum service registration for acct: URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jul 2012 04:54:45 -0000 Hello all, I've just uploaded a new revision of the draft that proposes to register an= enum service for resolving phone numbers into acct: URIs. This revision builds on -01 draft that already incorporated feedback receiv= ed from the enum group, and mainly updates the references to the new split = of webfinger vs acct: uri. You can find it at http://tools.ietf.org/html/draft-goix-appsawg-enum-sn-se= rvice-02 I very much welcome your feedback on this new revision. Regards Walter Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From stpeter@stpeter.im Fri Jul 13 09:19:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C577A21F8653; Fri, 13 Jul 2012 09:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPoZO1KG27hk; Fri, 13 Jul 2012 09:19:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2083121F8629; Fri, 13 Jul 2012 09:19:11 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C772740075; Fri, 13 Jul 2012 10:38:34 -0600 (MDT) Message-ID: <50004AA1.90903@stpeter.im> Date: Fri, 13 Jul 2012 10:19:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Goix Laurent Walter References: <31BE8A42-33A2-48FC-B787-F6338A9B8481@telecomitalia.it> In-Reply-To: <31BE8A42-33A2-48FC-B787-F6338A9B8481@telecomitalia.it> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "enum@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Enum service registration for acct: URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jul 2012 16:19:12 -0000 Seems reasonable, thanks for working on this! On 7/12/12 10:55 PM, Goix Laurent Walter wrote: > Hello all, > > I've just uploaded a new revision of the draft that proposes to register an enum service for resolving phone numbers into acct: URIs. > This revision builds on -01 draft that already incorporated feedback received from the enum group, and mainly updates the references to the new split of webfinger vs acct: uri. > > You can find it at http://tools.ietf.org/html/draft-goix-appsawg-enum-sn-service-02 > > I very much welcome your feedback on this new revision. > > Regards > Walter From ned.freed@mrochek.com Fri Jul 13 18:23:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243D811E80A4 for ; Fri, 13 Jul 2012 18:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPP0OtYyVIke for ; Fri, 13 Jul 2012 18:23:15 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 198AF11E8085 for ; Fri, 13 Jul 2012 18:23:15 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHT735TP0G005AK1@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 13 Jul 2012 18:18:48 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHQN2U9IY80006TF@mauve.mrochek.com>; Fri, 13 Jul 2012 18:18:44 -0700 (PDT) Message-id: <01OHT7332FMS0006TF@mauve.mrochek.com> Date: Fri, 13 Jul 2012 18:17:18 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 11 Jul 2012 18:40:07 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120711114411.694627c5@hetzer> <4FFD5000.8010908@gmx.de> <4FFD9713.7060006@dcrocker.net> <01OHPTP7PS260006TF@mauve.mrochek.com> To: Mateusz Karcz Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jul 2012 01:23:16 -0000 > So I had to: > 1. Add references to HTTP specification. > 2. Simply syntax definition. > 3. Separate issue definition and actual problems definition. > 4. Write Security Considerations. > 5. Change form of draft from standarising to proposing. > 6. Find examples of errors, which are result of ambiguous strings. > 7. Change order of elements in draft. > 8. Think two times about sense of that project. I'm sorry to have to say it, but this completely misses the main point of what I was suggesting. My suggestion was to write a document that was first about the issues in general that arise from use of the User-Agent string, and only secondarily about how a subset of those issues can be addresses by nailing down the syntax. Ned From stpeter@stpeter.im Mon Jul 16 08:04:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6E421F8799 for ; Mon, 16 Jul 2012 08:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gql2qTReyFa1 for ; Mon, 16 Jul 2012 08:04:42 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7143E21F870E for ; Mon, 16 Jul 2012 08:04:41 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E535240075; Mon, 16 Jul 2012 09:24:21 -0600 (MDT) Message-ID: <50042DB3.40401@stpeter.im> Date: Mon, 16 Jul 2012 09:05:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Nottingham References: <20120705022204.29179.82506.idtracker@ietfa.amsl.com> <87D923B1-0931-4336-ABF1-A5D1B0C495BE@mnot.net> In-Reply-To: <87D923B1-0931-4336-ABF1-A5D1B0C495BE@mnot.net> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-nottingham-json-home-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 15:04:43 -0000 On 7/4/12 8:28 PM, Mark Nottingham wrote: >> Abstract: >> This document proposes a "home document" format for non-browser HTTP >> clients. Hi Mark, this approach seems eminently sensible. I was expecting you to also define a well-known URI at which to find home documents, but it's not in the spec and I'm wondering why. :) Peter -- Peter Saint-Andre https://stpeter.im/ From dhc@dcrocker.net Mon Jul 16 08:08:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625EB21F8498 for ; Mon, 16 Jul 2012 08:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcRirQQuOc5b for ; Mon, 16 Jul 2012 08:08:22 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B414D21F8480 for ; Mon, 16 Jul 2012 08:08:22 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6GF96KI002478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Jul 2012 08:09:06 -0700 Message-ID: <50042E85.6050100@dcrocker.net> Date: Mon, 16 Jul 2012 08:08:53 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ned Freed References: <20120711114411.694627c5@hetzer> <4FFD5000.8010908@gmx.de> <4FFD9713.7060006@dcrocker.net> <01OHPTP7PS260006TF@mauve.mrochek.com> <01OHT7332FMS0006TF@mauve.mrochek.com> In-Reply-To: <01OHT7332FMS0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 16 Jul 2012 08:09:07 -0700 (PDT) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:08:23 -0000 On 7/13/2012 6:17 PM, Ned Freed wrote: > My suggestion was to write a document > that was first about the issues in general that arise from use of > the User-Agent string, and only secondarily about how a subset of those > issues can be addresses by nailing down the syntax. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Mon Jul 16 14:20:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45CC11E819D for ; Mon, 16 Jul 2012 14:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUBJkDITb83O for ; Mon, 16 Jul 2012 14:20:59 -0700 (PDT) Received: from dynmail-01-mht.dyndns.com (dynmail-01-mht.dyndns.com [216.146.45.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4906D11E814E for ; Mon, 16 Jul 2012 14:20:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dynmail-01-mht.dyndns.com (Postfix) with ESMTP id 7CA2D12D09E4 for ; Mon, 16 Jul 2012 17:21:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at dynmail-01-mht.dyndns.com Received: from dynmail-01-mht.dyndns.com ([127.0.0.1]) by localhost (dynmail-01-mht.dyndns.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd8m2uU2Dpwv for ; Mon, 16 Jul 2012 17:21:42 -0400 (EDT) Received: from dyn.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) by dynmail-01-mht.dyndns.com (Postfix) with ESMTPSA id 283E712D09E1 for ; Mon, 16 Jul 2012 17:21:42 -0400 (EDT) Date: Mon, 16 Jul 2012 17:21:41 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20120716212141.GP96149@dyn.com> References: <20120716204725.9601.71787.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120716204725.9601.71787.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] New Version Notification for draft-sullivan-domain-origin-assert-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 21:21:00 -0000 Dear colleagues, On Mon, Jul 16, 2012 at 01:47:25PM -0700, internet-drafts@ietf.org wrote: > > Filename: draft-sullivan-domain-origin-assert > Revision: 01 > Title: Asserting DNS Administrative Boundaries Within DNS Zones > Creation date: 2012-07-16 > WG ID: Individual Submission > Number of pages: 16 > URL: http://www.ietf.org/internet-drafts/draft-sullivan-domain-origin-assert-01.txt > Status: http://datatracker.ietf.org/doc/draft-sullivan-domain-origin-assert > Htmlized: http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-01 > Diff: http://tools.ietf.org/rfcdiff?url2=draft-sullivan-domain-origin-assert-01 I uploaded a revision of the above draft; the -00 was discussed on this list some time ago. This version attempts to deal with a number of concerns people raised. Other highlights: * Changed the mnemonic from BOUND to AREALM * Added ports and scheme to the RRTYPE * Added some motivating text and suggestions about what can be done with the new RRTYPE * Removed use of "origin" term, because it was confusing. The document filename preserves "origin" in the name in order that the tracker doesn't lose the change history, but that's just a vestige. * Removed references to cross-document information sharing and ECMAScript. I don't understand the issues there, but Maciej Stachowiak convinced me that they're different enough that this mechanism probably won't work. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From internet-drafts@ietf.org Mon Jul 16 16:30:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F92D11E82CF; Mon, 16 Jul 2012 16:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qO9DTQsIokcW; Mon, 16 Jul 2012 16:30:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4E511E82B8; Mon, 16 Jul 2012 16:30:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716233034.25125.79613.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 16:30:34 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-suffix-regs-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 23:30:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Additional Media Type Structured Syntax Suffixes Author(s) : Tony Hansen Filename : draft-ietf-appsawg-media-type-suffix-regs-02.txt Pages : 11 Date : 2012-07-16 Abstract: A content media type name sometimes includes partitioned meta- information distinguish by a Structured Syntax, to permit noting an attribute of the media as a suffix to the name. This document defines several Structured Syntax Suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax Suffixes, and updates the "+xml" Message Type Structured Syntax Suffix registration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-suffix-regs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-media-type-suffix-r= egs-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mnot@mnot.net Mon Jul 16 16:41:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7063F11E8303 for ; Mon, 16 Jul 2012 16:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.229 X-Spam-Level: X-Spam-Status: No, score=-105.229 tagged_above=-999 required=5 tests=[AWL=-2.630, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Cyhfnp1YYij for ; Mon, 16 Jul 2012 16:41:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id EAEAA11E8300 for ; Mon, 16 Jul 2012 16:41:51 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BD7C122E253; Mon, 16 Jul 2012 19:42:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <50042DB3.40401@stpeter.im> Date: Tue, 17 Jul 2012 09:42:25 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <0497210C-8620-44EF-827F-6111CA25FE9D@mnot.net> References: <20120705022204.29179.82506.idtracker@ietfa.amsl.com> <87D923B1-0931-4336-ABF1-A5D1B0C495BE@mnot.net> <50042DB3.40401@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-json-home-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 23:41:53 -0000 On 17/07/2012, at 1:05 AM, Peter Saint-Andre wrote: > On 7/4/12 8:28 PM, Mark Nottingham wrote: >=20 >>> Abstract: >>> This document proposes a "home document" format for non-browser = HTTP >>> clients. >=20 > Hi Mark, this approach seems eminently sensible. I was expecting you = to > also define a well-known URI at which to find home documents, but it's > not in the spec and I'm wondering why. :) I go back and forth on it.=20 A few people have been encouraging me to do so, but I tend to think it = sends the wrong message; that a hostname should always have just one = home document, when there might be several views co-located on the same = server (segregated by usage profile, user groups, "alternate views", = etc.). E.g., I believe that "versioning" an API should involve minting a new = home document, and serving both side-by-side for a period. If home = documents are per-URI, this is easy; it just means pointing people to = or or whatever, whereas using a = .well-known means that they HAVE to use a new hostname. OTOH it's really powerful to "mix and match" a lot of different APIs = into one home document, presenting a unified view, and that's one of the = big use cases for the spec. A well-known would help with this. In short, I'm still thinking about it, and what kinds of language I'd = put around it; that's why it didn't make it into the recent rev. Any input on either side would be most welcome. Cheers, -- Mark Nottingham http://www.mnot.net/ From superuser@gmail.com Mon Jul 16 21:45:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9471721F84FD for ; Mon, 16 Jul 2012 21:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umo9EYj7cM0S for ; Mon, 16 Jul 2012 21:45:17 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 108D311E8087 for ; Mon, 16 Jul 2012 21:45:16 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so109089lbb.31 for ; Mon, 16 Jul 2012 21:46:02 -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=LbcScRN8sAAE3l1tKjVXW2uF7Leageac8ZxugMridiI=; b=TeY1WCPqKRb0Hio/hRDsVMpJ3mnNvx7EVYT065Xloeka5T4ctbx+gFYtWS0ZwFCKV8 OlCDwyvodjPHr/660saR59l9rax5/5PdNVwFl/t0V/lKpucNxC6QzSj3ZqZ5vhARo4yT Yy+lv0AGieecgP5TrPR5ZQrdKnX7dRckNTr6nAWqdMtli04NLBJB0S9ErBi6yY+BTW+Y gaa8bNTkwpYuE2B7CQAqc0zghXvsm87l4yZFqY+5NL/Iide1YKlS2XC7Uyd347RbXmjT mI+3c4obKreEFfFsSDjEwKLgTtQc3wieJ/mHc4qGDsVSwrye2guV7HLbk0+AgqwZXdZv jOKw== MIME-Version: 1.0 Received: by 10.152.112.138 with SMTP id iq10mr982529lab.13.1342500362721; Mon, 16 Jul 2012 21:46:02 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 16 Jul 2012 21:46:02 -0700 (PDT) Date: Mon, 16 Jul 2012 21:46:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d0408da073b1a8004c4ff39db Subject: [apps-discuss] Agenda for IETF 84 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2012 04:45:23 -0000 --f46d0408da073b1a8004c4ff39db Content-Type: text/plain; charset=ISO-8859-1 I have just emailed everyone that made a request to be on the APPSAWG/APPAREA agenda, and also people we're inviting to present (e.g., BoF chairs) to confirm topics, times, and schedules. The deadline for us to submit an agenda is Wednesday, so: (a) If you got the email, please reply as soon as possible with the requested confirmation; and (b) If you didn't get the email but should, please let me know immediately. Thanks, -MSK, APPSAWG co-chair --f46d0408da073b1a8004c4ff39db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have just emailed everyone that made a request to be on the APPSAWG/APPAR= EA agenda, and also people we're inviting to present (e.g., BoF chairs)= to confirm topics, times, and schedules.=A0 The deadline for us to submit = an agenda is Wednesday, so:

(a) If you got the email, please reply as soon as possible with the req= uested confirmation; and

(b) If you didn't get the email but sho= uld, please let me know immediately.

Thanks,

-MSK, APPSAWG co= -chair

--f46d0408da073b1a8004c4ff39db-- From tony@att.com Mon Jul 16 22:25:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B013211E80BB for ; Mon, 16 Jul 2012 22:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jk-Zr7T3UleO for ; Mon, 16 Jul 2012 22:25:49 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 6861A11E80B7 for ; Mon, 16 Jul 2012 22:25:49 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id b87f4005.0.418553.00-479.1144615.nbfkord-smmo04.seg.att.com (envelope-from ); Tue, 17 Jul 2012 05:26:36 +0000 (UTC) X-MXL-Hash: 5004f78c1bc0be20-40afee9dc724e0b7d6e95abc315daf01c45b1964 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6H5QZxf019102 for ; Tue, 17 Jul 2012 01:26:35 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6H5QVtt019094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Jul 2012 01:26:31 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Tue, 17 Jul 2012 01:26:13 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q6H5QD2t025917 for ; Tue, 17 Jul 2012 01:26:13 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q6H5Q700025607 for ; Tue, 17 Jul 2012 01:26:09 -0400 Received: from [135.70.3.91] (vpn-135-70-3-91.vpn.west.att.com[135.70.3.91]) by maillennium.att.com (mailgw1) with ESMTP id <20120717052145gw100n9823e> (Authid: tony); Tue, 17 Jul 2012 05:21:46 +0000 X-Originating-IP: [135.70.3.91] Message-ID: <5004F76C.8070406@att.com> Date: Tue, 17 Jul 2012 01:26:04 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Nottingham References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=23gnTRy6nFgA:10 a=cgbV5Ep4loIA:10 a=ScEQJRfK2-] X-AnalysisOut: [EA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1] X-AnalysisOut: [0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=pGLkceISAAAA:8 a=48vgC7m] X-AnalysisOut: [UAAAA:8 a=wvn1p7I7AAAA:8 a=StVF-2MF5GjR1ZzEUZAA:9 a=wPNLvf] X-AnalysisOut: [GTeEIA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10] Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2012 05:25:50 -0000 Mark, the suffix-regs doc is mostly trying to document the rules under which existing suffixes have been informally permitted in the past and provide a more formal basis for them to be used in the future. Except for +ber, +der and +zip, there are already examples of the other suffixes mentioned in this document. For example, in addition to all of the +xml media types, consider all of these media types that are already being used: application/soap+fastinfoset application/vnd.collection+json application/vnd.hal+json application/vnd.oftn.l10n+json application/vnd.nokia.conml+wbxml application/vnd.nokia.landmark+wbxml application/vnd.nokia.pcd+wbxml application/vnd.syncml.dm+wbxml application/vnd.wv.csp+wbxml You ask about the guidance being provided to the Expert Reviewers in the media type registry document. That advice is expanded on by the media-type-suffix-regs document; Expert Reviewers should consider both pieces of guidance. (One can argue that the additional guidance in this document should have been in the other document; for various reasons it didn't happen.) And yes, the gateway is being protected by an Expert Reviewer. But that's been true for them in the past, as well as all of the media types in general. I don't see anyone being to drive a tank through that gateway any more easily now than they have in the past. As an example of a recently proposed media type suffix that did *not* pass muster, consider +exi. Tony Hansen On 6/25/2012 1:52 AM, Mark Nottingham wrote: > I still haven't seen a satisfying answer to my questions about how this is actually going to be used. They may be out there, but I can't escape the feeling that people are going along with this because it "seems like a good idea", and I'm concerned that the implications of allowing a multitude of suffixes -- thereby effectively adding another dimension of identity to our format identifiers -- hasn't been properly considered. > > I'm especially concerned because, as I noted in my review of the media type registrations document, there isn't any discussion of appropriate vs. inappropriate use in this registry; the only guidance given to the experts for this registry is: > >> The primary guideline for whether a structured type name suffix is >> registrable is that it be described by a readily-available >> description, preferably within a document published by an established >> standards organization, and for which there's a reference that can be >> used in a Normative References section of an RFC. > Now, if that isn't a hole that you can drive a tank through, I don't know what is (BTW, the media types registration document doesn't even explicitly specify a policy for this registry; it appears to be Expert Review). > > E.g., the recent +merge-patch suffix proposal. If James had chosen to pursue that, on what grounds could the Expert (whoever that will be) reject the proposal? > > I realise this document is only a shell for registering the suffixes, rather than their registration, but I still haven't seen any meaningful response to the concerns that I brought up, first in review of the media type registrations document, and later in separate e-mail. > > Regards, > > > On 20/06/2012, at 4:15 PM, Murray S. Kucherawy wrote: > >> On Mon, Jun 11, 2012 at 5:25 AM, Murray S. Kucherawy wrote: >> This note begins a Working Group Last Call on draft-ietf-appsawg-media-type-suffix-regs, ending Monday, June 25. Please review the document and comment on it. >> >> Note that its "parent" document, draft-ietf-appsawg-media-type-regs, is now in IESG Evaluation. >> >> >> A reminder that this WGLC closes in less than a week. Please review the document and send your comments soon. >> >> Thanks, >> -MSK, APPSAWG co-chair >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From tony@att.com Mon Jul 16 22:28:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F2221F8608 for ; Mon, 16 Jul 2012 22:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkRB-XacAmCN for ; Mon, 16 Jul 2012 22:28:41 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 49ED221F8606 for ; Mon, 16 Jul 2012 22:28:41 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 738f4005.0.255065.00-368.715255.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 17 Jul 2012 05:29:28 +0000 (UTC) X-MXL-Hash: 5004f8384e3e1db9-b22d74f28b2162aa338d96debd2c320ff508456b Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6H5TRSZ019662 for ; Tue, 17 Jul 2012 01:29:27 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6H5TOg6019653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Jul 2012 01:29:25 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Tue, 17 Jul 2012 01:29:03 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q6H5T3KF030478 for ; Tue, 17 Jul 2012 01:29:03 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q6H5T0Ld030233 for ; Tue, 17 Jul 2012 01:29:00 -0400 Received: from [135.70.3.91] (vpn-135-70-3-91.vpn.west.att.com[135.70.3.91]) by maillennium.att.com (mailgw1) with ESMTP id <20120717052438gw100n9825e> (Authid: tony); Tue, 17 Jul 2012 05:24:39 +0000 X-Originating-IP: [135.70.3.91] Message-ID: <5004F819.2050506@att.com> Date: Tue, 17 Jul 2012 01:28:57 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Henry S. Thompson" References: <4FE33B5F.4020205@isode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=23gnTRy6nFgA:10 a=cgbV5Ep4loIA:10 a=ScEQJRfK2-] X-AnalysisOut: [EA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:1] X-AnalysisOut: [0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=mXIEBzQlRjDac3gD9EoA:9 a] X-AnalysisOut: [=wPNLvfGTeEIA:10] Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2012 05:28:42 -0000 I incorporated this text almost verbatim into draft-ietf-appsawg-media-type-suffix-regs-02. Tony Hansen On 6/21/2012 2:48 PM, Henry S. Thompson wrote: > I didn't read it that way. It quite specifically circumscribes what a > particular xxx+json registration should do. The phrasing is perhaps a > little too concise. I believe what we should be aiming for, which I > believe this is trying to say, consistent with the best practices under > development by the W3C TAG, is as follows > > a) Syntax and semantics of fragids specified for +SUF should be same > as specified for xxx/SUF > b) Syntax and semantics for fragids for a specific xxx/yyy+SUF as > follows: > b1) For cases defined in +SUF, where the fragid resolves per > the +SUF rules, then as specified in +SUF > b2) For cases defined in +SUF, where the fragid _doesn't_ resolve per > the +SUF rules, then as specified in xxx/yyy+SUF > b3) For cases not defined in +SUF, then as specified in xxx/yyy+SUF > > Is that better? > > ht From michiel@unhosted.org Tue Jul 17 01:22:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAA321F8631 for ; Tue, 17 Jul 2012 01:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efae7oKoLmeY for ; Tue, 17 Jul 2012 01:22:39 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C716B21F8634 for ; Tue, 17 Jul 2012 01:22:38 -0700 (PDT) Received: by yhq56 with SMTP id 56so134378yhq.31 for ; Tue, 17 Jul 2012 01:23:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=1uzmz4CepY/4LxrxzYdzC3l7qxzKv5vxluau6AeX7v4=; b=jpB1todZro3+AF9fcyAT/nP1lHPPvQSOVAYWzAJzye9zROKneqEcxpBr9/deg5bnWt NCRNEOfuNjYyw7bJYBDItH171QZrwcC2OHrmnvDtrI/eg6x+u9vSKvRngpeAGlq0UzdS u5Ain2vb7lWvdVKRtb0s161myhINK6IBKnfk0UTpx31xl+JP9tn19KzJd9lfFplCw6KH B3K0h6vt0bw//vWqYzzOcK8UR+YH/F1BIWGEVgKMT5elNt8r8X0QVjNZ6GsWAQVaqNUY Y6x+Z0HTe9F2QdKkxFZkLYf6IZisxVCAadVAEZ+uOoWgIKYp9UzvNRvFHb+Fld8VVZI1 WzVw== MIME-Version: 1.0 Received: by 10.66.85.231 with SMTP id k7mr3444662paz.76.1342513404749; Tue, 17 Jul 2012 01:23:24 -0700 (PDT) Received: by 10.142.10.4 with HTTP; Tue, 17 Jul 2012 01:23:24 -0700 (PDT) X-Originating-IP: [89.247.181.2] In-Reply-To: <0497210C-8620-44EF-827F-6111CA25FE9D@mnot.net> References: <20120705022204.29179.82506.idtracker@ietfa.amsl.com> <87D923B1-0931-4336-ABF1-A5D1B0C495BE@mnot.net> <50042DB3.40401@stpeter.im> <0497210C-8620-44EF-827F-6111CA25FE9D@mnot.net> Date: Tue, 17 Jul 2012 10:23:24 +0200 Message-ID: From: Michiel de Jong To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkv089a3ft3yC8LI+aLtaGijh5y2rFudyhsKcNgN7qCBymK6jyyut6If28f0MiG1PyR3Kfu Cc: IETF Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-json-home-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2012 08:22:40 -0000 hi! i'm following this work with much interest. imho a well-known URI is not immediately useful for the use case i'm imagining, which is client developers using a generic code library for handling the interaction with the API. We already see this now with OAuth, there are OAuth client libraries in all popular languages that a programmer can use to easily build a client for something. These libraries take configuration files that are not human-memorable. An example i found for one such library: OAuthClientRequest request =3D OAuthClientRequest .authorizationLocation("https://graph.facebook.com/oauth/author= ize") .setClientId("your-facebook-application-client-id") .setRedirectURI("http://www.example.com/redirect") .buildQueryMessage(); These libraries are already useful, even though their config is not human-memorable. You have to spend some time installing such a library into your project anyway, and learning how to work with it, so whether you then paste a json-home URL or only a domain name into the code that you build around such a library, is then a triviality. imho, a well-known URI would be useful where the service provider is chosen at run-time. Two small comments that came to my mind when reading the doc: 1) i would love to have a way to make the relationship between the /widgets/ and /widgets/{widget_id} URLs explicit. It would require introducing the concept of items and collections, but I think many APIs already use those concepts at quite a low level in their design. Then, i could announce that a POST to a collection creates an item (returning e.g. either the newly created object with its id inside it in the body, or a Location: header to the newly created object). Right now i see how the client will have default expectations of what GET, PUT, DELETE and PATCH will do (namely, read, write, remove, modify), but i would not know how to define default expectations of what a POST would do (because we can't talk of inserting without talking of collections). 2) i think byte ranges are often supported for GET, even if they are not supported for PUT. Should we interpret "accept-ranges": ["bytes"] to apply to "maybe all, but at least one" of the methods? My 2ct, Michiel On Tue, Jul 17, 2012 at 1:42 AM, Mark Nottingham wrote: > > On 17/07/2012, at 1:05 AM, Peter Saint-Andre wrote: > >> On 7/4/12 8:28 PM, Mark Nottingham wrote: >> >>>> Abstract: >>>> This document proposes a "home document" format for non-browser HTTP >>>> clients. >> >> Hi Mark, this approach seems eminently sensible. I was expecting you to >> also define a well-known URI at which to find home documents, but it's >> not in the spec and I'm wondering why. :) > > I go back and forth on it. > > A few people have been encouraging me to do so, but I tend to think it se= nds the wrong message; that a hostname should always have just one home doc= ument, when there might be several views co-located on the same server (seg= regated by usage profile, user groups, "alternate views", etc.). > > E.g., I believe that "versioning" an API should involve minting a new hom= e document, and serving both side-by-side for a period. If home documents a= re per-URI, this is easy; it just means pointing people to or or whatever, whereas using a .well-known means that t= hey HAVE to use a new hostname. > > OTOH it's really powerful to "mix and match" a lot of different APIs into= one home document, presenting a unified view, and that's one of the big us= e cases for the spec. A well-known would help with this. > > In short, I'm still thinking about it, and what kinds of language I'd put= around it; that's why it didn't make it into the recent rev. > > Any input on either side would be most welcome. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From mikekelly321@gmail.com Tue Jul 17 01:48:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB5E21F85C6 for ; Tue, 17 Jul 2012 01:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-aXkCB+XOhK for ; Tue, 17 Jul 2012 01:48:31 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9148421F85A7 for ; Tue, 17 Jul 2012 01:48:31 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so346685obb.31 for ; Tue, 17 Jul 2012 01:49:18 -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=mnc9rRmtcw0SVLk8JSf6N3WeOVOeFtheBwcZfIYAJJg=; b=XjXKXpjBrX3ZeumoTVRtoZLh+z41QmHtHeJm0ZZUEnUGBNGDYJluqAWJs2iWF0mWw+ +weCwVHnU11YS5IK5/rUtHhghVqPAtKdQWZEPxRiC9ch7/jcEwwtkDF5j1Bhhkyrr0wl e12gC5WP04zo1pKYyUchJ0OXwEt2Z4HliF70lKE1hR1ti342sIRHKdJ1xMhSPsKASyc7 ymiQjBoemyu8TSe9TPvsfvWkze40mTiisilQxR8rayVF1AMqhN5QKrZcHowu0tNKfro+ pb+yovUQr6apj9V7gziDyKQ/OQ+k2osXviIcV4sCWAg4n7AMfFQm+G1aE646W3Q7yOsh P+Xg== MIME-Version: 1.0 Received: by 10.60.172.101 with SMTP id bb5mr2096072oec.44.1342514958152; Tue, 17 Jul 2012 01:49:18 -0700 (PDT) Received: by 10.60.65.234 with HTTP; Tue, 17 Jul 2012 01:49:18 -0700 (PDT) In-Reply-To: References: <20120705022204.29179.82506.idtracker@ietfa.amsl.com> <87D923B1-0931-4336-ABF1-A5D1B0C495BE@mnot.net> <50042DB3.40401@stpeter.im> <0497210C-8620-44EF-827F-6111CA25FE9D@mnot.net> Date: Tue, 17 Jul 2012 09:49:18 +0100 Message-ID: From: Mike Kelly To: Michiel de Jong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-json-home-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2012 08:48:32 -0000 If json-home is meant for representing entry points into an application then it stands to reason that clients should already be aware of its URI (the entry point of the API) and there should be no requirement for reserving a well known address. Maybe I'm missing something here? Cheers, M On Tue, Jul 17, 2012 at 9:23 AM, Michiel de Jong wro= te: > hi! > > i'm following this work with much interest. imho a well-known URI is > not immediately useful for the use case i'm imagining, which is client > developers using a generic code library for handling the interaction > with the API. We already see this now with OAuth, there are OAuth > client libraries in all popular languages that a programmer can use to > easily build a client for something. These libraries take > configuration files that are not human-memorable. An example i found > for one such library: > > OAuthClientRequest request =3D OAuthClientRequest > .authorizationLocation("https://graph.facebook.com/oauth/auth= orize") > .setClientId("your-facebook-application-client-id") > .setRedirectURI("http://www.example.com/redirect") > .buildQueryMessage(); > > These libraries are already useful, even though their config is not > human-memorable. You have to spend some time installing such a library > into your project anyway, and learning how to work with it, so whether > you then paste a json-home URL or only a domain name into the code > that you build around such a library, is then a triviality. > > imho, a well-known URI would be useful where the service provider is > chosen at run-time. > > Two small comments that came to my mind when reading the doc: > 1) i would love to have a way to make the relationship between the > /widgets/ and /widgets/{widget_id} URLs explicit. It would require > introducing the concept of items and collections, but I think many > APIs already use those concepts at quite a low level in their design. > Then, i could announce that a POST to a collection creates an item > (returning e.g. either the newly created object with its id inside it > in the body, or a Location: header to the newly created object). > > Right now i see how the client will have default expectations of what > GET, PUT, DELETE and PATCH will do (namely, read, write, remove, > modify), but i would not know how to define default expectations of > what a POST would do (because we can't talk of inserting without > talking of collections). > > 2) i think byte ranges are often supported for GET, even if they are > not supported for PUT. Should we interpret "accept-ranges": ["bytes"] > to apply to "maybe all, but at least one" of the methods? > > > My 2ct, > Michiel > > On Tue, Jul 17, 2012 at 1:42 AM, Mark Nottingham wrote: >> >> On 17/07/2012, at 1:05 AM, Peter Saint-Andre wrote: >> >>> On 7/4/12 8:28 PM, Mark Nottingham wrote: >>> >>>>> Abstract: >>>>> This document proposes a "home document" format for non-browser HTTP >>>>> clients. >>> >>> Hi Mark, this approach seems eminently sensible. I was expecting you to >>> also define a well-known URI at which to find home documents, but it's >>> not in the spec and I'm wondering why. :) >> >> I go back and forth on it. >> >> A few people have been encouraging me to do so, but I tend to think it s= ends the wrong message; that a hostname should always have just one home do= cument, when there might be several views co-located on the same server (se= gregated by usage profile, user groups, "alternate views", etc.). >> >> E.g., I believe that "versioning" an API should involve minting a new ho= me document, and serving both side-by-side for a period. If home documents = are per-URI, this is easy; it just means pointing people to or or whatever, whereas using a .well-known means that = they HAVE to use a new hostname. >> >> OTOH it's really powerful to "mix and match" a lot of different APIs int= o one home document, presenting a unified view, and that's one of the big u= se cases for the spec. A well-known would help with this. >> >> In short, I'm still thinking about it, and what kinds of language I'd pu= t around it; that's why it didn't make it into the recent rev. >> >> Any input on either side would be most welcome. >> >> Cheers, >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> _______________________________________________ >> 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 --=20 Mike http://twitter.com/mikekelly85 http://github.com/mikekelly http://linkedin.com/in/mikekelly123 From laurentwalter.goix@telecomitalia.it Tue Jul 17 05:33:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F44B21F8530 for ; Tue, 17 Jul 2012 05:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGi8KM+B6-j7 for ; Tue, 17 Jul 2012 05:33:19 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6B18B21F8649 for ; Tue, 17 Jul 2012 05:33:18 -0700 (PDT) Content-Type: multipart/mixed; boundary="_59101711-fc58-4339-b007-716a06b8a1a7_" Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 17 Jul 2012 14:34:01 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Tue, 17 Jul 2012 14:34:01 +0200 From: Goix Laurent Walter To: "apps-discuss@ietf.org" Date: Tue, 17 Jul 2012 14:33:59 +0200 Thread-Topic: About URI templates in descriptors Thread-Index: Ac1kGHC44N3IJvwsTzqrtIclfYak/Q== Message-ID: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Subject: [apps-discuss] About URI templates in descriptors X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2012 12:33:21 -0000 --_59101711-fc58-4339-b007-716a06b8a1a7_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A181842DGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A181842DGRFMBX704BA02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I have noticed over the past months different drafts making use on URI temp= lates (rfc6570 typically) with different approaches/syntaxes. I'd like to u= nderstand whether a best -common- practice can be found on its usage (unles= s it exists already). Here are some examples: - http://tools.ietf.org/html/draft-nottingham-json-home-01 makes u= se of "href-template" together with "href-vars" for dynamic definition of t= emplate variables, such as: "href-template": "/widgets/{widget_id}", "href-vars": { "widget_id": "http://example.org/param/widget" } - http://tools.ietf.org/html/draft-kelly-json-hal-03 uses < href >= for regular URIS as well as templates, and defines a "templated" boolean f= lag to discriminate them, such as: "href": "http://docs.acme.com/relations/{rel}", "templated": true - http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-00 relie= s on the "template" link attribute defined in OASIS XRD (or in RFC6415's JR= D in json), and only uses the "uri" template variable defined in RFC6415, s= uch as: "template" : "https://example.com/lrdd/?format=3Djson&uri=3D{uri}" I am wondering whether it could make sense to: - Harmonize the syntax in referencing template URIs within descrip= tors, at least in these use cases, which seem consistent in their reference= to such type of URIs - Consider a registry for reserved template variables (just like f= or link rels), to improve interoperability, whilst still allowing for exten= sibility/dynamicity Here would be a very personal consideration: - Leverage the XRD/rfc6415 syntax for referencing template URIs th= rough the "template" property (in lieu of "href" or "href-template" and wit= h no "template: true" extra property) - Leverage the json-home concept of "template-vars" for dynamic de= finition of template variables (in a first place these could be seen as "lo= cal variables" that override the "reserved" variables if present) - register globally some early template variable names, such as "u= ri" (rfc6415) and "username" (cited as example in json-home draft) I apologize if this was somehow already discussed in the past (e.g. the con= cept of a registry for uri template variable names) and would be happy to g= et some pointer of the outcome of that discussion, or any type of other fee= dback. thanks walter ------------------------------------------------------------------ Telecom Italia Laurent-Walter Goix Innovation & Industry Relations, Research & Prototyping, Future Internet Piazza Einaudi 8 - 20124 Milano (Italy) Tel. +39 026213445 Mob. +39 3356114196 Fax +39 0641869055 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non ? necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE53A181842DGRFMBX704BA02_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

I have noticed over the past mo= nths different drafts making use on URI templates (rfc6570 typically) with = different approaches/syntaxes. I’d like to understand whether a best = –common- practice can be found on its usage (unless it exists already). Here are some examples:

 

-  = ;        http://tools.ietf.org/html/dr= aft-nottingham-json-home-01 makes use of “href-template” to= gether with “href-vars” for dynamic definition of template variables, such as:

         "href-template": "/widgets/{widg= et_id}",

       &= nbsp; "href-vars": {

       &= nbsp;   "widget_id": "http://example.org/param/wid= get"

       &= nbsp; }

-  = ;        http://tools.ietf.org/html/draft-ke= lly-json-hal-03 uses « href = ;» for regular URIS as well as templates, and defines a “templated” boolean flag to discriminate them, such as:= 

        "=
href": "=
http://docs.acme.com/relations/{rel}",=

         =
"templated": true
 

-  = ;        http://tools.ietf.org/html/= draft-ietf-appsawg-webfinger-00 relies on the “template” li= nk attribute defined in OASIS XRD (or in RFC6415’s JRD in json), and only uses the “uri” template variable define= d in RFC6415, such as:

        "template" : &quo=
t;https://example.com/lrdd/?format=3Djson&uri=3D{uri}"<=
/pre>

 


I am wondering whether it could=
 make sense to:


-  =
;       
Harmonize the syntax in=
 referencing template URIs within descriptors, at least in these use cases,=
 which seem consistent in their reference to such type of URIs



-  =
;       
Consider a registry for=
 reserved template variables (just like for link rels), to improve interope=
rability, whilst still allowing for extensibility/dynamicity


 


Here would be a very personal c=
onsideration:


-  =
;       
Leverage the XRD/rfc641=
5 syntax for referencing template URIs through the “template” p=
roperty (in lieu of “href” or “href-template” and w=
ith no “template: true” extra property)


-  =
;       
Leverage the json-home =
concept of “template-vars” for dynamic definition of template v=
ariables (in a first place these could be seen as “local variables=
221; that override the “reserved” variables if present)


-  =
;       
register globally some =
early template variable names, such as “uri” (rfc6415) and R=
20;username” (cited as example in json-home draft)<=
/p>

 


I apologize if this was somehow=
 already discussed in the past (e.g. the concept of a registry for uri temp=
late variable names) and would be happy to get some pointer of the outcome =
of that discussion, or any type of other
 feedback.


 


thanks


walter


 


----------------------------------------------------------------=
--

Telecom Italia

Laurent-Walter Goix=



Innovation & Industry=
 Relations, Research & Prototyping, Future Internet 


Piazza Einaudi 8 - 2012=
4 Milano (Italy)

Tel. +39 026213445


Mob. +39 3356114196



Fax +39 0641869055


 =



 
= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non è necessario.

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A181842DGRFMBX704BA02_-- --_59101711-fc58-4339-b007-716a06b8a1a7_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_59101711-fc58-4339-b007-716a06b8a1a7_-- From GK@ninebynine.org Tue Jul 17 06:46:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E814421F86E3 for ; Tue, 17 Jul 2012 06:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA0hF72Buo0Z for ; Tue, 17 Jul 2012 06:46:43 -0700 (PDT) Received: from relay1.mail.ox.ac.uk (relay1.mail.ox.ac.uk [129.67.1.165]) by ietfa.amsl.com (Postfix) with ESMTP id C7BA521F8714 for ; Tue, 17 Jul 2012 06:46:42 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay1.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1Sr87d-0007qt-4a; Tue, 17 Jul 2012 14:47:29 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Sr87c-0000wB-6A; Tue, 17 Jul 2012 14:47:29 +0100 Message-ID: <50056B57.8010807@ninebynine.org> Date: Tue, 17 Jul 2012 14:40:39 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Goix Laurent Walter References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] About URI templates in descriptors X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2012 13:46:44 -0000 Hi, I've been doing work that supplies templates in RDF data, which is yet another syntax (or three). I don't think a common syntax is really an option, as it depends somewhat on the carrier syntax adopted by the application. Mark's JSON-home draft provides a possible common entry point (along with his Link-template proposal) - I don't see that it makes sense to do much more than that without further context. #g -- On 17/07/2012 13:33, Goix Laurent Walter wrote: > Hello all, > > I have noticed over the past months different drafts making use on URI templates (rfc6570 typically) with different approaches/syntaxes. I'd like to understand whether a best -common- practice can be found on its usage (unless it exists already). Here are some examples: > > > - http://tools.ietf.org/html/draft-nottingham-json-home-01 makes use of "href-template" together with "href-vars" for dynamic definition of template variables, such as: > "href-template": "/widgets/{widget_id}", > "href-vars": { > "widget_id": "http://example.org/param/widget" > } > > - http://tools.ietf.org/html/draft-kelly-json-hal-03 uses< href> for regular URIS as well as templates, and defines a "templated" boolean flag to discriminate them, such as: > > "href": "http://docs.acme.com/relations/{rel}", > > "templated": true > > > > - http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-00 relies on the "template" link attribute defined in OASIS XRD (or in RFC6415's JRD in json), and only uses the "uri" template variable defined in RFC6415, such as: > > "template" : "https://example.com/lrdd/?format=json&uri={uri}" > > I am wondering whether it could make sense to: > > - Harmonize the syntax in referencing template URIs within descriptors, at least in these use cases, which seem consistent in their reference to such type of URIs > > - Consider a registry for reserved template variables (just like for link rels), to improve interoperability, whilst still allowing for extensibility/dynamicity > > Here would be a very personal consideration: > > - Leverage the XRD/rfc6415 syntax for referencing template URIs through the "template" property (in lieu of "href" or "href-template" and with no "template: true" extra property) > > - Leverage the json-home concept of "template-vars" for dynamic definition of template variables (in a first place these could be seen as "local variables" that override the "reserved" variables if present) > > - register globally some early template variable names, such as "uri" (rfc6415) and "username" (cited as example in json-home draft) > > I apologize if this was somehow already discussed in the past (e.g. the concept of a registry for uri template variable names) and would be happy to get some pointer of the outcome of that discussion, or any type of other feedback. > > thanks > walter > > ------------------------------------------------------------------ > Telecom Italia > Laurent-Walter Goix > Innovation& Industry Relations, Research& Prototyping, Future Internet > Piazza Einaudi 8 - 20124 Milano (Italy) > Tel. +39 026213445 > Mob. +39 3356114196 > Fax +39 0641869055 > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. > > [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From superuser@gmail.com Tue Jul 17 14:19:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B005B11E80B5 for ; Tue, 17 Jul 2012 14:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khTEvnqU9Pfi for ; Tue, 17 Jul 2012 14:19:41 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE1211E80B3 for ; Tue, 17 Jul 2012 14:19:41 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1327926lbb.31 for ; Tue, 17 Jul 2012 14:20:29 -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=Yt5hsBQJ4IPEFfaKELCQEg97zquc2GigI6ouMXKze/4=; b=yjj27Hpw5+akuZ3TtK8TIEpTCXDyAjGOWXFQGU4xx3wovhnAlLiGdPK+4i9yVuoPpR pi+3UEoNtJILeQamjOEWYqUt6fhseab+n4Clm5xWqpYDgxi4dlxURS8SwHKxXfR/507p dQztn+UmOoJF/TLf51t+bA8VLrUm3m6aPeyuX0rL86MIeHuVvAGwO9vSbg0Gcg7cCYea W8PpHEz5rBTAg++FE9aptsf0S5yiigrSmqDrfVC4zZMwwu+NZfsMs8Tjv1pPykAfrvf9 UB+vBq1+VUyX1H0h+A0Ij5my/froNx0pdk/JxrI0VsPIwGoh1Cvl58b0w+4hH8eTfGPF JYcA== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr459120lab.47.1342560029093; Tue, 17 Jul 2012 14:20:29 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Tue, 17 Jul 2012 14:20:29 -0700 (PDT) Date: Tue, 17 Jul 2012 14:20:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d0435c1d29faea904c50d1d26 Subject: [apps-discuss] IETF 84 APPSAWG Agenda posted X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2012 21:19:42 -0000 --f46d0435c1d29faea904c50d1d26 Content-Type: text/plain; charset=ISO-8859-1 APPSAWG will be meeting at IETF 84 in Vancouver at 9am PDT on Monday in room "Georgia B". The agenda is now available at https://datatracker.ietf.org/meeting/84/agenda/appsawg/. If you are presenting anything and have slides to be projected, please have them to appsawg-chairs@tools.ietf.org by 6pm PDT on Sunday, July 29th so that the master slide set can be uploaded for remote participants. Submissions after that time may not be used on Monday. -MSK, APPSAWG co-chair --f46d0435c1d29faea904c50d1d26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable APPSAWG will be meeting at IETF 84 in Vancouver at 9am PDT on Monday in roo= m "Georgia B".

The agenda is now available at https://datatracker= .ietf.org/meeting/84/agenda/appsawg/.

If you are presenting anything and have slides to be projected, please = have them to appsawg-chair= s@tools.ietf.org by 6pm PDT on Sunday, July 29th so that the master sli= de set can be uploaded for remote participants.=A0 Submissions after that t= ime may not be used on Monday.

-MSK, APPSAWG co-chair

--f46d0435c1d29faea904c50d1d26-- From mnot@mnot.net Tue Jul 17 17:59:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E13311E80C0 for ; Tue, 17 Jul 2012 17:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.237 X-Spam-Level: X-Spam-Status: No, score=-105.237 tagged_above=-999 required=5 tests=[AWL=-2.638, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eev56Rjlbs3 for ; Tue, 17 Jul 2012 17:59:19 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4979911E8101 for ; Tue, 17 Jul 2012 17:59:19 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1E17422E257; Tue, 17 Jul 2012 21:00:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Wed, 18 Jul 2012 10:59:57 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120705022204.29179.82506.idtracker@ietfa.amsl.com> <87D923B1-0931-4336-ABF1-A5D1B0C495BE@mnot.net> <50042DB3.40401@stpeter.im> <0497210C-8620-44EF-827F-6111CA25FE9D@mnot.net> To: Michiel de Jong X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-json-home-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2012 00:59:20 -0000 Hi Michiel, On 17/07/2012, at 6:23 PM, Michiel de Jong wrote: > Two small comments that came to my mind when reading the doc: > 1) i would love to have a way to make the relationship between the > /widgets/ and /widgets/{widget_id} URLs explicit. It would require > introducing the concept of items and collections, but I think many > APIs already use those concepts at quite a low level in their design. > Then, i could announce that a POST to a collection creates an item > (returning e.g. either the newly created object with its id inside it > in the body, or a Location: header to the newly created object). >=20 > Right now i see how the client will have default expectations of what > GET, PUT, DELETE and PATCH will do (namely, read, write, remove, > modify), but i would not know how to define default expectations of > what a POST would do (because we can't talk of inserting without > talking of collections). Yep, I want to go there. > 2) i think byte ranges are often supported for GET, even if they are > not supported for PUT. Should we interpret "accept-ranges": ["bytes"] > to apply to "maybe all, but at least one" of the methods? It's only for GET; = https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p5-ran= ge.html#range.retrieval.requests Cheers, -- Mark Nottingham http://www.mnot.net/ From jan.algermissen@nordsc.com Wed Jul 18 07:27:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0E721F872D for ; Wed, 18 Jul 2012 07:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qF7FVzQYA8PG for ; Wed, 18 Jul 2012 07:27:46 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id F115121F8775 for ; Wed, 18 Jul 2012 07:27:45 -0700 (PDT) Received: from [10.39.137.151] (tmo-096-115.customers.d1-online.com [80.187.96.115]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0LZYWu-1TaUe50ib6-00lUOp; Wed, 18 Jul 2012 16:28:34 +0200 From: Jan Algermissen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jul 2012 16:28:29 +0200 Message-Id: To: "apps-discuss@ietf.org application-layer protocols" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:l2bpY/VbQ58Lo6+jSoRUSg1E/ou3VDezgUmp++4bLpa hg+t4BYwNCoqXQQItjuJSaTMbqzkOKvwi8ZwNiXpxe+azr0vr5 C6yd1RrASCWjHE/lYD8p8ebgKLM9JDTPDV/mdEunbflzi1WOo4 XHd9I0HWnE293xc1JcD3lzwEFEumTiuvL1LD8FWz2rUOMyE/oe RjvXmLOYZB7sioBBjaTdjxiJSNScuntbA8nLzI5kwyVnmfkEmT 7dwMXwgg60SKv+oCdmDy4vgQ5pEg7V98lsOKZFQZAn89RyWnnL 8Xsr4bKsBi/IXFqV8TAhqO4izIGzELiPE0+CL1jHoUTWdAs7Ck rjftgBADlk29XiVaoiNI8wNKs/Arfj22MO7vKRjHaNcc82cm94 0eWEGp0uLipSA== Cc: Mark Nottingham Subject: [apps-discuss] Inclusion-mechanism for draft-nottingham-json-home-01? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2012 14:27:46 -0000 Hi Mark, I am playing around with your json-home I-D[1]. Despite being entirely not a fan of generating artifacts like json-home = documents from code I am facing a situation where this seems like the = best way to get the point of following your nose across. Having accepted generation for the moment, I am facing the issue of = integrating generated aspects of the home document and non-generated = aspects. Hence the question: Have you considered an inclusion mechanism for = json-home documents to split them into parts with different locations = and ownership? I am not sure about this, but it would also open up options for managing = parts with differing live times, probably to allow features under = development to change far more frequently than the stable 'official' = parts. Your example might then look something like this: { "resources": { "http://example.org/rel/widgets": { "href": "/widgets/" }, "http://example.org/rel/widget": { "href-template": "/widgets/{widget_id}", "href-vars": { "widget_id": "http://example.org/param/widget" }, "hints": { "allow": ["GET", "PUT", "DELETE", "PATCH"], "representations": ["application/json"], "accept-patch": ["application/json-patch"], "accept-post": ["application/xml"], "accept-ranges": ["bytes"] } } }, "include" : "/home/inc/other.js", "include" : "/home/inc/dev-features-02.js", } However, I am all for making crystal clear that such documentation is = intended to be so stable that generation is actually a non-use case. Jan [1] http://tools.ietf.org/html/draft-nottingham-json-home-01= From jan.algermissen@nordsc.com Wed Jul 18 07:54:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EC321F8687 for ; Wed, 18 Jul 2012 07:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+u1L-5csEDE for ; Wed, 18 Jul 2012 07:54:25 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3735B21F86B9 for ; Wed, 18 Jul 2012 07:54:25 -0700 (PDT) Received: from [10.154.193.163] (tmo-103-14.customers.d1-online.com [80.187.103.14]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MFQw8-1T3ek81plE-00ELxO; Wed, 18 Jul 2012 16:55:13 +0200 From: Jan Algermissen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jul 2012 16:55:11 +0200 Message-Id: <63F18980-6462-49DF-8A6E-58E6B5F634C6@nordsc.com> To: "apps-discuss@ietf.org application-layer protocols" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:YWTLDiZ1riXHGYkmKdSJpw4eQgy77wbiCnqKhPc52Vi 2UZuFQdqbm5kHhFcFUAfSsoI9UIjBbQu9nFjUlbfm148oikw65 EAX1sjXZRsYOq+GfitGd7HKXTUHsyYHDSPoJZTFFEW9uRkMGlN NVXEjECR/VoExvpLA4fkRdU/QLh3UeImAYiy5r9SRtfo9+sN8g pwfnN1A84pzb8YxJBGOYoaA+PO8k9q5C4oteb/dm9OXkrcOwgS 123TaPKdoWDOi1X0Q48p1jGPcl+RwEpliyzsicZqKPLrysPRS2 IxYOcHjWvQ1Bzo6Oot+w/rgjCJOp+M+TwfoGSxBzeujkony/eQ RL1eToO3vE23/9x9orZ6fub6AIm7kZTgPSb0AkzZ1TYxoJ666Z Uqp9wFa3cGP9P6ZqoVkZH9FMSm2Jc7qXi8= Cc: Mark Nottingham Subject: [apps-discuss] Avoiding sending out 'problematic' signals with jason-home X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2012 14:54:27 -0000 Hi Mark, [sorry, I had somehow unsubscribed from the list and hence cannot reply = to the postings I mention below] in [1] you responded: "E.g., I believe that "versioning" an API should involve minting a new = home document, and serving both side-by-side for a period." If something like this would make it into the draft I think it would = send out wrong impressions. FWIW, versioning happens at the media type / = conneg level and URIs should remains stable. Granted there can be = exceptions, but once you hand out 'versioning capabilities' to the world = they'll all just jump on it like crazy because it satisfies SOAPy brains = too easily. You crafted the wording of the 'hints' section so carefully, but I am = still sure, people will thankfully mistake it as a design-time WADL-like = tool. Let's not add 'versioning' to that. ----- In [2] you respond: > Right now i see how the client will have default expectations of what > GET, PUT, DELETE and PATCH will do (namely, read, write, remove, > modify), but i would not know how to define default expectations of > what a POST would do (because we can't talk of inserting without > talking of collections). Yep, I want to go there. Umm, am I missing something? The expectations a client can have regarding the POST are already = sufficiently defined by the target resource semantics the client = understands from understanding the link relation it follows. The expectations regarding methods are not a 'default' that can be = extended. HTTP already defines their meaning. Adding expectations on to = means creating a new protocol. I really do think that something as clean and simple as json-home moves = us a great step forward in terms of handing wanna-be REST adopters the = necessary tools! But I also think it is a very slippery slope regarding the issue of = helping adopters to actually go through a mind shift away from RPC = towards a use of HTTP that actually brings them the benefits they expect = from it. Any RPC-ish touch will make that shift harder, IMHO. Jan [1] = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06700.html [2] = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06709.html From superuser@gmail.com Wed Jul 18 12:31:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A561E11E81A3 for ; Wed, 18 Jul 2012 12:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwW6I-X9m0jx for ; Wed, 18 Jul 2012 12:31:03 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC5F11E81A2 for ; Wed, 18 Jul 2012 12:31:02 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2810234lbb.31 for ; Wed, 18 Jul 2012 12:31:52 -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=4p/kDv8vm5tqi+hRv5StbH2pIThbRLBu6UV9pomWfaM=; b=l8jv1i7pCCLPebN3F9ru/PembQsvVD5fVpdrFOuVamnX47M3mnIxgQYe+T0Osw8AxM 1JVyEoA8T4Xd+wQv3MX4jPCVrXun05LKzssNqNYI/5AuHyaqYR6Q0EfX9CpXS9VvWyQt YNa3O5KdoScAkPL29Uk+r89FvTN0fm1kt34zPwRooEptLB6FOil9A4rflQAKXgYg5m/b uKAYxGA+vmGdBzanm4l3AO/v/wRMA+qnFp7wtz40nUOcwEXN7DglbjqXGWz2axVDwfdZ K99zGuC6fJo/u2ObYJIbjCTCoZ6QAInJwUPhRm3LUYMhvfiF/GjlEvkwXbT/ZOsYZ5ZP xdmg== MIME-Version: 1.0 Received: by 10.152.104.47 with SMTP id gb15mr4800499lab.45.1342639912616; Wed, 18 Jul 2012 12:31:52 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 18 Jul 2012 12:31:52 -0700 (PDT) Date: Wed, 18 Jul 2012 12:31:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d0421824d0d838404c51fb759 Subject: [apps-discuss] Status of draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2012 19:31:03 -0000 --f46d0421824d0d838404c51fb759 Content-Type: text/plain; charset=ISO-8859-1 Apps folks, Tony has posted a new version of this draft that appears to address most comments. Please review it and comment, especially if you provided comments previously. Some time ago, Mark Nottingham posted comments that have not been thoroughly addressed: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05998.html As document shepherd, it seems to me that the absence of concurring opinion in the archive suggests that Mark is alone in his concerns, and that those concerns are overshadowed by the existence of media type suffixes and the need to more clearly document them. However, in the interests of tying up loose ends, I'd like the working group to consider his questions once more before sending the document to the IESG. Therefore: If you agree with some or all of Mark's concerns, please post your thoughts here in the next two weeks. At the end of the Vancouver meeting, we will determine how to proceed based on the response to this. Also, please post if you disagree, with reasons. Silence will be taken to mean the working group is okay with the document going forward as-is. Thank you, -MSK, APPSAWG co-chair --f46d0421824d0d838404c51fb759 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Apps folks,

Tony has posted a new version of this draft that appears= to address most comments.=A0 Please review it and comment, especially if y= ou provided comments previously.

Some time ago, Mark Nottingham posted comments that have not been thoro= ughly addressed: http://www.ietf.org/mail-archiv= e/web/apps-discuss/current/msg05998.html

As document shepherd, it seems to me that the absence of concurring opinion= in the archive suggests that Mark is alone in his concerns, and that those= concerns are overshadowed by the existence of media type suffixes and the = need to more clearly document them.=A0 However, in the interests of tying u= p loose ends, I'd like the working group to consider his questions once= more before sending the document to the IESG.

Therefore: If you agree with some or all of Mark's concerns, please pos= t your thoughts here in the next two weeks.=A0 At the end of the Vancouver = meeting, we will determine how to proceed based on the response to this.=A0= Also, please post if you disagree, with reasons.=A0 Silence will be taken = to mean the working group is okay with the document going forward as-is.
Thank you,

-MSK, APPSAWG co-chair

--f46d0421824d0d838404c51fb759-- From jan.algermissen@nordsc.com Wed Jul 18 13:02:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A09621F8831 for ; Wed, 18 Jul 2012 13:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=-4.175, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJS+zE8FsSFu for ; Wed, 18 Jul 2012 13:02:25 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 01B9821F8821 for ; Wed, 18 Jul 2012 13:02:24 -0700 (PDT) Received: from [192.168.2.103] (p548FCFD6.dip.t-dialin.net [84.143.207.214]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0M3dFB-1TiJdq0Uoj-00rHhg; Wed, 18 Jul 2012 22:03:15 +0200 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Jan Algermissen In-Reply-To: Date: Wed, 18 Jul 2012 22:03:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <460D97D3-E3DD-4E46-9ACB-3C5E3FD1F02E@nordsc.com> References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:7TsS26vI3hGQ9n3UFIPKd0WiyR9COldduKR6E+yAjyO 7kQT2VKPOvd00aqWkE3F2IOo1a7ARsbpcZ5ABZiu9PsvVptvHD UDVqkNlIFBg9wiB6PpRglHWGtexPmy35Sq1LRmeWHySsFt31vF +R2OMUKYvpPrKCP++NSlAmfxDUO5tgmSCFX4jB99Fz4e3xN+Bk OMna+0ixjgS7Cp6YqmFGLkqNjff+ZLQ3szpJE71fHujkDN3o+/ ZR31VSlKCgz9hXjN8o25AGbTRp+pSTCnkHIvg00U1NiSb5qR0D Ctcnnjaee4Bno+W9Rjzm6KFavDNu6Ak3RlndUZXJwkhUst66i3 GxteryoEcF3HQvLd25Kd8WFkDvwROfvMVze+KwBRDbfAk7OJdp vsw4DbAR6OYfg== Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2012 20:02:26 -0000 On Jul 18, 2012, at 9:31 PM, Murray S. Kucherawy wrote: > Apps folks, >=20 > Tony has posted a new version of this draft that appears to address = most comments. Please review it and comment, especially if you provided = comments previously. >=20 > Some time ago, Mark Nottingham posted comments that have not been = thoroughly addressed: = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05998.html Thanks for bringing this up. >=20 > As document shepherd, it seems to me that the absence of concurring = opinion in the archive suggests that Mark is alone in his concerns, and = that those concerns are overshadowed by the existence of media type = suffixes and the need to more clearly document them. However, in the = interests of tying up loose ends, I'd like the working group to consider = his questions once more before sending the document to the IESG. >=20 > Therefore: If you agree with some or all of Mark's concerns, please = post your thoughts here in the next two weeks. =20 I agree with Mark's concern about the existence of real use cases that = are addressed by this. Can the authors provide some examples to = illustrator the point? All the message processing stacks I have worked with dispatch on the = full media type identifier. Might be that the spec is YAGNI ? Having said that, I see one potential case: intermediaries (needing no = knowledge of the application semantics) that turn payload running = through them into general data structures: Search for 'entity introspection' in = http://jalg.net/2011/11/esi-facelift/=20 Jan > At the end of the Vancouver meeting, we will determine how to proceed = based on the response to this. Also, please post if you disagree, with = reasons. Silence will be taken to mean the working group is okay with = the document going forward as-is. >=20 > Thank you, >=20 > -MSK, APPSAWG co-chair >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From julian.reschke@gmx.de Wed Jul 18 13:12:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D2111E8189 for ; Wed, 18 Jul 2012 13:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.177 X-Spam-Level: X-Spam-Status: No, score=-105.177 tagged_above=-999 required=5 tests=[AWL=-2.578, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTKeGasCiGtp for ; Wed, 18 Jul 2012 13:12:01 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8A8D311E8166 for ; Wed, 18 Jul 2012 13:12:00 -0700 (PDT) Received: (qmail invoked by alias); 18 Jul 2012 20:12:50 -0000 Received: from p5DD96F20.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.111.32] by mail.gmx.net (mp004) with SMTP; 18 Jul 2012 22:12:50 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/xtMlJCSHxiEvjA6R0NIbZITjBu6cV0EEK5EsAXU vGtWjvXkHScWNg Message-ID: <500718C0.4040703@gmx.de> Date: Wed, 18 Jul 2012 22:12:48 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Jan Algermissen References: <460D97D3-E3DD-4E46-9ACB-3C5E3FD1F02E@nordsc.com> In-Reply-To: <460D97D3-E3DD-4E46-9ACB-3C5E3FD1F02E@nordsc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2012 20:12:01 -0000 On 2012-07-18 22:03, Jan Algermissen wrote: > ... > I agree with Mark's concern about the existence of real use cases that are addressed by this. Can the authors provide some examples to illustrator the point? > > All the message processing stacks I have worked with dispatch on the full media type identifier. Might be that the spec is YAGNI ? > ... -> I encourage to also read the *responses* to Mark's mail :-) Best regards, Julian From ned.freed@mrochek.com Wed Jul 18 15:07:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E8211E8157 for ; Wed, 18 Jul 2012 15:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ky8pJxn-RJrt for ; Wed, 18 Jul 2012 15:07:46 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E1CC611E8087 for ; Wed, 18 Jul 2012 15:07:45 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHZZPUTDCW004RA3@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 18 Jul 2012 15:03:35 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHZVQBJXY80006TF@mauve.mrochek.com>; Wed, 18 Jul 2012 15:03:33 -0700 (PDT) Message-id: <01OHZZPTN9XS0006TF@mauve.mrochek.com> Date: Wed, 18 Jul 2012 14:46:23 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 18 Jul 2012 12:31:52 -0700" MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII References: To: "Murray S. Kucherawy" Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2012 22:07:46 -0000 > Apps folks, > Tony has posted a new version of this draft that appears to address most > comments. Please review it and comment, especially if you provided > comments previously. > Some time ago, Mark Nottingham posted comments that have not been > thoroughly addressed: > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05998.html Those comments were and are out of order and I see no point in responding to them. Questioning the utility of the +format suffixes was a matter to be dealt when the media type registration procedure was updated to define the registry. All the current document does is seed the already registry that is already specified and approved. If Mark has questions about or objections to specific prefixes being registered, or to the contents of those registrations, he needs to separate those out and represent them as such. Futhermore, if you look in the archives, the entire topic of having suffixes has in fact been discussed, both in the process leading up to the approval of the revised registration document as well as in the original discussions about the XML-MIME RFC. I see no point in rehashing those discussions again. > As document shepherd, it seems to me that the absence of concurring opinion > in the archive suggests that Mark is alone in his concerns, and that those > concerns are overshadowed by the existence of media type suffixes and the > need to more clearly document them. This document doesn't do that. All it does is seed the registry. As I see it, the only comments that are in order are about the content of those registration entries. > However, in the interests of tying up > loose ends, I'd like the working group to consider his questions once more > before sending the document to the IESG. > Therefore: If you agree with some or all of Mark's concerns, please post > your thoughts here in the next two weeks. At the end of the Vancouver > meeting, we will determine how to proceed based on the response to this. > Also, please post if you disagree, with reasons. Silence will be taken to > mean the working group is okay with the document going forward as-is. In case it isn't obvious: I disgree with his concerns, but even if I didn't I fail to see how they are relevant at this point. Ned From mnot@mnot.net Wed Jul 18 17:35:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C6511E80E3 for ; Wed, 18 Jul 2012 17:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.229 X-Spam-Level: X-Spam-Status: No, score=-105.229 tagged_above=-999 required=5 tests=[AWL=-2.630, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5Br8auuJwgE for ; Wed, 18 Jul 2012 17:35:21 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id A37CE11E80B6 for ; Wed, 18 Jul 2012 17:35:21 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D289222E259; Wed, 18 Jul 2012 20:36:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: <5004F76C.8070406@att.com> Date: Thu, 19 Jul 2012 10:36:02 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <2C6D1C2F-8404-4F78-B366-D552954CB7C6@mnot.net> References: <5004F76C.8070406@att.com> To: Tony Hansen X-Mailer: Apple Mail (2.1278) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2012 00:35:22 -0000 On 17/07/2012, at 3:26 PM, Tony Hansen wrote: > Mark, the suffix-regs doc is mostly trying to document the rules under = which existing suffixes have been informally permitted in the past and = provide a more formal basis for them to be used in the future. Except = for +ber, +der and +zip, there are already examples of the other = suffixes mentioned in this document. For example, in addition to all of = the +xml media types, consider all of these media types that are already = being used: >=20 > application/soap+fastinfoset > application/vnd.collection+json > application/vnd.hal+json > application/vnd.oftn.l10n+json > application/vnd.nokia.conml+wbxml > application/vnd.nokia.landmark+wbxml > application/vnd.nokia.pcd+wbxml > application/vnd.syncml.dm+wbxml > application/vnd.wv.csp+wbxml >=20 > You ask about the guidance being provided to the Expert Reviewers in = the media type registry document. That advice is expanded on by the = media-type-suffix-regs document; Where? I'm talking about guidance for new suffixes, not new media types = using existing suffixes. > Expert Reviewers should consider both pieces of guidance. (One can = argue that the additional guidance in this document should have been in = the other document; for various reasons it didn't happen.) >=20 > And yes, the gateway is being protected by an Expert Reviewer. But = that's been true for them in the past, as well as all of the media types = in general. I don't see anyone being to drive a tank through that = gateway any more easily now than they have in the past. As an example of = a recently proposed media type suffix that did *not* pass muster, = consider +exi. *sigh* We can, and should, do better than this. >=20 > Tony Hansen >=20 > On 6/25/2012 1:52 AM, Mark Nottingham wrote: >> I still haven't seen a satisfying answer to my questions about how = this is actually going to be used. They may be out there, but I can't = escape the feeling that people are going along with this because it = "seems like a good idea", and I'm concerned that the implications of = allowing a multitude of suffixes -- thereby effectively adding another = dimension of identity to our format identifiers -- hasn't been properly = considered. >>=20 >> I'm especially concerned because, as I noted in my review of the = media type registrations document, there isn't any discussion of = appropriate vs. inappropriate use in this registry; the only guidance = given to the experts for this registry is: >>=20 >>> The primary guideline for whether a structured type name suffix = is >>> registrable is that it be described by a readily-available >>> description, preferably within a document published by an = established >>> standards organization, and for which there's a reference that = can be >>> used in a Normative References section of an RFC. >> Now, if that isn't a hole that you can drive a tank through, I don't = know what is (BTW, the media types registration document doesn't even = explicitly specify a policy for this registry; it appears to be Expert = Review). >>=20 >> E.g., the recent +merge-patch suffix proposal. If James had chosen to = pursue that, on what grounds could the Expert (whoever that will be) = reject the proposal? >>=20 >> I realise this document is only a shell for registering the suffixes, = rather than their registration, but I still haven't seen any meaningful = response to the concerns that I brought up, first in review of the media = type registrations document, and later in separate e-mail. >>=20 >> Regards, >>=20 >>=20 >> On 20/06/2012, at 4:15 PM, Murray S. Kucherawy wrote: >>=20 >>> On Mon, Jun 11, 2012 at 5:25 AM, Murray S. Kucherawy = wrote: >>> This note begins a Working Group Last Call on = draft-ietf-appsawg-media-type-suffix-regs, ending Monday, June 25. = Please review the document and comment on it. >>>=20 >>> Note that its "parent" document, draft-ietf-appsawg-media-type-regs, = is now in IESG Evaluation. >>>=20 >>> A reminder that this WGLC closes in less than a week. Please = review the document and send your comments soon. >>>=20 >>> Thanks, >>> -MSK, APPSAWG co-chair >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >> -- >> Mark Nottingham http://www.mnot.net/ >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Jul 18 18:16:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376B721F8711 for ; Wed, 18 Jul 2012 18:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.212 X-Spam-Level: X-Spam-Status: No, score=-105.212 tagged_above=-999 required=5 tests=[AWL=-2.613, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvCVqxwydJK9 for ; Wed, 18 Jul 2012 18:16:50 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1715921F8710 for ; Wed, 18 Jul 2012 18:16:49 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E0BA122E1F4; Wed, 18 Jul 2012 21:17:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <01OHZZPTN9XS0006TF@mauve.mrochek.com> Date: Thu, 19 Jul 2012 11:17:31 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01OHZZPTN9XS0006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2012 01:16:51 -0000 On 19/07/2012, at 7:46 AM, Ned Freed wrote: >> Apps folks, >=20 >> Tony has posted a new version of this draft that appears to address = most >> comments. Please review it and comment, especially if you provided >> comments previously. >=20 >> Some time ago, Mark Nottingham posted comments that have not been >> thoroughly addressed: >> = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05998.html >=20 > Those comments were and are out of order and I see no point in = responding to > them. "Out of order"? Seriously? Last I checked, you don't Chair this WG. > Questioning the utility of the +format suffixes was a matter to be = dealt=20 > when the media type registration procedure was updated to define the = registry. > All the current document does is seed the already registry that is = already > specified and approved. I did question it in my apps area review of the registration procedure = document = := """ * Section 4.2.8 introduces structured suffixes. These may be very = popular, but I don't see any description of their value, nor appropriate = vs. inappropriate use (and I suspect there are many opportunities for = abuse here). Also, I suspect that having many of these will be very = counterproductive, and therefore wonder whether DE is the appropriate = registry policy here. """ You subsequently dodged the question = := """ This document didn't introduce them; RFC 3023 did. See above for why the = sort of text you're asking for doesn't belong here. As for this being the right registration process, that's a consensus = issue, not a document editing issue, and certainly not at this stage. I've heard no objections other than this one, and if past experience is any = indication, worries about "opening the floodgates" have rarely proved to be well = founded. If fact we usually end up with the opposite: Overly onerous processes = that prevent people from getting things done. =20 Anyway, if you want to try and get consensus that the current process is insufficiently restrictive feel free to do so. But until such a = consensus emerges I'm not going to change it. """ The Chairs chose not to pursue it (I considered the issued raised as = part of the review). I had other things to do. I posted the follow = message only to get *some* sense of why we're doing this, and what = constraints are around it.=20 > If Mark has questions about or objections to specific prefixes being > registered, or to the contents of those registrations, he needs to = separate > those out and represent them as such. That's beside the point, and plainly NOT the issue at hand. > Futhermore, if you look in the archives, the entire topic of having = suffixes > has in fact been discussed, both in the process leading up to the = approval of > the revised registration document as well as in the original = discussions about > the XML-MIME RFC. I see no point in rehashing those discussions again. =20 And you could have pointed me to those discussions, but chose not to. = You could have even suggested I look for them, but chose not to do so. >> As document shepherd, it seems to me that the absence of concurring = opinion >> in the archive suggests that Mark is alone in his concerns, and that = those >> concerns are overshadowed by the existence of media type suffixes and = the >> need to more clearly document them. >=20 > This document doesn't do that. All it does is seed the registry. As I = see it, > the only comments that are in order are about the content of those = registration > entries.=20 My question wasn't specific to that document, it was reiterating the = concern I expressed earlier, and the fact that it hadn't been addressed, = as evidenced by the later document.=20 >> However, in the interests of tying up >> loose ends, I'd like the working group to consider his questions once = more >> before sending the document to the IESG. >=20 >> Therefore: If you agree with some or all of Mark's concerns, please = post >> your thoughts here in the next two weeks. At the end of the = Vancouver >> meeting, we will determine how to proceed based on the response to = this. >> Also, please post if you disagree, with reasons. Silence will be = taken to >> mean the working group is okay with the document going forward as-is. >=20 > In case it isn't obvious: I disgree with his concerns, but even if I = didn't > I fail to see how they are relevant at this point. A reasoned reply (or pointers) would be nice, instead of what looks like = stonewalling and diversionary tactics. I'm fine if no one else is concerned about this, but I don't think it's = unreasonable for me to raise my concerns and ask a few questions.=20 -- Mark Nottingham http://www.mnot.net/ From ned.freed@mrochek.com Wed Jul 18 19:16:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D692411E8096 for ; Wed, 18 Jul 2012 19:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVAXynM-u6Zy for ; Wed, 18 Jul 2012 19:16:20 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 10FBF11E807F for ; Wed, 18 Jul 2012 19:16:20 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OI08IMVGGW004RKR@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 18 Jul 2012 19:15:04 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHZVQBJXY80006TF@mauve.mrochek.com>; Wed, 18 Jul 2012 19:15:01 -0700 (PDT) Message-id: <01OI08IKU8880006TF@mauve.mrochek.com> Date: Wed, 18 Jul 2012 18:43:49 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 19 Jul 2012 11:17:31 +1000" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OHZZPTN9XS0006TF@mauve.mrochek.com> To: Mark Nottingham Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2012 02:16:21 -0000 > On 19/07/2012, at 7:46 AM, Ned Freed wrote: > >> Apps folks, > > > >> Tony has posted a new version of this draft that appears to address most > >> comments. Please review it and comment, especially if you provided > >> comments previously. > > > >> Some time ago, Mark Nottingham posted comments that have not been > >> thoroughly addressed: > >> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05998.html > > > > Those comments were and are out of order and I see no point in responding to > > them. > "Out of order"? Seriously? Last I checked, you don't Chair this WG. You need to brush up on your understanding of basic rules of committee procedure if you believe the Chair is the only one who can call something out of order. If we followed Robert's Rules here I would have called it a point of order. Points of order can be raised by anyone. But we're less formal, so I didn't use that term. That said, the Chairs are of course free to overrule me on this point. But in that case I'll flip the question around: Suppose your objection(s) regarding the appropriateness of the use of +suffixes were to be sustained. What then? How can those objections possibly be addressed in a document that does nothing but register the initial set of suffixes? That's why your objections are out of order. And again, if you care to rephrase them as objections to specific registrations, or to the content of those regitrations, that would make perfect sense for the present document. > > Questioning the utility of the +format suffixes was a matter to be dealt > > when the media type registration procedure was updated to define the registry. > > All the current document does is seed the already registry that is already > > specified and approved. > I did question it in my apps area review of the registration procedure > document : And your concerns were noted, and addressed to the extent we believed was necessary and appropriate. You subsequently chose not to pursue those objections further. That was your call. And now the document has been approved. > """ > * Section 4.2.8 introduces structured suffixes. These may be very popular, but I don't see any description of their value, nor appropriate vs. inappropriate use (and I suspect there are many opportunities for abuse here). Also, I suspect that having many of these will be very counterproductive, and therefore wonder whether DE is the appropriate registry policy here. > """ > You subsequently dodged the question > : I don't care if I set the question to tap dancing with a collection of angels on the head of a pin. The only relevant point is that you did not object further, the IESG has considered the document along with the reviews it received and approved it, and the document defining the mechanism and procedure you are now objecting to is in the RFC Editor queue. This is a standards process. Not a debating society where nothing is ever settled and every issue can be reopened on a whim. We have to have closure, and this particular process has gone on far too long as it is. And if you're regretting not saying more at an earlier point in the process, you should know you're hardly alone in having this happen to you. I've lost track of the number of times I've let something slide, or not reviewed something carefully enough, or not implemented something in a timely enough fashion, only to discover when later reviewing the resulting RFC that it contains something I consider to be egregiously wrong, or broken, or stupid, or whatever. (It happened to me today, as a matter of fact. And it's even happened when I coauthored the document in question. *cough* RFC 2231 *cough* I kick myself about this sort of stuff all the time. But what I don't do is try an unring bells that have already rung. And finally, I also try not to let the best be the enemy of the good. Suppose for a moment that media type suffixes, their clear popularity in actual use notwithstanding, have no real value. Is there a significant downside to having them? Or alternately, if the rules and process for them is not the best, is that going to cause harm? Ned From mnot@mnot.net Wed Jul 18 19:33:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5D721F84D6 for ; Wed, 18 Jul 2012 19:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.195 X-Spam-Level: X-Spam-Status: No, score=-105.195 tagged_above=-999 required=5 tests=[AWL=-2.596, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpIAAQMjc7PH for ; Wed, 18 Jul 2012 19:33:25 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id ED28B21F84D1 for ; Wed, 18 Jul 2012 19:33:18 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 63E2C22E257; Wed, 18 Jul 2012 22:34:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <01OI08IKU8880006TF@mauve.mrochek.com> Date: Thu, 19 Jul 2012 12:34:01 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <46E73CC5-2851-4F2C-9680-3C681ECA092A@mnot.net> References: <01OHZZPTN9XS0006TF@mauve.mrochek.com> <01OI08IKU8880006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2012 02:33:27 -0000 On 19/07/2012, at 11:43 AM, Ned Freed wrote: >> On 19/07/2012, at 7:46 AM, Ned Freed wrote: >=20 >>>> Apps folks, >>>=20 >>>> Tony has posted a new version of this draft that appears to address = most >>>> comments. Please review it and comment, especially if you provided >>>> comments previously. >>>=20 >>>> Some time ago, Mark Nottingham posted comments that have not been >>>> thoroughly addressed: >>>> = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05998.html >>>=20 >>> Those comments were and are out of order and I see no point in = responding to >>> them. >=20 >> "Out of order"? Seriously? Last I checked, you don't Chair this WG. >=20 > You need to brush up on your understanding of basic rules of committee > procedure if you believe the Chair is the only one who can call = something out > of order. >=20 > If we followed Robert's Rules here I would have called it a point of = order. > Points of order can be raised by anyone. But we're less formal, so I = didn't=20 > use that term. My rule of thumb is that when you refer to things like Roberts' Rules, = something has already failed. Anyway. > That's why your objections are out of order. And again, if you care to = rephrase > them as objections to specific registrations, or to the content of = those > regitrations, that would make perfect sense for the present document. Where have you seen me object to anything on this topic, Ned? At what = point did I raise an objection -- please point to it? I asked a few questions and expressed some concern. Kindly stop = misreading my intent. >> You subsequently dodged the question >> = := >=20 > I don't care if I set the question to tap dancing with a collection of = angels > on the head of a pin. The only relevant point is that you did not = object > further, the IESG has considered the document along with the reviews = it > received and approved it, and the document defining the mechanism and = procedure > you are now objecting to is in the RFC Editor queue. >=20 > This is a standards process. Not a debating society where nothing is = ever > settled and every issue can be reopened on a whim. We have to have = closure, and > this particular process has gone on far too long as it is. Oh, absolutely. I'm just a bit bewildered by the defensiveness and = aggression instigated by a couple of questions. > And if you're regretting not saying more at an earlier point in the = process, > you should know you're hardly alone in having this happen to you. I've = lost > track of the number of times I've let something slide, or not reviewed > something carefully enough, or not implemented something in a timely = enough > fashion, only to discover when later reviewing the resulting RFC that = it > contains something I consider to be egregiously wrong, or broken, or = stupid, or > whatever. (It happened to me today, as a matter of fact. And it's even > happened when I coauthored the document in question. *cough* RFC 2231 = *cough* >=20 > I kick myself about this sort of stuff all the time. But what I don't = do is try > an unring bells that have already rung. You're reading a LOT into my motivations, and I'd ask you to stop.=20 My concerns were first about the technical issues at hand, and later = that my (timely) comments seemed not to be addressed.=20 > And finally, I also try not to let the best be the enemy of the good. = Suppose > for a moment that media type suffixes, their clear popularity in = actual > use notwithstanding, have no real value. Is there a significant = downside > to having them? Or alternately, if the rules and process for them is = not > the best, is that going to cause harm? I suppose that's a response, of sorts. -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Jul 18 21:07:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF17911E8093 for ; Wed, 18 Jul 2012 21:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.887 X-Spam-Level: X-Spam-Status: No, score=-104.887 tagged_above=-999 required=5 tests=[AWL=-2.888, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGH9RCYARVKl for ; Wed, 18 Jul 2012 21:07:32 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2405311E8085 for ; Wed, 18 Jul 2012 21:07:32 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9E74022E256; Thu, 19 Jul 2012 00:08:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Thu, 19 Jul 2012 14:08:14 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <666EFE37-22A2-4BE7-8461-351DE09EEE18@mnot.net> References: To: Jan Algermissen X-Mailer: Apple Mail (2.1278) Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Inclusion-mechanism for draft-nottingham-json-home-01? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2012 04:07:32 -0000 I've considered it, but wouldreally want to squint hard at it before = doing it. Inclusion mechanisms IME are very tricky unless they're very carefully = designed; they made WSDL a mess, for example, and WADL wasn't much = better. It *might* be necessary, but I'd like to get a lot more = experience with the space before including (heh) it in the spec. Right now, my bet would be on using a pre-processor of some sort (i.e., = a "JSON include" mechanism) to generate the document you publish, if = it's a management problem on the back end your'e trying to solve. Make sense? Cheers, On 19/07/2012, at 12:28 AM, Jan Algermissen wrote: > Hi Mark, >=20 > I am playing around with your json-home I-D[1]. >=20 > Despite being entirely not a fan of generating artifacts like = json-home documents from code I am facing a situation where this seems = like the best way to get the point of following your nose across. >=20 > Having accepted generation for the moment, I am facing the issue of = integrating generated aspects of the home document and non-generated = aspects. >=20 > Hence the question: Have you considered an inclusion mechanism for = json-home documents to split them into parts with different locations = and ownership? >=20 > I am not sure about this, but it would also open up options for = managing parts with differing live times, probably to allow features = under development to change far more frequently than the stable = 'official' parts. >=20 > Your example might then look something like this: >=20 > { > "resources": { > "http://example.org/rel/widgets": { > "href": "/widgets/" > }, > "http://example.org/rel/widget": { > "href-template": "/widgets/{widget_id}", > "href-vars": { > "widget_id": "http://example.org/param/widget" > }, > "hints": { > "allow": ["GET", "PUT", "DELETE", "PATCH"], > "representations": ["application/json"], > "accept-patch": ["application/json-patch"], > "accept-post": ["application/xml"], > "accept-ranges": ["bytes"] > } > } > }, > "include" : "/home/inc/other.js", > "include" : "/home/inc/dev-features-02.js", > } >=20 >=20 > However, I am all for making crystal clear that such documentation is = intended to be so stable that generation is actually a non-use case. >=20 > Jan >=20 >=20 > [1] http://tools.ietf.org/html/draft-nottingham-json-home-01 -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Jul 18 22:47:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE57B21F862B for ; Wed, 18 Jul 2012 22:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhHcXGJHjrBb for ; Wed, 18 Jul 2012 22:47:47 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D066D21F8629 for ; Wed, 18 Jul 2012 22:47:46 -0700 (PDT) Received: from [10.5.67.171] (unknown [72.32.115.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DE26322E253; Thu, 19 Jul 2012 01:48:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <63F18980-6462-49DF-8A6E-58E6B5F634C6@nordsc.com> Date: Thu, 19 Jul 2012 15:48:28 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <6B73AD97-849A-475B-9607-D304499DAE1B@mnot.net> References: <63F18980-6462-49DF-8A6E-58E6B5F634C6@nordsc.com> To: Jan Algermissen X-Mailer: Apple Mail (2.1278) Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Avoiding sending out 'problematic' signals with jason-home X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2012 05:47:47 -0000 Hey Jan, On 19/07/2012, at 12:55 AM, Jan Algermissen wrote: > Hi Mark, >=20 > [sorry, I had somehow unsubscribed from the list and hence cannot = reply to the postings I mention below] >=20 > in [1] you responded: >=20 > "E.g., I believe that "versioning" an API should involve minting a new = home document, and serving both side-by-side for a period." >=20 > If something like this would make it into the draft I think it would = send out wrong impressions. FWIW, versioning happens at the media type / = conneg level and URIs should remains stable. Granted there can be = exceptions, but once you hand out 'versioning capabilities' to the world = they'll all just jump on it like crazy because it satisfies SOAPy brains = too easily. >=20 > You crafted the wording of the 'hints' section so carefully, but I am = still sure, people will thankfully mistake it as a design-time WADL-like = tool. Let's not add 'versioning' to that. I probably think of "versioning" in a way that's different to most = people, to the point where I probably shouldn't use that word, sorry. I see a home document being a collection of resource objects that is = added to over time; you can make backwards-compatible changes by adding = new relations to it, or by some kinds of modifications to it. At some point far in the future, that home document *might* get so = bloated and crufty that you decide to mint a new one. At that point, = you'd create a new home document and direct new users to it, encouraging = old users to upgrade. That's what I mean by "versioning" the home = document.=20 Evolving (I'll avoid the "V" word) the individual formats and relation = types used is indeed an entirely separable and separate thing. Now, to the original discussion; could you do that new home document on = a new hostname? Certainly (e.g., if you're on api.example.com, you could = mint new-api.example.com). A few sites have already followed this = pattern roughly, IIRC. I'm still not quite sure a .well-known is = necessary, tho. > In [2] you respond: >=20 > >> Right now i see how the client will have default expectations of what >> GET, PUT, DELETE and PATCH will do (namely, read, write, remove, >> modify), but i would not know how to define default expectations of >> what a POST would do (because we can't talk of inserting without >> talking of collections). >=20 > Yep, I want to go there. > >=20 > Umm, am I missing something? >=20 > The expectations a client can have regarding the POST are already = sufficiently defined by the target resource semantics the client = understands from understanding the link relation it follows. >=20 > The expectations regarding methods are not a 'default' that can be = extended. HTTP already defines their meaning. Adding expectations on to = means creating a new protocol. I'm talking about a hint that lets clients know that they can create a = resource with a given relation by POSTing to a particular resource; = nothing more. It's a common enough pattern that it's useful to surface. It's really just a shortcut; the link relation type + media type still = define the semantics of POSTing to the resource, it's just surfacing = this information in an easy-to-read way for a common case. Think of it = as a mini-form. Is that less concerning? > I really do think that something as clean and simple as json-home = moves us a great step forward in terms of handing wanna-be REST adopters = the necessary tools! >=20 > But I also think it is a very slippery slope regarding the issue of = helping adopters to actually go through a mind shift away from RPC = towards a use of HTTP that actually brings them the benefits they expect = from it. Any RPC-ish touch will make that shift harder, IMHO. Absolutely; that's exactly why I'm treading so gingerly. Cheers, -- Mark Nottingham http://www.mnot.net/ From jan.algermissen@nordsc.com Wed Jul 18 23:06:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3D621F853B for ; Wed, 18 Jul 2012 23:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[AWL=-3.083, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFm4vRaMKhkc for ; Wed, 18 Jul 2012 23:06:39 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE2021F8609 for ; Wed, 18 Jul 2012 23:06:37 -0700 (PDT) Received: from [192.168.2.103] (p548FAD48.dip.t-dialin.net [84.143.173.72]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LhAAN-1Tc3XV382p-00oOvG; Thu, 19 Jul 2012 08:07:26 +0200 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: <666EFE37-22A2-4BE7-8461-351DE09EEE18@mnot.net> Date: Thu, 19 Jul 2012 08:07:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <91185A17-A56F-493E-A17F-EA6C0B6218B6@nordsc.com> References: <666EFE37-22A2-4BE7-8461-351DE09EEE18@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:NBpHSWM0k/oArdRoakqQcA7vZRjXeTaZD9vS69RqbiV cMaZLNRw9WQiqTIois4UDNDn5euamhlCik4ADQOedQ7rFj8+rz dEVHm3niBX8e6pIuNcraJ8Qilyii/xP61OLxZqwz6e2OyH3kaS pvmmKZdLdN5/kgbgKUVqAriNSL/vgrYVnrOpBkyfQHPWWJLd9f 1RsCd89VF3cVF8yChTdQHxTy2Tn1BeQ34KuNL6w20e0Y6O3YZo 9/trTNNtEp1UcfWb0KYwCwlxnlGqA030GpEvqDTaV8VcTE/JqZ gseAFbgj2ceU93Ie+/Gq6kdDuBv/te0kp2egUl7J1KXUDCKmGd VduCxq8Mlw1eQP31C+RJ21ztDKsL+jxqFtelNYjiy2hyfRUPFl Oug90diSXz6yQ== Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Inclusion-mechanism for draft-nottingham-json-home-01? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2012 06:06:40 -0000 On Jul 19, 2012, at 6:08 AM, Mark Nottingham wrote: > I've considered it, but wouldreally want to squint hard at it before = doing it. Yes, my feeling, too. >=20 > Inclusion mechanisms IME are very tricky unless they're very carefully = designed; they made WSDL a mess, for example, and WADL wasn't much = better. It *might* be necessary, but I'd like to get a lot more = experience with the space before including (heh) it in the spec. >=20 > Right now, my bet would be on using a pre-processor of some sort = (i.e., a "JSON include" mechanism) to generate the document you publish, = if it's a management problem on the back end your'e trying to solve. >=20 > Make sense? Absolutely. Jan >=20 > Cheers, >=20 >=20 > On 19/07/2012, at 12:28 AM, Jan Algermissen wrote: >=20 >> Hi Mark, >>=20 >> I am playing around with your json-home I-D[1]. >>=20 >> Despite being entirely not a fan of generating artifacts like = json-home documents from code I am facing a situation where this seems = like the best way to get the point of following your nose across. >>=20 >> Having accepted generation for the moment, I am facing the issue of = integrating generated aspects of the home document and non-generated = aspects. >>=20 >> Hence the question: Have you considered an inclusion mechanism for = json-home documents to split them into parts with different locations = and ownership? >>=20 >> I am not sure about this, but it would also open up options for = managing parts with differing live times, probably to allow features = under development to change far more frequently than the stable = 'official' parts. >>=20 >> Your example might then look something like this: >>=20 >> { >> "resources": { >> "http://example.org/rel/widgets": { >> "href": "/widgets/" >> }, >> "http://example.org/rel/widget": { >> "href-template": "/widgets/{widget_id}", >> "href-vars": { >> "widget_id": "http://example.org/param/widget" >> }, >> "hints": { >> "allow": ["GET", "PUT", "DELETE", "PATCH"], >> "representations": ["application/json"], >> "accept-patch": ["application/json-patch"], >> "accept-post": ["application/xml"], >> "accept-ranges": ["bytes"] >> } >> } >> }, >> "include" : "/home/inc/other.js", >> "include" : "/home/inc/dev-features-02.js", >> } >>=20 >>=20 >> However, I am all for making crystal clear that such documentation is = intended to be so stable that generation is actually a non-use case. >>=20 >> Jan >>=20 >>=20 >> [1] http://tools.ietf.org/html/draft-nottingham-json-home-01 >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 From dret@berkeley.edu Wed Jul 18 23:38:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4DC21F84F8 for ; Wed, 18 Jul 2012 23:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Beo2LXBTBsJ for ; Wed, 18 Jul 2012 23:38:27 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id E9B1B21F84F2 for ; Wed, 18 Jul 2012 23:38:27 -0700 (PDT) Received: from laubervilliers-151-13-21-144.w217-128.abo.wanadoo.fr ([217.128.60.144] helo=dretair.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1SrkOL-0007vw-AQ; Wed, 18 Jul 2012 23:39:19 -0700 Message-ID: <5007AB98.5060201@berkeley.edu> Date: Thu, 19 Jul 2012 08:39:20 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Mark Nottingham References: <666EFE37-22A2-4BE7-8461-351DE09EEE18@mnot.net> In-Reply-To: <666EFE37-22A2-4BE7-8461-351DE09EEE18@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Inclusion-mechanism for draft-nottingham-json-home-01? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2012 06:38:28 -0000 On 2012-07-19 06:08 , Mark Nottingham wrote: > Inclusion mechanisms IME are very tricky unless they're very carefully designed; they made WSDL a mess, for example, and WADL wasn't much better. It *might* be necessary, but I'd like to get a lot more experience with the space before including (heh) it in the spec. > Right now, my bet would be on using a pre-processor of some sort (i.e., a "JSON include" mechanism) to generate the document you publish, if it's a management problem on the back end your'e trying to solve. for the XML version of home documents, that could translate into requiring that xml-home processors support XInclude, or publishers could run XInclude processes server-side, if the requirement for clients seems to be too much. 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 mikekelly321@gmail.com Thu Jul 19 01:22:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB9A21F86A8 for ; Thu, 19 Jul 2012 01:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dME4chrrMJbp for ; Thu, 19 Jul 2012 01:22:14 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCB5F21F86D3 for ; Thu, 19 Jul 2012 01:22:13 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3947712obb.31 for ; Thu, 19 Jul 2012 01:23:06 -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=2r77t5EbpwRerZlXB7pG8vIT5Z76CpKe1U76xGXgb5E=; b=qte5wYWlT7KyrEVYjnL3YBcXzrsCHjkYEySUP0tG1nNFUAvLnVY//aGcyQxCFPRTUo H/wmDpgr3J8vAkDkh3MZJvdV5JsGvc7IhytN2VJJ1SRgs12pLqLgIh2uVCiaMbb1mw7l E1Y0otbPkD/WzsuE+qSa3beJa1Lw8ZD+FC9Hz54fwdCzCnuKVL5D+HBcckNN/HnjaZnz FPRtgfmx1RzI11lh8ZZCeV27I3TtvBGkUMcrdaK1YrLUkKXedYUNjXynJERD7tTJaMCf u04vCAUyYrmZgy5Q2JeAf4rNmmUJ5QfIZN6dCjmYT5EkV8V5r/xM1lpRNrwWhHx3GS1V toig== MIME-Version: 1.0 Received: by 10.60.12.234 with SMTP id b10mr1129435oec.72.1342686186294; Thu, 19 Jul 2012 01:23:06 -0700 (PDT) Received: by 10.60.65.234 with HTTP; Thu, 19 Jul 2012 01:23:06 -0700 (PDT) In-Reply-To: <6B73AD97-849A-475B-9607-D304499DAE1B@mnot.net> References: <63F18980-6462-49DF-8A6E-58E6B5F634C6@nordsc.com> <6B73AD97-849A-475B-9607-D304499DAE1B@mnot.net> Date: Thu, 19 Jul 2012 09:23:06 +0100 Message-ID: From: Mike Kelly To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Avoiding sending out 'problematic' signals with jason-home X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2012 08:22:16 -0000 On Thu, Jul 19, 2012 at 6:48 AM, Mark Nottingham wrote: > Hey Jan, > > On 19/07/2012, at 12:55 AM, Jan Algermissen wrote: > >> Hi Mark, >> >> [sorry, I had somehow unsubscribed from the list and hence cannot reply = to the postings I mention below] >> >> in [1] you responded: >> >> "E.g., I believe that "versioning" an API should involve minting a new h= ome document, and serving both side-by-side for a period." >> >> If something like this would make it into the draft I think it would sen= d out wrong impressions. FWIW, versioning happens at the media type / conne= g level and URIs should remains stable. Granted there can be exceptions, bu= t once you hand out 'versioning capabilities' to the world they'll all just= jump on it like crazy because it satisfies SOAPy brains too easily. >> >> You crafted the wording of the 'hints' section so carefully, but I am st= ill sure, people will thankfully mistake it as a design-time WADL-like tool= . Let's not add 'versioning' to that. > > I probably think of "versioning" in a way that's different to most people= , to the point where I probably shouldn't use that word, sorry. > > I see a home document being a collection of resource objects that is adde= d to over time; you can make backwards-compatible changes by adding new rel= ations to it, or by some kinds of modifications to it. > > At some point far in the future, that home document *might* get so bloate= d and crufty that you decide to mint a new one. At that point, you'd create= a new home document and direct new users to it, encouraging old users to u= pgrade. That's what I mean by "versioning" the home document. > > Evolving (I'll avoid the "V" word) the individual formats and relation ty= pes used is indeed an entirely separable and separate thing. > > Now, to the original discussion; could you do that new home document on a= new hostname? Certainly (e.g., if you're on api.example.com, you could min= t new-api.example.com). A few sites have already followed this pattern roug= hly, IIRC. I'm still not quite sure a .well-known is necessary, tho. > > >> In [2] you respond: >> >> >>> Right now i see how the client will have default expectations of what >>> GET, PUT, DELETE and PATCH will do (namely, read, write, remove, >>> modify), but i would not know how to define default expectations of >>> what a POST would do (because we can't talk of inserting without >>> talking of collections). >> >> Yep, I want to go there. >> >> >> Umm, am I missing something? >> >> The expectations a client can have regarding the POST are already suffic= iently defined by the target resource semantics the client understands from= understanding the link relation it follows. >> >> The expectations regarding methods are not a 'default' that can be exten= ded. HTTP already defines their meaning. Adding expectations on to means cr= eating a new protocol. > > I'm talking about a hint that lets clients know that they can create a re= source with a given relation by POSTing to a particular resource; nothing m= ore. It's a common enough pattern that it's useful to surface. > > It's really just a shortcut; the link relation type + media type still de= fine the semantics of POSTing to the resource, it's just surfacing this inf= ormation in an easy-to-read way for a common case. Think of it as a mini-fo= rm. > > Is that less concerning? > So is it intended that automated clients would use this control when making the request? Or is it just a bit of extra sugar to help a humans when they're exploring the API? I'm assuming the latter, as I can't see how the former would work in practi= ce. Cheers, M From superuser@gmail.com Thu Jul 19 06:15:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6939721F8794 for ; Thu, 19 Jul 2012 06:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrFlvKAglQ0b for ; Thu, 19 Jul 2012 06:15:23 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 08D3721F8726 for ; Thu, 19 Jul 2012 06:15:22 -0700 (PDT) Received: by eekc1 with SMTP id c1so771189eek.31 for ; Thu, 19 Jul 2012 06:16:15 -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=07BnQkmFdiS8OF6Y7+3mUWRUQ/XctX4/gYRVuliBncU=; b=btZpUhiJrs7cipt0Z1I2SOjOaG+bu2EqlwDXSQSUSzxiF64je56xK07nQU8CrB678n cxowmAp+hTQDerIROs0R3e7/UMi/ilvyV/F/glp8zajCGb4LXuCxy4SV4jF0aH4GBGO4 6J10Er0HojshqiLEwSKomXsSDIKTfXOoAab8Kg19qpIcxTTUqQ9Rhy4+GcVu/9yEdSJe e5caJFodjJ2v7B2nmQcXeW6LLYPkpkTIaKltAEbtdMNdf4Tenzl7MGGZQJ6AhnJye6QJ z9D6sfFqMT6I917pNclaFfijO6uq/blrDfTtOZkVrIWCbq3nzBZT8BLb1/Gw+lqWVEP4 CxCg== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr2229885lab.9.1342703775226; Thu, 19 Jul 2012 06:16:15 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 19 Jul 2012 06:16:15 -0700 (PDT) Date: Thu, 19 Jul 2012 06:16:15 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=e89a8f22c4118f9bc004c52e95cf Subject: [apps-discuss] APPSAWG Process and Milestones X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2012 13:15:24 -0000 --e89a8f22c4118f9bc004c52e95cf Content-Type: text/plain; charset=ISO-8859-1 Hello APPSAWG folks, Barry and your co-chairs have been discussing working group milestones. When APPSAWG was chartered we logged a single milestone in the charter, namely what was then our only document. Since then we haven't been updating these as new work arrives or old work completes. We're looking at adopting a new procedure in APPSAWG, partly to keep the milestones current but also to improve document progress in general and avoid these long idle periods they seem to suffer. The procedure is described here, and we'd like some feedback on it before selecting a path forward. The idea is to assign both a document shepherd and a target date for submission to the IESG ("Publication Requested" state) at the time a document is accepted into APPSAWG. That date, once agreed, will be added to our charter as a milestone. The document shepherd is typically a working group chair, but we might take the liberty from time to time to assign someone else. That person will be responsible for keeping the document active and working with the author(s) to ensure feedback is appropriately addressed. Selection of the shepherd will consider that person's availability to help drive progress of the document so nothing stagnates, and notify the co-chairs when a change to the target date will be needed. We feel this will improve the efficiency of document processing in APPSAWG, and will also spread some of the workload around. It might also give some newcomers the support they need to get their work processed without undue delay, and allow a few people who've never shepherded a document before to give it a try. We have the following documents active: draft-ietf-appsawg-malformed-mail (shepherd: Salvatore) draft-ietf-appsawg-media-type-suffix-regs (shepherd: Murray) draft-ietf-appsawg-json-patch (shepherd: Murray) draft-ietf-appsawg-json-pointer (shepherd: Murray) draft-ietf-appsawg-webfinger (shepherd: Salvatore) We propose the following milestones: draft-ietf-appsawg-malformed-mail: November 2012 draft-ietf-appsawg-media-type-suffix-regs: August 2012 draft-ietf-appsawg-json-patch: October 2012 draft-ietf-appsawg-json-pointer: October 2012 draft-ietf-appsawg-webfinger: December 2012 So, comments please, on both the procedure and the proposed milestones for these. Thanks, -MSK and (soon officially) Salvatore, APPSAWG co-chairs --e89a8f22c4118f9bc004c52e95cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello APPSAWG folks,

Barry and your co-chairs have been=20 discussing working group milestones.=A0 When APPSAWG was chartered we=20 logged a single milestone in the charter, namely what was then our only=20 document.=A0 Since then we haven't been updating these as new work arri= ves or old work completes.

We're looking at adopting a new procedure in APPSAWG, partly to kee= p the milestones current but also to improve document progress in general and avoid these long idle periods they seem to suffer.=A0 The procedure=20 is described here, and we'd like some feedback on it before selecting a= =20 path forward.

The idea is to assign both a document shepherd and a target date for submission to the IESG ("Publication Requested" state) at the ti= me a document is accepted into=20 APPSAWG.=A0 That date, once agreed, will be added to our charter as a=20 milestone.=A0 The document shepherd is typically a working group chair,=20 but we might take the liberty from time to time to assign someone else.=A0 That person will be responsible for keeping the document active and=20 working with the author(s) to ensure feedback is appropriately=20 addressed.=A0 Selection of the shepherd will consider that person's=20 availability to help drive progress of the document so nothing=20 stagnates, and notify the co-chairs when a change to the target date=20 will be needed.

We feel this will improve the efficiency of document processing in=20 APPSAWG, and will also spread some of the workload around.=A0 It might=20 also give some newcomers the support they need to get their work=20 processed without undue delay, and allow a few people who've never=20 shepherded a document before to give it a try.

We have the following documents active:

draft-ietf-appsawg-malfo= rmed-mail (shepherd: Salvatore)
draft-ietf-appsawg-medi= a-type-suffix-regs (shepherd: Murray)
draft-ietf-appsawg-json-patch (she= pherd: Murray)
draft-ietf-appsawg-json-pointer (shepherd: Murray)
draft-ietf-appsawg-we= bfinger (shepherd: Salvatore)

We propose the following milestones:
draft-ietf-appsawg-malformed-mail: November 2012
draft-ietf-appsawg-media-type-suffix-regs: August 2012
draft-ietf-appsawg-json-patch: October 2012
draft-ietf-appsawg-json-pointer: October 2012
draft-ietf-appsawg-webfinger: December 2012

So, comments please, on = both the procedure and the proposed milestones for these.

Thanks,
-MSK and (soon officially) Salvatore, APPSAWG co-chairs
--e89a8f22c4118f9bc004c52e95cf-- From stpeter@stpeter.im Thu Jul 19 07:39:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E18921F86F6 for ; Thu, 19 Jul 2012 07:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPJZpRGHXACW for ; Thu, 19 Jul 2012 07:39:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AAE3B21F86F3 for ; Thu, 19 Jul 2012 07:39:09 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D6AE94005A; Thu, 19 Jul 2012 08:59:08 -0600 (MDT) Message-ID: <50081500.9060902@stpeter.im> Date: Thu, 19 Jul 2012 08:09:04 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] APPSAWG Process and Milestones X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2012 14:39:10 -0000 On 7/19/12 7:16 AM, Murray S. Kucherawy wrote: > So, comments please, on both the procedure and the proposed milestones > for these. +1 to both. /psa From ben@niven-jenkins.co.uk Thu Jul 19 11:09:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30E721F86B7 for ; Thu, 19 Jul 2012 11:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZsHhX4KybGE for ; Thu, 19 Jul 2012 11:09:40 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id D9DE921F86B1 for ; Thu, 19 Jul 2012 11:09:39 -0700 (PDT) Received: from 52.red-80-25-156.staticip.rima-tde.net ([80.25.156.52] helo=[192.168.11.169]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SrvBI-0007Op-6M; Thu, 19 Jul 2012 19:10:32 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Thu, 19 Jul 2012 19:10:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jan Algermissen X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: Mark Nottingham , "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Inclusion-mechanism for draft-nottingham-json-home-01? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2012 18:09:45 -0000 Jan, On 18 Jul 2012, at 15:28, Jan Algermissen wrote: > Hi Mark, >=20 > I am playing around with your json-home I-D[1]. >=20 > Despite being entirely not a fan of generating artifacts like = json-home documents from code I am facing a situation where this seems = like the best way to get the point of following your nose across. >=20 > Having accepted generation for the moment, I am facing the issue of = integrating generated aspects of the home document and non-generated = aspects. >=20 > Hence the question: Have you considered an inclusion mechanism for = json-home documents to split them into parts with different locations = and ownership? Wouldn't having a json-home document where some of the links are to 1 or = more other json-home document(s) solve that for you while using the = specification in the current draft as-is? Ben >=20 > I am not sure about this, but it would also open up options for = managing parts with differing live times, probably to allow features = under development to change far more frequently than the stable = 'official' parts. >=20 > Your example might then look something like this: >=20 > { > "resources": { > "http://example.org/rel/widgets": { > "href": "/widgets/" > }, > "http://example.org/rel/widget": { > "href-template": "/widgets/{widget_id}", > "href-vars": { > "widget_id": "http://example.org/param/widget" > }, > "hints": { > "allow": ["GET", "PUT", "DELETE", "PATCH"], > "representations": ["application/json"], > "accept-patch": ["application/json-patch"], > "accept-post": ["application/xml"], > "accept-ranges": ["bytes"] > } > } > }, > "include" : "/home/inc/other.js", > "include" : "/home/inc/dev-features-02.js", > } >=20 >=20 > However, I am all for making crystal clear that such documentation is = intended to be so stable that generation is actually a non-use case. >=20 > Jan >=20 >=20 > [1] http://tools.ietf.org/html/draft-nottingham-json-home-01 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From jan.algermissen@nordsc.com Thu Jul 19 12:25:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E7921F8775 for ; Thu, 19 Jul 2012 12:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.261 X-Spam-Level: X-Spam-Status: No, score=-4.261 tagged_above=-999 required=5 tests=[AWL=-2.013, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrXqhz1otJbX for ; Thu, 19 Jul 2012 12:25:54 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 37FC721F8773 for ; Thu, 19 Jul 2012 12:25:53 -0700 (PDT) Received: from [192.168.2.103] (p548FAD48.dip.t-dialin.net [84.143.173.72]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0M0zHj-1TiVzg3mH9-00v9QG; Thu, 19 Jul 2012 21:26:44 +0200 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: Date: Thu, 19 Jul 2012 21:26:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <89DCF1F4-7CFA-4454-B09B-2217098FBD43@nordsc.com> References: To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:/oKVoM9fGa4jYaTE16I4l3lFdsmSSKggfJys/Zhb1IB TBon0urVK5aM1HFfrRfwEfudn5VcnycP2IZXDJcg/4vMC+N7wR U7wl/jaJtTPWR8RjgwWCgpjAdXR7f51HfAwWpZaupcSNpx2D4B oUJYLX/xjagggFdkJvd4A+YXrJea+fxCgLSSWSU6nkhufNGDwv Mthidwyykvj2QY0Xxfdq5ragRJ4+vWh6PCf81cdG157uUqXYwi +XJSOdqOsfYPnsAC3kGC6fQQmiBgoOH3Jee7zLhhY8LO2HDHMg FE+j9NQQSIYlapFIScIFMYFzqpbhZVO6kHKWdbrk8c+fKcfjYl 3GYGdMn2x63K8pTNdHEou6Fh57V5h5F+cZ7WW9xu42JsBQ85K/ PRpHh2wH8vrzg== Cc: Mark Nottingham , "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Inclusion-mechanism for draft-nottingham-json-home-01? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2012 19:25:55 -0000 On Jul 19, 2012, at 8:10 PM, Ben Niven-Jenkins wrote: > Jan, >=20 > On 18 Jul 2012, at 15:28, Jan Algermissen wrote: >=20 >> Hi Mark, >>=20 >> I am playing around with your json-home I-D[1]. >>=20 >> Despite being entirely not a fan of generating artifacts like = json-home documents from code I am facing a situation where this seems = like the best way to get the point of following your nose across. >>=20 >> Having accepted generation for the moment, I am facing the issue of = integrating generated aspects of the home document and non-generated = aspects. >>=20 >> Hence the question: Have you considered an inclusion mechanism for = json-home documents to split them into parts with different locations = and ownership? >=20 > Wouldn't having a json-home document where some of the links are to 1 = or more other json-home document(s) Yes, that could be an option. Something like 'seeAlso' :-) > solve that for you while using the specification in the current draft = as-is? >=20 Is was more curious about Mark's thoughts than having a real problem. = And I al all for simpler specs. Jan > Ben >=20 >=20 >>=20 >> I am not sure about this, but it would also open up options for = managing parts with differing live times, probably to allow features = under development to change far more frequently than the stable = 'official' parts. >>=20 >> Your example might then look something like this: >>=20 >> { >> "resources": { >> "http://example.org/rel/widgets": { >> "href": "/widgets/" >> }, >> "http://example.org/rel/widget": { >> "href-template": "/widgets/{widget_id}", >> "href-vars": { >> "widget_id": "http://example.org/param/widget" >> }, >> "hints": { >> "allow": ["GET", "PUT", "DELETE", "PATCH"], >> "representations": ["application/json"], >> "accept-patch": ["application/json-patch"], >> "accept-post": ["application/xml"], >> "accept-ranges": ["bytes"] >> } >> } >> }, >> "include" : "/home/inc/other.js", >> "include" : "/home/inc/dev-features-02.js", >> } >>=20 >>=20 >> However, I am all for making crystal clear that such documentation is = intended to be so stable that generation is actually a non-use case. >>=20 >> Jan >>=20 >>=20 >> [1] http://tools.ietf.org/html/draft-nottingham-json-home-01 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From mnot@mnot.net Thu Jul 19 17:33:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1EE11E80A6 for ; Thu, 19 Jul 2012 17:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.193 X-Spam-Level: X-Spam-Status: No, score=-105.193 tagged_above=-999 required=5 tests=[AWL=-2.594, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhGqpv+gUShO for ; Thu, 19 Jul 2012 17:33:58 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBE411E80BE for ; Thu, 19 Jul 2012 17:33:53 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3E02822E259; Thu, 19 Jul 2012 20:34:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: Date: Fri, 20 Jul 2012 10:34:38 +1000 Content-Transfer-Encoding: 7bit Message-Id: References: To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] APPSAWG Process and Milestones X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jul 2012 00:33:59 -0000 On 19/07/2012, at 11:16 PM, Murray S. Kucherawy wrote: > draft-ietf-appsawg-json-patch: October 2012 > draft-ietf-appsawg-json-pointer: October 2012 Seems doable to me. Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Thu Jul 19 17:59:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEA911E80B6 for ; Thu, 19 Jul 2012 17:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.176 X-Spam-Level: X-Spam-Status: No, score=-105.176 tagged_above=-999 required=5 tests=[AWL=-2.577, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJvTVL-Hov2x for ; Thu, 19 Jul 2012 17:59:41 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C109011E80A6 for ; Thu, 19 Jul 2012 17:59:41 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0E22522E1F4; Thu, 19 Jul 2012 21:00:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Fri, 20 Jul 2012 11:00:31 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <0B1F6C59-FFA6-46D9-9541-9716BEEED76D@mnot.net> References: To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1278) Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Inclusion-mechanism for draft-nottingham-json-home-01? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jul 2012 00:59:42 -0000 On 20/07/2012, at 4:10 AM, Ben Niven-Jenkins wrote: > Wouldn't having a json-home document where some of the links are to 1 = or more other json-home document(s) solve that for you while using the = specification in the current draft as-is? Oof. I'm not sure I like where that leads. Would you expect a client to = deref and combine all of the home documents? -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Thu Jul 19 18:01:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104D411E80CE for ; Thu, 19 Jul 2012 18:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.16 X-Spam-Level: X-Spam-Status: No, score=-105.16 tagged_above=-999 required=5 tests=[AWL=-2.561, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-r0eUlq9cma for ; Thu, 19 Jul 2012 18:01:37 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 363D311E80CA for ; Thu, 19 Jul 2012 18:01:37 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7982F22E1F4; Thu, 19 Jul 2012 21:02:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: Date: Fri, 20 Jul 2012 11:02:27 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <63F18980-6462-49DF-8A6E-58E6B5F634C6@nordsc.com> <6B73AD97-849A-475B-9607-D304499DAE1B@mnot.net> To: Mike Kelly X-Mailer: Apple Mail (2.1278) Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Avoiding sending out 'problematic' signals with jason-home X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jul 2012 01:01:38 -0000 On 19/07/2012, at 6:23 PM, Mike Kelly wrote: >>> In [2] you respond: >>>=20 >>> >>>> Right now i see how the client will have default expectations of = what >>>> GET, PUT, DELETE and PATCH will do (namely, read, write, remove, >>>> modify), but i would not know how to define default expectations of >>>> what a POST would do (because we can't talk of inserting without >>>> talking of collections). >>>=20 >>> Yep, I want to go there. >>> >>>=20 >>> Umm, am I missing something? >>>=20 >>> The expectations a client can have regarding the POST are already = sufficiently defined by the target resource semantics the client = understands from understanding the link relation it follows. >>>=20 >>> The expectations regarding methods are not a 'default' that can be = extended. HTTP already defines their meaning. Adding expectations on to = means creating a new protocol. >>=20 >> I'm talking about a hint that lets clients know that they can create = a resource with a given relation by POSTing to a particular resource; = nothing more. It's a common enough pattern that it's useful to surface. >>=20 >> It's really just a shortcut; the link relation type + media type = still define the semantics of POSTing to the resource, it's just = surfacing this information in an easy-to-read way for a common case. = Think of it as a mini-form. >>=20 >> Is that less concerning? >>=20 >=20 > So is it intended that automated clients would use this control when > making the request? Or is it just a bit of extra sugar to help a > humans when they're exploring the API? >=20 > I'm assuming the latter, as I can't see how the former would work in = practice. For example, a client library could expose a call that lets a developer = create a new resource of a given relation type. Cheers, -- Mark Nottingham http://www.mnot.net/ From mikekelly321@gmail.com Fri Jul 20 00:33:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4BB21F85AF for ; Fri, 20 Jul 2012 00:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9FrHZ2etq72 for ; Fri, 20 Jul 2012 00:33:54 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7B921F85AC for ; Fri, 20 Jul 2012 00:33:54 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so144492wib.13 for ; Fri, 20 Jul 2012 00:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=jPAwG3bWVmM1QFOGpEViyASP3fUXwNLLQyzz4upSvF4=; b=FvFgxs0PbVXo3M6YqF+YwdMhpGHqn72ehH1Rpgkju+LfZEgBu+wUORwqgGwk5ZoQ7r zF51hCg2AkPeremwENxRFGMeL4KFqoOe4f7mgdSc8clp59kUfca+Fg2+GmO3NqtdnkLY s9WQtOLkjmhg6rzT75nVRzlRcqRx7R/LU7TbvTB+30DjkseTNEbR2wptqlgEJgdLl6aX kfUIaEDc6BTSbI6luZ2QKsUPWnYHQloLw/Y5LLWAoXYfJG4x7mz18dVuB5YpGpuzqw23 yhYwGFXWRcA4lfb4O0eiZUR8ExtdXfS56bD72v5OxNscONMxG6lQo1Croy4DYjj9yH5M fKvg== Received: by 10.180.82.39 with SMTP id f7mr11678144wiy.2.1342769689123; Fri, 20 Jul 2012 00:34:49 -0700 (PDT) Received: from [192.168.0.3] (5acf9147.bb.sky.com. [90.207.145.71]) by mx.google.com with ESMTPS id t8sm43131763wiy.3.2012.07.20.00.34.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Jul 2012 00:34:48 -0700 (PDT) References: <63F18980-6462-49DF-8A6E-58E6B5F634C6@nordsc.com> <6B73AD97-849A-475B-9607-D304499DAE1B@mnot.net> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: Mike Kelly Date: Fri, 20 Jul 2012 08:34:46 +0100 To: Mark Nottingham Cc: "apps-discuss@ietf.orgapplication-layer protocols" Subject: Re: [apps-discuss] Avoiding sending out 'problematic' signals with jason-home X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jul 2012 07:33:55 -0000 On 20 Jul 2012, at 02:02, Mark Nottingham wrote: >=20 > On 19/07/2012, at 6:23 PM, Mike Kelly wrote: >=20 >>>> In [2] you respond: >>>>=20 >>>> >>>>> Right now i see how the client will have default expectations of what >>>>> GET, PUT, DELETE and PATCH will do (namely, read, write, remove, >>>>> modify), but i would not know how to define default expectations of >>>>> what a POST would do (because we can't talk of inserting without >>>>> talking of collections). >>>>=20 >>>> Yep, I want to go there. >>>> >>>>=20 >>>> Umm, am I missing something? >>>>=20 >>>> The expectations a client can have regarding the POST are already suffi= ciently defined by the target resource semantics the client understands from= understanding the link relation it follows. >>>>=20 >>>> The expectations regarding methods are not a 'default' that can be exte= nded. HTTP already defines their meaning. Adding expectations on to means cr= eating a new protocol. >>>=20 >>> I'm talking about a hint that lets clients know that they can create a r= esource with a given relation by POSTing to a particular resource; nothing m= ore. It's a common enough pattern that it's useful to surface. >>>=20 >>> It's really just a shortcut; the link relation type + media type still d= efine the semantics of POSTing to the resource, it's just surfacing this inf= ormation in an easy-to-read way for a common case. Think of it as a mini-for= m. >>>=20 >>> Is that less concerning? >>>=20 >>=20 >> So is it intended that automated clients would use this control when >> making the request? Or is it just a bit of extra sugar to help a >> humans when they're exploring the API? >>=20 >> I'm assuming the latter, as I can't see how the former would work in prac= tice. >=20 > For example, a client library could expose a call that lets a developer cr= eate a new resource of a given relation type. >=20 Right, but how would the selection of method be made by the code? Would it b= e dynamic depending on what's in the allow hint? How would that logic deal w= ith a change that removed PUT and replaced it with POST? Cheers, M From hsivonen@gmail.com Fri Jul 20 01:58:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986B221F84CD for ; Fri, 20 Jul 2012 01:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5oChbvq5h4i for ; Fri, 20 Jul 2012 01:58:28 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C50221F84BD for ; Fri, 20 Jul 2012 01:58:28 -0700 (PDT) Received: by yhq56 with SMTP id 56so4088755yhq.31 for ; Fri, 20 Jul 2012 01:59:23 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=keCy7uXK7jJdtCkLQ/Rr2IXEUIesT7WgR65RsB2d5kI=; b=tkB9JDbZkkdL0phOAq22KG5nTa31azLmyTetCfjd4MAP5UvYV2jRbWA1Q6M1udDbtP 9fwKhmwb0tmgLQ/bNPUvmqHoMimPnj0njFnb2zAP1O7n/+uxKoc5ThbxAtLH+g9Dib7I OSM6aaq4/va++qiW5X5kcVbKCaJOSMR8LZvlZvNLMQeRTbLLnO+kx+1dfRgQm0Nky6O0 ap1MYXOUVCS+iuZ2fjPFBiQ8J/Ii5mRaTnK8z36AvXdRKrgArj7hfk7Jff9aQxLOrCpQ QryEQSKJOkWy8h8eggxfX5ZPm5VMoZ40VRfXxQp7SJmZkWo51WBzJ96T/LDCFykkagqJ +wfw== MIME-Version: 1.0 Received: by 10.236.145.40 with SMTP id o28mr5007404yhj.70.1342774763737; Fri, 20 Jul 2012 01:59:23 -0700 (PDT) Sender: hsivonen@gmail.com Received: by 10.100.49.34 with HTTP; Fri, 20 Jul 2012 01:59:23 -0700 (PDT) In-Reply-To: <01OHT7332FMS0006TF@mauve.mrochek.com> References: <20120711114411.694627c5@hetzer> <4FFD5000.8010908@gmx.de> <4FFD9713.7060006@dcrocker.net> <01OHPTP7PS260006TF@mauve.mrochek.com> <01OHT7332FMS0006TF@mauve.mrochek.com> Date: Fri, 20 Jul 2012 11:59:23 +0300 X-Google-Sender-Auth: ZsoVRSx_PNoZ_yQiQPMZzD8LLMk Message-ID: From: Henri Sivonen To: Ned Freed Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jul 2012 08:58:29 -0000 On Sat, Jul 14, 2012 at 4:17 AM, Ned Freed wrote: >> So I had to: >> 1. Add references to HTTP specification. >> 2. Simply syntax definition. >> 3. Separate issue definition and actual problems definition. >> 4. Write Security Considerations. >> 5. Change form of draft from standarising to proposing. >> 6. Find examples of errors, which are result of ambiguous strings. >> 7. Change order of elements in draft. >> 8. Think two times about sense of that project. > > I'm sorry to have to say it, but this completely misses the main > point of what I was suggesting. My suggestion was to write a document > that was first about the issues in general that arise from use of > the User-Agent string, and only secondarily about how a subset of those > issues can be addresses by nailing down the syntax. Furthermore, without implementor interest, this isn't going to go anywhere, and the draft seems completely out of touch with implementor interest. For example, http://tools.ietf.org/html/draft-karcz-uuas-00#section-2.1.2.1 describes a legacy thing that no implementor seems to be interested in adding at this point if they don't already have it, and implementors who still did have it two years ago have been removing it. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From alexey.melnikov@isode.com Fri Jul 20 02:56:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B3221F85A0 for ; Fri, 20 Jul 2012 02:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5PFico-58Xx for ; Fri, 20 Jul 2012 02:56:32 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 41A2A21F859B for ; Fri, 20 Jul 2012 02:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342778285; d=isode.com; s=selector; i=@isode.com; bh=mdX7ERx7dkTfkk9FnQoTFyoDHuphWxwF07I/gteGwCk=; 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=NNVrBwq/63bgSfyZHX4A0USRvcBPiR+uBkWDVsuqZuet2QEhpihI3s88PrvdfIWwPeNk8G rYYssnM3GUWYzCjpJGp6iQAga9R0si+DfM/Y2pXRSO0Fo7VW/I5y9zccBkboAErrD0ofFm jf3+PBjpvcibRQbuhifXjf/ajF3bEcE=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 20 Jul 2012 10:58:05 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <50086B10.4030901@isode.com> Date: Thu, 19 Jul 2012 21:16:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "Murray S. Kucherawy" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] APPSAWG Process and Milestones X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jul 2012 09:56:33 -0000 On 19/07/2012 14:16, Murray S. Kucherawy wrote: > Hello APPSAWG folks, > > Barry and your co-chairs have been discussing working group > milestones. When APPSAWG was chartered we logged a single milestone > in the charter, namely what was then our only document. Since then we > haven't been updating these as new work arrives or old work completes. > > We're looking at adopting a new procedure in APPSAWG, partly to keep > the milestones current but also to improve document progress in > general and avoid these long idle periods they seem to suffer. The > procedure is described here, and we'd like some feedback on it before > selecting a path forward. > > The idea is to assign both a document shepherd and a target date for > submission to the IESG ("Publication Requested" state) at the time a > document is accepted into APPSAWG. That date, once agreed, will be > added to our charter as a milestone. The document shepherd is > typically a working group chair, but we might take the liberty from > time to time to assign someone else. That person will be responsible > for keeping the document active and working with the author(s) to > ensure feedback is appropriately addressed. Selection of the shepherd > will consider that person's availability to help drive progress of the > document so nothing stagnates, and notify the co-chairs when a change > to the target date will be needed. > > We feel this will improve the efficiency of document processing in > APPSAWG, and will also spread some of the workload around. It might > also give some newcomers the support they need to get their work > processed without undue delay, and allow a few people who've never > shepherded a document before to give it a try. I like the procedure. > > We have the following documents active: > > draft-ietf-appsawg-malformed-mail (shepherd: Salvatore) > draft-ietf-appsawg-media-type-suffix-regs (shepherd: Murray) > draft-ietf-appsawg-json-patch (shepherd: Murray) > draft-ietf-appsawg-json-pointer (shepherd: Murray) > draft-ietf-appsawg-webfinger (shepherd: Salvatore) > > We propose the following milestones: > > draft-ietf-appsawg-malformed-mail: November 2012 > draft-ietf-appsawg-media-type-suffix-regs: August 2012 > draft-ietf-appsawg-json-patch: October 2012 > draft-ietf-appsawg-json-pointer: October 2012 > draft-ietf-appsawg-webfinger: December 2012 Looks Ok to me. > > So, comments please, on both the procedure and the proposed milestones > for these. > > Thanks, > > -MSK and (soon officially) Salvatore, APPSAWG co-chairs From ned.freed@mrochek.com Fri Jul 20 08:18:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E2E21F84C5 for ; Fri, 20 Jul 2012 08:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJcXrf00491q for ; Fri, 20 Jul 2012 08:18:19 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A308521F848F for ; Fri, 20 Jul 2012 08:18:19 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OI2E0Y61UO005PA2@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 20 Jul 2012 08:14:12 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHZVQBJXY80006TF@mauve.mrochek.com>; Fri, 20 Jul 2012 08:14:08 -0700 (PDT) Message-id: <01OI2E0VF5PQ0006TF@mauve.mrochek.com> Date: Fri, 20 Jul 2012 08:12:55 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 20 Jul 2012 11:59:23 +0300" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120711114411.694627c5@hetzer> <4FFD5000.8010908@gmx.de> <4FFD9713.7060006@dcrocker.net> <01OHPTP7PS260006TF@mauve.mrochek.com> <01OHT7332FMS0006TF@mauve.mrochek.com> To: Henri Sivonen Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jul 2012 15:18:20 -0000 > On Sat, Jul 14, 2012 at 4:17 AM, Ned Freed wrote: > >> So I had to: > >> 1. Add references to HTTP specification. > >> 2. Simply syntax definition. > >> 3. Separate issue definition and actual problems definition. > >> 4. Write Security Considerations. > >> 5. Change form of draft from standarising to proposing. > >> 6. Find examples of errors, which are result of ambiguous strings. > >> 7. Change order of elements in draft. > >> 8. Think two times about sense of that project. > > > > I'm sorry to have to say it, but this completely misses the main > > point of what I was suggesting. My suggestion was to write a document > > that was first about the issues in general that arise from use of > > the User-Agent string, and only secondarily about how a subset of those > > issues can be addresses by nailing down the syntax. > Furthermore, without implementor interest, this isn't going to go > anywhere, and the draft seems completely out of touch with implementor > interest. For example, > http://tools.ietf.org/html/draft-karcz-uuas-00#section-2.1.2.1 > describes a legacy thing that no implementor seems to be interested in > adding at this point if they don't already have it, and implementors > who still did have it two years ago have been removing it. Exactly. A document that explains a security issue first and proposes an implementation strategy second has value even if the second part is ignored. Ned From jan.algermissen@nordsc.com Sat Jul 21 03:34:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6893E21F8672 for ; Sat, 21 Jul 2012 03:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[AWL=-1.610, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1+HJJb6RWsF for ; Sat, 21 Jul 2012 03:34:51 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2807C21F848B for ; Sat, 21 Jul 2012 03:34:43 -0700 (PDT) Received: from [192.168.2.103] (p548F9AF3.dip.t-dialin.net [84.143.154.243]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0M8hNb-1TnOyV0EuB-00wEqa; Sat, 21 Jul 2012 12:35:40 +0200 From: Jan Algermissen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Jul 2012 12:35:38 +0200 Message-Id: <3836C1EF-F57B-4496-A1BB-5ADB4E731254@nordsc.com> To: "apps-discuss@ietf.org application-layer protocols" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:DzyUL+Kwe9FG9ZqVuvtfAAtHYC5da8ui8zPP4hP/oEQ ARNAPqUjnTii92qqth8vgksgnfByGVwhY7GZLp5Zx7ypKZL5I6 EZCEyAnd6JpZeoafo6MkVoleQw8s61604fZo4Bt4RFvwoTQuHX mSb6/qYC5qmY2dFSlbjsWcNQJOhawBhE4jmxOqV1QV0eUOIFSN IdR+nna2OBv5AH5gmYWNyN3n1CS31aANXi7vS9SrQ97mzknTM4 FSzj9okbGirDdN1X/XwnSE/+NAtE/eRTkCutfkAjRtc1B9Gu0c HQigIB4CCJgb1WpfcVFifqNDdiQbdkmm9hpHqIi0al8Nxwgh8M AQNe2ycq4ALPP1wbRnttv9bLN4MfPovHm/2lVt2EMu99YetYbG CD+yQLIKVjvBw== Subject: [apps-discuss] Question on URI-Templates - How to make non-variable segments optional? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jul 2012 10:34:51 -0000 Hi, I have a question on RFC 6570 [1]. Is it possible to define optional non-variable path segments? For example, there are customers with IDs and each customer can have 1-N = accounts with accountIds. The service I have provides customer information including all accounts = and customer information including just one account: http://example.org/svc/customers/{custId} and http://example.org/svc/customers/{custId}/accounts/{accountId} Is there a way to write a template that handles both productions in one = template? What I am looking for is a way to express that = /accounts/{accountId} is optional as a whole, not just {accountId}. Jan [1] http://tools.ietf.org/html/rfc6570= From ioseb.dzmanashvili@gmail.com Sat Jul 21 04:23:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE9021F867B for ; Sat, 21 Jul 2012 04:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YE48TnEIrz48 for ; Sat, 21 Jul 2012 04:23:43 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0FA21F84D9 for ; Sat, 21 Jul 2012 04:23:28 -0700 (PDT) Received: by bkty7 with SMTP id y7so3820501bkt.31 for ; Sat, 21 Jul 2012 04:24: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=GkJJonhlAS/01leCd2AXE2i5xidSFhQ5J7fMoJc7OWY=; b=LfUl/xX6fOlBbo7NHJbl4P2GBifbM46o66sgWXrABPYS6xKNGHoDEZcrsZBYaXut3i +TYLs0IJR98pMDu8XIHHrK4E6HdvjDsOIJOPzuEew3R1hNXtE9GMbC53R2sMzFBQZLVx plYbDCAIdPdMeW/34gVHrjCYnnpYcWHE6wyrRtOIazejSrfSiaj4zoP+B1zFnvc8sLZN KkOHEOPAf3+tOJUmVrMFKRxgKLvlhNBxiQ70cUpoLcafVrt4loM63aIhVtFiTk/fXL15 C2Cd3Tkg6r16fGf3VpDPvD1QtLux64WuOZUp7lMAnUfx2/cmSTvnn/aikXCPGN1A9btI J4JQ== MIME-Version: 1.0 Received: by 10.204.130.156 with SMTP id t28mr4724963bks.33.1342869866130; Sat, 21 Jul 2012 04:24:26 -0700 (PDT) Received: by 10.204.79.133 with HTTP; Sat, 21 Jul 2012 04:24:26 -0700 (PDT) In-Reply-To: <3836C1EF-F57B-4496-A1BB-5ADB4E731254@nordsc.com> References: <3836C1EF-F57B-4496-A1BB-5ADB4E731254@nordsc.com> Date: Sat, 21 Jul 2012 15:24:26 +0400 Message-ID: From: Ioseb Dzmanashvili To: Jan Algermissen Content-Type: multipart/alternative; boundary=00151743f82e59aca804c5554165 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Question on URI-Templates - How to make non-variable segments optional? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jul 2012 11:23:44 -0000 --00151743f82e59aca804c5554165 Content-Type: text/plain; charset=ISO-8859-1 Hello Jan, In recent weeks i was doing extensive URI Template spec related work( https://github.com/ioseb/uri-template) and as far as i can tell there is a possibility to control optional path segments with template like this: http://example.org/svc/customers/{custId}{/account*} In the example above {/account*} path segment expansion(i.e. "/") and explode operator(i.e. "*") achieves desired result without problems. Of course result depends on input variables. Below are examples: | $template = "http://example.org/svc/customers/{custId}{/account*}"; | $variables = array( | 'custId' => 21 | ); | | echo uri_template($template, $variables); | | // produces http://example.org/svc/customers/21 In the example above {/account*} part is ignored entirely as far as "account" variable was not provided. | $variables = array( | 'custId' => 21, | 'account' => array('accounts', 31) | ); | | echo uri_template($template, $variables); | | // produces http://example.org/svc/customers/21/accounts/31 In the example above, $variables array contains "account" variable which value is initialized to list(as per RFC) which forces URI Template processor to expand this variable to: /accounts/31 Hope this helps! Cheers, ioseb On Sat, Jul 21, 2012 at 2:35 PM, Jan Algermissen wrote: > Hi, > > I have a question on RFC 6570 [1]. > > Is it possible to define optional non-variable path segments? > > For example, there are customers with IDs and each customer can have 1-N > accounts with accountIds. > > The service I have provides customer information including all accounts > and customer information including just one account: > > > http://example.org/svc/customers/{custId} > > and > > http://example.org/svc/customers/{custId}/accounts/{accountId} > > > Is there a way to write a template that handles both productions in one > template? What I am looking for is a way to express that > /accounts/{accountId} is optional as a whole, not just {accountId}. > > > Jan > > > [1] http://tools.ietf.org/html/rfc6570 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Ioseb Dzmanashvili Lead Architect Picktek LLC 24b Khazbegi ave. Tbilisi, 0177, Georgia T (+995 32) 39.58.56, F (+1 202) 315.3934 picktek.com code.ge github.com/ioseb twitter.com/iosebi --00151743f82e59aca804c5554165 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Jan,

In recent weeks i was doing extensive URI Tem= plate spec related work(h= ttps://github.com/ioseb/uri-template) and as far as i can tell there is= a possibility to control optional path segments with template like this:


In the example above=A0{/account*} path segment expansion(= i.e. "/") and explode operator(i.e. "*") achieves desir= ed result without problems. Of course result depends on input variables. Be= low are =A0examples:

| =A0$variables =3D array(
<= div>| =A0=A0 'custId' =3D> 21
| =A0);
| =A0
| =A0echo uri_template($template, $v= ariables);
| =A0

In the example above=A0{/account*} part is ignored entirely as far as = "account" variable was not provided.
=A0
| = =A0$variables =3D array(
| =A0=A0 'custId' =A0=3D> 21,=
| =A0=A0 'account' =3D> array('accounts', 31)=
|=A0=A0);
|=A0=A0
|=A0=A0echo uri_template($templa= te, $variables);
|=A0=A0

In the example above, $variables array contains "a= ccount" variable which value is initialized to list(as per RFC) which = forces URI Template processor to expand this variable to:=A0/accounts/31

Hope this helps!

Cheers,
=
ioseb

On Sat, Jul 21, 2012 at 2:35= PM, Jan Algermissen <jan.algermissen@nordsc.com> w= rote:
Hi,

I have a question on RFC 6570 [1].

Is it possible to define optional non-variable path segments?

For example, there are customers with IDs and each customer can have 1-N ac= counts with accountIds.

The service I have provides customer information including all accounts and= customer information including just one account:


htt= p://example.org/svc/customers/{custId}

and

http://example.org/svc/customers/{custId}/accounts/{accou= ntId}


Is there a way to write a template that handles both productions in one tem= plate? What I am looking for is a way to express that /accounts/{accountId}= is optional as a whole, not just {accountId}.


Jan


[1] http:/= /tools.ietf.org/html/rfc6570
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



--
Ioseb Dzmana= shvili
Lead Architect
Picktek LLC
24b Khazbegi ave.
Tbilisi, 0= 177, Georgia
T (+995 32) 39.58.56, F (+1 202) 315.3934 --00151743f82e59aca804c5554165-- From jan.algermissen@nordsc.com Sat Jul 21 05:13:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AD021F84C5 for ; Sat, 21 Jul 2012 05:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=-1.342, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMo918ga7rPs for ; Sat, 21 Jul 2012 05:13:14 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEB621F84B6 for ; Sat, 21 Jul 2012 05:13:14 -0700 (PDT) Received: from [192.168.2.103] (p548F9AF3.dip.t-dialin.net [84.143.154.243]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MDl62-1T47252BTS-00Gcgl; Sat, 21 Jul 2012 14:14:11 +0200 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: <6B73AD97-849A-475B-9607-D304499DAE1B@mnot.net> Date: Sat, 21 Jul 2012 14:14:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <21163EC1-34DD-4EB7-8CDD-DFC9C6C2324C@nordsc.com> References: <63F18980-6462-49DF-8A6E-58E6B5F634C6@nordsc.com> <6B73AD97-849A-475B-9607-D304499DAE1B@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:2m0hO9gf0AFEArD+hlYBhX2N2hF4vfLVIDAs/Y1m4lr FiwSD/2T7bjrXGmpHqxnWvgThiBMz6qHxVaQZVv5bbkCmNmSEq w416ZMks9l+8S9Ly2R/eHYX0G5vVtwQodBGHyRjpz3i7I2m3ec iQrZHc4Mb0BKdCIkrmxHsqMsylQ8/wA/fHWz9vJ0Pljjt8jRYC yKBPodF5ZxH3iU1JOnSprCRnGxTmCpltiEnqfg3H506AFmrd8N UqQaV2RNo0G47x7CplNXea1pjjnI405h45VHo+irdyv1wC13OV sBIz4kyI78hxPwOoqz2XdRTr7qSEMDXOPYwyHzJyae7PPXo8OX janlyqMk8G5+qbYsCnmBcMbtrrxEGBztQ83NDvASr7aj0BDFdt cMic9PCbYZUBQ== Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Avoiding sending out 'problematic' signals with jason-home X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jul 2012 12:13:15 -0000 On Jul 19, 2012, at 7:48 AM, Mark Nottingham wrote: > Hey Jan, >=20 > On 19/07/2012, at 12:55 AM, Jan Algermissen wrote: >=20 >> Hi Mark, >>=20 >> [sorry, I had somehow unsubscribed from the list and hence cannot = reply to the postings I mention below] >>=20 >> in [1] you responded: >>=20 >> "E.g., I believe that "versioning" an API should involve minting a = new home document, and serving both side-by-side for a period." >>=20 >> If something like this would make it into the draft I think it would = send out wrong impressions. FWIW, versioning happens at the media type / = conneg level and URIs should remains stable. Granted there can be = exceptions, but once you hand out 'versioning capabilities' to the world = they'll all just jump on it like crazy because it satisfies SOAPy brains = too easily. >>=20 >> You crafted the wording of the 'hints' section so carefully, but I am = still sure, people will thankfully mistake it as a design-time WADL-like = tool. Let's not add 'versioning' to that. >=20 > I probably think of "versioning" in a way that's different to most = people, to the point where I probably shouldn't use that word, sorry. >=20 > I see a home document being a collection of resource objects that is = added to over time; you can make backwards-compatible changes by adding = new relations to it, or by some kinds of modifications to it. >=20 > At some point far in the future, that home document *might* get so = bloated and crufty that you decide to mint a new one. At that point, = you'd create a new home document and direct new users to it, encouraging = old users to upgrade. That's what I mean by "versioning" the home = document.=20 >=20 Ok, understood. Thanks for clarifying. > Evolving (I'll avoid the "V" word) the individual formats and relation = types used is indeed an entirely separable and separate thing. >=20 > Now, to the original discussion; could you do that new home document = on a new hostname? Certainly (e.g., if you're on api.example.com, you = could mint new-api.example.com). A few sites have already followed this = pattern roughly, IIRC. I'm still not quite sure a .well-known is = necessary, tho. Could a combination with OPTIONS, redirects and/or link headers work? Maybe a slight modification (while you are still at it :-) of the = OPTIONS definition would allow that? However, I think that if you are in a scenario, where you discover = services completely (e.g. by asking DNS for instances of a service type) = the result will likely include a URI to turn to anyhow. And if you are = in a situation where primary entry URIs of services are exchanged = between parties up front those URIs can well be home document URIs. It = is unlikely that it will ever only be the domain name alone, IMO. I'd say well known locations are not necessary. Jan >=20 >=20 >> In [2] you respond: >>=20 >> >>> Right now i see how the client will have default expectations of = what >>> GET, PUT, DELETE and PATCH will do (namely, read, write, remove, >>> modify), but i would not know how to define default expectations of >>> what a POST would do (because we can't talk of inserting without >>> talking of collections). >>=20 >> Yep, I want to go there. >> >>=20 >> Umm, am I missing something? >>=20 >> The expectations a client can have regarding the POST are already = sufficiently defined by the target resource semantics the client = understands from understanding the link relation it follows. >>=20 >> The expectations regarding methods are not a 'default' that can be = extended. HTTP already defines their meaning. Adding expectations on to = means creating a new protocol. >=20 > I'm talking about a hint that lets clients know that they can create a = resource with a given relation by POSTing to a particular resource; = nothing more. It's a common enough pattern that it's useful to surface. >=20 > It's really just a shortcut; the link relation type + media type still = define the semantics of POSTing to the resource, it's just surfacing = this information in an easy-to-read way for a common case. Think of it = as a mini-form. >=20 > Is that less concerning? >=20 >=20 >> I really do think that something as clean and simple as json-home = moves us a great step forward in terms of handing wanna-be REST adopters = the necessary tools! >>=20 >> But I also think it is a very slippery slope regarding the issue of = helping adopters to actually go through a mind shift away from RPC = towards a use of HTTP that actually brings them the benefits they expect = from it. Any RPC-ish touch will make that shift harder, IMHO. >=20 >=20 > Absolutely; that's exactly why I'm treading so gingerly. >=20 > Cheers, >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 From jan.algermissen@nordsc.com Sat Jul 21 05:29:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2E621F86B0 for ; Sat, 21 Jul 2012 05:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Krbx-6fXKpnA for ; Sat, 21 Jul 2012 05:29:39 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6571D21F8682 for ; Sat, 21 Jul 2012 05:29:39 -0700 (PDT) Received: from [192.168.2.103] (p548F9AF3.dip.t-dialin.net [84.143.154.243]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MgUmQ-1TFCYN24gg-00NjRN; Sat, 21 Jul 2012 14:30:37 +0200 From: Jan Algermissen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Jul 2012 14:30:34 +0200 Message-Id: <6FD9C173-C11D-443F-86AF-7B2F7DD00752@nordsc.com> To: "apps-discuss@ietf.org application-layer protocols" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:iOPMPU2nX+/aHABggOhPppXZWWAqZtuW2jy02JxMJb9 aWEFN0XuKeBM/LEyM32ONMn43nKbPehlgEd+yYKS89lZGQZzbg YA2wVerAn29PrZbqYIKVmZDNaPxw/pgbElAjDIb6GBuYXiXG2+ d9TRHxHV0k1IT00mXZTQAC7qAXYA5ptF/JlOnzftZr5zjhvaT1 SVvhs/XdK00yQnMHJBgfqwnNvrGPeK6pxefJFdwmr9L9/kcI64 XdR0yzo4rmGjOBcR/4KvA0vaYMfcf6MZvX6ICv55EgGjlQcsWf H9p4bYleLJtFURUr7J3yQa5uJ+yGpO9DuwiipU4ojmtjeEVzng 2/uWo5lJ0A1kKaw6NNWNz64WI+ZjKMoH7CzTWu13xlMxZEvkco fE66FbtTrMAlg== Subject: [apps-discuss] Duplicate rels in json-home docs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jul 2012 12:29:40 -0000 Hi Mark, you clarified for me in our last exchange that your understanding is = that relations in json-home documents are unique. That there cannot be = more than one resource defined per relation value. (Assuming I replay = that correctly here). I see it the same way. However, I am now running in a situation, where there are several = resources that allow lookup of basically the she kind of information but = based on very different lookup vars. E.g. looking up customers by their customer ID, by ID of any of their = accounts or by some other ID, lets say social security number.[1] Each of these lookup resources return the same .. = representation and basically have the same semantic (being resources = where you can lookup customers). As a result, I end up with a bunch of different 'forms' for different = lookup-parameter combinations. Now, the uniqueness of the rels in json-home docs prevents me from = expressing these 'forms' unless I mint a new relation for each form - = which feels like link relation bloat and is also semantically not really = correct. What would be correct is to have the json-home consumer iterate over all = forms for a given rel value and pick the one that suits the parameter = combinations it has at hand. Thoughts? You might say, that a better design of the URI space solves this, by = simply making the parameters optional query parameters of a single form. = However, then the capabilities of json-home would seriously limit a = designers 'control' over the URI space and probably conflict with legacy = issues she cannot solve. Or, maybe the guy writing the json-home has no control over the source = code (yeah, its me :-) Jan [1] The design here is out of the question, its legacy systems and has = nothing to do with customers :-)= From ned.freed@mrochek.com Sat Jul 21 09:58:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F8A21F869A for ; Sat, 21 Jul 2012 09:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lnd98x2M5Gct for ; Sat, 21 Jul 2012 09:58:10 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC5921F8683 for ; Sat, 21 Jul 2012 09:58:10 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OI3VS4R58W005TBZ@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 21 Jul 2012 09:54:03 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHZVQBJXY80006TF@mauve.mrochek.com>; Sat, 21 Jul 2012 09:54:01 -0700 (PDT) Message-id: <01OI3VS3DVQS0006TF@mauve.mrochek.com> Date: Sat, 21 Jul 2012 09:08:12 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 19 Jul 2012 12:34:01 +1000" <46E73CC5-2851-4F2C-9680-3C681ECA092A@mnot.net> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OHZZPTN9XS0006TF@mauve.mrochek.com> <01OI08IKU8880006TF@mauve.mrochek.com> <46E73CC5-2851-4F2C-9680-3C681ECA092A@mnot.net> To: Mark Nottingham Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jul 2012 16:58:11 -0000 > On 19/07/2012, at 11:43 AM, Ned Freed wrote: > >> On 19/07/2012, at 7:46 AM, Ned Freed wrote: > > > >>>> Apps folks, > >>> > >>>> Tony has posted a new version of this draft that appears to address most > >>>> comments. Please review it and comment, especially if you provided > >>>> comments previously. > >>> > >>>> Some time ago, Mark Nottingham posted comments that have not been > >>>> thoroughly addressed: > >>>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05998.html > >>> > >>> Those comments were and are out of order and I see no point in responding to > >>> them. > > > >> "Out of order"? Seriously? Last I checked, you don't Chair this WG. > > > > You need to brush up on your understanding of basic rules of committee > > procedure if you believe the Chair is the only one who can call something out > > of order. > > > > If we followed Robert's Rules here I would have called it a point of order. > > Points of order can be raised by anyone. But we're less formal, so I didn't > > use that term. > My rule of thumb is that when you refer to things like Roberts' Rules, > something has already failed. Anyway. Which is exactly my point: Something *has* failed. > > That's why your objections are out of order. And again, if you care to rephrase > > them as objections to specific registrations, or to the content of those > > regitrations, that would make perfect sense for the present document. > Where have you seen me object to anything on this topic, Ned? At what point > did I raise an objection -- please point to it? Fine. Let's call it them questions then. Or if you prefer, concerns. But regardless of what you call it, it is still out of order for the current last call. > I asked a few questions and expressed some concern. Kindly stop misreading my > intent. Well, it was never *my* intention to read anything into your intentions here, because they are frankly irrelevant to the matter at hand. I only care about the effects your questions/concerns are having on the process. > >> You subsequently dodged the question > >> : > > > > I don't care if I set the question to tap dancing with a collection of angels > > on the head of a pin. The only relevant point is that you did not object > > further, the IESG has considered the document along with the reviews it > > received and approved it, and the document defining the mechanism and procedure > > you are now objecting to is in the RFC Editor queue. > > > > This is a standards process. Not a debating society where nothing is ever > > settled and every issue can be reopened on a whim. We have to have closure, and > > this particular process has gone on far too long as it is. > Oh, absolutely. I'm just a bit bewildered by the defensiveness and aggression > instigated by a couple of questions. I calls them as I sees them. And what I see here are some out of order questions/concerns holding up the process for a document that needs to be approved before a document I coauthored can be published. If you don't think that warrants the tone I've used, then we'll just have to disagree about that. > > And if you're regretting not saying more at an earlier point in the process, > > you should know you're hardly alone in having this happen to you. I've lost > > track of the number of times I've let something slide, or not reviewed > > something carefully enough, or not implemented something in a timely enough > > fashion, only to discover when later reviewing the resulting RFC that it > > contains something I consider to be egregiously wrong, or broken, or stupid, or > > whatever. (It happened to me today, as a matter of fact. And it's even > > happened when I coauthored the document in question. *cough* RFC 2231 *cough* > > > > I kick myself about this sort of stuff all the time. But what I don't do is try > > an unring bells that have already rung. > You're reading a LOT into my motivations, and I'd ask you to stop. Please note the conditional in the first sentence. This doesn't apply to you, then it doesn't apply to you. > My concerns were first about the technical issues at hand, and later that my > (timely) comments seemed not to be addressed. Really? Your questions/concerns are from: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05998.html Your questions/concerns are about the appropriateness of using media type suffixes in general. The paragraph you cited in the present draft is just collecting the principles behind suffix use in one place, which seemed to us to be a good thing to do when you're seeding the registry. As such, any comments on it are effectively about the text in the registration procedure document it is based on, or section 7 of the RFC 3023 where this originated. I see nothing in your comments that's specific to the suffixes the document in last call registers. Indeed, the title of your message was "Questions about Structured Syntax Suffixes (SSS)", not "Questions about the contents of the initial registry" or anything similar. I suppose one way to address this would be to sidestep it by dropping the "when to use" paragraph from the present document. I would have no objection to doing that if it will make people happier, although I think that capturing that information here is useful, although it is clearly secondary to the purpose of the document. But this is Tony's call, not mine. Ned From jan.algermissen@nordsc.com Sun Jul 22 13:35:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A0621F84DC for ; Sun, 22 Jul 2012 13:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.955 X-Spam-Level: X-Spam-Status: No, score=-2.955 tagged_above=-999 required=5 tests=[AWL=-1.306, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+geDZHgWpuZ for ; Sun, 22 Jul 2012 13:35:43 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6398E21F84DA for ; Sun, 22 Jul 2012 13:35:43 -0700 (PDT) Received: from [192.168.2.103] (p548FA287.dip.t-dialin.net [84.143.162.135]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MZysF-1T86lf42MJ-00LpB2; Sun, 22 Jul 2012 22:36:45 +0200 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Jan Algermissen In-Reply-To: Date: Sun, 22 Jul 2012 22:36:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3836C1EF-F57B-4496-A1BB-5ADB4E731254@nordsc.com> To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:zS0rG8Q8JHXAzF/55aMFbLFc23bJpRwV7KkCVN5iEk6 yf9XdYnFvrV9doHM3KWP5IhiNIAXDWfHY0OKahisqlQiVNAcBU iCfe7/JVFLtF5G39+9yS9KmEVQC0WCUgUHr8r2NZPbMS2taXIM AXIRhbJEikDFZe7ROyc5vo2fN1+oeFNf1zGa0+WxUL1dv5LoHl QD6fVLRs2oeST/1czN5o7rlDo1L86KjNr7985KiUJIu0wlNOq9 P+jZfOAlFyWAfHfixoPwGMbmTaWHXGQqmVBCu3SO7Dh0getaux nqkymQyDuy5fB5WB1AdarznCvSKge+CRz7XQIsEudnHV5ykjhx CYdV9Rcur3yfsSYS4FEF0B4pYa8Xu3aekwNj2BdtDAIqHtIU9b zx7SeqM6E+sgA== Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Question on URI-Templates - How to make non-variable segments optional? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2012 20:35:44 -0000 Hi Ioseb, On Jul 21, 2012, at 1:24 PM, Ioseb Dzmanashvili wrote: > Hello Jan, >=20 > In recent weeks i was doing extensive URI Template spec related = work(https://github.com/ioseb/uri-template) and as far as i can tell = there is a possibility to control optional path segments with template = like this: >=20 > http://example.org/svc/customers/{custId}{/account*} >=20 > In the example above {/account*} path segment expansion(i.e. "/") and = explode operator(i.e. "*") achieves desired result without problems. Of = course result depends on input variables. Below are examples: >=20 > | $template =3D = "http://example.org/svc/customers/{custId}{/account*}"; > | $variables =3D array( > | 'custId' =3D> 21 > | ); > | =20 > | echo uri_template($template, $variables); > | =20 > | // produces http://example.org/svc/customers/21 >=20 > In the example above {/account*} part is ignored entirely as far as = "account" variable was not provided. > =20 > | $variables =3D array( > | 'custId' =3D> 21, > | 'account' =3D> array('accounts', 31) > | ); > | =20 > | echo uri_template($template, $variables); > | =20 > | // produces http://example.org/svc/customers/21/accounts/31 >=20 > In the example above, $variables array contains "account" variable = which value is initialized to list(as per RFC) Yeah, that was on my mind, too. Unfortunately, I am using the templates = in a situation where mapping a variable to a constant string is totally = out of the question :-) (I am 'documenting' legacy APIs using Marks; json-home documents[1]) But thanks! Jan [1] http://tools.ietf.org/html/draft-nottingham-json-home-01 > which forces URI Template processor to expand this variable to: = /accounts/31 >=20 > Hope this helps! >=20 > Cheers, > ioseb >=20 > On Sat, Jul 21, 2012 at 2:35 PM, Jan Algermissen = wrote: > Hi, >=20 > I have a question on RFC 6570 [1]. >=20 > Is it possible to define optional non-variable path segments? >=20 > For example, there are customers with IDs and each customer can have = 1-N accounts with accountIds. >=20 > The service I have provides customer information including all = accounts and customer information including just one account: >=20 >=20 > http://example.org/svc/customers/{custId} >=20 > and >=20 > http://example.org/svc/customers/{custId}/accounts/{accountId} >=20 >=20 > Is there a way to write a template that handles both productions in = one template? What I am looking for is a way to express that = /accounts/{accountId} is optional as a whole, not just {accountId}. >=20 >=20 > Jan >=20 >=20 > [1] http://tools.ietf.org/html/rfc6570 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 >=20 > --=20 > Ioseb Dzmanashvili > Lead Architect > Picktek LLC > 24b Khazbegi ave.=20 > Tbilisi, 0177, Georgia > T (+995 32) 39.58.56, F (+1 202) 315.3934 > picktek.com > code.ge > github.com/ioseb > twitter.com/iosebi >=20 From mnot@mnot.net Sun Jul 22 17:37:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22F021F853E for ; Sun, 22 Jul 2012 17:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.691 X-Spam-Level: X-Spam-Status: No, score=-104.691 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9ZEehOxkdGc for ; Sun, 22 Jul 2012 17:37:53 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C858621F84E1 for ; Sun, 22 Jul 2012 17:37:53 -0700 (PDT) Received: from [192.168.0.100] (unknown [1.152.178.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5CAEB22DD6D; Sun, 22 Jul 2012 20:37:45 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <01OI3VS3DVQS0006TF@mauve.mrochek.com> Date: Mon, 23 Jul 2012 10:37:49 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <89BC161F-5F00-4676-AFDB-4DC1B5409737@mnot.net> References: <01OHZZPTN9XS0006TF@mauve.mrochek.com> <01OI08IKU8880006TF@mauve.mrochek.com> <46E73CC5-2851-4F2C-9680-3C681ECA092A@mnot.net> <01OI3VS3DVQS0006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2012 00:37:54 -0000 On 22/07/2012, at 2:08 AM, Ned Freed wrote: >>>=20 >>> I don't care if I set the question to tap dancing with a collection = of angels >>> on the head of a pin. The only relevant point is that you did not = object >>> further, the IESG has considered the document along with the reviews = it >>> received and approved it, and the document defining the mechanism = and procedure >>> you are now objecting to is in the RFC Editor queue. >>>=20 >>> This is a standards process. Not a debating society where nothing is = ever >>> settled and every issue can be reopened on a whim. We have to have = closure, and >>> this particular process has gone on far too long as it is. >=20 >> Oh, absolutely. I'm just a bit bewildered by the defensiveness and = aggression >> instigated by a couple of questions. >=20 > I calls them as I sees them. And what I see here are some out of order > questions/concerns holding up the process for a document that needs to = be > approved before a document I coauthored can be published. >=20 > If you don't think that warrants the tone I've used, then we'll just = have to > disagree about that. I think there would have been a lot more light and less heat without the = tone you've used. >> My concerns were first about the technical issues at hand, and later = that my >> (timely) comments seemed not to be addressed. >=20 > Really? Your questions/concerns are from: >=20 > = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05998.html >=20 > Your questions/concerns are about the appropriateness of using media = type > suffixes in general. The paragraph you cited in the present draft is = just > collecting the principles behind suffix use in one place, which seemed = to us to > be a good thing to do when you're seeding the registry. As such, any = comments > on it are effectively about the text in the registration procedure = document it > is based on, or section 7 of the RFC 3023 where this originated. >=20 > I see nothing in your comments that's specific to the suffixes the = document in > last call registers. Indeed, the title of your message was "Questions = about > Structured Syntax Suffixes (SSS)", not "Questions about the contents = of the > initial registry" or anything similar. Indeed. As far as I can see, the horse has well and truly bolted.=20 =20 > I suppose one way to address this would be to sidestep it by dropping = the "when > to use" paragraph from the present document. I would have no objection = to doing > that if it will make people happier, although I think that capturing = that > information here is useful, although it is clearly secondary to the = purpose of > the document. But this is Tony's call, not mine. I don't think any changes, or blocking, the current document will help; = my issues were always with the media type registry doc and the process = around it. Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Sun Jul 22 17:38:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F6A21F85C9 for ; Sun, 22 Jul 2012 17:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.691 X-Spam-Level: X-Spam-Status: No, score=-102.691 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6a6JSNwBYKi for ; Sun, 22 Jul 2012 17:38:30 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id B764421F85C4 for ; Sun, 22 Jul 2012 17:38:30 -0700 (PDT) Received: from [192.168.0.100] (unknown [1.152.178.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 276F322E1EB; Sun, 22 Jul 2012 20:38:23 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Mon, 23 Jul 2012 10:38:31 +1000 Content-Transfer-Encoding: 7bit Message-Id: <1E572DDF-D7EF-4C61-974A-37925C0F6132@mnot.net> References: <20120711114411.694627c5@hetzer> <4FFD5000.8010908@gmx.de> <4FFD9713.7060006@dcrocker.net> <01OHPTP7PS260006TF@mauve.mrochek.com> <01OHT7332FMS0006TF@mauve.mrochek.com> To: Henri Sivonen X-Mailer: Apple Mail (2.1278) Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] Unified User-Agent String X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2012 00:38:32 -0000 +1 On 20/07/2012, at 6:59 PM, Henri Sivonen wrote: > On Sat, Jul 14, 2012 at 4:17 AM, Ned Freed wrote: >>> So I had to: >>> 1. Add references to HTTP specification. >>> 2. Simply syntax definition. >>> 3. Separate issue definition and actual problems definition. >>> 4. Write Security Considerations. >>> 5. Change form of draft from standarising to proposing. >>> 6. Find examples of errors, which are result of ambiguous strings. >>> 7. Change order of elements in draft. >>> 8. Think two times about sense of that project. >> >> I'm sorry to have to say it, but this completely misses the main >> point of what I was suggesting. My suggestion was to write a document >> that was first about the issues in general that arise from use of >> the User-Agent string, and only secondarily about how a subset of those >> issues can be addresses by nailing down the syntax. > > Furthermore, without implementor interest, this isn't going to go > anywhere, and the draft seems completely out of touch with implementor > interest. For example, > http://tools.ietf.org/html/draft-karcz-uuas-00#section-2.1.2.1 > describes a legacy thing that no implementor seems to be interested in > adding at this point if they don't already have it, and implementors > who still did have it two years ago have been removing it. > > -- > Henri Sivonen > hsivonen@iki.fi > http://hsivonen.iki.fi/ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From ioseb.dzmanashvili@gmail.com Sun Jul 22 23:13:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA2311E8079 for ; Sun, 22 Jul 2012 23:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG8e0aNaehsC for ; Sun, 22 Jul 2012 23:13:41 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id F045D21F85F9 for ; Sun, 22 Jul 2012 23:13:40 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so1935538wib.13 for ; Sun, 22 Jul 2012 23:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=rpNjFG6LXfNl7WdmkA8VujbFzXsEIbHvw5uQ9T5Oizs=; b=c/ig7jMlBMkZNvswROYqNy4NJTmCiI0Yj+76iJcNUbljAjTEkJnyDgf6xM450cPr8A +PKJW3isn7i5Fx4bg9YfUmjqPYO45tuLPjsKn/KJzze4BlxQhimmE14sig/vO50nXYrV 0cMNt2u/hFzfRaDwzQlxQiAHZTH7pDphj/I8XMslSiTk+wBDFwPiL4FNNZlqbkEU9gP0 jhekBiSPNUzEAMyLvuvzzIQfDDk6p0J5PivAsEwfYff7x2w/Wv8hfnCZyrTgBCcZwkYI o21NaZYZon3GE0O0PJURrJ7/+CIEPycjptNiV9ayCoTu0+I9mflIkrlXjX7UXW5ChTh3 AQsw== Received: by 10.180.19.169 with SMTP id g9mr46115955wie.9.1343024019843; Sun, 22 Jul 2012 23:13:39 -0700 (PDT) Received: from [192.168.1.110] ([94.240.230.4]) by mx.google.com with ESMTPS id w7sm15323126wiz.0.2012.07.22.23.13.33 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Jul 2012 23:13:38 -0700 (PDT) Date: Mon, 23 Jul 2012 10:13:56 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: In-Reply-To: References: <3836C1EF-F57B-4496-A1BB-5ADB4E731254@nordsc.com> X-Mailer: sparrow 1.6.2 (build 1143.6) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="500ceba4_419ac241_f60e" Cc: "=?utf-8?Q?apps-discuss=40ietf.org_application-layer_protocols?=" Subject: Re: [apps-discuss] Question on URI-Templates - How to make non-variable segments optional? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2012 06:13:43 -0000 --500ceba4_419ac241_f60e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jan, Unfortunately for this case i do not have idea except including both templates separately in service description. Cheers, ioseb On Monday, July 23, 2012 at 12:36 AM, Jan Algermissen wrote: > Hi Ioseb, > > On Jul 21, 2012, at 1:24 PM, Ioseb Dzmanashvili wrote: > > > Hello Jan, > > > > In recent weeks i was doing extensive URI Template spec related work(https://github.com/ioseb/uri-template) and as far as i can tell there is a possibility to control optional path segments with template like this: > > > > http://example.org/svc/customers/{custId}{/account*} > > > > In the example above {/account*} path segment expansion(i.e. "/") and explode operator(i.e. "*") achieves desired result without problems. Of course result depends on input variables. Below are examples: > > > > | $template = "http://example.org/svc/customers/{custId}{/account*}"; > > | $variables = array( > > | 'custId' => 21 > > | ); > > | > > | echo uri_template($template, $variables); > > | > > | // produces http://example.org/svc/customers/21 > > > > In the example above {/account*} part is ignored entirely as far as "account" variable was not provided. > > > > | $variables = array( > > | 'custId' => 21, > > | 'account' => array('accounts', 31) > > | ); > > | > > | echo uri_template($template, $variables); > > | > > | // produces http://example.org/svc/customers/21/accounts/31 > > > > In the example above, $variables array contains "account" variable which value is initialized to list(as per RFC) > > Yeah, that was on my mind, too. Unfortunately, I am using the templates in a situation where mapping a variable to a constant string is totally out of the question :-) > (I am 'documenting' legacy APIs using Marks; json-home documents[1]) > > But thanks! > > Jan > > [1] http://tools.ietf.org/html/draft-nottingham-json-home-01 > > > > > > which forces URI Template processor to expand this variable to: /accounts/31 > > > > Hope this helps! > > > > Cheers, > > ioseb > > > > On Sat, Jul 21, 2012 at 2:35 PM, Jan Algermissen wrote: > > Hi, > > > > I have a question on RFC 6570 [1]. > > > > Is it possible to define optional non-variable path segments? > > > > For example, there are customers with IDs and each customer can have 1-N accounts with accountIds. > > > > The service I have provides customer information including all accounts and customer information including just one account: > > > > > > http://example.org/svc/customers/{custId} > > > > and > > > > http://example.org/svc/customers/{custId}/accounts/{accountId} > > > > > > Is there a way to write a template that handles both productions in one template? What I am looking for is a way to express that /accounts/{accountId} is optional as a whole, not just {accountId}. > > > > > > Jan > > > > > > [1] http://tools.ietf.org/html/rfc6570 > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org (mailto:apps-discuss@ietf.org) > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > > > -- > > Ioseb Dzmanashvili > > Lead Architect > > Picktek LLC > > 24b Khazbegi ave. > > Tbilisi, 0177, Georgia > > T (+995 32) 39.58.56, F (+1 202) 315.3934 > > picktek.com (http://picktek.com) > > code.ge > > github.com/ioseb (http://github.com/ioseb) > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > --500ceba4_419ac241_f60e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Jan, 

Unfortunately= for this case i do not have idea except including both templates separat= ely in service description.

Cheers,
io= seb
=20

On Monday, July 23, 20= 12 at 12:36 AM, Jan Algermissen wrote:

Hi Ioseb,

On Jul 21, 2012, at 1:24 PM, Ioseb Dzmanashvili wrote:

<= /div>
Hello Jan,

In recent weeks i was doing extensive URI Template spec related w= ork(https://github.= com/ioseb/uri-template) and as far as i can tell there is a possibili= ty to control optional path segments with template like this:
<= br>

In the example above =7B/account*=7D pat= h segment expansion(i.e. =22/=22) and explode operator(i.e. =22*=22) achi= eves desired result without problems. Of course result depends on input v= ariables. Below are examples:


In the example above =7B= /account*=7D part is ignored entirely as far as =22account=22 variable wa= s not provided.
=7C =24variables =3D array(
<= div>=7C 'custId' =3D> 21,
=7C 'account' =3D> array= ('accounts', 31)
=7C );
=7C
=7C echo ur= i=5Ftemplate(=24template, =24variables);
=7C

=
In the example above, =24variables array contains =22account=22 vari= able which value is initialized to list(as per R=46C)

Yeah, that was on my mind, too. Unfortunately, I= am using the templates in a situation where mapping a variable to a cons= tant string is totally out of the question :-)
(I am 'documenti= ng' legacy APIs using Marks; json-home documents=5B1=5D)

But thanks=21

Jan

<= div>=5B1=5D http://tools.ietf.org/html/draft-nottingham-json-home-01<= /div>




which forces URI Template processor to ex= pand this variable to: /accounts/31

Hope this he= lps=21

Cheers,
ioseb

On Sat, Jul 21, 2012 at 2:35 PM, Jan Algermissen <jan.algermissen=40nordsc.com&g= t; wrote:
Hi,

I have a question on R=46= C 6570 =5B1=5D.

Is it possible to define optiona= l non-variable path segments=3F

=46or example, t= here are customers with IDs and each customer can have 1-N accounts with = accountIds.

The service I have provides customer= information including all accounts and customer information including ju= st one account:



and

http://example.org/svc/customers/=7BcustId=7D/accounts/=7B= accountId=7D


Is there a way t= o write a template that handles both productions in one template=3F What = I am looking for is a way to express that /accounts/=7BaccountId=7D is op= tional as a whole, not just =7BaccountId=7D.

Jan


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
apps-discuss mailing list


=

--
Ioseb Dzmanashvili
Lead= Architect
Picktek LLC
24b Khazbegi ave.
T= bilisi, 0177, Georgia
T (+995 32) 39.58.56, =46 (+1 202) 315.39= 34
code.ge
 =20 =20 =20 =20
=20

--500ceba4_419ac241_f60e-- From mikekelly321@gmail.com Mon Jul 23 02:30:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871CC21F8501 for ; Mon, 23 Jul 2012 02:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLBj2t8NjBSc for ; Mon, 23 Jul 2012 02:30:49 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDB921F849D for ; Mon, 23 Jul 2012 02:30:49 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so10684614obb.31 for ; Mon, 23 Jul 2012 02:30:48 -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=tQMObaWIi+/wvRDKSofIGHmu/ZzOFU4O2uYqU7Aw7cI=; b=UznpXAB13ekXhkGELVHIVE3SL2Q1mN9u+N9ayNY5Djaox9o2tKMXhzwNLp824UDPf+ 742GJObIe0B4vjP4LupksmV8fBgC8c1WUcpBAACWchWau6OmffvDEx5HZizdSCSGA1GN w5sft1d/5Feot2ZYoIjrNR4F8+CQyWG/QQ+UskHb80KvbveoNvh0P6sKQwcyRSM8uEjw bh4UVFl0zctX+ae10+kwLw59WC7Nt8ggADMcbAZNLKtR8p0txrWkE4RVjkOFVZ7FQ41A bO254SWyeq+bbENpFR37wFdr5DNEoM08c3iI+Aua2YYJ1jn74TFIeZEmc2fahrsP2dLK KGtQ== MIME-Version: 1.0 Received: by 10.60.19.232 with SMTP id i8mr19663110oee.35.1343035848633; Mon, 23 Jul 2012 02:30:48 -0700 (PDT) Received: by 10.60.65.234 with HTTP; Mon, 23 Jul 2012 02:30:48 -0700 (PDT) In-Reply-To: References: <3836C1EF-F57B-4496-A1BB-5ADB4E731254@nordsc.com> Date: Mon, 23 Jul 2012 10:30:48 +0100 Message-ID: From: Mike Kelly To: Ioseb Dzmanashvili Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Question on URI-Templates - How to make non-variable segments optional? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2012 09:30:49 -0000 On Mon, Jul 23, 2012 at 7:13 AM, Ioseb Dzmanashvili wrote: > Hi Jan, > > Unfortunately for this case i do not have idea except including both > templates separately in service description. Right, I was wondering why this isn't an option? From julian.reschke@gmx.de Mon Jul 23 11:15:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D72611E80B5 for ; Mon, 23 Jul 2012 11:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.007 X-Spam-Level: X-Spam-Status: No, score=-104.007 tagged_above=-999 required=5 tests=[AWL=-2.008, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpxj9CXCr0xf for ; Mon, 23 Jul 2012 11:15:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4360111E8093 for ; Mon, 23 Jul 2012 11:15:44 -0700 (PDT) Received: (qmail invoked by alias); 23 Jul 2012 18:15:44 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp028) with SMTP; 23 Jul 2012 20:15:44 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX193T/If7x534/Vyja/4Zy084rT81YtvPLd2/vBmt1 S3Q4UrF0EIx6/f Message-ID: <500D94C4.8030304@gmx.de> Date: Mon, 23 Jul 2012 20:15:32 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [apps-discuss] ABNF changes in draft-ietf-appsawg-http-forwarded-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2012 18:15:46 -0000 Hi there, I just became aware of some ABNF related changes in the latest draft; see : Forwarded = 1#forwarded-element forwarded-element = [ forwarded-pair ] *[ ";" forwarded-pair ] forwarded-pair = token "=" value value = token / quoted-string node = nodename [ ":" node-port ] nodename = IPv4address / "[" IPv6address "]" / "unknown" / obfnode IPv4address = IPv6address = obfnode = "_" 1*( ALPHA / DIGIT / "." / "_" / "-") node-port = port / obfport port = 1*5DIGIT obfport = "_" 1*(ALPHA / DIGIT / "." / "_" / "-") token = quoted-string = DIGIT = ALPHA = 1) The change to forwarded-element makes leading and trailing semicolons invalid. I believe that's a bad idea, and also contrary to prior WG discussions. Disallowing them in the ABNF will have zero effect on implementations (we know that from other header fields that use similar syntax), so pretending they won't happen isn't useful. It just creates a situation where some recipients accept them and some do not. 2) Moving the "node" ABNF here is very misleading; these productions are used in *values*, after potential unescaping of quoted-string; so at a completely different processing level. 3) Nit: the prose productions for token and quoted-string are invalid as ABNF doesn't allow CRLF here. That probably will resolve itself once the reference is replaced with a shorter string. Best regards, Julian From alexey.melnikov@isode.com Mon Jul 23 11:17:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3BD11E80DF for ; Mon, 23 Jul 2012 11:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le-EdFtXYZ48 for ; Mon, 23 Jul 2012 11:17:32 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id DBCF011E8093 for ; Mon, 23 Jul 2012 11:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1343067502; d=isode.com; s=selector; i=@isode.com; bh=673Adlet64U9hateTfQIbE1JAGqBD0vOTTfgufb6QI4=; 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=qJMP996YzGttLybPk9Ksn0nd0daGrltOel406bHr5VbqP8Sb2qpZKO0fRQcoZ3AHMxLqEb avUeCx4Xz/334jA1PSadEGQLUkU/sGKAV8WRGTTP6sRpM5wwHiz8jhe/ZEm4d7xvdDPSTQ FZ0yyMhaumc+LrFtn2C4JEbISJW6wtA=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 23 Jul 2012 19:18:21 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <500D9549.2010803@isode.com> Date: Mon, 23 Jul 2012 19:17:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "Murray S. Kucherawy" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2012 18:17:32 -0000 On 18/07/2012 20:31, Murray S. Kucherawy wrote: > Apps folks, > > Tony has posted a new version of this draft that appears to address > most comments. Please review it and comment, especially if you > provided comments previously. I am mostly happy with draft-ietf-appsawg-media-type-suffix-regs-02. I have noticed that the new text about fragment identifier handling was added to definitions of XML related suffixes (good), +zip (?) and not to +ber/+der. I would like to have a discussion about why +zip was included but +ber/+der weren't. From julian.reschke@gmx.de Mon Jul 23 11:27:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBE511E80BD for ; Mon, 23 Jul 2012 11:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.282 X-Spam-Level: X-Spam-Status: No, score=-104.282 tagged_above=-999 required=5 tests=[AWL=-1.683, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIE5-HWpssj4 for ; Mon, 23 Jul 2012 11:27:16 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B48FE21F85D6 for ; Mon, 23 Jul 2012 11:27:15 -0700 (PDT) Received: (qmail invoked by alias); 23 Jul 2012 18:26:57 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp012) with SMTP; 23 Jul 2012 20:26:57 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18ELkhFxDYErmhHjgEIOpJ1i0D956XEKdm/O37zw+ FkrYgwkm4HXaU6 Message-ID: <500D9763.7090009@gmx.de> Date: Mon, 23 Jul 2012 20:26:43 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Alexey Melnikov References: <500D9549.2010803@isode.com> In-Reply-To: <500D9549.2010803@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2012 18:27:16 -0000 On 2012-07-23 20:17, Alexey Melnikov wrote: > On 18/07/2012 20:31, Murray S. Kucherawy wrote: >> Apps folks, >> >> Tony has posted a new version of this draft that appears to address >> most comments. Please review it and comment, especially if you >> provided comments previously. > > I am mostly happy with draft-ietf-appsawg-media-type-suffix-regs-02. I > have noticed that the new text about fragment identifier handling was > added to definitions of XML related suffixes (good), +zip (?) and not to > +ber/+der. I would like to have a discussion about why +zip was included > but +ber/+der weren't. > ... Also, I was assuming that we define "+gz" or "+gzip", as this appears to have a proper use case (use of "svz" content inside data URIs using base64 encoding). Best regards, Julian From barryleiba.mailing.lists@gmail.com Mon Jul 23 11:45:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF81421F848A for ; Mon, 23 Jul 2012 11:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.403 X-Spam-Level: X-Spam-Status: No, score=-101.403 tagged_above=-999 required=5 tests=[AWL=-1.626, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ks2jN4YKehhG for ; Mon, 23 Jul 2012 11:45:07 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A20BC21F8498 for ; Mon, 23 Jul 2012 11:45:06 -0700 (PDT) Received: by lagv3 with SMTP id v3so194066lag.31 for ; Mon, 23 Jul 2012 11:45:05 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8JnDRafD5iriirY/kdvEHCZ1ppkKSjmZP3yY1FEoNso=; b=XyKhV8QyogZ+mLhneL0anQ9tMT0+VpM9Sjy8GJkRdNaHtp6TmRCWGpVCsNbHR4E7a9 GRQ72ouJtiHLc8zUMl2aV26+2QPRtVwQ72o0XQURM8tE6s95xq3mN4QEml9dyaVATiBD vv4vg5ifstmRdtaikU2MQoR/kJEZ1XLsUDnnwXPQSQSOhlRbwx9+ue03Li4d7wWy6ver XK5WWhM8AFhEZRzAxWk7SgOzaiTPF7ljZi6QHvGPBLx3dRkbIpzPS7L8kbXcV7wEDgCh ek6cZcklMCHIASW+vlzlab5A14J7MZpZJ76ilvq+aZvTigSzsGu/lg3RuZuXRIGsF+7S Rnmw== MIME-Version: 1.0 Received: by 10.112.36.130 with SMTP id q2mr8021363lbj.44.1343069105507; Mon, 23 Jul 2012 11:45:05 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Mon, 23 Jul 2012 11:45:05 -0700 (PDT) In-Reply-To: <500D94C4.8030304@gmx.de> References: <500D94C4.8030304@gmx.de> Date: Mon, 23 Jul 2012 14:45:05 -0400 X-Google-Sender-Auth: EaUy0r7fw-G8mZwjg1WBTv6BhRA Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] ABNF changes in draft-ietf-appsawg-http-forwarded-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2012 18:45:07 -0000 > Forwarded = 1#forwarded-element > > forwarded-element = > [ forwarded-pair ] *[ ";" forwarded-pair ] > > forwarded-pair = token "=" value > value = token / quoted-string > > node = nodename [ ":" node-port ] > nodename = IPv4address / "[" IPv6address "]" / > "unknown" / obfnode > > IPv4address = > IPv6address = > obfnode = "_" 1*( ALPHA / DIGIT / "." / "_" / "-") > > node-port = port / obfport > port = 1*5DIGIT > obfport = "_" 1*(ALPHA / DIGIT / "." / "_" / "-") > > token = [I-D.ietf-httpbis-p1-messaging], Section 3.2.4> > quoted-string = [I-D.ietf-httpbis-p1-messaging], Section 3.2.4> > > DIGIT = > ALPHA = > > 1) The change to forwarded-element makes leading and trailing semicolons > invalid. I believe that's a bad idea, and also contrary to prior WG > discussions. Disallowing them in the ABNF will have zero effect on > implementations (we know that from other header fields that use similar > syntax), so pretending they won't happen isn't useful. It just creates a > situation where some recipients accept them and some do not. This was done unintentionally: I asked a question in my AD review, and Andreas responded with the ABNF change. I'm sure he'll be happy to change that one back. > 2) Moving the "node" ABNF here is very misleading; these productions are > used in *values*, after potential unescaping of quoted-string; so at a > completely different processing level. I don't understand what you're complaining about here. Is it just the ordering of the ABNF productions? If so, suggest specifically where "node" should go in the order. If it's that you don't want the ABNF all in one place, we're going to have a row about that, because I strongly think that it's easier on implementors to have it together. > 3) Nit: the prose productions for token and quoted-string are invalid as > ABNF doesn't allow CRLF here. That probably will resolve itself once the > reference is replaced with a shorter string. Yes; it might help to put in a note to the RFC Editor about this. I'll do that., Barry From julian.reschke@gmx.de Mon Jul 23 12:28:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48ED11E80B8 for ; Mon, 23 Jul 2012 12:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.151 X-Spam-Level: X-Spam-Status: No, score=-103.151 tagged_above=-999 required=5 tests=[AWL=-4.371, BAYES_50=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCaHlDll20Uf for ; Mon, 23 Jul 2012 12:28:42 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E5F2911E80AE for ; Mon, 23 Jul 2012 12:28:41 -0700 (PDT) Received: (qmail invoked by alias); 23 Jul 2012 19:28:40 -0000 Received: from p54BB2E36.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.46.54] by mail.gmx.net (mp071) with SMTP; 23 Jul 2012 21:28:40 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/ISMB859TISBA0X/ZAnSIHnZo74RiyJ3NkDG+8YY fP0fwUGVm4LGWc Message-ID: <500DA5E1.1020006@gmx.de> Date: Mon, 23 Jul 2012 21:28:33 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Barry Leiba References: <500D94C4.8030304@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] ABNF changes in draft-ietf-appsawg-http-forwarded-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2012 19:28:43 -0000 On 2012-07-23 20:45, Barry Leiba wrote: >> Forwarded = 1#forwarded-element >> >> forwarded-element = >> [ forwarded-pair ] *[ ";" forwarded-pair ] >> >> forwarded-pair = token "=" value >> value = token / quoted-string >> >> node = nodename [ ":" node-port ] >> nodename = IPv4address / "[" IPv6address "]" / >> "unknown" / obfnode >> >> IPv4address = >> IPv6address = >> obfnode = "_" 1*( ALPHA / DIGIT / "." / "_" / "-") >> >> node-port = port / obfport >> port = 1*5DIGIT >> obfport = "_" 1*(ALPHA / DIGIT / "." / "_" / "-") >> >> token = > [I-D.ietf-httpbis-p1-messaging], Section 3.2.4> >> quoted-string = > [I-D.ietf-httpbis-p1-messaging], Section 3.2.4> >> >> DIGIT = >> ALPHA = >> >> 1) The change to forwarded-element makes leading and trailing semicolons >> invalid. I believe that's a bad idea, and also contrary to prior WG >> discussions. Disallowing them in the ABNF will have zero effect on >> implementations (we know that from other header fields that use similar >> syntax), so pretending they won't happen isn't useful. It just creates a >> situation where some recipients accept them and some do not. > > This was done unintentionally: I asked a question in my AD review, and > Andreas responded with the ABNF change. I'm sure he'll be happy to > change that one back. Ok. >> 2) Moving the "node" ABNF here is very misleading; these productions are >> used in *values*, after potential unescaping of quoted-string; so at a >> completely different processing level. > > I don't understand what you're complaining about here. Is it just the > ordering of the ABNF productions? If so, suggest specifically where > "node" should go in the order. If it's that you don't want the ABNF > all in one place, we're going to have a row about that, because I > strongly think that it's easier on implementors to have it together. I'd like to be where it was. Having the productions in a single place suggests that they are somehow related to each other, which they are not at all. >> 3) Nit: the prose productions for token and quoted-string are invalid as >> ABNF doesn't allow CRLF here. That probably will resolve itself once the >> reference is replaced with a shorter string. > > Yes; it might help to put in a note to the RFC Editor about this. > I'll do that., > ... Best regards, Julian From barryleiba@gmail.com Mon Jul 23 12:37:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC7F11E80D0 for ; Mon, 23 Jul 2012 12:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.777 X-Spam-Level: X-Spam-Status: No, score=-101.777 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKjvJTgtIxVQ for ; Mon, 23 Jul 2012 12:37:48 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id D056111E809B for ; Mon, 23 Jul 2012 12:37:42 -0700 (PDT) Received: by qaea16 with SMTP id a16so1363633qae.10 for ; Mon, 23 Jul 2012 12:37:42 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Mzj5ksl2sKuYGfj6+FCkiNQupGDSaSx25KlPu9zVFyI=; b=IfBhQ1Uk+AzlVvangt+DhHxEPw9PllDRmIEYJwf0uWBOwM5d3J6gOnijcEICQNAGMl uZeP6nfR1ulJW0UbOVRevPMq/jSDv/WqzxJp1QCUFpq7ItCAmBdw+noMq6Fxz2VhqAzM wYfDIHJCVBVF7Ce2WFINSwgGcDIHR2DxJ8ucdBEtfsuqIaYeyMMO1V4uInva5RV6xN1b JJjqYzzFT6EH530D8Nsroj4JFQmVQvExCTi4x9YWEm9cMW3LqSIRJqCOqHVVV5TxVHM7 +UIAFKFHfFNFp6RTpR0T0vrjRg/mLoyJqcIS133RMtJvkV1JIMH5ysiJ4xc+wvGsSShm ExGw== MIME-Version: 1.0 Received: by 10.224.213.4 with SMTP id gu4mr26301767qab.0.1343072262225; Mon, 23 Jul 2012 12:37:42 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Mon, 23 Jul 2012 12:37:42 -0700 (PDT) In-Reply-To: <500DA5E1.1020006@gmx.de> References: <500D94C4.8030304@gmx.de> <500DA5E1.1020006@gmx.de> Date: Mon, 23 Jul 2012 15:37:42 -0400 X-Google-Sender-Auth: QLHhqt0aszpVslGFwQkDnlPadkQ Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] ABNF changes in draft-ietf-appsawg-http-forwarded-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2012 19:37:50 -0000 >>> 2) Moving the "node" ABNF here is very misleading; these productions are >>> used in *values*, after potential unescaping of quoted-string; so at a >>> completely different processing level. >> >> I don't understand what you're complaining about here. Is it just the >> ordering of the ABNF productions? If so, suggest specifically where >> "node" should go in the order. If it's that you don't want the ABNF >> all in one place, we're going to have a row about that, because I >> strongly think that it's easier on implementors to have it together. > > I'd like to be where it was. > > Having the productions in a single place suggests that they are somehow > related to each other, which they are not at all. Nonsense. Having them in a single place makes them easier to find and easier to refer to. I'm happy to defer to you on the content of the productions. But for the arrangement, I think it's a bad idea to have small bits of ABNF in different places in the document. Does anyone besides Julian and me have a comment on this point? Barry From julian.reschke@gmx.de Mon Jul 23 12:47:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED57311E807F for ; Mon, 23 Jul 2012 12:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.66 X-Spam-Level: X-Spam-Status: No, score=-104.66 tagged_above=-999 required=5 tests=[AWL=-2.680, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnlycJTT2RDs for ; Mon, 23 Jul 2012 12:47:39 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D0DBE21F84B6 for ; Mon, 23 Jul 2012 12:47:38 -0700 (PDT) Received: (qmail invoked by alias); 23 Jul 2012 19:47:35 -0000 Received: from p54BB2E36.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.46.54] by mail.gmx.net (mp001) with SMTP; 23 Jul 2012 21:47:35 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19A9itgYntA9kDuKfswu8yLVbv4wZ+hJeWK4/4jbo FhRPpuylhVcx00 Message-ID: <500DAA4F.5040802@gmx.de> Date: Mon, 23 Jul 2012 21:47:27 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Barry Leiba References: <500D94C4.8030304@gmx.de> <500DA5E1.1020006@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] ABNF changes in draft-ietf-appsawg-http-forwarded-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2012 19:47:40 -0000 On 2012-07-23 21:37, Barry Leiba wrote: >>>> 2) Moving the "node" ABNF here is very misleading; these productions are >>>> used in *values*, after potential unescaping of quoted-string; so at a >>>> completely different processing level. >>> >>> I don't understand what you're complaining about here. Is it just the >>> ordering of the ABNF productions? If so, suggest specifically where >>> "node" should go in the order. If it's that you don't want the ABNF >>> all in one place, we're going to have a row about that, because I >>> strongly think that it's easier on implementors to have it together. >> >> I'd like to be where it was. >> >> Having the productions in a single place suggests that they are somehow >> related to each other, which they are not at all. > > Nonsense. Having them in a single place makes them easier to find and > easier to refer to. I have to disagree. ABNF productions should be placed where they are used (or referenced from there). If these turn out to be "many" places, one should consider an appendix with all productions, an index, or both. Again: if somebody writes a parser that deals with both "forwarded-pair" and "node" in the same piece of code, then that parser is VERY likely broken. This header field uses a generic name/value syntax, and then puts additional constrains on certain values (after unescaping). Just because both use ABNF doesn't mean that one thing has anything to do with the other thing. > I'm happy to defer to you on the content of the productions. But for > the arrangement, I think it's a bad idea to have small bits of ABNF in > different places in the document. > > Does anyone besides Julian and me have a comment on this point? The same issue will come up very soon in HTTPbis; if you disagree how we're doing things over there it would be very good to find out about that before we're after LC. Best regards, Julian From barryleiba@gmail.com Mon Jul 23 13:20:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BF021F8478 for ; Mon, 23 Jul 2012 13:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.97 X-Spam-Level: X-Spam-Status: No, score=-102.97 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQrwDqUQpk1l for ; Mon, 23 Jul 2012 13:20:07 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA42321F8472 for ; Mon, 23 Jul 2012 13:20:06 -0700 (PDT) Received: by qcac10 with SMTP id c10so3811834qca.31 for ; Mon, 23 Jul 2012 13:20:06 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=a+Fzpnqby/D2nO17nrsRWTEOn3QLjyUAuxigYlMV35Y=; b=TTuJO6eHfDaU4wT3X0EI1wqfJRAiwhSOaOdHaTcjlwgzMbPq1RS124lhgVb6usfjsd 0xPt4mqQNgo9jelPDreGt4ICYUTvvIffs8Ul6jeV/LJTBvy0qh10W/wc1bJTmutNJgDt w2wKkdpwwfh2P++YIPBt1o8dA+Wj6i9SczwsjImM1xpGsRyS9OrCTTk7TWJNl9d5i6S1 LSkd0qkFNEDKe3Ng3I1XTqv8q49/f6vEEJxntB2vx1B3zNlA5iSqc9g3t48hADxkYZzY bRG7ehHPE17KHDJJm9TfGbCPLql++oWLXeI9jsIQG6rge1ebEk4MU2fMzu/V7w0t2hPd Kikg== MIME-Version: 1.0 Received: by 10.229.135.196 with SMTP id o4mr7690999qct.154.1343074806315; Mon, 23 Jul 2012 13:20:06 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Mon, 23 Jul 2012 13:20:06 -0700 (PDT) In-Reply-To: <500DAA4F.5040802@gmx.de> References: <500D94C4.8030304@gmx.de> <500DA5E1.1020006@gmx.de> <500DAA4F.5040802@gmx.de> Date: Mon, 23 Jul 2012 16:20:06 -0400 X-Google-Sender-Auth: td1L87lR71t3j6tCjCjWQ712yNg Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] ABNF changes in draft-ietf-appsawg-http-forwarded-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2012 20:20:08 -0000 >>> Having the productions in a single place suggests that they are somehow >>> related to each other, which they are not at all. >> >> Nonsense. Having them in a single place makes them easier to find and >> easier to refer to. > > I have to disagree. ABNF productions should be placed where they are used > (or referenced from there). If these turn out to be "many" places, one > should consider an appendix with all productions, an index, or both. Ack; we disagree. Neither unusual, nor disastrous. > Again: if somebody writes a parser that deals with both "forwarded-pair" and > "node" in the same piece of code, then that parser is VERY likely broken. Oh, I think the component you're referring to isn't the parser (the same parser absolutely will be used for both in many implementations), but the lexical processor. But that doesn't really matter; you're right that if someone tries to treat a "node" as the same part of speech as a "forwarded-pair", we have problems. > The same issue will come up very soon in HTTPbis; if you disagree how we're > doing things over there it would be very good to find out about that before > we're after LC. How about this as a compromise; I would be very happy with this alternative: The ABNF stays together in the same section, but it is separated into groupings (or subsections, that would be OK too) to make it clear that the grouping that contains "node" is lexically different to the other grouping(s). What do you think? The productions could be grouped as they were before, along with forward references to where they're discussed. Barry From alexey.melnikov@isode.com Mon Jul 23 13:24:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0377C11E809B for ; Mon, 23 Jul 2012 13:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.798 X-Spam-Level: X-Spam-Status: No, score=-99.798 tagged_above=-999 required=5 tests=[AWL=-1.795, BAYES_50=0.001, J_CHICKENPOX_37=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 042NDiKfNRSR for ; Mon, 23 Jul 2012 13:24:25 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B42A11E809A for ; Mon, 23 Jul 2012 13:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1343075114; d=isode.com; s=selector; i=@isode.com; bh=MFsdPrauOGfNFpw9RfGFIvPjMNfkQfuglaAvr7QVv6E=; 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=uN1zvWNX4BXw8y9JN0hQJQ2pSOAd+LRR11o9UbHv3PViwel4FayiApw9GKEkM7FBSRk+Ff gff7lUdrHm1eAwrbIGI4fnKvQKH+tpWm+Vm2hAWtcBjlTCqoLDKk2xL2x/v1TYpGl3LnGW P5DD5WVJCPzrmTMvD6DFybDYKca4uAM=; Received: from [188.28.141.90] (188.28.141.90.threembb.co.uk [188.28.141.90]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 23 Jul 2012 21:25:14 +0100 References: <500D94C4.8030304@gmx.de> <500DA5E1.1020006@gmx.de> In-Reply-To: <500DA5E1.1020006@gmx.de> Message-Id: <91BC807C-EBF3-4CB3-A051-908C3689FBA3@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Mon, 23 Jul 2012 21:24:16 +0100 To: Julian Reschke MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] ABNF changes in draft-ietf-appsawg-http-forwarded-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2012 20:24:26 -0000 Hi, On 23 Jul 2012, at 20:28, Julian Reschke wrote: > On 2012-07-23 20:45, Barry Leiba wrote: >>> Forwarded =3D 1#forwarded-element >>>=20 >>> forwarded-element =3D >>> [ forwarded-pair ] *[ ";" forwarded-pair ] >>>=20 >>> forwarded-pair =3D token "=3D" value >>> value =3D token / quoted-string >>>=20 >>> node =3D nodename [ ":" node-port ] >>> nodename =3D IPv4address / "[" IPv6address "]" / >>> "unknown" / obfnode >>>=20 >>> IPv4address =3D >>> IPv6address =3D >>> obfnode =3D "_" 1*( ALPHA / DIGIT / "." / "_" / "-") >>>=20 >>> node-port =3D port / obfport >>> port =3D 1*5DIGIT >>> obfport =3D "_" 1*(ALPHA / DIGIT / "." / "_" / "-") >>>=20 >>> token =3D >> [I-D.ietf-httpbis-p1-messaging], Section 3.2.4> >>> quoted-string =3D >> [I-D.ietf-httpbis-p1-messaging], Section 3.2.4> >>>=20 >>> DIGIT =3D >>> ALPHA =3D >>>=20 >>> 1) The change to forwarded-element makes leading and trailing semicolons= >>> invalid. I believe that's a bad idea, and also contrary to prior WG >>> discussions. Disallowing them in the ABNF will have zero effect on >>> implementations (we know that from other header fields that use similar >>> syntax), so pretending they won't happen isn't useful. It just creates a= >>> situation where some recipients accept them and some do not. >>=20 >> This was done unintentionally: I asked a question in my AD review, and >> Andreas responded with the ABNF change. I'm sure he'll be happy to >> change that one back. >=20 > Ok. >=20 >>> 2) Moving the "node" ABNF here is very misleading; these productions are= >>> used in *values*, after potential unescaping of quoted-string; so at a >>> completely different processing level. >>=20 >> I don't understand what you're complaining about here. Is it just the >> ordering of the ABNF productions? If so, suggest specifically where >> "node" should go in the order. If it's that you don't want the ABNF >> all in one place, we're going to have a row about that, because I >> strongly think that it's easier on implementors to have it together. >=20 > I'd like to be where it was. >=20 > Having the productions in a single place suggests that they are somehow re= lated to each other, which they are not at all. >=20 My 2p: having ABNF in one place is Ok. Besides it means that all productions= are defined before being referenced. From ned.freed@mrochek.com Mon Jul 23 14:18:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2560D11E808E for ; Mon, 23 Jul 2012 14:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVf2zj8kOC4W for ; Mon, 23 Jul 2012 14:18:21 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA1711E807F for ; Mon, 23 Jul 2012 14:18:21 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OI6XF7WDZ4005NL7@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 23 Jul 2012 14:13:18 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OHZVQBJXY80006TF@mauve.mrochek.com>; Mon, 23 Jul 2012 14:13:15 -0700 (PDT) Message-id: <01OI6XF6DE7Y0006TF@mauve.mrochek.com> Date: Mon, 23 Jul 2012 13:24:53 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 23 Jul 2012 15:37:42 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <500D94C4.8030304@gmx.de> <500DA5E1.1020006@gmx.de> To: Barry Leiba Cc: Julian Reschke , IETF Apps Discuss Subject: Re: [apps-discuss] ABNF changes in draft-ietf-appsawg-http-forwarded-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2012 21:18:22 -0000 > >>> 2) Moving the "node" ABNF here is very misleading; these productions are > >>> used in *values*, after potential unescaping of quoted-string; so at a > >>> completely different processing level. > >> > >> I don't understand what you're complaining about here. Is it just the > >> ordering of the ABNF productions? If so, suggest specifically where > >> "node" should go in the order. If it's that you don't want the ABNF > >> all in one place, we're going to have a row about that, because I > >> strongly think that it's easier on implementors to have it together. > > > > I'd like to be where it was. > > > > Having the productions in a single place suggests that they are somehow > > related to each other, which they are not at all. > Nonsense. Having them in a single place makes them easier to find and > easier to refer to. Indeed it does. But it also means that the text referencing the ABNF may now be disconnected from it. > I'm happy to defer to you on the content of the productions. But for > the arrangement, I think it's a bad idea to have small bits of ABNF in > different places in the document. > Does anyone besides Julian and me have a comment on this point? It's a tradeoff and there is no one right answer. Of the three options: (1) ABNF where the text defines/refers to the construct. (2) Collected ABNF. (3) Both (1) and (2). The only one I think has no place is (3), and that's only because our relatively weak tools have no means of doing the collecting for us, leading to silly states when revisions are made. Generally speaking I prefer (1) when there are only a few bits of ABNF in the document. (2) is strongly preferred when you're defining, say, an entire language. Anything in between is a judgement call. Another factor that needs to be considered is whether or not the text talks about or elaborates on specific ABNF details. In that case the ABNF needs to be adjacent. Otherwise I tend to perfer collecting. Getting back to the document at hand, one problem I see is that the recent change has the text and ABNF at odds with each other: There's now a section that purports to describe a header field but it now includes ABNF that isn't directly references into that definition at all. That's confusing, but it can easily be solved by moving the collected ABNF to the end in a collected ABNF section. However, that really doesn't address the main issue here, which is that this document is using something I call a syntax overlap. Specifically, there's a general ABNF for the field, then there is additional ABNF that kinda sorta replaces one ABNF production (value) with another (node). Except it doesn't really do that, because that blurs the distinction between a token and a quoted string. It's ABNF restricting what can appear inside a value, and AFAIK we have no representation for that sort of thing. The original MIME RFC was full of this sort of stuff, and for exactly the same reason: We were trying to restrict the syntax of media type parameter values And people complained about it because it was - big duh here - inconsistent and therefore quite confusing. When I took over editorship from Nathaniel I spent a bunch of time trying to getting rid of the inconsistencies without adding unnecessary complexity, and failing miserably. I then took a much more radical step: I deleted every last bit of the overlapping ABNF. And if memory serves, exactly one person complained, and they went silent when I asked them how they would have fixed the inconsistency issue. My takeaway from that is overlapping ABNF should be used sparingly if at all, but when it is unavoidable keeping it separate and unlinked is actuallly preferablea. As a result my fairly strong preference in this case is to go with the approach in the previous draft version. But this has everything to do with the overlap, and nothing to do with how ABNF is best presented when there is no overlap. If there was no overlap I'd prefer to have all the ABNF in one place. Ned From paulej@packetizer.com Mon Jul 23 18:43:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A46921F844E for ; Mon, 23 Jul 2012 18:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuzrUEgiuFzW for ; Mon, 23 Jul 2012 18:43:32 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 65A6821F844A for ; Mon, 23 Jul 2012 18:43:32 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q6O1hT8R020891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jul 2012 21:43:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1343094210; bh=/PgczUF9If5EQPFleR1jAiC93WvMVAwhuVmE80l6Jpk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=NjDe+Sq9zynkFJwgLu/b7LfXNHdFJZ6K0wGJlZlsVieohdcSeLCQj2XRD3CJKeFhK t8l2Nvb6kk49ld5F6vzTMyobT5ZBJLExWggJ4090OXMfoaVw+oCinGVc2UwCIB2ktv FEI1B5ZnHC1u6NQ9srPljUz4gkO75i7fhGCpVUf0= From: "Paul E. Jones" To: "'James M Snell'" References: <0bfa01cd5e4c$9ff2fe40$dfd8fac0$@packetizer.com> <0d8401cd5ef3$09872c90$1c9585b0$@packetizer.com> In-Reply-To: Date: Mon, 23 Jul 2012 21:43:31 -0400 Message-ID: <016801cd693d$bb651d60$322f5820$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIESQ8ibvH5DCcy0bSWDNtRTuLHcQHrVckpAT77RpsC8F+mjQJv6czGloV35qA= Content-Language: en-us Cc: 'IETF Apps Discuss' Subject: Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and Simple Web Discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2012 01:43:33 -0000 James, Sorry for the belated reply. I was out of the office the week your = message came in and I'm still catching up. One has to have some kind of syntax. It might be in the form of a Link = header (as you've proposed in the "index" draft) or a payload (as = proposed in the "WebFinger" and "SWD" drafts). Regardless of the = approach, there is syntax. What we've proposed in WebFinger and SWD is to return the information = we're seeking in the payload of the HTTP request. For clients, this is = the more appropriate place to put it, since this is how HTTP is intended = to use. Using Link headers as a form of metadata is perhaps useful when = returning various web content, but I don't think it should be the syntax = for the primary content being returned. In fact, one might even use a = Link header in a WF response of there was appropriate metadata to = convey. The approach we've proposed in WF provides for a simple client-side = implementation that is consistent, and it also allows one to separate = the HTTP request/response logic from the software layer that requests = and acts upon the discoverable information. A WF application could = request information and it would get a payload of information back or it = will not. Messages like 3xx can be handled "under the hood", as could = authentication request, 5xx, etc.=20 Another benefit to using JSON or XML, either one, is that one could = convey more information than just a link relation and value. There are = also properties that could be defined. We discussed on this list how we = could use those properties to indicate what port numbers or other = information to use by an auto-provisioning email client, as an example. = For clients not interested in those properties, they would simply be = ignored. So regardless of approach, there is syntax. It's a matter of where that = syntax is placed, how useful the syntax is, and how easily it can be = consumed. All of the approaches presented are fairly simple, but I = think building on host-meta (which was the plan for the past several = years) offers the most consistent approach, while also being simple and = rich at the same time. I can issue a single query and get a payload = with lots of information back, all neatly wrapped in a simple syntax = carried in the response payload. Let me also say that I tell you all of this without bias. I did not = create the XRD syntax, RFC 6415, or define any of the mechanisms myself. = I came to the party a bit late after much of this was already defined = (XRD was just being approved). I liked what I saw and I am interested = to see it through, as it has value to social networking applications and = enterprise applications. Paul > -----Original Message----- > From: James M Snell [mailto:jasnell@gmail.com] > Sent: Wednesday, July 11, 2012 7:03 PM > To: Paul E. Jones > Cc: IETF Apps Discuss > Subject: Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: = WebFinger > and Simple Web Discovery >=20 > Paul, for most of this we'll apparently have to simply disagree and = leave > it at that as I've got no intention or desire to try to convince you = to > change your opinion. The intent of my memo was to solely to document = that > I feel there's an even easier way of accomplishing the same task with > fewer moving parts. I believe I provided an adequate example that = proves > that point. >=20 > I still do not see why parsing *any* XML or JSON should be a = requirement, > however, as I do not see what particular benefit they provide. I've = asked > several times but have not yet seen a clear answer to this very basic > question: *Why* are they *required*? What benefits do those = dependencies > provide that are critical to solving the basic problem? Are they = simply > something that would be nice to have? >=20 > I don't need yet another explanation as to why you think it's just = trivial > so why am I bothering to ask... I want to know why those dependencies = are > *required*. >=20 > Note, fwiw, that the /.well-known/index proposal is not contrary to = the > possible use of XRD/LRDD... for instance, one could easily do = something > like... >=20 > GET /.well-known/index/{some-opaque-id}/lrdd HTTP/1.1 > Host: example.org >=20 > And get back a... >=20 > HTTP/1.1 302 Found > Location: /lrdd/?uri=3Dacct:bob@example.org >=20 > - James From paulej@packetizer.com Mon Jul 23 19:54:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DBF21F8534 for ; Mon, 23 Jul 2012 19:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuXl3YNSn2A8 for ; Mon, 23 Jul 2012 19:54:05 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A844E21F8526 for ; Mon, 23 Jul 2012 19:54:05 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q6O2s2Cv022749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jul 2012 22:54:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1343098443; bh=94uIQrCo+spaJ8dh3mFDeVff3t031uW9RFY2yb4UD/Q=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=g8SucFZr+qqHIUIbY3DYncHrXHbHU13zP74ZDUK80VnAPsGOOzhBMTHW5gFIa9fzU 0tJZXdXgRAEpPll3PaTUtsH/sQB3RFFqnxHBQUC7VEWNt3WkLVGX2itKcKWRK2D+4e +LuO63cn5npEXalXgOO+6ave4v5b0DFh067GIZ8o= From: "Paul E. Jones" To: "'Melvin Carvalho'" References: <0bfa01cd5e4c$9ff2fe40$dfd8fac0$@packetizer.com> <0d8401cd5ef3$09872c90$1c9585b0$@packetizer.com> In-Reply-To: Date: Mon, 23 Jul 2012 22:54:03 -0400 Message-ID: <018201cd6947$964cc320$c2e64960$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0183_01CD6926.0F3DBB30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIESQ8ibvH5DCcy0bSWDNtRTuLHcQHrVckpAT77RpsC8F+mjQJiwRJtloYQ81A= Content-Language: en-us Cc: 'IETF Apps Discuss' Subject: Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and Simple Web Discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2012 02:54:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0183_01CD6926.0F3DBB30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, When I said JSON did not have a formal syntax specification, I intended to say a schema definition. I know there was work on a JSON schema, but not sure where that went. JSON is certainly well-defined, but a complete schema language is missing. Therefore, it's hard to define things in terms of JSON without doing so using examples. RFC 6415 did it by considering XRD syntax and specifying how that maps. Paul From: Melvin Carvalho [mailto:melvincarvalho@gmail.com] Sent: Thursday, July 12, 2012 4:30 AM To: Paul E. Jones Cc: James M Snell; IETF Apps Discuss Subject: Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and Simple Web Discovery On 11 July 2012 01:23, Paul E. Jones wrote: James, > On Mon, Jul 9, 2012 at 8:32 PM, Paul E. Jones > wrote: > > James, > > > > Allow me to comment on your draft w.r.t. the parts related to WebFinger. > > WebFinger did built upon the host-meta spec, which is that we see the > > "two step" process. However, the "resource" parameter MUST be > > supported by WebFinger servers. As such, this eliminates most of the > > complexity issues on the client side. > > > > To your comments specifically, > > > > 1) XRD and JRD support: this is only required on the server. The > > client can choose what it wants. This is largely historical, but I'm > > not shy to say that I favor XML. I respect that some prefer JSON, > though. > > > > Why should there be a choice at all? Just choose one and be done with > it... preferably the least complicated of the two > (http://www.xprogramming.com/Practices/PracSimplest.html) This is due to the relatively recent shift in the "preferred syntax de jour". When the work on WebFinger and host-meta started, XML was considered the lingua franca of the Internet. Interest in JSON was growing, but still had not reached critical mass. By the time RFC 6415 was nearing publication, interest in JSON had grown to a point where the authors felt it needed inclusion, so a JSON version of XRD (called JRD) was defined in RFC 6415. They're both trivial syntaxes. Since JSON lacks a formal syntax specification I think JSON does have a formal syntax specification: http://json.org/ Or did you mean that JRD? , JRD is defined with respect to XRD, which is in turn defined using XML Schema. JRD is definitely most interesting to people right now, but XRD is already implemented in the wild. Personally, I prefer XRD and see no particular advantage in using JRD. (JSON works well in JavaScript applications, so I appreciate why people would like to use it. In C++, though, present roughly the same work to utilize.) XRD and JRD are defined in RFC 6415. They exist and so I do not see any reason to exclude one in favor of the other. Writing the server code to support both is a trivial exercise, so why remove one arguing that it's complex? It's not. > > 2) Two-step HTTP request process: Requests could be a single step. No > > client is required to implement a two-step request, ever. The > > two-step option exists, since WebFinger is an extension of RFC 6415, > > but the "resource" makes the query a one-step operation. > > > > Yup... I made sure to point this out clearly in my note. If, as you say, > clients are not ever required to implement the two-step flow, then why is > it defined at all? Why add the additional complexity? This was one of the > main points of my document and my counter proposal for /.well-known/index > ... the RFC6415 requirement seems entirely superfluous to achieving the > goal. Host-Meta / WebFinger allows for one to query information related to a host and to specific resources controlled by that host. So, a client can make a query and learn something about the host. One can then make a second query and learn about a particular resource at that host. Alternatively, if information about the host is not of interest, one can make a single query and ask for information about the resource directly. We could re-write RFC 6415 and say that if the "resource" parameter is not there, only return host-specific link relations (versus URI templates). However, there is no point in re-writing writing what is defined and implemented. That's especially true given how simple and consistent the logic is when implementing the host-meta / WebFinger server code. > > 3) There are several sub-parts: > > > > 3a) The WebFinger protocol defines normative dependencies on no fewer > > than ten separate specifications: that's being a bit unfair. We tried > > to be thorough with documenting material. We could perhaps make > > .well-known, web linking, URI syntax, and mailto URI informative. We > > could discuss where those references should live, but HTTP and XRD/JRD > > are really the core part of WebFinger. It's not so complex as you > suggest here. > > > > 3b) A WebFinger client needs to not only be capable of sending HTTP > > requests; but capable of parsing XML or JSON: They must parse one of > > the two. This is pretty basic. > > > > 3c) Capable of understanding the specific XRD and JRD vocabularies: > > there are no "specific" vocabularies, just XRD and JRD syntax. Both > > are simple and a client picks what it wants. > > > > 3d) Capable of processing URL Templates: since "resource" is > > mandatory, a client does not need to deal with templates > > I think you may have missed the key point I was making: XML, JSON, XRD, > JRD, URL templates, Digital Signatures, host-meta.. these are all things > that WebFinger says are required without providing any reasonable > justification as to WHY they are required. Both the Simple Web Discovery > draft and my /.well-known/index examples illustrate that we can easily > solve the fundamental problem with a whole lot less than what WebFinger > defines... even if those things are -- by your own statement -- only there > for "spec completeness". Your draft and SWD just use a different syntax. They do not eliminate syntax. One way or the other, we must have syntax. XRD and JRD are required, because RFC 6415 (which is the basis for WebFinger) defined XRD and JRD. RFC 6415 is something this group just completed in October 2011, I'll note. Signatures on XRD are optional and I doubt anybody will do it, anyway. I suspect the folks in OASIS did that just for completeness. I'm certainly not going to ever bother with them. People should use HTTPS and be done with it. URI templates are useful to RFC 6415 and those who elect to not use the "resource" parameter. Using the "resource" parameter, one never sees URI templates. However, they exist because they are defined in RFC 6415 to allow for querying resource-specific link relations. So what does it take to create a WebFinger server? It's so trivial, I can do it with static files. When one can do that, that means it's not that complex. See here for an example: http://www.packetizer.com/webfinger/server.html > > 3e) Capable of processing XML digital signatures included within an > > XRD > > document: yeah, if HTTPS is not used. I doubt anybody will use > > signatures in favor of HTTPS. I suspect no client will process the > signatures, either. > > (There is "standards completeness" and reality.) > > > > 4) WebFinger uses email-like identifiers and this is a privacy concern: > > email-like IDs are suggested to make WebFinger easy to use *by > > humans*, but there is definitely no requirement that one MUST use > > "acct:paulej@packetizer.com ". One can use any valid URI. An > > enterprise could use some cryptic URI. The recommendation to use > > paulej@packetizer.com, for example, it to make your life easier if you > > want to learn more about me. What is actually exposed and what is > > accessible is a matter of the publisher of that content and can be > > secured using standard web security mechanisms. Note that use of > > HTTPS also hides the email-like ID, too, so it's not seen on the wire, > > so I'm really not sure why you're concerned with this. Those who want > security will use TLS. > > Several things with this one... > > 1. All of the examples that deal with people show the use of acct > identifiers. From experience, I know that developers will generally look > at the examples in the spec before they look at the spec text itself and > they will generally follow whatever pattern is illustrated... Simply > saying that "some cryptic URI" could be used does not sufficiently deal > with the issue. Support for hashed or otherwise obfuscated identifiers > within the request URI should be made explicit .. either via clear example > or by normative requirement. Not all examples use "acct", though most certainly do. There are three examples using "http" and one using a fictitious "device". If one uses TLS, this is a non-issue, anyway. When TLS is used, identifiers are never seen outside the application. Even if TLS was not used, I'm still not sure why hiding one's identifier is a concern when we're also perfectly OK with returning information about people in the clear or making it public in the first place :-) > 2. The use of SSL/TLS does not prevent request URIs from being recorded in > log files, exposed in browsers, or compromised in a variety of unforeseen > ways. Yes, it protects the data in transit but protects nothing when the > data is at rest. The server that would be responding to requests would be the one that would be recording stuff in log files when using TLS. It already knows about these IDs and could certainly translate an obfuscated value into a real value and log requests that way. Exposed in browsers? Users will type in "paulej@packetizer.com", so it's already in a browser. If one wants to use something with WF that does not look like an email address, they can. > > So just to reiterate, a WebFinger request for this URL: > > > > https://packetizer.com/.well-known/host-meta.json?resource=acct:paulej > > @packe > > tizer.com > > > > Typically looks like this: > > > > GET /.well-known/host-meta.json?resource=acct:paulej@packetizer.com > > HTTP/1.1 > > Host: packetizer.com > > > > The reply might have this body: > > > > { > > "subject" : "acct:paulej@packetizer.com ", > > "links" : > > [ > > { > > "rel" : "http://webfinger.net/rel/avatar", > > "href" : > "http://www.packetizer.com/people/paulej/images/paulej.jpg" > > }, > > { > > "rel" : "http://specs.openid.net/auth/2.0/provider", > > "href" : "https://openid.packetizer.com/paulej" > > }, > > { > > "rel" : "http://webfinger.net/rel/profile-page", > > "href" : "http://www.packetizer.com/people/paulej/" > > }, > > { > > "rel" : "vcard", > > "href" : "http://www.packetizer.com/people/paulej/paulej.vcf" > > }, > > { > > "rel" : "http://schemas.google.com/g/2010#updates-from", > > "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml" > > } > > ] > > } > > > > That's a fairly simple request / response, IMO. > > > > And an alternative approach would look like.. (the numbers are the > sha-256 digest of the acct id) > > GET /.well- > known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d7 > f8 > HTTP/1.1 > Host: packetizer.com > > HTTP/1.1 300 Multiple Choices > Link: ; > rel="http://webfinger.net/rel/avatar", > ; > rel="http://specs.openid.net/auth/2.0/provider", > ; rel="http://webfinger.net/rel/profile.page", > ; rel="vcard", > ; > rel="http://schemas.google.com/g/2010#updates-from" This is just another syntax, as I said. Also, I personally find this more challenging to deal with since it's in the headers, not the payload. Might the web server itself want to introduce a Link header or perhaps a web proxy? One might get back information that was not strictly about the resource being queried. (For example, a link to a copyright statement or "authorized users" statement or other.) > And if all I want is the location of the avatar, for instance, it could be > even easier... > > GET /.well- > known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d7 > f8/avatar > HTTP/1.1 > Host: packetizer.com > > HTTP/1.1 302 Found > Location: /people/paulej/images/paulej.jpg So, I get a 302 and don't know why. Am I being redirected because the user's information moved or because the information I seek is located there? Web browsers will not even tell me about 302s when writing JavaScript code, AFAIK. So, I might issue a query to get several things (e.g., calendar and avatar), but only an avatar exists. The server returns a 302 and I get a payload with a picture and have no idea what it is for. Or would you return a 200 in that case with a single "Link:" href/rel pair? > Why should I, as the client, ever have to worry about XRD/JRD at all? > This is an important question that I have not yet seen an adequate answer > for. Anyone who has worked with me before on things knows that with solid > examples and a reasonable explanation I can be swayed to see the light and > the error of my ways. So far, however, I am just not seeing it here. Because this is a very simple and consistent syntax that nicely packages up a set of link relations and properties. I might also provided with a list of aliases for the user/target. We had a separate dialog about how we could use the JRD syntax to convey provisioning information related to mail servers. I'm not sure if anyone would do that, but having the ability to include additional properties is nice, since it allows for a richer set of information to be conveyed. Lastly, having an XRD or JRD in hand allows that document to be passed "down the line" for processing. Headers in HTTP could, too, but as I said, it's an alternate syntax that is less complete and I personally find dealing with a returned payload simpler than putting valuable response information in headers. Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_0183_01CD6926.0F3DBB30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

When I said JSON did not have a formal syntax specification, I = intended to say a schema definition.  I know there was work on a = JSON schema, but not sure where that went.  JSON is certainly = well-defined, but a complete schema language is missing.  = Therefore, it’s hard to define things in terms of JSON without = doing so using examples.  RFC 6415 did it by considering XRD syntax = and specifying how that maps.

 

Paul

 

From:= = Melvin Carvalho [mailto:melvincarvalho@gmail.com]
Sent: = Thursday, July 12, 2012 4:30 AM
To: Paul E. = Jones
Cc: James M Snell; IETF Apps Discuss
Subject: = Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and = Simple Web Discovery

 

 

On 11 July 2012 01:23, Paul E. Jones <paulej@packetizer.com> wrote:

James,


> On Mon, Jul 9, 2012 at 8:32 PM, = Paul E. Jones <paulej@packetizer.com>
&g= t; wrote:
> > James,
> >
> > Allow me to = comment on your draft w.r.t. the parts related to WebFinger.
> = > WebFinger did built upon the host-meta spec, which is that we see = the
> > "two step" process.  However, the = "resource" parameter MUST be
> > supported by = WebFinger servers.  As such, this eliminates most of the
> = > complexity issues on the client side.
> >
> > To = your comments specifically,
> >
> > 1) XRD and JRD = support: this is only required on the server. The
> > client = can choose what it wants.  This is largely historical, but = I'm
> > not shy to say that I favor XML.  I respect that = some prefer JSON,
> though.
> >
>
> Why = should there be a choice at all? Just choose one and be done = with
> it... preferably the least complicated of the two
> = (http://www.xprogramming.com/Practices/PracSimplest.html= )

This is due to the = relatively recent shift in the "preferred syntax de jour". =  When the work on WebFinger and host-meta started, XML was = considered the lingua franca of the Internet.  Interest in JSON was = growing, but still had not reached critical mass.  By the time RFC = 6415 was nearing publication, interest in JSON had grown to a point = where the authors felt it needed inclusion, so a JSON version of XRD = (called JRD) was defined in RFC 6415.

They're both trivial = syntaxes.  Since JSON lacks a formal syntax = specification


I think JSON = does have a formal syntax specification:

http://json.org/

Or did you mean = that JRD?
 

, JRD is = defined with respect to XRD, which is in turn defined using XML Schema. =  JRD is definitely most interesting to people right now, but XRD is = already implemented in the wild.  Personally, I prefer XRD and see = no particular advantage in using JRD.  (JSON works well in = JavaScript applications, so I appreciate why people would like to use = it.  In C++, though, present roughly the same work to = utilize.)

XRD and JRD are defined in RFC 6415.  They exist = and so I do not see any reason to exclude one in favor of the other. =  Writing the server code to support both is a trivial exercise, so = why remove one arguing that it's complex?  It's = not.


> > 2) Two-step HTTP request = process: Requests could be a single step.  No
> > client = is required to implement a two-step request, ever.  The
> = > two-step option exists, since WebFinger is an extension of RFC = 6415,
> > but the "resource" makes the query a = one-step operation.
> >
>
> Yup... I made sure to = point this out clearly in my note. If, as you say,
> clients are = not ever required to implement the two-step flow, then why is
> it = defined at all? Why add the additional complexity? This was one of = the
> main points of my document and my counter proposal for = /.well-known/index
> ... the RFC6415 requirement seems entirely = superfluous to achieving the
> goal.

Host-Meta / WebFinger allows for one to query = information related to a host and to specific resources controlled by = that host.  So, a client can make a query and learn something about = the host.  One can then make a second query and learn about a = particular resource at that host.  Alternatively, if information = about the host is not of interest, one can make a single query and ask = for information about the resource directly.

We could re-write = RFC 6415 and say that if the "resource" parameter is not = there, only return host-specific link relations (versus URI templates). =  However, there is no point in re-writing writing what is defined = and implemented.  That's especially true given how simple and = consistent the logic is when implementing the host-meta / WebFinger = server code.


> > 3) There are several = sub-parts:
> >
> > 3a) The WebFinger protocol defines = normative dependencies on no fewer
> > than ten separate = specifications: that's being a bit unfair. We tried
> > to be = thorough with documenting material.  We could perhaps make
> = > .well-known, web linking, URI syntax, and mailto URI informative. =  We
> > could discuss where those references should live, = but HTTP and XRD/JRD
> > are really the core part of WebFinger. =  It's not so complex as you
> suggest here.
> = >
> > 3b) A WebFinger client needs to not only be capable of = sending HTTP
> > requests; but capable of parsing XML or JSON: = They must parse one of
> > the two. This is pretty = basic.
> >
> > 3c) Capable of understanding the = specific XRD and JRD vocabularies:
> > there are no = "specific" vocabularies, just XRD and JRD syntax. Both
> = > are simple and a client picks what it wants.
> >
> = > 3d) Capable of processing URL Templates: since "resource" = is
> > mandatory, a client does not need to deal with = templates
>
> I think you may have missed the key point I = was making: XML, JSON, XRD,
> JRD, URL templates, Digital = Signatures, host-meta.. these are all things
> that WebFinger says = are required without providing any reasonable
> justification as = to WHY they are required. Both the Simple Web Discovery
> draft = and my /.well-known/index examples illustrate that we can easily
> = solve the fundamental problem with a whole lot less than what = WebFinger
> defines... even if those things are -- by your own = statement -- only there
> for "spec = completeness".

Your draft = and SWD just use a different syntax.  They do not eliminate syntax. =  One way or the other, we must have syntax.

XRD and JRD are = required, because RFC 6415 (which is the basis for WebFinger) defined = XRD and JRD.  RFC 6415 is something this group just completed in = October 2011, I'll note.

Signatures on XRD are optional and I = doubt anybody will do it, anyway.  I suspect the folks in OASIS did = that just for completeness.  I'm certainly not going to ever bother = with them.  People should use HTTPS and be done with it.

URI = templates are useful to RFC 6415 and those who elect to not use the = "resource" parameter.  Using the "resource" = parameter, one never sees URI templates.  However, they exist = because they are defined in RFC 6415 to allow for querying = resource-specific link relations.

So what does it take to create = a WebFinger server?  It's so trivial, I can do it with static = files.  When one can do that, that means it's not that complex. =  See here for an example:
http://www.packetizer.com/webfinger/server.html


> > 3e) Capable of processing = XML digital signatures included within an
> > XRD
> > = document: yeah, if HTTPS is not used. I doubt anybody will use
> = > signatures in favor of HTTPS.  I suspect no client will = process the
> signatures, either.
> > (There is = "standards completeness" and reality.)
> >
> = > 4) WebFinger uses email-like identifiers and this is a privacy = concern:
> > email-like IDs are suggested to make WebFinger = easy to use *by
> > humans*, but there is definitely no = requirement that one MUST use
> > "acct:paulej@packetizer.com".  One can use any valid URI.  An
> > = enterprise could use some cryptic URI.  The recommendation to = use
> > paulej@packetizer.com, for = example, it to make your life easier if you
> > want to learn = more about me.  What is actually exposed and what is
> > = accessible is a matter of the publisher of that content and can = be
> > secured using standard web security mechanisms. =  Note that use of
> > HTTPS also hides the email-like ID, = too, so it's not seen on the wire,
> > so I'm really not sure = why you're concerned with this.  Those who want
> security = will use TLS.
>
> Several things with this = one...
>
> 1. All of the examples that deal with people show = the use of acct
> identifiers. From experience, I know that = developers will generally look
> at the examples in the spec = before they look at the spec text itself and
> they will generally = follow whatever pattern is illustrated... Simply
> saying that = "some cryptic URI" could be used does not sufficiently = deal
> with the issue. Support for hashed or otherwise obfuscated = identifiers
> within the request URI should be made explicit .. = either via clear example
> or by normative = requirement.

Not all = examples use "acct", though most certainly do.  There are = three examples using "http" and one using a fictitious = "device".

If one uses TLS, this is a non-issue, anyway. =  When TLS is used, identifiers are never seen outside the = application.  Even if TLS was not used, I'm still not sure why = hiding one's identifier is a concern when we're also perfectly OK with = returning information about people in the clear or making it public in = the first place :-)


> 2. The use of SSL/TLS does not = prevent request URIs from being recorded in
> log files, exposed = in browsers, or compromised in a variety of unforeseen
> ways. = Yes, it protects the data in transit but protects nothing when = the
> data is at rest.

The server that would be responding to requests would = be the one that would be recording stuff in log files when using TLS. =  It already knows about these IDs and could certainly translate an = obfuscated value into a real value and log requests that way. =  Exposed in browsers?  Users will type in "paulej@packetizer.com", = so it's already in a browser.  If one wants to use something with = WF that does not look like an email address, they = can.


> > So just to reiterate, a = WebFinger request for this URL:
> >
> > https://packetizer.com/.well-known/host-meta.json?resou= rce=3Dacct:paulej
> > @packe
> > tizer.com
> = >
> > Typically looks like this:
> >
> > = GET /.well-known/host-meta.json?resource=3Dacct:paulej@packetizer.com
> > HTTP/1.1
> > Host: packetizer.com
> >
> > The reply = might have this body:
> >
> > {
> >   = "subject" : "acct:paulej@packetizer.com",
> >   "links" :
> >   = [
> >     {
> >       = "rel" : "http://webfinger.net/rel/avatar",
> = >       "href" :
> "http://www.packetizer.com/people/paulej/images/paulej.j= pg"
> >     },
> >     = {
> >       "rel" : "http://specs.openid.net/auth/2.0/provider",> >       "href" : "https://openid.packetizer.com/paulej"
> = >     },
> >     {
> >   =     "rel" : "http://webfinger.net/rel/profile-page",
>= ; >       "href" : "http://www.packetizer.com/people/paulej/"
&= gt; >     },
> >     {
> > =       "rel" : "vcard",
> > =       "href" : "http://www.packetizer.com/people/paulej/paulej.vcf&= quot;
> >     },
> >     {
> = >       "rel" : "http://schemas.google.com/g/2010#updates-from"= ,
> >       "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml"
> >     }
> >   ]
> > = }
> >
> > That's a fairly simple request / response, = IMO.
> >
>
> And an alternative approach would look = like.. (the numbers are the
> sha-256 digest of the acct = id)
>
> GET /.well-
> = known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d= 7
> f8
> HTTP/1.1
> Host: packetizer.com
>
> HTTP/1.1 300 = Multiple Choices
> Link: = </people/paulej/images/paulej.jpg>;
> rel=3D"http://webfinger.net/rel/avatar",
> =   <https://openid.packetizer.com/paulej>;
> = rel=3D"http://specs.openid.net/auth/2.0/provider",>   </people/paulej/>; rel=3D"http://webfinger.net/rel/profile.page",
>= ;   </people/paulej/paulej.vcf>; = rel=3D"vcard",
>   = </people/paulej/blog/blog.xml>;
> rel=3D"http://schemas.google.com/g/2010#updates-from"=

This is just another = syntax, as I said.  Also, I personally find this more challenging = to deal with since it's in the headers, not the payload.

Might = the web server itself want to introduce a Link header or perhaps a web = proxy?  One might get back information that was not strictly about = the resource being queried.  (For example, a link to a copyright = statement or "authorized users" statement or = other.)


> And if all I want is the = location of the avatar, for instance, it could be
> even = easier...
>
> GET /.well-
> = known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d= 7
> f8/avatar
> HTTP/1.1
> Host: packetizer.com
>
> HTTP/1.1 302 = Found
> Location: = /people/paulej/images/paulej.jpg

So, I get a 302 and don't know why.  Am I being = redirected because the user's information moved or because the = information I seek is located there?  Web browsers will not even = tell me about 302s when writing JavaScript code, AFAIK.  So, I = might issue a query to get several things (e.g., calendar and avatar), = but only an avatar exists.  The server returns a 302 and I get a = payload with a picture and have no idea what it is for.  Or would = you return a 200 in that case with a single "Link:" href/rel = pair?


> Why should I, as the client, = ever have to worry about XRD/JRD at all?
> This is an important = question that I have not yet seen an adequate answer
> for. Anyone = who has worked with me before on things knows that with solid
> = examples and a reasonable explanation I can be swayed to see the light = and
> the error of my ways. So far, however, I am just not seeing = it here.

Because this is a very = simple and consistent syntax that nicely packages up a set of link = relations and properties.  I might also provided with a list of = aliases for the user/target.

We had a separate dialog about how = we could use the JRD syntax to convey provisioning information related = to mail servers.  I'm not sure if anyone would do that, but having = the ability to include additional properties is nice, since it allows = for a richer set of information to be conveyed.

Lastly, having an = XRD or JRD in hand allows that document to be passed "down the = line" for processing.  Headers in HTTP could, too, but as I = said, it's an alternate syntax that is less complete and I personally = find dealing with a returned payload simpler than putting valuable = response information in headers.

Paul


_______________________________________________
= apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 

------=_NextPart_000_0183_01CD6926.0F3DBB30-- From julian.reschke@gmx.de Tue Jul 24 00:54:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C2821F8616 for ; Tue, 24 Jul 2012 00:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.633 X-Spam-Level: X-Spam-Status: No, score=-104.633 tagged_above=-999 required=5 tests=[AWL=-2.653, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo4n+4Q3PEOS for ; Tue, 24 Jul 2012 00:54:48 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id BA9E521F8615 for ; Tue, 24 Jul 2012 00:54:47 -0700 (PDT) Received: (qmail invoked by alias); 24 Jul 2012 07:54:45 -0000 Received: from p54BB2E36.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.46.54] by mail.gmx.net (mp027) with SMTP; 24 Jul 2012 09:54:45 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Xl80UKMOXq93kE2g2zItCGuJdmgwCbXXPCvpYQM 7K5EwgRNBvNrJo Message-ID: <500E54BC.7010102@gmx.de> Date: Tue, 24 Jul 2012 09:54:36 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Barry Leiba References: <500D94C4.8030304@gmx.de> <500DA5E1.1020006@gmx.de> <500DAA4F.5040802@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] ABNF changes in draft-ietf-appsawg-http-forwarded-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2012 07:54:49 -0000 On 2012-07-23 22:20, Barry Leiba wrote: > ... >> Again: if somebody writes a parser that deals with both "forwarded-pair" and >> "node" in the same piece of code, then that parser is VERY likely broken. > > Oh, I think the component you're referring to isn't the parser (the > same parser absolutely will be used for both in many implementations), What I'm trying to say is that the natural way to process this header is a two-step process (starting with the field value extracted from the HTTP header block): 1) Parse into a list of forwarded-elements, containing lists of forwarded-pairs, consisting of parameter name and value (unescaping the quoted-string value when needed). 2) Parse the values inside the forwarded-pair parameter values according to the syntactical constraints of the given parameter. The ABNF needed for 1) belongs into Section 4. The ABNF fragments for 2) belong into Section 5 (or later). There's absolutely no point to present ABNF productions that haven't anything to do with 1) in Section 4. > but the lexical processor. But that doesn't really matter; you're > right that if someone tries to treat a "node" as the same part of > speech as a "forwarded-pair", we have problems. > >> The same issue will come up very soon in HTTPbis; if you disagree how we're >> doing things over there it would be very good to find out about that before >> we're after LC. > > How about this as a compromise; I would be very happy with this alternative: > > The ABNF stays together in the same section, but it is separated into > groupings (or subsections, that would be OK too) to make it clear that > the grouping that contains "node" is lexically different to the other > grouping(s). > > What do you think? The productions could be grouped as they were > before, along with forward references to where they're discussed. I think it's marginally better, but still much much worse than what we had before. I'll also quote from Ned's mail: > ... > However, that really doesn't address the main issue here, which is that this > document is using something I call a syntax overlap. Specifically, there's a > general ABNF for the field, then there is additional ABNF that kinda sorta > replaces one ABNF production (value) with another (node). Except it doesn't > really do that, because that blurs the distinction between a token and a quoted > string. It's ABNF restricting what can appear inside a value, and AFAIK we have > no representation for that sort of thing. > ... That's exactly what's going on here, and it would be cool if we could come up with a recommendation how to deal with cases like these. The ABNF in the draft we're discussing defines *multiple* grammars; one for parsing the field value in general, and then multiple mini-grammars for specific parameter values. These have nothing to do with each other, except for potentially re-using common ABNF constructs. We shouldn't give the impression that this is not the case. Best regards, Julian From masinter@adobe.com Fri Jul 27 12:12:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A39021F867E for ; Fri, 27 Jul 2012 12:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.37 X-Spam-Level: X-Spam-Status: No, score=-105.37 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9W3CSMgds+A for ; Fri, 27 Jul 2012 12:12:36 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED3621F86E8 for ; Fri, 27 Jul 2012 12:12:33 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUBLoIcpvTEGgqom4HldkBnmTJWr2uEL4@postini.com; Fri, 27 Jul 2012 12:12:35 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q6RJA6k0012734; Fri, 27 Jul 2012 12:10:06 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q6RJBxZD018174; Fri, 27 Jul 2012 12:12:31 -0700 (PDT) Received: from SJ1SWM219.corp.adobe.com (10.5.77.61) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.3.264.0; Fri, 27 Jul 2012 12:12:23 -0700 Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by SJ1SWM219.corp.adobe.com ([fe80::d55c:7209:7a34:fcf7%12]) with mapi; Fri, 27 Jul 2012 12:12:23 -0700 From: Larry Masinter To: "Murray S. Kucherawy" , IETF Apps Discuss Date: Fri, 27 Jul 2012 12:12:21 -0700 Thread-Topic: [apps-discuss] Status of draft-ietf-appsawg-media-type-suffix-regs Thread-Index: Ac1lG/+uVS7u+3E4QLm1Tg5nnUkf2gHDulxg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C68CB012D9182D408CED7B884F441D4D1E2D869FFDnambxv01acorp_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jul 2012 19:12:37 -0000 --_000_C68CB012D9182D408CED7B884F441D4D1E2D869FFDnambxv01acorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is now a "First Public Working Draft" of the W3C TAG document on "Bes= t Practices for Fragment Identifiers and Media Type Definitions". Although = late in the process (and still a 'work in progress', until it reaches W3C '= recommendation' status), perhaps it might be helpful, if only as an informa= tional reference for possible future guidelines. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The [W3C] Technical Architecture Group (http://www.w3.org/2001/tag/ ) has = published the First Public Working Draft of Best Practices for Fragment Ide= ntifiers and Media Type Definitions (http://www.w3.org/TR/2012/WD-fragid-be= st-practices-20120726/). Fragment identifiers within URIs are specified as = being interpreted based on the media type of a representation. Media type d= efinitions therefore have to provide details about how fragment identifiers= are interpreted for that media type. This document recommends best practic= es for the authors of media type definitions, for the authors of structured= syntax suffix definitions (such as +xml), for the authors of specification= s that define syntax for fragment identifiers, and for authors that publish= documents that are intended to be used with fragment identifiers or who re= fer to URIs using fragment identifiers. --_000_C68CB012D9182D408CED7B884F441D4D1E2D869FFDnambxv01acorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There is = now a “First Public Working Draft” of the W3C TAG document on &= #8220;Best Practices for Fragment Identifiers and Media Type Definitions= 221;. Although late in the process (and still a ‘work in progressR= 17;, until it reaches W3C ‘recommendation’ status), perhaps it = might be helpful, if only as an informational reference for possible future= guidelines.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

 

  

The [W3C] Technical Architecture Group (http://www.w3.org/2001/tag/  ) has p= ublished the First Public Working Draft of Best Practices for Fragment Iden= tifiers and Media Type Definitions (http://www.w3.org/TR/2012/WD-fragid-best-= practices-20120726/). Fragment identifiers within URIs are specified as= being interpreted based on the media type of a representation. Media type = definitions therefore have to provide details about how fragment identifier= s are interpreted for that media type. This document recommends best practi= ces for the authors of media type definitions, for the authors of structure= d syntax suffix definitions (such as +xml), for the authors of specificatio= ns that define syntax for fragment identifiers, and for authors that publis= h documents that are intended to be used with fragment identifiers or who r= efer to URIs using fragment identifiers.

 

 

 

= --_000_C68CB012D9182D408CED7B884F441D4D1E2D869FFDnambxv01acorp_-- From paul.hoffman@vpnc.org Fri Jul 27 14:42:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A710011E80A5; Fri, 27 Jul 2012 14:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZGDI-ho3W4T; Fri, 27 Jul 2012 14:42:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0117211E8080; Fri, 27 Jul 2012 14:42:05 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6RKop9K022921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Jul 2012 13:50:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <0B751F7F-3AF8-4AF2-92C0-3D384FBCD4C4@ietf.org> Date: Fri, 27 Jul 2012 14:42:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <11358423-A51A-4353-A883-C5BFA2BF13BC@vpnc.org> References: <500707B1.2090100@KingsMountain.com> <0B751F7F-3AF8-4AF2-92C0-3D384FBCD4C4@ietf.org> To: IETF X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss Subject: Re: [apps-discuss] Memorial for RL "Bob" Morgan X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jul 2012 21:42:06 -0000 On Jul 27, 2012, at 2:28 PM, IETF Chair wrote: > The memorial service for RL "Bob" Morgan will take place on Sunday. = Since many of his friends will be in Vancouver for the IETF meeting, we = have arranged a room at the Hyatt hotel to receive the broadcast from = the the memorial as it takes place in Seattle. If you want to = participate, please come to Regency F from 11:00AM - 2:00PM on Sunday. >=20 > I miss RL "Bob" Morgan. I am sure many others in the IETF community = do as well. For those of you whom are only now finding out about Bob's death, here's = a bit of background: On Jul 26, 2012, at 3:06 PM, Michael R. Gettes wrote: > The tribute web site has been updated with information about the = Memorial for Bob to > be held this Sunday @ 11 AM Pacific Time, 2PM Eastern, 7PM London and = 4AM Monday in Sydney. >=20 > Please visit https://spaces.internet2.edu/display/rlbob/Home for more = information. >=20 > The event will be broadcast video with an accompanying twitter feed. >=20 > Please consider a donation to the education of Bob's children or to a = charity in his name. > Information about donating can be found on his tribute web site. >=20 > Please feel free to forward this email as you see fit to ensure = everyone is aware of the event. From paf@frobbit.se Fri Jul 27 14:48:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C4521F85C6; Fri, 27 Jul 2012 14:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPt0d3mlkX1v; Fri, 27 Jul 2012 14:48:20 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id EC20321F84EA; Fri, 27 Jul 2012 14:48:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id EBD9E14435BDC; Fri, 27 Jul 2012 23:48:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9U8VnBTr8Ym; Fri, 27 Jul 2012 23:48:14 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 7087314435BCD; Fri, 27 Jul 2012 23:48:14 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <11358423-A51A-4353-A883-C5BFA2BF13BC@vpnc.org> Date: Fri, 27 Jul 2012 23:48:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <45AB8A7A-0DF1-4FA0-AB90-1485F90F52AD@frobbit.se> References: <500707B1.2090100@KingsMountain.com> <0B751F7F-3AF8-4AF2-92C0-3D384FBCD4C4@ietf.org> <11358423-A51A-4353-A883-C5BFA2BF13BC@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1485) Cc: IETF , Apps Discuss Subject: Re: [apps-discuss] Memorial for RL "Bob" Morgan X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jul 2012 21:48:20 -0000 27 jul 2012 kl. 23:42 skrev Paul Hoffman : >> I miss RL "Bob" Morgan. I am sure many others in the IETF community = do as well. >=20 > For those of you whom are only now finding out about Bob's death, = here's a bit of background: There is an article in the latest version of IETF Journal where he plays = an important part, including photo of him. = http://www.internetsociety.org/articles/implementing-identity-management-s= olutions I am happy to see the addition to the article online that of course does = not exist in the printed version. Patrik From barryleiba.mailing.lists@gmail.com Fri Jul 27 23:15:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B1721F86B8 for ; Fri, 27 Jul 2012 23:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn90tNGwbaVN for ; Fri, 27 Jul 2012 23:15:39 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB1221F84D8 for ; Fri, 27 Jul 2012 23:15:38 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2730489lbb.31 for ; Fri, 27 Jul 2012 23:15:37 -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 :x-google-sender-auth:message-id:subject:from:to:content-type; bh=qYM6xOv7A/kQCiJLLU0QNWbiWu+lJRczlo/hGGdgQ+0=; b=AmYRwVje7Azj7ik0c5WmzpTBpGfWysl7govQP4neRxC4XCZpSKiySL86xldlIrZq9x Bfpxoz0FPtprGldtK80qT7WSCtTitY1UcgLqOgpQIzNikl9QPqB8z8+1PafYd8c8EaKY kW0cOBHKBOEYznb5aJoUQAlcyFKOChAG+NvO+qtYnIn8El+eGsN4rf/n6lmpVWc9mlIZ xMV37IiOrYmSg04g7V5A13Mb3K0UpfM6CBryJxR6qQsGiDlmiMiLYDL8liTMQ7pLS3Ay JZxDnUiDJ0UfKOhzG1SFTV3AJV8q68hO9zvsMFFFIRsprWLLj7Q2XUNIj4/heXc9k2DG fJUQ== MIME-Version: 1.0 Received: by 10.112.83.169 with SMTP id r9mr2353392lby.66.1343456137398; Fri, 27 Jul 2012 23:15:37 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Fri, 27 Jul 2012 23:15:37 -0700 (PDT) In-Reply-To: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> Date: Sat, 28 Jul 2012 02:15:37 -0400 X-Google-Sender-Auth: RadxcFa_jXe7Xw9xbXFX6z4veFQ Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jul 2012 06:15:41 -0000 The last call for this document is over, but we still need comments on one thing. I put the following in the last call announcement: ==================================== A specific point for Last Call discussion, please: During AD Evaluation, the registration policy for the new "HTTP Forwarded parameters" registry (see Section 9) was changed to "Specification Required" from "RFC Required". This needs further review during Last Call, for two reasons: 1. While RFC Required forces new registrations through the IETF RFC process, and might discourage registrations from individuals or organizations that are unfamiliar with or averse to that process, Specification Required necessitates the appointment of a Designated Expert to review the requests and associated specifications. Each of these policies comes with baggage, and we have to make sure we're weighing it down with the *right* baggage. 2. If we stay with Specification Required we should include a short paragraph with rough guidelines for the Designated Expert: what to consider when approving registration requests. If we want the DE to approve most requests, just checking the associated specifications for sanity, we need to say that. If we want the DE to put some judgment into deciding whether the requested parameters make sense and fit into the usage model, or whatever, we should say something about that. Comments and proposed text for this are encouraged. ==================================== We had last call comments about other things, but nothing on this. We shouldn't just be picking a registration policy arbitrarily, without discussion in the working group of what the *right* policy is. Let's have a bit of discussion on this point before the document moves ahead. I'm leaving it in "Waiting for AD Go-Ahead" state for now. Barry From sm@elandsys.com Sat Jul 28 09:24:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3F721F8649 for ; Sat, 28 Jul 2012 09:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j33Es91eZI5A for ; Sat, 28 Jul 2012 09:24:38 -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 DF0BD21F84B3 for ; Sat, 28 Jul 2012 09:24:38 -0700 (PDT) Received: from sm-THINK.elandsys.com ([12.217.29.66]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6SGOOw5008298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 28 Jul 2012 09:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1343492670; bh=iyE7RnFCZf3g+TsC5hen0TXDSvPpShtDQea8OphmWZI=; h=Date:To:From:Subject:Cc; b=UJO5SwAasOD9/zELlsbMdc5zrLO20yZanynWyyRP5CDVQY3LXA+5SngcFvpXMmEU9 cfulUJNZHVIrO3Lb0Ol7mK7HLiUzYV+6caXXiJ3gIuUZgNrAbqthQzCQn3XbkYiryK /83T8lyxM48ysQ+XPOuX/eOv2YvYRTYsPqQ5njRw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1343492670; i=@elandsys.com; bh=iyE7RnFCZf3g+TsC5hen0TXDSvPpShtDQea8OphmWZI=; h=Date:To:From:Subject:Cc; b=PtM8kCRJe/2M/CrjjZQtDqTt9nNuY8ogK5TP4X8JnTmUYhQWut/AWQrbmdPW9pb3d SOgKWUU6AZ63EJ0oV3OBwrlAD5Ik5+w9/+37YCAQJDOYBQ7YLak3jdL65FBrltmmU3 milvYtmu/XrdMtjW01Gs/isrqs3+iPJ4AyfL/AB8= Message-Id: <6.2.5.6.2.20120728091421.047cbaa8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 28 Jul 2012 09:24:03 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] Apps Area Directorate report for June 2012 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jul 2012 16:24:41 -0000 The Applications Area Directorate provides=20 semi-formal reviews of Internet-Drafts as a way=20 to improve the quality of IETF=20 specifications. The directorate consists of the=20 Working Group Chairs of the Applications Area and=20 recognized experts in the Applications Area. The following reviews were performed in June 2012: Reviewer I-D Joseph Yee draft-melnikov-smtp-priority-tunneling-02 Carsten Bormann draft-ietf-6man-rfc3484bis-05 Yoshiro Yoneya draft-ietf-v6ops-ra-guard-implementation-04 Jiankang Yao draft-ietf-v6ops-6204bis-09 Martin D=FCrst draft-farrell-decade-ni-07 Tobias Gondrom draft-ietf-krb-wg-kdc-model-12 S. Moonesamy draft-vegoda-cotton-rfc5735bis-02 Alexey Melnikov draft-ietf-nea-pt-tls-04 Joseph Yee draft-ietf-6man-lineid Eliot Lear draft-ietf-intarea-ipv4-id-update-05 Claudio Allocchio draft-ietf-codec-opus Jiankang Yao draft-ietf-6lowpan-btle-07 Pending reviews are listed at= http://trac.tools.ietf.org/area/app/trac/report/1 Regards, S. Moonesamy On behalf of the Applications Area Directorate http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From andreas@sbin.se Sat Jul 28 16:50:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F68321F8629 for ; Sat, 28 Jul 2012 16:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyRVUnQTMxi1 for ; Sat, 28 Jul 2012 16:50:38 -0700 (PDT) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by ietfa.amsl.com (Postfix) with ESMTP id 827E221F8604 for ; Sat, 28 Jul 2012 16:50:37 -0700 (PDT) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 8034040004 for ; Sun, 29 Jul 2012 01:50:35 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 74DF140006; Sun, 29 Jul 2012 01:50:35 +0200 (CEST) Received: from [10.70.219.132] (unknown [82.113.121.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id A9C3340004; Sun, 29 Jul 2012 01:50:30 +0200 (CEST) Message-ID: <50147AF3.7020302@sbin.se> Date: Sun, 29 Jul 2012 01:51:15 +0200 From: Andreas Petersson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Barry Leiba References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jul 2012 23:50:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/28/12 8:15 AM, Barry Leiba wrote: > The last call for this document is over, but we still need > comments on one thing. > > > [...] > > We had last call comments about other things, but nothing on this. > We shouldn't just be picking a registration policy arbitrarily, > without discussion in the working group of what the *right* policy > is. Let's have a bit of discussion on this point before the > document moves ahead. I'm leaving it in "Waiting for AD Go-Ahead" > state for now. > Just a reminder, I did send this during the LC: http://www.ietf.org/mail-archive/web/ietf/current/msg73929.html Cheers, Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQFHrxAAoJEEaYRbQUWNlet0AQAM/qmWFAYT4qgDGxFkCcK2Mu /ri6X8ncwW1UwfLiD8NoUtTTJZYLf8k9PoiprQLOR0YEnkyGMXp1i+fMyifHEY4Y NSAxS7Wl/vu9UPiPbjPnoL/T76Cf+aTBckJm2kpSxOggxcUBrUt8As9smYRl0Uv+ jJj9hWvaeNJAvkdPztpBL5iiiZQgjopH8SU5iJpoEhMNz8Ii5RtzmWW7rUWtdmWk GpwRmdAvPCmfuFHfPhVxaISWOWy7mvvpiP7XmUENo8MeLtryYmxsxQjZXa5psQ49 ClzYiUQnWPkg97NEhzDxceDb5kMxqEQfFHRvVANu+X0r8hA0BUqZy2EoyC+bkgAO ZrDLO8f3c5hrevuy4oOQhOPZ1zbisej2K+wmfHeuTB8Njy3K5A0rEJvXrBOAlGe6 W60V9r5+3FICX0q4D8QCdHQJYlEO8i3iddhT2jT7iyekWRZyDiGX4pS7iDWPX8/U prrbvjVoR/42SGc42bPOhwFi57ozmuM3tCMrelI0cFQWqI6kStM4Qus6m4W37Dfz sUuBwVpZaMtusH3LDF7qcZXIsRNfXi/iXRRoAAKzKHgkuYt02j81vpvMjtu59Csp kvl8HkFr8iHTk107BgpQVoE1knGD6eS3XzXHU3y/7WI8QC4HsuBdJUjXstmfCaGD uhjIIOUI/3c81b0/29du =/2ar -----END PGP SIGNATURE----- From barryleiba@gmail.com Sat Jul 28 16:54:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96EA21F86B5 for ; Sat, 28 Jul 2012 16:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjTFps0AUAJP for ; Sat, 28 Jul 2012 16:54:16 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7426021F8629 for ; Sat, 28 Jul 2012 16:54:16 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7437389pbc.31 for ; Sat, 28 Jul 2012 16:54:16 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bWYK4NVel/I1ajXr45aumYr6081dRSanL2Ah2zKgtbc=; b=CtA5+FU/kQOfTqraxFhlXFiawZrMCtf6/PIl+g7Jbf/sXBxcdLdT3lKC7Co1ZfLB1Z us8O3DKuEUMCD4lcrHEMJKTXAWZTeap9l/vFKt2BnZpanR68TfzAc0qnwwCRvY4kTDaQ QtyW7j89gOF1UQA39rftWkWhXMZ0wPgyDRmwS8x+dHlg1StBOYyAaVi8KF2zilAQQKVp bZcs4RrkSdPjbIh3lwgvVL+2kx9iqdWlMu6XLbFGRZ0P4Z0FSRti4yyJpxBJHPz3oSfe eL5DTM8bUuWBgwCRH14+EcixTl+cGR8tVVQK1qcc9KFYEpnuwPlbq5ToRw28Y4Yh7dHf +asA== MIME-Version: 1.0 Received: by 10.68.231.168 with SMTP id th8mr25069471pbc.14.1343519656314; Sat, 28 Jul 2012 16:54:16 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.68.64.103 with HTTP; Sat, 28 Jul 2012 16:54:16 -0700 (PDT) In-Reply-To: <50147AF3.7020302@sbin.se> References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <50147AF3.7020302@sbin.se> Date: Sat, 28 Jul 2012 19:54:16 -0400 X-Google-Sender-Auth: 2rKlXL7DaJ2mJcwInoO9q-k4JOI Message-ID: From: Barry Leiba To: Andreas Petersson Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jul 2012 23:54:17 -0000 >> We had last call comments about other things, but nothing on this. >> We shouldn't just be picking a registration policy arbitrarily, >> without discussion in the working group of what the *right* policy >> is. Let's have a bit of discussion on this point before the >> document moves ahead. I'm leaving it in "Waiting for AD Go-Ahead" >> state for now. > > Just a reminder, I did send this during the LC: > http://www.ietf.org/mail-archive/web/ietf/current/msg73929.html Indeed you did, Andreas; sorry: I meant that no one else commented pro or con about it. I'd like to get some sense that someone other than us is happy with this (or is not). Barry From alexey.melnikov@isode.com Sun Jul 29 07:33:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D332021F8606 for ; Sun, 29 Jul 2012 07:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL9zPXXkj2l2 for ; Sun, 29 Jul 2012 07:33:13 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC7221F85B8 for ; Sun, 29 Jul 2012 07:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1343572459; d=isode.com; s=selector; i=@isode.com; bh=kKtYg6UXppTUqEAMjtJLtnUs5y66nurV3Py8DMH6/fk=; 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=ruNA3UjXp4Y2is+jdcUZMapg+f6uijoa0YnJTumNANHcX0n9vHqyro1vMWf/9S5R+/uTVn oTUIBSE8Ah1iHa6m3Tzol7Ud5h5Kg5rA/QeUbR/TW9TrbM77JvtN49shbRdmg0WvLkHm30 N3e8Nf7Pxmlhu/7k5YVFdOkcMb/U0NU=; Received: from [10.71.15.137] (209-207-95-33.ip.van.radiant.net [209.207.95.33]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 29 Jul 2012 15:34:18 +0100 References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> In-Reply-To: Message-Id: <9B30F7F1-A25D-4B18-8DD5-DD4FF7A84709@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Sun, 29 Jul 2012 07:33:10 -0700 To: Barry Leiba MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (Forwarded HTTP Extension) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2012 14:33:14 -0000 On 27 Jul 2012, at 23:15, Barry Leiba wrote: > The last call for this document is over, but we still need comments on > one thing. >=20 > I put the following in the last call announcement: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > A specific point for Last Call discussion, please: > During AD Evaluation, the registration policy for the new "HTTP > Forwarded parameters" registry (see Section 9) was changed to > "Specification Required" from "RFC Required". This needs further > review during Last Call, for two reasons: >=20 > 1. While RFC Required forces new registrations through the IETF RFC > process, and might discourage registrations from individuals or > organizations that are unfamiliar with or averse to that process, > Specification Required necessitates the appointment of a Designated > Expert to review the requests and associated specifications. Each of > these policies comes with baggage, and we have to make sure we're > weighing it down with the *right* baggage. >=20 > 2. If we stay with Specification Required we should include a short > paragraph with rough guidelines for the Designated Expert: what to > consider when approving registration requests. If we want the DE to > approve most requests, just checking the associated specifications for > sanity, we need to say that. If we want the DE to put some judgment > into deciding whether the requested parameters make sense and fit into > the usage model, or whatever, we should say something about that. > Comments and proposed text for this are encouraged. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > We had last call comments about other things, but nothing on this. We > shouldn't just be picking a registration policy arbitrarily, without > discussion in the working group of what the *right* policy is. Let's > have a bit of discussion on this point before the document moves > ahead. I'm leaving it in "Waiting for AD Go-Ahead" state for now. I think Specification Required would be better here, so I support this chang= e. From superuser@gmail.com Sun Jul 29 20:24:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C6921F8585 for ; Sun, 29 Jul 2012 20:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.671 X-Spam-Level: X-Spam-Status: No, score=-3.671 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRpUgo+RBX6D for ; Sun, 29 Jul 2012 20:24:30 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C91A21F8460 for ; Sun, 29 Jul 2012 20:24:29 -0700 (PDT) Received: by lagv3 with SMTP id v3so3259618lag.31 for ; Sun, 29 Jul 2012 20:24:29 -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=nYuf/uXTI3ihVf9CUURIHPqEDfM00Mfb71MQPu8/7hI=; b=sj2C0WrSXaofBdJVURfkBzVW7tx7QG15DqEDuI6rDHIKTnQ5LZGIOqO6N800qS4pOZ 3P2DykMATioC2Wx7S3k/dM2zUT29N6c/8oyvAhPr6PvHgUU+H7HWkhMILNFCIH8j7upl uX2gXf4QiQLGzEsuO8WcJbjUesDTF41AUl9BO2Y7kyYVl9eELBibSKlp+BIxkbhxuKAB plUagbg8rzhU2I2xLz96HLApz1dcFuM70ixfxlKpQj9LqUUX4bkJDtuk9jHmjtIsE7o+ nw9drQnVYYSigVGteBikvcv3g5NSgIY7I/Ga7+hq1MgjT4jrWBdUI3sroo9hNQtCSN7U sCGA== MIME-Version: 1.0 Received: by 10.112.39.135 with SMTP id p7mr4634788lbk.78.1343618669031; Sun, 29 Jul 2012 20:24:29 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sun, 29 Jul 2012 20:24:29 -0700 (PDT) Date: Sun, 29 Jul 2012 20:24:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=485b390f7a767b311704c603999f Subject: [apps-discuss] Slides for APPSAWG meeting X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2012 03:24:30 -0000 --485b390f7a767b311704c603999f Content-Type: text/plain; charset=ISO-8859-1 Greetings, So far we have only received slides from Mark Nottingham (JSON pointer/patch) and Andrew Sullivan (Administrative Boundaries in the DNS). We assume therefore that everyone else is planning to wing it from the microphones. If you do have slides to present, please send them to appsawg-chairs@tools.ietf.org ASAP. We will not be able to accept USB drives or other media at the desk. Thanks, -MSK, APPSAWG co-chair --485b390f7a767b311704c603999f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings,

So far we have only received slides from Mark Nottingham = (JSON pointer/patch) and Andrew Sullivan (Administrative Boundaries in the = DNS).=A0 We assume therefore that everyone else is planning to wing it from= the microphones.

If you do have slides to present, please send them to appsawg-chairs@tools.ietf.org ASAP.=A0 = We will not be able to accept USB drives or other media at the desk.
Thanks,

-MSK, APPSAWG co-chair

--485b390f7a767b311704c603999f-- From dcrocker@bbiw.net Sun Jul 29 21:57:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E220F11E810F; Sun, 29 Jul 2012 21:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MK8rOkDIZw33; Sun, 29 Jul 2012 21:57:32 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3781411E808D; Sun, 29 Jul 2012 21:57:31 -0700 (PDT) Received: from [192.168.0.101] (S0106002401e57197.vc.shawcable.net [24.84.118.170]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q6U4vRAE005550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 Jul 2012 21:57:28 -0700 Message-ID: <50161436.8080900@bbiw.net> Date: Sun, 29 Jul 2012 21:57:26 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: apps-discuss@ietf.org, draft-ietf-dime-rfc4005bis.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 29 Jul 2012 21:57:31 -0700 (PDT) Cc: iesg Subject: [apps-discuss] Review of: draft-ietf-dime-rfc4005bis-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2012 04:57:35 -0000 G'day. I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dime-rfc4005bis-09 Title: Diameter Network Access Server Application Reviewer: Dave Crocker Review Date: 18 June 2012 Summary: This draft continues problems from the original, at a minimum lacking definitions of terms, citation or definition of notational conventions, apparent normative redundancy with base documents. Major Issues: Active vs. passive voice -- the documents use of passive voice greatly expands the verbiage but also sometimes make it difficult to discern which participating entity is the identified actor. Apparently redundant normative text -- this document appears to contain restatements of normative text from the base Diameter document. This is extremely poor practice, since it invites divergence. Possibly inconsistent use of terminology -- Some of the terms used appear to have equivalent meaning but are not defines; to the extent that they are meant to have different meaning I could not tell what that was. Most significantly, it appears that this document cannot readily be read without very deep familiarity with other Diameter documentation, making this nearly an appendix to those. At the least, the dependencies should be made explicit and detailed. The Introduction's opening paragraph might have been thought to take care of this requirement, but it doesn't, at least not for me. For one thing, it isn't phrase so as to accomplish this. For another, the references are to entire documents, implying -- but not saying -- don't read this until you are deeply familiar with all of these other documents. The broader comments appear to apply to the original documents as well as this (and related) current ones. It's likely that making changes accordingly would be a major effort. Whether that's worth the effort isn't something I can judge. I think the revisions would make for tighter, clearer specifications that are probably easier to maintain, but I can't offer an opinion about the benefit this would have in terms of existing implementers or better market adoption, since I'm not familiar with Diameter's degree of market penetration nor the skills of those who have (or might) adopt it. Minor Issues: -- Nits: -- Detailed comments: > Network Working Group G. Zorn, Ed. > Internet-Draft Network Zen > Obsoletes: 4005 (if approved) May 18, 2012 > Intended status: Standards Track > Expires: November 19, 2012 > > > Diameter Network Access Server Application > draft-ietf-dime-rfc4005bis-09 > > Abstract > > This document describes the Diameter protocol application used for When summarizing the nature or purpose of a document, it is best for the abstract and Introduction to use different words than are in the title. Simply repeating the language of the title does not explain the title. The simple rule should be to assume that the new reader does not automatically understand the meaning of the title. In this case, I also have no idea what "the Diameter protocol application" means here. "protocol application" is not typical phrasing. Does it really mean that details are being specified for software implementation of Diameter at the server? Typically, the IETF does not specify details about software implementation, nevermind put such a specification on the standards track. (And, yes, I see that this is a -bis document; but that does not change the underlying concern.) What is the motivation for this version of the document? What problems or improvements are being provided? That is, why was it worth the effort to revise the previous document? These are not explained in the bis document. > Authentication, Authorization, and Accounting (AAA) services in the > Network Access Server (NAS) environment; it obsoletes RFC 4005. When > combined with the Diameter Base protocol, Transport Profile, and > Extensible Authentication Protocol specifications, this application > specification satisfies typical network access services requirements. ... > 1. Introduction > > This document describes the Diameter protocol application used for > AAA in the Network Access Server (NAS) environment. When combined > with the Diameter Base protocol [I-D.ietf-dime-rfc3588bis], Transport > Profile [RFC3539], and EAP [RFC4072] specifications, this > specification satisfies the NAS-related requirements defined in > Aboba, et al. [RFC2989] and Beadles & Mitton [RFC3169]. This assertion raises a dilemma: The cited documents are extensive and the topic(s?) complex. There is no way to know what details are being referred to, to evaluate the assertion. Worse, fixing this deficiency is certain to be a large effort. > First, this document describes the operation of a Diameter NAS > application. What is "a Diameter NAS application"? It does not seem to be explained in this document, nor is there a citation to its definition. > Then it defines the Diameter message Command-Codes. > The following sections list the AVPs used in these messages, grouped AVPs? Define acronyms when they are introduced. Explain their meaning. If the acronym is not destined for regular use within the document, consider replacing the acronym with the full term. If this document is a case of "this document only makes sense when you are intimately familiar with these other documents", then specify those other documents. As the document stands now, it does not formally citte foundational documents, although it does seem to rely on some. In general, this document's frequent use of "AVP" appears to be an oddly syntactic focus. Typical specifications refer to attributes, without such frequent, explicit reference to the form of their having values. On its own, this point could seem like quibbling, but it's part of the reaction I had when reading the document, that is seemed less accessible than one would wish for a new reader. > by common usage. These are session identification, authentication, > authorization, tunneling, and accounting. The authorization AVPs are > further broken down by service type. This document appears to require deep knowledge of The Diameter Base Protocol. In reality, I don't think this document can be meaningfully read without that knowledge. So this document should say that. (The language in the first paragraph of the Intro doesn't actually say it.) > 1.1. Changes from RFC 4005 > > This document obsoletes RFC 4005 and is not backward compatible with > that document. An overview of some the major changes are given > below. "not backward compatible" automatically raises basic questions about transition from old to new and support during an extended transition. The word 'transition' does not appear in this document. > o All of the material regarding RADIUS/Diameter protocol > interactions has been removed. > > o The Command Code Format (CCF) [I-D.ietf-dime-rfc3588bis] for the presumably the references to I-Ds need to be changed for RFC publication? > Accounting-Request and Accounting-Answer messages has been changed > to explicitly require the inclusion of the Acct-Application-Id AVP > and exclude the Vendor-Specific-Application-Id AVP. Normally, > this type of change would also require the allocation of a new > command code and consequently, a new application-id (See Section > 1.3.3 of [I-D.ietf-dime-rfc3588bis]). However, the presence of an > instance of the Acct-Application-Id AVP was required in RFC 4005, > as well: > > The ACR message [BASE] is sent by the NAS to report its session > information to a target server downstream. > > Either of Acct-Application-Id or Vendor-Specific-Application-Id > AVPs MUST be present. If the Vendor-Specific-Application-Id > grouped AVP is present, it must have an Acct-Application-Id > inside. > > Thus, though the syntax of the commands has changed, the semantics > have not (with the caveat that the Acct-Application-Id AVP can no > longer be contained in the Vendor-Specific-Application-Id AVP). Sounds oddly disruptive. /Why/ has the syntax been changed? What problem is this solving? > > > > > Zorn Expires November 19, 2012 [Page 5] > > Internet-Draft Diameter NASREQ May 2012 > > > o The lists of RADIUS attribute values have been deleted in favor of > references to the appropriate IANA registries. > > o The accounting model to be used is now specified. > > There are many other many miscellaneous fixes that have been > introduced in this document that may not be considered significant > but they are useful nonetheless. Examples are fixes to example IP Useful, but not significant. Interesting concept. Perhaps what is meant is not major or not substantive or not normative? > addresses, addition of clarifying references, etc. All of the errata > previously filed against RFC 4005 have been fixed. A comprehensive > list of changes is not shown here for practical reasons. > > 1.2. Terminology > > Section 1.2 of the base Diameter specification > [I-D.ietf-dime-rfc3588bis] defines most of the terminology used in > this document. Additionally, the following terms and acronyms are > used in this application: > > NAS (Network Access Server) > A device that provides an access service for a user to a network. > The service may be a network connection or a value-added service > such as terminal emulation [RFC2881]. Do not define a term by re-using the words in the term. In this case, even a word as obvious as 'access' could mean a variety of things. Everything is "a network connection". Perhaps the distinction here is between host-level attachment service, versus user-level application service? I can't tell. ... > VPN (Virtual Private Network) > In this document, this term is used to describe access services > that use tunneling methods. Since VPN is a well-entrenched, standard term of art, it seems odd -- and likely counterproductive -- to imply that use in this document will be non-standard, especially since the definition provided seems on a par with usual definitions, such as wikipedia's. > 1.4. Advertising Application Support > > Diameter nodes conforming to this specification MUST advertise > support by including the value of one (1) in the Auth-Application-Id > of the Capabilities-Exchange-Request (CER) message. "this specification' -> this version of specification [???] There is no other reference to the CER message in this document. As such, it's not clear what context for the message is meant. Offhand, it appears that advertising support of the spec is made during a session that implements the spec? This seems at least odd. Since this version of the spec uses a different syntax, it's not likely that any implementation will be speaking a different version of the protocol. > 1.5. Application Identification > > When used in this application, the Auth-Application-Id AVP MUST be > set to the value one (1) in the following messages > > o AA-Request (Section 3.1) > > > > > > Zorn Expires November 19, 2012 [Page 7] > > Internet-Draft Diameter NASREQ May 2012 > > > o Re-Auth-Request(Section 3.3) > > o Session-Termination-Request (Section 3.5) > > o Abort-Session-Request (Section 3.7) > > 1.6. Accounting Model > > It is RECOMMENDED that the coupled accounting model (Section 9.3 of > [I-D.ietf-dime-rfc3588bis]) be used with this application; therefore, > the value of the Acct-Application-Id AVP in the Accounting-Request > (Section 3.10) and Accounting-Answer (Section 3.9) messages SHOULD be > set to one (1). All of the values in those two sections (except the "271") are symbolic. As such, setting a value to "1" has no obvious meaning. I assume that the issue would be fixed by using symbolic values here? > 2. NAS Calls, Ports, and Sessions > > The arrival of a new call or service connection at a port of a "a port"? is this a reference to a transport-level port? That's the only use of the word in the base diameter document. What is a 'call' and what does it mean for it to "arrive", in this context? How is it different from a service connection? The word 'call' in the base document does not have a usage that seems relevant here. Is this document really trying to specify how a host dispatches a server? If so, that means it's discussing implementation details rather than protocol details. > Network Access Server (NAS) starts a Diameter NAS message exchange. I would guess that the Diameter-level initiation of a NAS message exchange is caused by a Diameter-level message, not the transport connection it triggers. If so, what message would that be? > Information about the call, the identity of the user, and the user's The base Diameter document does not specify the concept of a 'call'. > authentication information are packaged into a Diameter AA-Request > (AAR) message and sent to a server. > > The server processes the information and responds with a Diameter AA- "processes the information"? What does this mean, in protocol interoperability terms? I'd expect some statement about the semantics of the processes, relative to the overall exchange. > Answer (AAA) message that contains authorization information for the > NAS, or a failure code (Result-Code AVP). A value of > DIAMETER_MULTI_ROUND_AUTH indicates an additional authentication > exchange, and several AAR and AAA messages may be exchanged until the > transaction completes. "may"? This paragraph appears to be largely redundant with the base Diameter document. Redundancy like this invites divergence over time and ambiguity about which text is controlling. > Depending on the value of the Auth-Request-Type AVP, the Diameter The reader is supposed to guess what values produce what results or actions? I don't see the choices/mappings/whatever documented. > 3.1. AA-Request (AAR) Command > > The AA-Request (AAR), which is indicated by setting the Command-Code > field to 265 and the 'R' bit in the Command Flags field, is used to > request authentication and/or authorization for a given NAS user. The text provides detail about the internals of the AAR, but doesn't say who sends it. By the way, does the AA- mean Authentication/Authorization? That's implied but not stated. Since the labels are symbolic, mnemonic utility is improved by explaining the basis of the string. > The type of request is identified through the Auth-Request-Type AVP > [I-D.ietf-dime-rfc3588bis] The recommended value for most situations > is AUTHORIZE_AUTHENTICATE. > > If Authentication is requested, the User-Name attribute SHOULD be > present, as well as any additional authentication AVPs that would > carry the password information. A request for authorization SHOULD > only include the information from which the authorization will be > performed, such as the User-Name, Called-Station-Id, or Calling- This implies that some other sorts of information SHOULD NOT be included, but gives no indication what it is (or why). > Station-Id AVPs. All requests SHOULD contain AVPs uniquely > identifying the source of the call, such as Origin-Host and NAS-Port. This is a classic and frequent bit of guidance, but lacks any technical substance. The "such as" gives a concrete example, but otherwise the implementer has no idea what will satisfy the SHOULD. > Certain networks MAY use different AVPs for authorization purposes. > A request for authorization will include some AVPs defined in > Section 4.4. Which ones? How is the implementer to know? > It is possible for a single session to be authorized first and then > for an authentication request to follow. What is the implementer to do with this statement? > This AA-Request message MAY be the result of a multi-round > authentication exchange, which occurs when the AA-Answer message is > received with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. > A subsequent AAR message SHOULD be sent, with the User-Password AVP > that includes the user's response to the prompt, and MUST include any > State AVPs that were present in the AAA message. > > Message Format What meta-syntax is being used for specifying formats? It isn't ABNF and it isn't cited. > 3.2. AA-Answer (AAA) Command > > The AA-Answer (AAA) message is indicated by setting the Command-Code > field to 265 and clearing the 'R' bit in the Command Flags field. It Is it really helpful to have each of these say how to set the command, given that it's already listed in a table? Having prose that merely repeats details, rather than explaining them, expands the size of the document but, I believe, actually makes the substance less accessible. Worse, isn't that already done in the base Diameter document? And by the way, the base document defines a command as a request/answer pair. As such neither one, on its own, is a command. That is, this one appears to be the a "command answer", rather than a command. (And yes, that's painfully redundant, given the symbolic name.) I notice that the text often uses the word 'message' to refer to one of these transaction components of a command. That looks like a simple and reasonable choice. Hence, AA-Answer (AAA) Message? This assumes that "command" means a request/response pair. > is sent in response to the AA-Request (AAR) message. If > authorization was requested, a successful response will include the > authorization AVPs appropriate for the service being provided, as > defined in Section 4.4. The "if" seems odd, since the preceding sentence declares the necessary (and obvious) predicate. > > For authentication exchanges requiring more than a single round trip, > the server MUST set the Result-Code AVP to DIAMETER_MULTI_ROUND_AUTH. > An AAA message with this result code MAY include one Reply-Message or > > > > Zorn Expires November 19, 2012 [Page 12] > > Internet-Draft Diameter NASREQ May 2012 > > > more and MAY include zero or one State AVPs. > > If the Reply-Message AVP was present, the network access server > SHOULD send the text to the user's client to display to the user, "was present" suffers the problem of passive sentence form in a protocol specification -- and using past tense adds to the challenge: it isn't clear who does what. Offhand, I would think that it is, in fact, the server that generates replies (and presumably, therefore, chooses to include Reply-Message text.) However the above sentence implies otherwise. Since Diameter is a protocol specification, what does it mean for a server to send text to the user's client? What is the protocol mechanism for doing this? > instructing the client to prompt the user for a response. For > example, this capability can be achieved in PPP via PAP. If the > access client is unable to prompt the user for a new response, it > MUST treat the AA-Answer (AAA) with the Reply-Message AVP as an error > and deny access. The 'it' means the client? The client must deny access? > 3.3. Re-Auth-Request (RAR) Command > > A Diameter server may initiate a re-authentication and/or re- may? > authorization service for a particular session by issuing a Re-Auth- > Request (RAR) message [I-D.ietf-dime-rfc3588bis]. Re-authorization "service"? I don't understand what the word means here and didn't find any obvious guidance in the base Diameter document. The additional uses of the word in the next paragraph added to my confusion. > For example, for pre-paid services, the Diameter server that > originally authorized a session may need some confirmation that the > user is still using the services. I have no idea what this is about, what it's basis is or what it means. It seems to presume that the reader knows exactly what is being referred to, as 'pre-paid services' and why it would need some (additional) confirmation. > If a NAS receives an RAR message with Session-Id equal to a currently > active session and a Re-Auth-Type that includes authentication, it > MUST initiate a re-authentication toward the user, if the service > supports this particular feature. and if it doesn't, then what? > 3.4. Re-Auth-Answer (RAA) Command > > The Re-Auth-Answer (RAA) message [I-D.ietf-dime-rfc3588bis] is sent > in response to the RAR. The Result-Code AVP MUST be present and > indicates the disposition of the request. > > A successful RAA transaction MUST be followed by an AAR message. transaction -> command { ? } > 3.5. Session-Termination-Request (STR) Command > > The Session-Termination-Request (STR) message > [I-D.ietf-dime-rfc3588bis] is sent by the NAS to inform the Diameter > Server that an authenticated and/or authorized session is being > terminated. "is being". Again, this is passive voice for a 'command'. Consequently it is not clear whether the requestor has done the termination or is requesting that the server terminate. I assume the latter, but the text leaves this open. > 3.6. Session-Termination-Answer (STA) Command > > The Session-Termination-Answer (STA) message > [I-D.ietf-dime-rfc3588bis] is sent by the Diameter Server to > acknowledge the notification that the session has been terminated. > The Result-Code AVP MUST be present and MAY contain an indication > that an error occurred while the STR was being serviced. > > Upon sending or receiving the STA, the Diameter Server MUST release > all resources for the session indicated by the Session-Id AVP. Any > intermediate server in the Proxy-Chain MAY also release any > resources, if necessary. The server can /receive/ an STA? That appears to be at odds with the first paragraph. > 3.7. Abort-Session-Request (ASR) Command > > The Abort-Session-Request (ASR) message [I-D.ietf-dime-rfc3588bis] > may be sent by any server to the NAS providing session service, to > request that the session identified by the Session-Id be stopped. "by any server" suggests a multi-server model, with a NAS talking to more than one at a time (for a given session...?) As I understand it, NAS/Server sessions are bilateral, not multi-lateral. In addition, the "providing session service" implies that a NAS could be relevant to this text when it is /not/ providing session service. This seems unlikely. So the language here probably should be: MAY be sent by the server to the NAS to request that... > 3.8. Abort-Session-Answer (ASA) Command > > The ASA message [I-D.ietf-dime-rfc3588bis] is sent in response to the > ASR. The Result-Code AVP MUST be present and indicates the > disposition of the request. Who sends to whom? > 3.9. Accounting-Request (ACR) Command > > The ACR message [I-D.ietf-dime-rfc3588bis] is sent by the NAS to > report its session information to a target server downstream. 'downstream'? Is it relayed through intermediaries? What does 'downstream' mean here, beyond simply having a client/server dialogue? > The Acct-Application-Id AVP MUST be present. > > The AVPs listed in the Base protocol specification > [I-D.ietf-dime-rfc3588bis] MUST be assumed to be present, as What does "assumed to be present" mean? What is the point behind "assuming" and does this just mean supported by client and server software? Required to be used in the protocol exchanges? Something else? > 3.10. Accounting-Answer (ACA) Command > > The ACA message [I-D.ietf-dime-rfc3588bis] is used to acknowledge an is used to acknowledge -> acknowledges > Accounting-Request command. The Accounting-Answer command contains > the same Session-Id as the Request. The same level of security MUST > be applied to both the Accounting-Request and the corresponding Is this security requirement special to this command or is it univeral? Why? > Accounting-Answer message. For example, if the ACR was protected > using end-to-end security techniques then the corresponding ACA > message MUST be protected in the same way; note, however, that the > definition of such techniques is outside the scope of this document. > > Only the target Diameter Server or home Diameter Server SHOULD > respond with the Accounting-Answer command. target vs. home. What distinguishes which is to respond? How are they to know? > 4. Diameter NAS Application AVPs > > The following sections define a new derived AVP data format, a set of "new" will not mean much 10 years from now. RFCs should be written for long-term reading. "derived"? What does this mean? > application-specific AVPs and describe the use of AVPs defined in > other documents by the Diameter NAS Application. > > 4.1. Derived AVP Data Formats > > 4.1.1. QoSFilterRule What is the /purpose/ of this? Presumably it has something to do with filtering, but there's no context for it established. > The QosFilterRule format is derived from the OctetString AVP Base > Format. It uses the ASCII charset. Packets may be marked or metered > based on the following information: > marked vs. metered ? > > > Zorn Expires November 19, 2012 [Page 23] > > Internet-Draft Diameter NASREQ May 2012 > > > o Direction (in or out) > > o Source and destination IP address (possibly masked) > > o Protocol > > o Source and destination port (lists or ranges) > > o DSCP values (no mask or range) DSCP? > Rules for the appropriate direction are evaluated in order; the first "Rules for the appropriate direction"? What does this mean? > matched rule terminates the evaluation. Each packet is evaluated > once. If no rule matches, the packet is treated as best effort. An > access device unable to interpret or apply a QoS rule SHOULD NOT > terminate the session. This appears to be discussing a /set/ of rules, but there's been no discussion of a set. This appears to presume a model that hasn't been introduced. > > QoSFilterRule filters MUST follow the following format: There is more than one filter? Does this mean multiple sets or multiple rules within a single set? > action dir proto from src to dst [options] Where are the /semantics/ of these defined? > where > > action > tag Mark packet with a specific DSCP [RFC2474] > meter Meter traffic > > dir The format is as described under IPFilterRule > [I-D.ietf-dime-rfc3588bis] > > proto The format is as described under IPFilterRule > [I-D.ietf-dime-rfc3588bis] > > src and dst The format is as described under IPFilterRule > [I-D.ietf-dime-rfc3588bis] > > The options are described in Section 4.4.9. I didn't see them there. > > The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the > ipfw.c code may provide a useful base for implementations. "may be provided"??? I thought this was a protocol specification which defines its details or cites them formally. > 4.2. NAS Session AVPs > > Diameter reserves the AVP Codes 0 - 255 for RADIUS Attributes that > are implemented in Diameter. > > 4.2.1. Call and Session Information > > This section describes the AVPs specific to Diameter applications > that are needed to identify the call and session context and status > > > > Zorn Expires November 19, 2012 [Page 24] > > Internet-Draft Diameter NASREQ May 2012 > > > information. On a request, this information allows the server to > qualify the session. "on a request"? > These AVPs are used in addition to the following AVPs from the base > protocol specification [I-D.ietf-dime-rfc3588bis]: > > Session-Id > Auth-Application-Id > Origin-Host > Origin-Realm > Auth-Request-Type > Termination-Cause > > The following table gives the possible flag values for the session > level AVPs. "session-level"? > +----------+ > | AVP Flag | > | rules | > |----+-----+ > |MUST| MUST| > Attribute Name Section Defined | | NOT| > -----------------------------------------|----+-----| > NAS-Port 4.2.2 | M | V | > NAS-Port-Id 4.2.3 | M | V | > NAS-Port-Type 4.2.4 | M | V | > Called-Station-Id 4.2.5 | M | V | > Calling-Station-Id 4.2.6 | M | V | > Connect-Info 4.2.7 | M | V | > Originating-Line-Info 4.2.8 | M | V | > Reply-Message 4.2.9 | M | V | > -----------------------------------------|----+-----| > > 4.2.2. NAS-Port AVP > > The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains the > physical or virtual port number of the NAS which is authenticating > the user. Note that "port" is meant in its sense as a service > connection on the NAS, not as an IP protocol identifier. "service connection on the NAS"? "virtual" port number? This is the only time the term is used, and I don't see it in the base Diameter document and I don't know what it means. > Either the NAS-Port AVP or the NAS-Port-Id AVP (Section 4.2.3) SHOULD > be present in the AA-Request (AAR, Section 3.1) command if the NAS > differentiates among its ports. > > 4.2.3. NAS-Port-Id AVP > > The NAS-Port-Id AVP (AVP Code 87) is of type UTF8String and consists > of ASCII text identifying the port of the NAS authenticating the > > > > Zorn Expires November 19, 2012 [Page 25] > > Internet-Draft Diameter NASREQ May 2012 > > > user. Note that "port" is meant in its sense as a service connection > on the NAS, not as an IP protocol identifier. Although this doesn't distinguish physical from virtual, it does explain the term port. I suspect such explanations should be broken out into an earlier section that provides some framework and terminology. This will avoid having definitions buried deeply and possibly after first use. This can be especially helpful for sections, like this one, that seem likely to be used for reference, and therefore not read sequentially. > > Either the NAS-Port-Id AVP or the NAS-Port AVP (Section 4.2.2) SHOULD > be present in the AA-Request (AAR, Section 3.1) command if the NAS > differentiates among its ports. NAS-Port-Id is intended for use by > NASes that cannot conveniently number their ports. > > 4.2.4. NAS-Port-Type AVP > > The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and "Enumerated"? Where are the types defined? > 4.2.9. Reply-Message AVP > > The Reply-Message AVP (AVP Code 18) is of type UTF8String and > contains text that MAY be displayed to the user. When used in an AA- Since I doubt that this specification is intended to cover user interface design -- and hope that it is not -- I think that the normative, semantic point in specification terms is that the strings MUST be created with the intent of displaying them to humans. That is, these are human-consumable strings, not (necessarily) computer-consumable. > 4.4.1. Service-Type AVP > > The Service-Type AVP (AVP Code 6) is of type Enumerated and contains > the type of service the user has requested or the type of service to > be provided. One such AVP MAY be present in an authentication and/or > authorization request or response. A NAS is not required to > implement all of these service types. It MUST treat unknown or > unsupported Service-Types received in a response as a failure and end > the session with a DIAMETER_INVALID_AVP_VALUE Result-Code. > > When used in a request, the Service-Type AVP SHOULD be considered a > hint to the server that the NAS believes the user would prefer the > kind of service indicated. The server is not required to honor the A hint is a hint. It would be odd and probably wrong for an implementer to be "required to honor the hint". If they are required, it's not a hint. I believe the simpler and more useful phrasing would simply be: When used in a request, the Service-Type AVP is only a hint to the server that the NAS believes... And then delete the sentence after. > hint. Furthermore, if the service specified by the server is > supported, but not compatible with the current mode of access, the > NAS MUST fail to start the session. The NAS MUST also generate the > appropriate error message(s). Doesn't "MUST fail to start" equate to "MUST NOT start" and wouldn't that be the simpler and more typical phrasing? "appropriate"? What are the criteria and how is the implementer to know? > 4.4.10.5.4. Framed-Pool AVP > > The Framed-Pool AVP (AVP Code 88) is of type OctetString and contains > the name of an assigned address pool that SHOULD be used to assign an > address for the user. If a NAS does not support multiple address > pools, the NAS SHOULD ignore this AVP. Address pools are usually > used for IP addresses but can be used for other protocols if the NAS > supports pools for those protocols. Hmmm. If the NAS does not support multiple address pools and doesn't ignore this AVP, what happens and how will it be interoperable? This seems like something that requires an exact, shared model between the two sides, or else it's merely a notational convenience without interoperability substance. That is, either it's a MAY or a MUST? Or there needs to be some explanation of how to deal with the mismatch between the two sides. // d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From masinter@adobe.com Mon Jul 30 09:37:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4ED821F8625 for ; Mon, 30 Jul 2012 09:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.064 X-Spam-Level: X-Spam-Status: No, score=-107.064 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKDfZaLM3DxX for ; Mon, 30 Jul 2012 09:37:11 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 522E221F8622 for ; Mon, 30 Jul 2012 09:36:48 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUBa4HzoxJL8HHDrisjF3yndYAdF0idgc@postini.com; Mon, 30 Jul 2012 09:37:10 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q6UGak8N024279; Mon, 30 Jul 2012 09:36:46 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q6UGafYv025668; Mon, 30 Jul 2012 09:36:45 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Mon, 30 Jul 2012 09:36:44 -0700 From: Larry Masinter To: "apps-discuss@ietf.org" Date: Mon, 30 Jul 2012 09:36:42 -0700 Thread-Topic: "Best Practices for Fragment Identifiers and Media Type Definitions" Thread-Index: Ac1ub0CQYTgx/DVzSeG7oOeBJIEXFQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "www-tag@w3.org" Subject: [apps-discuss] "Best Practices for Fragment Identifiers and Media Type Definitions" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2012 16:37:11 -0000 To be more explicit (and provide additional URLs): http://www.w3.org/TR/fragid-best-practices/ is now (as of last week) a W= 3C "First Public Working Draft" as the first step of the "Recommendation" t= rack at W3C. The W3C TAG plan for moving this to Recommendation is http://www.w3.org/20= 01/tag/products/fragids.html=20 (a) comments on the document itself should be sent to www-tag@w3.org. Pleas= e note that the latest 'editor draft' is http://www.w3.org/2001/tag/doc/mim= eTypesAndFragids.=20 (b) it is likely too late to affect draft-ietf-appsawg-media-type-regs (c) Perhaps a reference to it from http://tools.ietf.org/html/draft-ietf-ap= psawg-media-type-suffix-regs (as an informative source of considerations an= expert reviewer might take into account) would be in order. Larry -- http://larry.masinter.net From superuser@gmail.com Mon Jul 30 13:17:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BE821F8505 for ; Mon, 30 Jul 2012 13:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-1.299, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyZau5JNkdqK for ; Mon, 30 Jul 2012 13:17:25 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C7C9621F844C for ; Mon, 30 Jul 2012 13:17:24 -0700 (PDT) Received: by lagv3 with SMTP id v3so3784348lag.31 for ; Mon, 30 Jul 2012 13:17:23 -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=ytxs8KRP+pVeGlXixhYfagcnOsy3SxgcgD61UC8TGe4=; b=DXHGsuiCmuF3dPaP/8rlhaOsX2OLu1tW0xU3skQ0uwchZ99AkmccbdIhxsGtmdZqEP DRPR7pGvkURP0hXpwOnFwAYruLU60cZuTCqO5TcaZCAiK9+PiZVYH8+Xozu07+w9qN/1 ug7a0LLrfKTsB+mfLbivcr9Rl2aDf/2U1idVPs5UqJXcty7I96xzv/JYL1JNZuT6xnr6 WY2Fq8HOWsCtWqIRePV/Hs5nnTsc5GdsMUAU6dLkY50y/FW4VNBDAFJgkDESNWdm53vM KXsyCJ6GD2HnYGUt8L0VG6HiU4QUAod9HOqCcX73D1F2PFC92SlMd0H0IP1msbL2mcga UqHw== MIME-Version: 1.0 Received: by 10.112.101.196 with SMTP id fi4mr5775388lbb.67.1343679443700; Mon, 30 Jul 2012 13:17:23 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 30 Jul 2012 13:17:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Jul 2012 13:17:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: Larry Masinter Content-Type: multipart/alternative; boundary=f46d0401682bef0bf604c611bf9d Cc: "www-tag@w3.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "Best Practices for Fragment Identifiers and Media Type Definitions" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2012 20:17:26 -0000 --f46d0401682bef0bf604c611bf9d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 30, 2012 at 9:36 AM, Larry Masinter wrote: > To be more explicit (and provide additional URLs): > > http://www.w3.org/TR/fragid-best-practices/ is now (as of last week) a > W3C "First Public Working Draft" as the first step of the "Recommendation" > track at W3C. > The W3C TAG plan for moving this to Recommendation is > http://www.w3.org/2001/tag/products/fragids.html > > (a) comments on the document itself should be sent to www-tag@w3.org. > Please note that the latest 'editor draft' is > http://www.w3.org/2001/tag/doc/mimeTypesAndFragids. > > (b) it is likely too late to affect draft-ietf-appsawg-media-type-regs > > (c) Perhaps a reference to it from > http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs (as > an informative source of considerations an expert reviewer might take into > account) would be in order. > > Is there any objection from the WG to making a reference to this in the suffix-regs document? (Perhaps before we go there: Is that first w3.orgURI going to be a permanent URI to which we could make reference?) -MSK --f46d0401682bef0bf604c611bf9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 30, 2012 at 9:36 AM, Larry Masinter <masinter@adobe.com&g= t; wrote:
To be more explicit (and provide additional URLs):

=A0 =A0http://www.w3.org/TR/fragid-best-practices/ is now (as of last we= ek) a W3C "First Public Working Draft" as the first step of the &= quot;Recommendation" track at W3C.
The W3C TAG plan for moving this to Recommendation is =A0http://www.w3.= org/2001/tag/products/fragids.html

(a) comments on the document itself should be sent to www-tag@w3.org. Please note that the latest 'editor dr= aft' is http://www.w3.org/2001/tag/doc/mimeTypesAndFragids.
(b) it is likely too late to affect draft-ietf-appsawg-media-type-regs

(c) Perhaps a reference to it from http://tools.iet= f.org/html/draft-ietf-appsawg-media-type-suffix-regs (as an informative= source of considerations an expert reviewer might take into account) would= be in order.


Is there any objection from the WG to making a re= ference to this in the suffix-regs document?=A0 (Perhaps before we go there= : Is that first w3.org URI going to be a perm= anent URI to which we could make reference?)

-MSK

--f46d0401682bef0bf604c611bf9d-- From ht@inf.ed.ac.uk Mon Jul 30 14:01:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD1011E81BB for ; Mon, 30 Jul 2012 14:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.296 X-Spam-Level: X-Spam-Status: No, score=-5.296 tagged_above=-999 required=5 tests=[AWL=-1.152, BAYES_00=-2.599, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PQoEGX0DaDK for ; Mon, 30 Jul 2012 14:01:36 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id E4B8211E818E for ; Mon, 30 Jul 2012 14:01:35 -0700 (PDT) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q6UL1HuM021145; Mon, 30 Jul 2012 22:01:17 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q6UL1HTv027762; Mon, 30 Jul 2012 22:01:17 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q6UL1HfU002974; Mon, 30 Jul 2012 22:01:17 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q6UL1G35002970; Mon, 30 Jul 2012 22:01:16 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: "Murray S. Kucherawy" References: From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 30 Jul 2012 22:01:16 +0100 In-Reply-To: (Murray S. Kucherawy's message of "Mon, 30 Jul 2012 13:17:23 -0700") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: "apps-discuss@ietf.org" , "www-tag@w3.org" Subject: Re: [apps-discuss] "Best Practices for Fragment Identifiers and Media Type Definitions" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jul 2012 21:01:37 -0000 Murray S. Kucherawy writes: > On Mon, Jul 30, 2012 at 9:36 AM, Larry Masinter wrote: > >> To be more explicit (and provide additional URLs): >> >> http://www.w3.org/TR/fragid-best-practices/ is now (as of last week) a >> W3C "First Public Working Draft" as the first step of the "Recommendation" >> track at W3C. >> . . . > Is there any objection from the WG to making a reference to this in the > suffix-regs document? I can't speak officially for the rest of the TAG, but I am pretty sure it is our hope that you will do precisely that. > (Perhaps before we go there: Is that first w3.org URI going to be a > permanent URI to which we could make reference?) Yes, the URI above will be as permanent as any w3.org document URI. It will track the latest version, and will eventually be the URI for the approved W3C Recommendation, assuming we get that far. 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 Peter.Rushforth@NRCan-RNCan.gc.ca Tue Jul 31 03:59:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003CC21F86B9 for ; Tue, 31 Jul 2012 03:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdWN5NVwo9Dm for ; Tue, 31 Jul 2012 03:59:17 -0700 (PDT) Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id 618D321F86B4 for ; Tue, 31 Jul 2012 03:59:17 -0700 (PDT) Received: from S-BSC-CAS2.nrn.nrcan.gc.ca (132.156.238.12) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 31 Jul 2012 06:59:16 -0400 Received: from S-BSC-MBX4.nrn.nrcan.gc.ca ([169.254.4.124]) by S-BSC-CAS2.nrn.nrcan.gc.ca ([fe80::48d4:f168:78ba:d4e8%19]) with mapi id 14.02.0283.003; Tue, 31 Jul 2012 06:59:15 -0400 From: "Rushforth, Peter" To: "apps-discuss@ietf.org application-layer protocols" Thread-Topic: [apps-discuss] abstract names registry idea from json-home docs Thread-Index: AQHNbwsQd5p5iBUgb0KX415V4PPKRQ== Date: Tue, 31 Jul 2012 10:59:14 +0000 Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF1AE2C93E@S-BSC-MBX4.nrn.nrcan.gc.ca> Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.156.238.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] abstract names registry idea from json-home docs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2012 10:59:18 -0000 Hi,=0A= =0A= The json-home spec defines a number of names which refer to protocol elemen= ts, which have values typed according to other RFCs. =0A= =0A= Recently, I proposed to the XML Core Working group that a number of names b= e added to the xml: namespace to burn hypermedia into the XML family of voc= abularies. =0A= =0A= I suggested that 'tref' which appears to be equivalent to json-home's 'href= -template' be added.=0A= =0A= In the beginning, there was just html (and http) to decide what these names= were going to be. But now, there are many communities deciding on names.= =0A= =0A= I was wondering if there would be value in a rel-type registry approach to = the (abstract) names for these concepts. Then vocabulary designers could '= re-use' or if necessary re-combine these names as appropriate, and if neces= sary, feed the name back into the registry via as a hint to other designers= .=0A= =0A= I'm at IETF 84 if it's worth discussing.=0A= =0A= Peter= From ned.freed@mrochek.com Tue Jul 31 10:05:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB8321F86FF for ; Tue, 31 Jul 2012 10:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[AWL=-1.162, BAYES_00=-2.599, FRT_ADOBE2=2.455] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY3YE97r9Kyd for ; Tue, 31 Jul 2012 10:05:57 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E4FE321F853A for ; Tue, 31 Jul 2012 10:05:56 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIHUXZ1Q68006E2X@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 31 Jul 2012 10:00:50 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Tue, 31 Jul 2012 10:00:47 -0700 (PDT) Message-id: <01OIHUXXAVUE0006TF@mauve.mrochek.com> Date: Tue, 31 Jul 2012 09:54:46 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 30 Jul 2012 13:17:23 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: "Murray S. Kucherawy" Cc: "apps-discuss@ietf.org" , "www-tag@w3.org" Subject: Re: [apps-discuss] "Best Practices for Fragment Identifiers and Media Type Definitions" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 Jul 2012 17:05:57 -0000 > On Mon, Jul 30, 2012 at 9:36 AM, Larry Masinter wrote: > > To be more explicit (and provide additional URLs): > > > > http://www.w3.org/TR/fragid-best-practices/ is now (as of last week) a > > W3C "First Public Working Draft" as the first step of the "Recommendation" > > track at W3C. > > The W3C TAG plan for moving this to Recommendation is > > http://www.w3.org/2001/tag/products/fragids.html > > > > (a) comments on the document itself should be sent to www-tag@w3.org. > > Please note that the latest 'editor draft' is > > http://www.w3.org/2001/tag/doc/mimeTypesAndFragids. > > > > (b) it is likely too late to affect draft-ietf-appsawg-media-type-regs > > > > (c) Perhaps a reference to it from > > http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs (as > > an informative source of considerations an expert reviewer might take into > > account) would be in order. > > > > > Is there any objection from the WG to making a reference to this in the > suffix-regs document? (Perhaps before we go there: Is that first > w3.orgURI going to be a permanent URI to which we could make > reference?) I certainly have no objection, but I also think this doesn't have much value. As I've pointed out several times now, the mandate of this document is to seed the registry. Nothing more. As such, it seems, well, unlikely that people will look in it for guidance as to how to define fragment identifiers. The timing here is really unfortunate because this really belongs in the media types registry document, but IMO adding such a reference there would require reopening the document and probably issuing a second last call. And that's too much, especially since, if past history is any indication the place people will look for this material is in existing registrations they find in the registry. So perhaps the thing to do is clean up the fragment id information in some existing registrations. Just a thought. Ned