From nobody Sun Nov 6 22:10:16 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CF9129653 for ; Sun, 6 Nov 2016 22:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IoQVcrEHIYU for ; Sun, 6 Nov 2016 22:10:13 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC3F129C40 for ; Sun, 6 Nov 2016 22:10:13 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id x190so162752050qkb.0 for ; Sun, 06 Nov 2016 22:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=XsqTVz9pSOdIZC2XnwE7oqG/3e/3MOAMDRGV7/H7uFI=; b=SYWLgtyjC05oThFLdjDUuwv60ysZaOC0jFtoLu8AYiF2tMnOE+Wf8UTc2f+7eaXXMo k3J0h3o6wY0uGHFRzdLZ/6tSZfiBZ6Ft5cEJx/gqnpkD5Ud80/tWFCLCqF9gvKL9AduI 64eDUekwq4nmRwzPgD2Y5d6AUfxX/v+br8UFAUaOviVofZNHlf2i+v2UvS4OEm8X92mX a+7F5K4xD731yiP2UilhZij9n0p+ojxu9fQVNQA/fAuEytExMFrhX0favvH5FnUs800t f79CB+CM+8OCJP47PVv/J50NXZFdgjKFQ9cuR4uXjyjasyqPqLN30rsY9lMhpHEdt5xz Heow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XsqTVz9pSOdIZC2XnwE7oqG/3e/3MOAMDRGV7/H7uFI=; b=ETzxlrKKwhvtMKJA1NA955R5EWdGpARck1l3j4ajsQqspkgITf8ViOZPTjER0Gd9dL OCZQEXTHvbdmgQyNMW6GuZu6mrgBBwqMtKFkz8UaeSPdGJ4CQTuS4aCdT+mNPNtNHy9k 7H9JFCLJQeEwJMk802L/r8mPf+SQIVfyoRfxI79STCt/OvWv1rmOd8Wyy7z9qeJ6JRdL SIhgFT6dkYk3vC/f8jLCFimglJzuZzcZBtqUyDQBQuXD5FT9skH57AgrGDVrwlTml1Ff BHAKn72A9AcbdmNXQ47WeKnySY3/I0G2Pq7vvcHImIQ68OkmUDxPkA2T2ehJ7bqIs4Iw Zziw== X-Gm-Message-State: ABUngvcfkbPHeORRqS0Y2c3qYJSJWVYgJrdDiKrxqffeXOPfRnm4ADK9aWOv5WTv2+iuJPD8p70FvN+eHCy7yw== X-Received: by 10.233.235.72 with SMTP id b69mr5661475qkg.144.1478499012488; Sun, 06 Nov 2016 22:10:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sun, 6 Nov 2016 22:10:12 -0800 (PST) From: Martin Thomson Date: Mon, 7 Nov 2016 17:10:12 +1100 Message-ID: To: "gen-art@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [art] Review of draft-levine-herkula-oneclick X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 06:10:15 -0000 This draft seems pretty useful. It's a very simple idea. It needs quite a bit of work before I would consider it fit for publication on the standards track. (Note: I reviewed -07; my review of the diff to -08 shows that there are no relevant changes between the two versions.) #1 Abstract and Introduction The first rationale for this draft is completely wrong (abstract and introduction, p1). The need for one-click arises because MTAs want to present UX for unsubscribing and the list providers generally don't have any programmatic way to access this function. The HTTPS URI in a List-Unsubscribe is intended to be opened in a browser and shown to a user. This is what makes it unsuitable for consumption by a machine or piece of software. That's the relevant point here. That anti-spam software automatically fetches the link is what causes GETs to these URIs to do the wrong thing is not something this draft addresses. It's something to bemoan, but you aren't going to get people who deploy bad software to write good software by publishing an RFC. I would add this point as an aside, noting that this sad truth is not one that this document will be likely to do anything about. #2 Section 3.1 Can the List-Unsubscribe header field include more than one HTTPS URI? If it can, are all URIs expected to behave equivalently? #3 Section 3.1 The list of key/ value pairs MUST contain the pair "List-Unsubscribe=One-Click". This is a pointless requirement. If the mailer wants to mark one-click subscriptions specially, it can provide whatever string it likes in the -Post header field. (It could include that string if that was what it wanted.) #4 Section 3.1 The URI and POST arguments SHOULD include an opaque identifier or other hard to forge component in addition to or instead of the plain- text names of the list and the subscriber. This needs to be a MUST. Is this both the URI and the -Post header field, or either? I would have said that either was OK. You should note that the latter is only OK if loading the URI triggers user authentication or some other process that an attacker would be unable to complete. However, this doesn't prevent an attacker from unsubscribing a user if ambient authority (e.g., cookies) were used to authenticate the user because then the attacker could use the spam (or spear-phishing) trick. If ambient authority is used, then the URI MUST include the opaque identifier. Also, the entropy requirement needs to be explicit. 96-bits of data that cannot be predicted by an attacker should suffice. The security considerations should observe here that all mail servers that receive the message will be able to unsubscribe the user. You should make a point of that in the security considerations. #5 Section 3.1; Section 8 This will deter attacks in which a malicious party sends spam with List-Unsubscribe links for a victim list, with the intention of causing list unsubscriptions from a victim list as a side effect of users reporting the spam. This is not the only way to cause a user to be unsubscribed if the links are low entropy. An attacker can just send POST requests if it came to that. You don't need to go to the effort of sending mail to someone else unless the mailer is going to insist that the mail receiver authenticate itself. I don't see that as likely. What you have created here is what is lovingly referred to as a capability URI (more info: https://w3ctag.github.io/capability-urls/). I would strongly encourage you to reference the W3C document here and maybe give a brief overview of the hazards involved in this design. It's a fine design, but not without risks. #6 Section 3.1 The One-Click action triggered by this URI SHOULD complete promptly and not burden the requester in an inappropriate way. This has 2119-strength language, but I don't see how to enforce it. I totally get the next sentence, but if that is the extent of the requirement, then this sentence doesn't need any of that language. (Usually, prompt responses are of most benefit to the server, so insisting on that isn't necessary.) #7 Section 3.2; Section 5; Section 7.3 The POST content SHOULD be sent as "multipart/form-data" [RFC7578] and MAY be sent as "application/x-www-form-urlencoded". I think that this is crazy. This implies that the contents of the -Post header field is parsed by the mail receiver and then re-composed into a different form. I would prefer if the header field were treated as an opaque string that was passed directly as the body of the POST request. This ensures a) that the information is unmodified, and b) the that mail receiver implementation is as simple as possible. I think that you could use text/plain with equal efficacy. Or, better yet, insist that the server not validate the content-type of the POST request. (Note that many implementations on the server side will ignore the content-type header field when expecting form POSTs, but insisting on "application/x-www-form-urlencoded" would be reasonable if you are aware of server code that is deployed and cannot be updated.) For Section 5, I think that it would be sufficient to define this as a completely free-form header field. #8 Section 3.2 The target of the POST action is the same as or similar to the one in the GET action for a manual unsubscription, ... I don't understand this. Isn't the target of the POST a URI from the List-Unsubscribe header field? Nit in this section: "the the HTTPS URI" #9 Section 4 Just a question: is there any reason that you insist on DKIM, but don't tie the DKIM information back to the URI in question? Is there any value in matching SDID to the hostname in the HTTPS URI? From nobody Mon Nov 7 03:09:12 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39109129C44 for ; Mon, 7 Nov 2016 03:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q627wZz6PIV8 for ; Mon, 7 Nov 2016 03:09:09 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52EC1129C4C for ; Mon, 7 Nov 2016 03:09:09 -0800 (PST) Received: (qmail 61672 invoked from network); 7 Nov 2016 11:09:09 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 7 Nov 2016 11:09:09 -0000 Date: 6 Nov 2016 17:21:17 -0000 Message-ID: <20161106172117.6531.qmail@ary.lan> From: "John Levine" To: art@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: martin.thomson@gmail.com Subject: Re: [art] Review of draft-levine-herkula-oneclick X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 11:09:11 -0000 Thanks for your review. >#1 Abstract and Introduction > >The first rationale for this draft is completely wrong (abstract and >introduction, p1). The need for one-click arises because MTAs want to >present UX for unsubscribing and the list providers generally don't >have any programmatic way to access this function. > >The HTTPS URI in a List-Unsubscribe is intended to be opened in a >browser and shown to a user. This is what makes it unsuitable for >consumption by a machine or piece of software. That's the relevant >point here. > >That anti-spam software automatically fetches the link is what causes >GETs to these URIs to do the wrong thing is not something this draft >addresses. It's something to bemoan, but you aren't going to get >people who deploy bad software to write good software by publishing an >RFC. I would add this point as an aside, noting that this sad truth >is not one that this document will be likely to do anything about. No, really, the motivation is what we say it is. A decade ago, list-unsubscribe URIs unsubscribed you on the GET and returned a page saying goodbye so you could script them. The anti-spam fetches made the GETs ambiguous, and provoked the confirmation pages. I suppose I can reword it, although the people who've implemented it don't seem to have any trouble understanding the motivation. >#2 Section 3.1 > >Can the List-Unsubscribe header field include more than one HTTPS URI? > If it can, are all URIs expected to behave equivalently? For this spec, you only get one. >#3 Section 3.1 > > The list of key/ > value pairs MUST contain the pair "List-Unsubscribe=One-Click". > >This is a pointless requirement. The mailers who've implemented this disagree with you; they find it useful to verify that the specific intention of the POST is a one-click unsubscribe. Do you see any reason it's so harmful that it's worth breaking the existing implementations? The latest version of the draft says that the -post header *only* contains the "List-Unsubscribe=One-Click" tag, to prevent bad guys from using it to remotely script arbitrary web forms. >#4 Section 3.1 > > The URI and POST arguments SHOULD include an opaque identifier or > other hard to forge component in addition to or instead of the plain- > text names of the list and the subscriber. > >This needs to be a MUST. > >Is this both the URI and the -Post header field, or either? Just the URI since the -Post header contents is now fixed. >doesn't prevent an attacker from unsubscribing a user if ambient >authority (e.g., cookies) were used to authenticate the user because >then the attacker could use the spam (or spear-phishing) trick. If >ambient authority is used, then the URI MUST include the opaque >identifier. The latest draft also says don't send cookies or other context info. >Also, the entropy requirement needs to be explicit. 96-bits of data >that cannot be predicted by an attacker should suffice. I think you're making unwarranted assumptions about the security goals of the people who implement this. List-Unsubscribe typically contain mailto: URLs that aren't authenticated at all, and that hasn't been a big problem in practice. They want it to be non-trivial to fake an unsubscribe, but I don't see any evidence that anyone expects military level security here. Also keep in mind that the identifier often is a key to a record in the mailer's database with no relationship to any other identifier in the message, so as long as the identifier space is reasonably sparse, it's pretty secure. > The security >considerations should observe here that all mail servers that receive >the message will be able to unsubscribe the user. You should make a >point of that in the security considerations. I suppose, but if someone's mail is going through hostile servers, he's got worse problems than the occasional unsubscription. Keep in mind that the way this works, every recipient gets a separate customized copy of the message, so only the recipient's own mail servers are going to see it. (If you're unfamiliar with the bulk mail market, they all send separate copies anyway.) >#5 Section 3.1; Section 8 > > This will deter attacks in which a malicious party sends spam > with List-Unsubscribe links for a victim list, with the intention of > causing list unsubscriptions from a victim list as a side effect of > users reporting the spam. > >This is not the only way to cause a user to be unsubscribed if the >links are low entropy. An attacker can just send POST requests if it >came to that. You don't need to go to the effort of sending mail to >someone else unless the mailer is going to insist that the mail >receiver authenticate itself. I don't see that as likely. Honestly, I don't see either as likely. I'll just take it out. > >What you have created here is what is lovingly referred to as a >capability URI (more info: https://w3ctag.github.io/capability-urls/). >I would strongly encourage you to reference the W3C document here and >maybe give a brief overview of the hazards involved in this design. >It's a fine design, but not without risks. Sure. Is there a more stable reference than a github file? >#6 Section 3.1 > > The One-Click action triggered by this URI SHOULD complete promptly > and not burden the requester in an inappropriate way. > >This has 2119-strength language, but I don't see how to enforce it. SHOULD means "do this if you want to interoperate unless you have a good reason to do something else." I don't see where enforcement is relevant. >#7 Section 3.2; Section 5; Section 7.3 > > The POST content SHOULD be sent as "multipart/form-data" [RFC7578] > and MAY be sent as "application/x-www-form-urlencoded". > >I think that this is crazy. This implies that the contents of the >-Post header field is parsed by the mail receiver and then re-composed >into a different form. Yes, the mail receiver does that, but the people who have implemented this like it just fine. They typically hand it to a http client library where it's treated like the contents of a web form. > I would prefer if the header field were >treated as an opaque string that was passed directly as the body of >the POST request. This ensures a) that the information is unmodified, >and b) the that mail receiver implementation is as simple as possible. That would be bad, since that would let bad guys put arbitrary crud into http requests. It would also be a lot harder to program since they'd have to go around the libraries they're already using. >#8 Section 3.2 > > The > target of the POST action is the same as or similar to the one in the > GET action for a manual unsubscription, ... > >I don't understand this. Isn't the target of the POST a URI from the >List-Unsubscribe header field? Editing error, it is indeed the same URI as the one you'd use for a manual unsub. >Just a question: is there any reason that you insist on DKIM, but >don't tie the DKIM information back to the URI in question? Is there >any value in matching SDID to the hostname in the HTTPS URI? That's deliberate. There's lots of service bureaus that send mail on behalf of clients, the division of work varies a lot, and it's quite common for the domain in the unsub URI to be different from all the other domains in the message. I asked a large mail receiver about this, and he said the point of the DKIM signature is to have some identity they can use to say yeah, this is someone we recognize as not totally evil. R's, John From nobody Mon Nov 7 15:20:43 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9FC129789 for ; Mon, 7 Nov 2016 15:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7pS3f_xOoux for ; Mon, 7 Nov 2016 15:20:39 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6DF129536 for ; Mon, 7 Nov 2016 15:20:39 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id p16so97386691qta.0 for ; Mon, 07 Nov 2016 15:20:39 -0800 (PST) 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; bh=uQIiATl/H/372KSi9MeqccMALNosVterHZJ2uLnDzZs=; b=HFMay9gvd0EZm4WdjUOL1fE3Qr3uk51Xwzpcv1uIPlYOWbUXyosbu5FPuj9WS7WGfJ hKAXF6cdAC6E6xzs7Uql0q/vfV6qRcKQyEaVtn2OZsTPdM3hkcbGdjdCn5PGr0JKis5a w/igpZW/AlCiwkHibIYcsTzI351IZY9DDnqAo/xJOznuyFFsqbljtOytybo+ujOo41FW avTpeDkKgOrpXiYNSNKiHIEazHnYixsfc2+RyZbd0zLtShwwM/3mUuxI5ioa83wt4/Eu vsT3sxAyt3l2BFC2t7SYn9vorvtcaw0TzWgJ8pebBvyZAyLfLTg+6f1TMHQ2ak5g3oq3 5jfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uQIiATl/H/372KSi9MeqccMALNosVterHZJ2uLnDzZs=; b=LONFN+xQDFBodZXz6s78jTO3PIpLDIMRtk/BA3Qdni8WMM1uUAz58dNRav+3fSIdE+ DDZsFNgDFWX5tutstfeGN12crMqEclZOciYVsUOyTEKMi5hV7WJmtkUBwlu/1vgOfyr2 8O93knfBJBXvlUTH3+kEKsPtix+hYOAZqA88qYr68l6qe3F8qSwDsRsgKplux/aohiAS L7mMAOAvZ8fIbzjogVX4EpWT4Gqlz7Ug9//mY4KwL4LE6kJNt+I/6/Z1T4ZtXYY1a/in xQ0QRhZJ5VC6fCzULVoHan/5UsGjm45tI/ZicXK7I5hrWPsN7wuaeRsv+NvTknc7bdC/ Irlw== X-Gm-Message-State: ABUngvevpMC0OEA7Z0Gvo8LdPcdElfesf1q9O5pb5qqWTsAKZ2m3hyZfNgKhN95wivgyrgaSRhEn+z7VRI6EWw== X-Received: by 10.200.50.227 with SMTP id a32mr9597264qtb.32.1478560838432; Mon, 07 Nov 2016 15:20:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 7 Nov 2016 15:20:37 -0800 (PST) In-Reply-To: <20161106172117.6531.qmail@ary.lan> References: <20161106172117.6531.qmail@ary.lan> From: Martin Thomson Date: Tue, 8 Nov 2016 10:20:37 +1100 Message-ID: To: John Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "gen-art@ietf.org" Subject: Re: [art] Review of draft-levine-herkula-oneclick X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 23:20:42 -0000 On 7 November 2016 at 04:21, John Levine wrote: > Thanks for your review. > >>#1 Abstract and Introduction >> >>The first rationale for this draft is completely wrong (abstract and >>introduction, p1). The need for one-click arises because MTAs want to >>present UX for unsubscribing and the list providers generally don't >>have any programmatic way to access this function. >> >>The HTTPS URI in a List-Unsubscribe is intended to be opened in a >>browser and shown to a user. This is what makes it unsuitable for >>consumption by a machine or piece of software. That's the relevant >>point here. >> >>That anti-spam software automatically fetches the link is what causes >>GETs to these URIs to do the wrong thing is not something this draft >>addresses. It's something to bemoan, but you aren't going to get >>people who deploy bad software to write good software by publishing an >>RFC. I would add this point as an aside, noting that this sad truth >>is not one that this document will be likely to do anything about. > > No, really, the motivation is what we say it is. A decade ago, > list-unsubscribe URIs unsubscribed you on the GET and returned a page > saying goodbye so you could script them. The anti-spam fetches made > the GETs ambiguous, and provoked the confirmation pages. > > I suppose I can reword it, although the people who've implemented > it don't seem to have any trouble understanding the motivation. You really need to explain that GET to the URI sometimes unsubscribes immediately (i.e., is unsafe) and sometimes shows a confirmation page. Nonetheless, my point stands. The point is that there is no reliable way for a machine to unsubscribe. Your point about automatic fetches of links might muddy the waters some, but it isn't the real motivation. (Again, see my point about bad software.) >>#2 Section 3.1 >> >>Can the List-Unsubscribe header field include more than one HTTPS URI? >> If it can, are all URIs expected to behave equivalently? > > For this spec, you only get one. Say that please. >>#3 Section 3.1 >> >> The list of key/ >> value pairs MUST contain the pair "List-Unsubscribe=One-Click". >> >>This is a pointless requirement. > > The mailers who've implemented this disagree with you; they find it > useful to verify that the specific intention of the POST is a one-click > unsubscribe. Do you see any reason it's so harmful that it's worth > breaking the existing implementations? > > The latest version of the draft says that the -post header *only* > contains the "List-Unsubscribe=One-Click" tag, to prevent bad > guys from using it to remotely script arbitrary web forms. OK, now I'm really confused. Why would you waste so many octets to send a single bit? I could see the value in having the mailer set an arbitrary string here. That's valuable because it allows it to bake in entropy in the case that it sends a generic unsubscribe link. >>#4 Section 3.1 >> >> The URI and POST arguments SHOULD include an opaque identifier or >> other hard to forge component in addition to or instead of the plain- >> text names of the list and the subscriber. >> >>This needs to be a MUST. >> >>Is this both the URI and the -Post header field, or either? > > Just the URI since the -Post header contents is now fixed. > >>doesn't prevent an attacker from unsubscribing a user if ambient >>authority (e.g., cookies) were used to authenticate the user because >>then the attacker could use the spam (or spear-phishing) trick. If >>ambient authority is used, then the URI MUST include the opaque >>identifier. > > The latest draft also says don't send cookies or other context info. That doesn't help. Because if the URI is guessable I can make your web browser load it (with cookies). And if the link is opened by the mail agent in a browser, then I can guarantee that it will have cookies. >>Also, the entropy requirement needs to be explicit. 96-bits of data >>that cannot be predicted by an attacker should suffice. > > I think you're making unwarranted assumptions about the security goals > of the people who implement this. List-Unsubscribe typically contain > mailto: URLs that aren't authenticated at all, and that hasn't been a > big problem in practice. They want it to be non-trivial to fake an > unsubscribe, but I don't see any evidence that anyone expects military > level security here. Also keep in mind that the identifier often is > a key to a record in the mailer's database with no relationship to > any other identifier in the message, so as long as the identifier space > is reasonably sparse, it's pretty secure. No, I'm not making assumptions, I'm describing what it takes to make something secure. I would also assert that given how easy it is to do so, it's worth doing. Of course, people can and will ignore advice. But we write RFCs on the understanding that some won't. I'd like to think that people who read RFCs also want to know what the best thing to do is and that we can occasionally help make things better by writing those things down. >> The security >>considerations should observe here that all mail servers that receive >>the message will be able to unsubscribe the user. You should make a >>point of that in the security considerations. > > I suppose, but if someone's mail is going through hostile servers, > he's got worse problems than the occasional unsubscription. Keep in > mind that the way this works, every recipient gets a separate > customized copy of the message, so only the recipient's own mail > servers are going to see it. (If you're unfamiliar with the bulk mail > market, they all send separate copies anyway.) Let's not adopt the policy that because worse things are possible we shouldn't fix the things that are fixable. Hostile works in many ways. (Ideally mail security would be such that mail servers have only one choice: drop mail or not.) >>#5 Section 3.1; Section 8 >> >> This will deter attacks in which a malicious party sends spam >> with List-Unsubscribe links for a victim list, with the intention of >> causing list unsubscriptions from a victim list as a side effect of >> users reporting the spam. >> >>This is not the only way to cause a user to be unsubscribed if the >>links are low entropy. An attacker can just send POST requests if it >>came to that. You don't need to go to the effort of sending mail to >>someone else unless the mailer is going to insist that the mail >>receiver authenticate itself. I don't see that as likely. > > Honestly, I don't see either as likely. I'll just take it out. I thought that it was useful to point out the consequences of the design (i.e., the capability URLs part), but whatever you have there should cover this well enough. >>What you have created here is what is lovingly referred to as a >>capability URI (more info: https://w3ctag.github.io/capability-urls/). >>I would strongly encourage you to reference the W3C document here and >>maybe give a brief overview of the hazards involved in this design. >>It's a fine design, but not without risks. > > Sure. Is there a more stable reference than a github file? Welcome to the new W3C. I don't think so unfortunately :/ >>#6 Section 3.1 >> >> The One-Click action triggered by this URI SHOULD complete promptly >> and not burden the requester in an inappropriate way. >> >>This has 2119-strength language, but I don't see how to enforce it. > > SHOULD means "do this if you want to interoperate unless you have > a good reason to do something else." I don't see where enforcement > is relevant. So, I've learned that SHOULD needs: a) good interoperability reasons for complying and b) an explanation of why someone might choose not to comply. I see neither here. >>#7 Section 3.2; Section 5; Section 7.3 >> >> The POST content SHOULD be sent as "multipart/form-data" [RFC7578] >> and MAY be sent as "application/x-www-form-urlencoded". >> >>I think that this is crazy. This implies that the contents of the >>-Post header field is parsed by the mail receiver and then re-composed >>into a different form. > > Yes, the mail receiver does that, but the people who have implemented > this like it just fine. They typically hand it to a http client > library where it's treated like the contents of a web form. That's not a good reason. See below. >> I would prefer if the header field were >>treated as an opaque string that was passed directly as the body of >>the POST request. This ensures a) that the information is unmodified, >>and b) the that mail receiver implementation is as simple as possible. > > That would be bad, since that would let bad guys put arbitrary crud > into http requests. It would also be a lot harder to program since > they'd have to go around the libraries they're already using. Why? I believe that ALL HTTP libraries allow you to POST octets. It's actually easier than fiddling with form posting. And since you are not including cookies, all you are doing is allowing the bad guy to ask you to make one single request. They could make the same request themselves, far more cheaply. Allowing mail receivers to modify the data makes this worse for the mail sender, who has to parse this gunk. (I'm not the only one who thinks that HTML form posting is a legacy the web could happily leave behind.) >>#8 Section 3.2 >> >> The >> target of the POST action is the same as or similar to the one in the >> GET action for a manual unsubscription, ... >> >>I don't understand this. Isn't the target of the POST a URI from the >>List-Unsubscribe header field? > > Editing error, it is indeed the same URI as the one you'd use for a manual unsub. > >>Just a question: is there any reason that you insist on DKIM, but >>don't tie the DKIM information back to the URI in question? Is there >>any value in matching SDID to the hostname in the HTTPS URI? > > That's deliberate. There's lots of service bureaus that send mail on > behalf of clients, the division of work varies a lot, and it's quite > common for the domain in the unsub URI to be different from all the > other domains in the message. I asked a large mail receiver about > this, and he said the point of the DKIM signature is to have some > identity they can use to say yeah, this is someone we recognize as not > totally evil. Acknowledged. I figured that it would be something like that. From nobody Mon Nov 7 23:55:41 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E9D1293FB for ; Mon, 7 Nov 2016 23:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BIGNUM_EMAILS=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=UVi+aKG0; dkim=pass (1536-bit key) header.d=taugh.com header.b=zGHgQj/W Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJSIQLRxjUvZ for ; Mon, 7 Nov 2016 23:55:39 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC85A1293D8 for ; Mon, 7 Nov 2016 23:55:38 -0800 (PST) Received: (qmail 9932 invoked from network); 8 Nov 2016 07:55:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=26cb.582184fa.k1611; bh=Qh54lVExyMOA2LZhBe96J7G72E1ZKqjr4MEdcNph4fk=; b=UVi+aKG0x7HmrtsFEtYjb1jntSZcLQCfbTVmWqDyMSlMPewfiQlOH7mdQOMMeprGhDj5yxEFfEO3MWA2kGsFNnjbXhBxAEt6aLkpRbBrAxvn6Xv+rEporTuc6BMbwSk4XMa9w3x3CQncFL/ZG22/Tu43/Reh+6cXhovQuetwon34cjzY5ceFjVyiypXT0uBiafR4J1tby/GoRfiV1TcJ2DumwxebTgnscTBCbn59KxiKBUUjS8HuSKjlKxZQ8Wtd DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=26cb.582184fa.k1611; bh=Qh54lVExyMOA2LZhBe96J7G72E1ZKqjr4MEdcNph4fk=; b=zGHgQj/W45Qv3WzsRyyD9AJHPNRntFBpQo9MI0FbO0eG4Qg2hcMsKvqV70ycI3t0OsjQ/y0d84/6cIXm/6WgA/XNorPy9iyK/9B743GsO0uiYIQGQXFF5Vs8eChXnTJoZSTzF+oDzAuVfl9/WHKnuFnFy3J3X6S53jfi+JN8UryC9xwSQRweZmp4FS2cui+nWEYuiRS/Gbo3xCRYCBQ5SsbLGxmQL7KfVgCiK1+XU2lz9Nj+LyEPRoV6oF30Ie0A Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 08 Nov 2016 07:55:37 -0000 Date: 8 Nov 2016 13:25:32 +0530 Message-ID: From: "John R Levine" To: "Martin Thomson" In-Reply-To: References: <20161106172117.6531.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: "gen-art@ietf.org" , John Levine Subject: Re: [art] Review of draft-levine-herkula-oneclick X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 07:55:40 -0000 > You really need to explain that GET to the URI sometimes unsubscribes > immediately (i.e., is unsafe) and sometimes shows a confirmation page. I thought I did. We seem to agree about what it should say, I'll see if I can make it clearer. >>> value pairs MUST contain the pair "List-Unsubscribe=One-Click". > OK, now I'm really confused. Why would you waste so many octets to > send a single bit? Basically, because we want to and it doesn't hurt anything. At this stage I'd want a much stronger reason to change the running code than that it's ugly. >>> [ re URIs and ]the entropy requirement needs to be explicit. >>> 96-bits of data that cannot be predicted by an attacker should suffice. >> >> I think you're making unwarranted assumptions about the security goals >> of the people who implement this. > No, I'm not making assumptions, I'm describing what it takes to make > something secure. I would also assert that given how easy it is to do > so, it's worth doing. A list with a million names is quite large. If there were a 40 bit identifier space, you'd get one in a million tries, a 50 bit space one in a billion, and since a try requires an http transaction, they are not particularly fast. Where does 96 bits come from? Also with respect to cookies and other context, the reason -08 says not to send them is to prevent marketers from connecting the unsub to the user's previous actvities in the scenario where it's coming from an MUA. If a bad guy were scripting something and doing multiple unsub tries with the same cookies, that'd be an immediate tell. >>> #6 Section 3.1 >>> >>> The One-Click action triggered by this URI SHOULD complete promptly >>> and not burden the requester in an inappropriate way. Upon further thought, this is just wrong. Humans need a fast response since they are impatient, but computers can be arbitrarily patient. Out it goes. [ re sending the POST argument as a web form ] > Allowing mail receivers to modify the data makes this worse for the > mail sender, who has to parse this gunk. (I'm not the only one who > thinks that HTML form posting is a legacy the web could happily leave > behind.) Perhaps, but the people who are using this use web forms all the time, notably on the two-click confirmation page, so the gunk parser is already there. The libraries they use have well debugged support for forms, both sending and receiving. I can believe that in whatever library one might use there is some way to send a blob and for the receiver to fetch it back, but in my apps using frameworks like Django or Bottle, the web form arguments show up as a dictionary for free. If we were rebuilding the web from scratch, we would no doubt do this differently, but we're not. This is a small tweak to systems that use forms now. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Nov 13 03:58:49 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B1F129494; Sun, 13 Nov 2016 03:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tX3ZITQ0RbbT; Sun, 13 Nov 2016 03:58:46 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74FB11294B7; Sun, 13 Nov 2016 03:58:46 -0800 (PST) Received: from dhcp-9b02.meeting.ietf.org (unknown [31.133.155.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F2543509B6; Sun, 13 Nov 2016 06:58:44 -0500 (EST) From: Sean Leonard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Nov 2016 20:58:45 +0900 Message-Id: <84018609-AEB2-4B1C-A386-65405F1D1AA5@seantek.com> To: IETF Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: art@ietf.org Subject: [art] ABNF drafts X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 11:58:47 -0000 Hello apps-discuss (and ART): The DISPATCH chairs asked me to post here. My co-authors (Paul Kyzivat and Chris Newman) and I have created a few = drafts to improve upon ABNF for IETF use. These are: draft-seantek-abnf-more-core-rules-07 Comprehensive Core Rules and References for ABNF *** This document extends the base definition of ABNF (Augmented Backus- Naur Form) to include a reference syntax, along with core rules that provide comprehensive support for certain symbols related to ASCII. draft-seantek-constrained-abnf Constrained ABNF *** This document extends the base definition of ABNF (Augmented Backus- Naur Form) to express a rule that is constrained by another rule. If a rule B is constrained by rule A, then every production generated by rule B must also be generated by rule A. By creating subordinate production forms, ABNF-using specifications can formally denote the relationship between a general rule and specific subsets of that rule, while preserving ABNF's context-free nature. draft-seantek-unicode-in-abnf-02 Unicode in ABNF *** This experimental document adds support for Unicode strings in ABNF (Augmented Backus-Naur Form), and provides certain symbols related to Unicode code point ranges. These drafts are being discussed on abnf-discuss@, but since that is a = fairly light mailing list, I would ask other participants to take a look = and provide any feedback on these items. They are not ready for = DISPATCHing yet, but we would like to keep them moving. Regards, Sean= From nobody Thu Nov 17 00:05:56 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD511295FC for ; Thu, 17 Nov 2016 00:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGIsi5sIWJpT for ; Thu, 17 Nov 2016 00:05:53 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BEE1294C7 for ; Thu, 17 Nov 2016 00:05:52 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id c47so124747163qtc.2 for ; Thu, 17 Nov 2016 00:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=J6a7GOt3/7e6wUmGWqxFE4RBJEkz6GNSbEDIa263EzU=; b=ENx4UJSrtM/zbpoxfjBdQ/+r1SWWB0X9BFQW5ewzZM8suQJU8u01LLG4gJiUcfCZ3G iTlQeJ2Zt+7nESYK2LYwcaqCpES9RqPB7FDuxjgWbrCKzjOOrDHipqAnSezlF4xsO0zT oP2a9A/DLZ61IMSspbAqGoHVEwpTqZ5uC7aWwzBzNoTck+iSAd7sMCAHF0X8xVibf5Sp kW+CyiTUrOEC5CCO47aSAt1XXVO8QbNPGR5ChEKlopTtRKLHDW50qVya0xDl+sxSnidG W4CZDHGirHidTG0zKje04M0uwAGCnM73vggfXsENBQu97ZDHV2wrU77Mwzhj2JzsyJoc LNaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=J6a7GOt3/7e6wUmGWqxFE4RBJEkz6GNSbEDIa263EzU=; b=U6gaEWeB3DPP2WbwlglaN0K7B0XwE+EhyTnGLd+wHucElQeg4mOV6oAo8Atiit11Bj t8cTDwyiO7OohcMsGh9QU/rAzQgB2OlXUZc+39CZ1kKxVJRsOE+LsNrUGMQc4INcuOx5 LnT/HRzdWFs9OqPlgtETnPcLIJMapCZLrhRxX42xqUBMWSa4I5vAbbGkMjrUt8ZMjpCm THtLDbX2WnBW1QD2D7y6x8GHLYMPq8veZMivGdw+TDJ5ToxC3MfmdtQfRtDPQ7+TtM0c 9wNz+YtDcHN3mSswjIqpq3A0/DcU8q/M/5+BU/+idTOCupN2B086cyn/OcX2DWhuwzb5 2p7w== X-Gm-Message-State: AKaTC03NNhvyxMoBzaLXOrU7hlrdGQPFHCG/diBFqVSBqmQNgUMXwse1o4SsYppCNK2dyCnY+9TrBz4v29bdGQ== X-Received: by 10.200.44.27 with SMTP id d27mr1125338qta.278.1479369951844; Thu, 17 Nov 2016 00:05:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 17 Nov 2016 00:05:51 -0800 (PST) From: Martin Thomson Date: Thu, 17 Nov 2016 17:05:51 +0900 Message-ID: To: "gen-art@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [art] Please dispatch draft-thomson-avtcore-sdp-uks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:05:55 -0000 We had a pretty constructive discussion about this in avtmumble today and the conclusion was that this was something we should look at. The general sense there was that this belonged with RFC 4572 (not part of the update, don't panic) in MMUSIC, but I observed that there are zero SDP changes in the document. Maybe this group can help. For those not present this morning, we described an extremely narrow attack on the use of RFC 4572. The draft explains the attack; and defines mitigations. From nobody Thu Nov 17 00:11:18 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE51129658 for ; Thu, 17 Nov 2016 00:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnrYeIibwHD7 for ; Thu, 17 Nov 2016 00:11:13 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABCF12966C for ; Thu, 17 Nov 2016 00:11:13 -0800 (PST) Received: from [10.0.2.251] ([104.200.151.48]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAH8B93p047202 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Nov 2016 02:11:11 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [104.200.151.48] claimed to be [10.0.2.251] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (14B100) In-Reply-To: Date: Thu, 17 Nov 2016 17:11:08 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <5F011AFF-AB1F-40C4-B29C-2444D0EFDB97@nostrum.com> References: To: Martin Thomson Archived-At: Cc: "gen-art@ietf.org" Subject: Re: [art] Please dispatch draft-thomson-avtcore-sdp-uks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:11:17 -0000 Looks is like this went to Gen-art. Did you mean to send to dispatch? Ben. > On Nov 17, 2016, at 5:05 PM, Martin Thomson wro= te: >=20 > We had a pretty constructive discussion about this in avtmumble today > and the conclusion was that this was something we should look at. The > general sense there was that this belonged with RFC 4572 (not part of > the update, don't panic) in MMUSIC, but I observed that there are zero > SDP changes in the document. Maybe this group can help. >=20 > For those not present this morning, we described an extremely narrow > attack on the use of RFC 4572. The draft explains the attack; and > defines mitigations. >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art From nobody Thu Nov 17 00:50:47 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F0612965E for ; Thu, 17 Nov 2016 00:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyYxx3SR_1Xb for ; Thu, 17 Nov 2016 00:50:44 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD6F1295EA for ; Thu, 17 Nov 2016 00:50:44 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id l8so17892086iti.1 for ; Thu, 17 Nov 2016 00:50:44 -0800 (PST) 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; bh=43PxRYOjuEJz3vtCUrbLWhkzkwFzl4Jtn9p49Voffcs=; b=N74NxmMhI0ewCYfqydRiNspcI5oCg08L//ivl51SR3pNVDaqSPGts9XGOGK8JUwrzX BH+pcK6E1nGf9JmwMrVJ53zuLI2pv4SSvcWXjd6HgUHVUfqAFbD+xhS14bnldEyYwmVO OvB8BksCtC0cPh5cL6vfw3VoogpxNC+3tIQ+BodsUR3Jd3MV96dmIq0oP+g3i90L8wab RAkmwPIBsvqqXuxPyDuCbiB2J+gPmqFnfURP/QEzp3kJhy1e1HuaNM8VPDBcWbeFFUQJ Sk7kwIDwG3Z5VpFjklh4mn8BsOcz5y7op3L/G2KQ5NuMOs6NaP21x8wEmxC1hXUfLSP6 kr7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=43PxRYOjuEJz3vtCUrbLWhkzkwFzl4Jtn9p49Voffcs=; b=FvSwF+OPK16WSdtCyYb4+3D3MrpsrdV1g/+3rcFf3qIJHppxh4BlSfKlf+S/ex+LYQ mJf4uxuR42IkOsLlf8aGrnusHjIuWRQOM3InZEXrA6g/0fdKwM39c5lIzoyvM5/TvpnK BrYixlb0ELVidxUMqqcQjK7ldtNriD6vlt9yUxDBPtuqO2lxeDnUN7Id4evH7PFLVmgb ky5E/O+TEj0k9uMdsP0df648rFRVLbA9ilzboDrorTW6AwD5BZ5GzTwlveH0zPUdPckn N8naUAAl1KOpbiio06GFztOJddnBhbr7Zz29rJOLht0G4zVHvs/U3Jgc+BMBm81F6Xjv MKJQ== X-Gm-Message-State: AKaTC02yx0SBeVy05GwzfIdgRbXKWCAYzLTv5HUpq/ZZXBHDirF/RHe0ygrUF3wA6CLfwT9Swx1Jdw6r70eM3g== X-Received: by 10.202.180.11 with SMTP id d11mr705588oif.55.1479372643435; Thu, 17 Nov 2016 00:50:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.47.243 with HTTP; Thu, 17 Nov 2016 00:50:42 -0800 (PST) In-Reply-To: <5F011AFF-AB1F-40C4-B29C-2444D0EFDB97@nostrum.com> References: <5F011AFF-AB1F-40C4-B29C-2444D0EFDB97@nostrum.com> From: Mary Barnes Date: Thu, 17 Nov 2016 02:50:42 -0600 Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=001a113ce750e70c6505417b4888 Archived-At: Cc: "gen-art@ietf.org" , Martin Thomson Subject: Re: [art] Please dispatch draft-thomson-avtcore-sdp-uks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:50:46 -0000 --001a113ce750e70c6505417b4888 Content-Type: text/plain; charset=UTF-8 It went to ART per the footer. I'm not sure why it's gen-art for the name though - I'd seen that before when I sent something and just thought I had funked something up in my contacts. But, I agree that maybe this ought to have gone to DISPATCH. Mary. On Thu, Nov 17, 2016 at 2:11 AM, Ben Campbell wrote: > Looks is like this went to Gen-art. Did you mean to send to dispatch? > > Ben. > > > On Nov 17, 2016, at 5:05 PM, Martin Thomson > wrote: > > > > We had a pretty constructive discussion about this in avtmumble today > > and the conclusion was that this was something we should look at. The > > general sense there was that this belonged with RFC 4572 (not part of > > the update, don't panic) in MMUSIC, but I observed that there are zero > > SDP changes in the document. Maybe this group can help. > > > > For those not present this morning, we described an extremely narrow > > attack on the use of RFC 4572. The draft explains the attack; and > > defines mitigations. > > > > _______________________________________________ > > art mailing list > > art@ietf.org > > https://www.ietf.org/mailman/listinfo/art > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --001a113ce750e70c6505417b4888 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It went to ART per the footer.=C2=A0 I'm not sure why = it's gen-art for the name though - I'd seen that before when I sent= something and just thought I had funked something up in my contacts.=C2=A0=

But, I agree that maybe this ought to have gone to DISP= ATCH. =C2=A0

Mary.

On Thu, Nov 17, 2016 a= t 2:11 AM, Ben Campbell <ben@nostrum.com> wrote:
Looks is like this went to Gen-art. Did you mean to se= nd to dispatch?

Ben.

> On Nov 17, 2016, at 5:05 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> We had a pretty constructive discussion about this in avtmumble today<= br> > and the conclusion was that this was something we should look at.=C2= =A0 The
> general sense there was that this belonged with RFC 4572 (not part of<= br> > the update, don't panic) in MMUSIC, but I observed that there are = zero
> SDP changes in the document.=C2=A0 Maybe this group can help.
>
> For those not present this morning, we described an extremely narrow > attack on the use of RFC 4572.=C2=A0 The draft explains the attack; an= d
> defines mitigations.
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art

_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art

--001a113ce750e70c6505417b4888-- From nobody Thu Nov 17 01:10:54 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBF9129662 for ; Thu, 17 Nov 2016 01:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUG8mWiqb-k5 for ; Thu, 17 Nov 2016 01:10:51 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE901295AB for ; Thu, 17 Nov 2016 01:10:51 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id n21so209977845qka.3 for ; Thu, 17 Nov 2016 01:10:51 -0800 (PST) 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; bh=nvwKldrG/FiZTB5VWfEmhsD6Drrp7n+5GpHeacFK34I=; b=ybDWFrfS+Dc+aowKEV07eHO6/8uHbaXqVwanQEreS5O4nlCIO1yusxeAWi7iD9Ycnu bXkuMY6VCe8Pj6r0/jZSTXmn80KbLfoBKgG6uNx1KktNUCE4YMvbv2XAQTTCZeVVyX/G w8qAa2apyAxcR75pSnjpyIUf7gY0O2wtEGKI4Z7YahvNvl+kj4k++L08kTaZYJo9Dfrr /huVTwfnfkH1IukrWeOhr1pO09AcPhZjZtetZc518NL6kk3liJmu64sQsn92+bFp6nb5 lDUTr4UUghcqVMg5t31pC1W8KWzBrMkAtMicg7IltJjFjAQwRlAntG+fLHF95KlJCa/Y NnoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nvwKldrG/FiZTB5VWfEmhsD6Drrp7n+5GpHeacFK34I=; b=KKB94raMWRUYTfbX10nYnkf/4aLpWwSh8LQfPK/OhNAbcCijElWS0As0CqCw0RArMa xV0Q+ZNKcnzHSfKJ6TtOeOvfJ1AcjHUSY1oxp2jjw6sYMkt/0nMpe9FZHpD5WoEZ5KLE g0ymF4OQZIZ9RnqgcAK/gijwVvoGJEDs5TU9euqRzVxHf8sh5hT/xgTuGpwOSQbcPQG+ btT37o4p6cpXwQQ5MVGwzjqhiHWtrp5/yoenDcDmtd5ZUC+QdQoABbMOyLXu0wXKAaCI 9LfYyjrilJ/ca9wr0BvKFLMKJFPMW20cznk79v/muJINkS8mxYucOe1881F8qYt7WK1A AM/Q== X-Gm-Message-State: AKaTC01JY+AQ3fruhZebIiBhUvZL7TVYl+hGocbdndkyV9YMDbMsL8Iu1RUTbv1wi3CxiO3wu2HfiLObjqAIYA== X-Received: by 10.55.12.2 with SMTP id 2mr2011545qkm.68.1479373850405; Thu, 17 Nov 2016 01:10:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 17 Nov 2016 01:10:49 -0800 (PST) Received: by 10.140.85.7 with HTTP; Thu, 17 Nov 2016 01:10:49 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 17 Nov 2016 18:10:49 +0900 Message-ID: To: ART Area Content-Type: multipart/alternative; boundary=001a114c5c9ed7f50e05417b90cf Archived-At: Subject: Re: [art] Please dispatch draft-thomson-avtcore-sdp-uks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 09:10:53 -0000 --001a114c5c9ed7f50e05417b90cf Content-Type: text/plain; charset=UTF-8 Apologies for the misdirected request. I will find the correct list. I have already corrected my contact book (which someone else polluted, and gmail helpfully remembered). On 17 Nov 2016 5:05 PM, "Martin Thomson" wrote: > We had a pretty constructive discussion about this in avtmumble today > and the conclusion was that this was something we should look at. The > general sense there was that this belonged with RFC 4572 (not part of > the update, don't panic) in MMUSIC, but I observed that there are zero > SDP changes in the document. Maybe this group can help. > > For those not present this morning, we described an extremely narrow > attack on the use of RFC 4572. The draft explains the attack; and > defines mitigations. > --001a114c5c9ed7f50e05417b90cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Apologies for the misdirected request. I will find the corre= ct list.=C2=A0 I have already corrected my contact book (which someone else= polluted, and gmail helpfully remembered).


On 17 Nov 2016 5:= 05 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
We had a pretty constructive discussion about th= is in avtmumble today
and the conclusion was that this was something we should look at.=C2=A0 The=
general sense there was that this belonged with RFC 4572 (not part of
the update, don't panic) in MMUSIC, but I observed that there are zero<= br> SDP changes in the document.=C2=A0 Maybe this group can help.

For those not present this morning, we described an extremely narrow
attack on the use of RFC 4572.=C2=A0 The draft explains the attack; and
defines mitigations.
--001a114c5c9ed7f50e05417b90cf-- From valzho@outlook.com Tue Nov 15 22:29:44 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483831296A9 for ; Tue, 15 Nov 2016 22:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04e1ja42aj_H for ; Tue, 15 Nov 2016 22:29:42 -0800 (PST) Received: from COL004-OMC3S10.hotmail.com (col004-omc3s10.hotmail.com [65.55.34.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64AF21296A8 for ; Tue, 15 Nov 2016 22:29:42 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com ([65.55.34.137]) by COL004-OMC3S10.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 15 Nov 2016 22:29:41 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=waOA+vldLIz0kFA8LjAzEEeajKI95mMwV0cFrIECFqw=; b=iRI2ZhGsSNjwjn5PHNPJmoPvpVC6TPxHT6soZctd2r51GDTDzn8oULIvGKvrqgo0WyzhiaGNuWVWGYBQNONsR6uhTxio2XZuLKUa6+6iKppZCCIqNBIFHzgsRNxxrdPVeJM8DMDt9R42mtC+3JtP7kDUoX+xdBBIlh0SOzhsmarK8zPaZrbVIibbZCUrdFTleyHidnTSmpS0PaQxlPgCIAulH6co1JGEFJUakkkdn/i+p44KrtSuwkXeNxfjJh/oPqOqAX+Tn68d0RKfFrzuYZBFvB4KrVCh7cr5WZWkbCYQ7QqQuYrTojWC74W3jnN7lBXMh8CCefeN6JommuJyaQ== Received: from BL2NAM02FT045.eop-nam02.prod.protection.outlook.com (10.152.76.54) by BL2NAM02HT215.eop-nam02.prod.protection.outlook.com (10.152.76.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.5; Wed, 16 Nov 2016 06:29:41 +0000 Received: from DM5PR16MB1450.namprd16.prod.outlook.com (10.152.76.56) by BL2NAM02FT045.mail.protection.outlook.com (10.152.77.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.5 via Frontend Transport; Wed, 16 Nov 2016 06:29:40 +0000 Received: from DM5PR16MB1450.namprd16.prod.outlook.com ([10.173.211.8]) by DM5PR16MB1450.namprd16.prod.outlook.com ([10.173.211.8]) with mapi id 15.01.0721.013; Wed, 16 Nov 2016 06:29:40 +0000 From: Darren Doyle To: "art@ietf.org" Thread-Topic: Question regarding RFC 6901 Thread-Index: AQHSP9LPsZYSv3+PoEu/7pjuY2rUPA== Date: Wed, 16 Nov 2016 06:29:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:7031; Count:34 x-ms-exchange-messagesentrepresentingtype: 1 x-incomingheadercount: 34 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; BL2NAM02HT215; 5:gWF9woYT1pB+hrqMrVUqRUd8x5fY27N/+rcIWfylWZ0PJDT+tun+LAuQAVhBxfq7uT63iN5Lg+S3AqJZWjR/Lrae7evjuFzeyz2YUFDAAWNrZ1wflDZ9xARdUCO6FGUIezivOBMwBl5hI/rMohLkig==; 24:iTnWzswsF1g3KBy13hE9sxKKKNwZ9y3UhVH4Vg2oXsHnwqtPydwZPwLIgS2qEurII+6QuURyQHeR2FH3JW6pbtU52vCA6jsLEJC3nTmQs68=; 7:rpGGWypzQ5g4uR7iwRX3baObCE72zqdQqowyjdO2bUOAo8MfVpFBCHz3OzMI6O49M0qIEVO55OAnzjh+/A+PqG0SUF0FHiLccp124TiStdHRtsRFVvY2bM+OwAzFAcPH2tQ3aNglHSYlz8Qm26g2BDpT+WXzRpw1oFnAwkjQoZ4HHsVlGEaeMIfESxieiWKJGo66PFRjMa1CK4Fczg8au1gqDwxfZBCnTg5Fi6me4t2fV9g61xzRhk1Fh+JPOz4JGqaOnEGGIfW7I9Xx6zloecEatJLlkcIQQ5hJ6W5ECWK+eJbKCPcbGihZYtiyod16KNmQhhBTIznfTgt3JmMu9ZSR4in6RFHx6DVZqXv2pqs= x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2NAM02HT215; H:DM5PR16MB1450.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 68d2128f-20a7-487a-c804-08d40de9f135 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(1603103113)(1603101340)(1601125047); SRVR:BL2NAM02HT215; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:BL2NAM02HT215; BCL:0; PCL:0; RULEID:; SRVR:BL2NAM02HT215; x-forefront-prvs: 01283822F8 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB14509019BE97136178A70FEDDABE0DM5PR16MB1450namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2016 06:29:40.3577 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT215 X-OriginalArrivalTime: 16 Nov 2016 06:29:41.0969 (UTC) FILETIME=[D06D9410:01D23FD2] Archived-At: X-Mailman-Approved-At: Thu, 17 Nov 2016 13:00:51 -0800 Subject: [art] Question regarding RFC 6901 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 06:30:41 -0000 --_000_DM5PR16MB14509019BE97136178A70FEDDABE0DM5PR16MB1450namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBqdXN0IHdhbnRlZCB0byBzdWJtaXQgc29tZXRoaW5nIGZvciBjb25zaWRlcmF0aW9uIHJlZ2Fy ZGluZyB0aGUgSlNPTiBQb2ludGVyIHNwZWNpZmljYXRpb24gKFJGQyA2OTAxKS4NCg0KQ3VycmVu dGx5IHRoZSBzcGVjaWZpY2F0aW9uIG1ha2VzIG5vIGNvbnNpZGVyYXRpb24gZm9yIEphdmFTY3Jp cHQgb2JqZWN0cyB3aGljaCBjb250YWluIG51bWVyaWNhbCBwcm9wZXJ0eSBrZXlz4oCUaW4gYWxs IG9mIHRoZSBwYXRoIGV4YW1wbGVzIG9mIHN1Y2guDQoNCkNvbnNpZGVyIHRoZSBmb2xsb3dpbmcg cGF0aDogIi9mb28vMSINCg0KSXQgaXMgdW5jbGVhciB3aGV0aGVyIHRoaXMgc2hvdWxkIHBvaW50 IHRvIHRoaXMgdGFyZ2V0OiB7ICJmb28iOiBbbnVsbCwgInRhcmdldCJdIH0NCm9yIHRvIHRoaXMg dGFyZ2V0OiB7ICJmb28iOiB7ICIxIjogInRhcmdldCIgfSB9DQoNCkJvdGggYXJlIGFjY2VwdGFi bGUgSlNPTi4gSSdtIGZpbmRpbmcgdGhhdCBwYXJzaW5nIGVuZ2luZXMgZ2VuZXJhbGx5IGFyZSBh YmxlIHRvIGZpbmQgYW4gZXhpc3RpbmcgcGF0aCwgYnV0IGFkZGluZyBkYXRhIHRvIGEgbm9uLWV4 aXN0ZW50IHBhdGggaXMgd2hlcmUgdGhpbmdzIHN0YXJ0IHRvIGJyZWFrIGRvd24uDQoNClBST1BP U0VEIFNPTFVUSU9OOg0KDQpVc2UgdGhlIHNsYXNoIC8gdG8gYWx3YXlzIGluZGljYXRlIGFuIG9i amVjdCByZWZlcmVuY2UsIGFuZCB0aGUgY29sb24gOiB0byBhbHdheXMgaW5kaWNhdGUgYW4gYXJy YXkgcmVmZXJlbmNlLiBXaXRoIHRoaXMgaW4gbWluZDoNCg0KDQogICogICAiL2Zvby8xIiBldmFs dWF0ZXMgdG8gIHsgImZvbyI6IHsgIjEiOiAidGFyZ2V0IiB9IH0NCiAgKiAgICIvZm9vOjEiIGV2 YWx1YXRlcyB0byB7ICJmb28iOiBbIG51bGwsICJ0YXJnZXQiIF0gfQ0KDQpJZiBhIGNvbG9uIGlz IG5lZWRlZCwgaXQgY2FuIHNpbXBseSBiZSBlc2NhcGVkIGFzIHRoZSBvdGhlciBzcGVjaWFsIGNo YXJhY3RlcnMgd2l0aCB+MiBzdWNoIHRoYXQNCg0KDQogICogICAiL2Zvby8xfjJiYXIiIGV2YWx1 YXRlcyB0byAgeyAiZm9vIjogeyAiMTpiYXIiOiAidGFyZ2V0IiB9IH0NCg0KDQpUaGFuayB5b3Ug Zm9yIHlvdXIgY29uc2lkZXJhdGlvbiENCkRhcnJlbiBEb3lsZQ0K --_000_DM5PR16MB14509019BE97136178A70FEDDABE0DM5PR16MB1450namp_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSBqdXN0IHdhbnRlZCB0byBzdWJt aXQgc29tZXRoaW5nIGZvciBjb25zaWRlcmF0aW9uIHJlZ2FyZGluZyB0aGUgSlNPTiBQb2ludGVy IHNwZWNpZmljYXRpb24gKFJGQyA2OTAxKS4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkN1cnJlbnRseSB0aGUgc3BlY2lmaWNhdGlvbiBtYWtlcyBu byBjb25zaWRlcmF0aW9uIGZvciBKYXZhU2NyaXB0IG9iamVjdHMgd2hpY2ggY29udGFpbiBudW1l cmljYWwgcHJvcGVydHkga2V5c+KAlGluIGFsbCBvZiB0aGUgcGF0aCBleGFtcGxlcyBvZiBzdWNo LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+Q29uc2lkZXIgdGhlIGZvbGxvd2luZyBwYXRoOiAmcXVvdDsvZm9vLzEmcXVvdDsmbmJzcDs8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pkl0IGlzIHVuY2xlYXIgd2hldGhlciB0aGlzIHNob3VsZCBwb2ludCB0byB0aGlzIHRhcmdldDog eyAmcXVvdDtmb28mcXVvdDs6IFtudWxsLCAmcXVvdDt0YXJnZXQmcXVvdDtdIH08L2Rpdj4NCjxk aXYgY2xhc3M9IiI+b3IgdG8gdGhpcyB0YXJnZXQ6IHsgJnF1b3Q7Zm9vJnF1b3Q7OiB7ICZxdW90 OzEmcXVvdDs6ICZxdW90O3RhcmdldCZxdW90OyB9IH08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJvdGggYXJlIGFjY2VwdGFibGUgSlNP Ti4gSSdtIGZpbmRpbmcgdGhhdCBwYXJzaW5nIGVuZ2luZXMgZ2VuZXJhbGx5IGFyZSBhYmxlIHRv IGZpbmQgYW4NCjxpIGNsYXNzPSIiPmV4aXN0aW5nPC9pPiBwYXRoLCBidXQgYWRkaW5nIGRhdGEg dG8gYSBub24tZXhpc3RlbnQgcGF0aCBpcyB3aGVyZSB0aGluZ3Mgc3RhcnQgdG8gYnJlYWsgZG93 bi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiIGNsYXNzPSIiPlBST1BPU0VEIFNPTFVUSU9OOjwvYj48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlVzZSB0aGUgc2xhc2ggLyB0 byA8aSBjbGFzcz0iIj5hbHdheXM8L2k+IGluZGljYXRlIGFuIG9iamVjdCByZWZlcmVuY2UsIGFu ZCB0aGUgY29sb24gOiB0bw0KPGkgY2xhc3M9IiI+YWx3YXlzPC9pPiBpbmRpY2F0ZSBhbiBhcnJh eSByZWZlcmVuY2UuIFdpdGggdGhpcyBpbiBtaW5kOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8dWwgY2xhc3M9Ik1haWxPdXRsaW5l Ij4NCjxsaSBjbGFzcz0iIj4mcXVvdDsvZm9vLzEmcXVvdDsgZXZhbHVhdGVzIHRvICZuYnNwO3sg JnF1b3Q7Zm9vJnF1b3Q7OiB7ICZxdW90OzEmcXVvdDs6ICZxdW90O3RhcmdldCZxdW90OyB9IH08 L2xpPjxsaSBjbGFzcz0iIj4mcXVvdDsvZm9vOjEmcXVvdDsgZXZhbHVhdGVzIHRvIHsgJnF1b3Q7 Zm9vJnF1b3Q7OiBbIG51bGwsICZxdW90O3RhcmdldCZxdW90OyBdIH08L2xpPjwvdWw+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklm IGEgY29sb24gaXMgbmVlZGVkLCBpdCBjYW4gc2ltcGx5IGJlIGVzY2FwZWQgYXMgdGhlIG90aGVy IHNwZWNpYWwgY2hhcmFjdGVycyB3aXRoIH4yIHN1Y2ggdGhhdDwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8dWwgY2xhc3M9Ik1haWxP dXRsaW5lIj4NCjxsaSBjbGFzcz0iIj4mcXVvdDsvZm9vLzF+MmJhciZxdW90OyBldmFsdWF0ZXMg dG8gJm5ic3A7eyAmcXVvdDtmb28mcXVvdDs6IHsgJnF1b3Q7MTpiYXImcXVvdDs6ICZxdW90O3Rh cmdldCZxdW90OyB9IH08L2xpPjwvdWw+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5UaGFuayB5b3UgZm9yIHlvdXIgY29uc2lkZXJhdGlvbiE8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+RGFycmVuIERveWxlPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR16MB14509019BE97136178A70FEDDABE0DM5PR16MB1450namp_-- From nobody Fri Nov 18 10:11:25 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD45212949A for ; Fri, 18 Nov 2016 10:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9_r0fV53SN3 for ; Fri, 18 Nov 2016 10:11:21 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C571129423 for ; Fri, 18 Nov 2016 10:11:21 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id g23so54369095wme.1 for ; Fri, 18 Nov 2016 10:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=w5zpjRF+S4bV10FBHysfxUU0rtff2IbzNOG/9kHrYqc=; b=nFr8028LmI+FLGKBx9sfhu3jm+FegCqLHvbbLNM5qizjY2Y+HiaKNVSXtF+z9ZxG1J DtSzcU21BHc6/ZH6JPmMVMMmCm54dbnEbOJC1SY6KBpEF8nnXTRGo9YBLKx2YdL/Hp19 nZRk7IUtXKnPJDeqLo83u3JYxuggavjvEF5JPG0ooGBHwXrjURlg1Yo6DYNVBt4A4YHj QNla4Yf4bt3kg7gwfLdqyMA3wjxk8UECGsDJivT/mHYiVX8Ng19XnX4Ma7Jo+3lSjMAu /G0CpoHVRtkV0xl9bodJ6346J2aZoGm7adNOkKVS8W3uPUJNtaCjhwXVuBwaqCHOSSOY Nmcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=w5zpjRF+S4bV10FBHysfxUU0rtff2IbzNOG/9kHrYqc=; b=AtmDvbRytfXUY3KJ7KpgGBno42wmHIM6ZWI1r4sxKO+FbVNhs9yoZ8KcQpq/cK8qTj FgLxIWxiz74/0OTDWvwkESmvz2jY/UD1IeRf1aPnakzGy4QYVxubuACgj9I5KDnSL4Mw ZWHaIXSmbvCKxgrdNjDKyV1RevbYqrhJjGuXdfkYjk5w8+ycoOSTCZth9naKaLX5lza1 AHAuajBWYBi6jhBMDCs1NWYHn6iP6Mwn3WeSF4wKtB8j5xXD7uGcmDKUExGePr2tXzRr WKYY4OHwDzq+G6n2Cvtbv+krMrClA6jW5+8zs/CrB2O/SBp2NcGOSvZCbc/PECxqkdNG 7+aw== X-Gm-Message-State: AKaTC03ksoe4zEZjsg0z0uu83E1TI7L92+PDIdw214iryqMv1goqP6SSdOHAvx6MDrDsozPzh7jr48GFqwPzAQ== X-Received: by 10.28.218.129 with SMTP id r123mr1102585wmg.137.1479492679843; Fri, 18 Nov 2016 10:11:19 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.3.41 with HTTP; Fri, 18 Nov 2016 10:11:19 -0800 (PST) From: Phillip Hallam-Baker Date: Fri, 18 Nov 2016 13:11:19 -0500 X-Google-Sender-Auth: 7NDU-iWoAfntcuXGeYBw5i-lhxE Message-ID: To: art@ietf.org Content-Type: multipart/alternative; boundary=001a114697bca145540541973b51 Archived-At: Subject: [art] What is the best current reference for using SRV with Web services? X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 18:11:24 -0000 --001a114697bca145540541973b51 Content-Type: text/plain; charset=UTF-8 I asked this a couple of years back and people returned material on protocols that have implemented pretty much every single approach possible. Before I commit to code, I was wondering if anything new was available. The basic concept here is that we have a Web Service "mmm" and we wish to make use of the DNS for discovery in a fashion that is as compatible with existing infrastructure as possible and reasonably performant. Web Services are not usually like Web Browsing. Latency is not an issue. This is the structure that I am looking to fill to describe a Service: public class ServiceDescription { public List Entries = new List(); public ServiceEntry Default ; And here are the service entries public class ServiceEntry { public virtual string Address; public virtual int Port= -1; public virtual int Priority ; public virtual int Weight; /// URI path to connect to (will default to /.well-known/<Service> public virtual string Path; public virtual TransportSecurity TransportSecurity = TransportSecurity.UNKNOWN; public virtual Transport Transport = Transport.UNKNOWN; public virtual string URI ; public virtual string UDF ; } The objective is to encode the data in some combination of DNS records. Right now I am looking to follow the CALDAV approach and use a combination of SRV and TXT records: https://tools.ietf.org/html/rfc6764 I have an SRV prefix assigned for mmm. So let us say that my DNS configuration is _mmm._tcp.prismproof.org SRV 1 100 80 host1.prismproof.org _mmm._tcp.prismproof.org SRV 1 100 80 host2.prismproof.org _mmm._tcp.prismproof.org TXT "policy=http://prismproof.org/policy/s13/ " "udf=M23kj-qewjh-qwdwe-iei3d" host1.prismproof.org A 10.0.0.1 _mmm._tcp.host1.prismproof.org TXT "path=/mesh/" host2.prismproof.org A 10.0.0.1 Assume the DNS settings are protected using DNSSEC. I have put a security policy attribute in this example but it could equally well be a statement 'also supports QUIC'. HTTP really is not ideal for a Web Service transport. QUIC plus a very minimal presentation layer, basically the ability to specify the Web Service Endpoint would be better. So obviously, the first step in resolution is to resolve the SRV record and the associated TXT records. The TXT record for host1.prismproof.org takes priority over the service record that sets defaults. So we have two services with the following attributes: host1.prismproof.org:80 "policy=.. udf=.. path=/mesh/" host2.prismproof.org:80 "policy=.. udf=.. " These correspond to the following Web Service Endpoints: http://host1.prismproof.org:80/mesh/ http://host2.prismproof.org:80/.well-known/mmm/ The reason for changing the DNS address in the URI to the host name is a little involved. Basically, not changing the DNS address would render large amounts of support library code unusable because they are hardwired to the platform DNS resolver. Providing a supplemental DNS resolver just to do SRV and TXT lookup is a lot easier than replacing the platform resolver. The downside to this is that we have in effect performed an internal HTTP redirect. And this is going to mess things up for TLS unless we require prismproof.org as the subjectAltName. Fortunately, most libraries seem to allow apps to override the cert checking so this is not a problem on my systems. It might be an issue with some scripting level languages though. Another reason for adopting this approach is that the security policy might say 'just use this certificate and don't check validity'. Which would be nonsense for a Web site but might make a lot of sense for a lightbulb or other IoT device *Alternative approaches* The TXT records could be replaced with a new DNS record but this does not actually help anything unless that is done for the purpose of making prefixes work with wildcards and DNSSEC. The DNS URI record has been proposed but it offers no practical advantage over the TXT approach and is limited to expressing path attributes. For DNSSEC to provide any value to me, I need to be able to put a security policy in there. I also want to be able to advertise alternative transports. At present, the policy is specified as a url and fingerprint. This allows the policy to be specified as a document on a Web site. It could also be a DNS record. Obviously, some very simple policies such as 'must use TLS' could be encoded in the DNS. The simplest policies could be specified in DANE. But as with the use of URI records, that doesn't seem to offer any advantage over putting the same information in the TXT record. --001a114697bca145540541973b51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I a= sked this a couple of years back and people returned material on protocols = that have implemented pretty much every single approach possible. Before I = commit to code, I was wondering if anything new was available.
The basic concept here is that we hav= e a Web Service "mmm" and we wish to make use of the DNS for disc= overy in a fashion that is as compatible with existing infrastructure as po= ssible and reasonably performant. Web Services are not usually like Web Bro= wsing. Latency is not an issue.

This is the structure that I am looking t= o fill to describe a Service:

=C2=A0 =C2=A0 public class ServiceDescription {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 public List<ServiceEntry> Entries =3D new= List<ServiceEntry>();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public S= erviceEntry Default ;

<= div style=3D"font-size:small">And here are the service entries

=C2=A0 =C2=A0 public class Serv= iceEntry {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public virtual string = Address;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public virtual int Port= =3D -1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public virtual int Priori= ty ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public virtual int Weight;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /// <summary>= URI path to connect to (will default to /.well-known/&lt;Service&gt= ;</summary>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public virtual= string Path;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 public v= irtual TransportSecurity TransportSecurity =3D=C2=A0
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TransportSecurity.UNKNOWN;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public virtual Transport Transport =3D = Transport.UNKNOWN;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 pub= lic virtual string URI ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public virtu= al string UDF ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

<= /div>
The objective is to encode the data in some combination of DNS re= cords. Right now I am looking to follow the CALDAV approach and use a combi= nation of SRV and TXT records:


I have an SRV prefix assigned= for mmm. So let us say that my DNS configuration is=C2=A0
_mmm._tcp.prismproof.org =C2= =A0SRV 1 100 80 h= ost2.prismproof.org
_mmm._tcp.prismproof.org =C2=A0TXT "policy=3Dhttp://prismp= roof.org/policy/s13/ "
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0"udf=3DM23kj-qewjh-qwdwe-iei3d"
_mmm._tcp.host1.prismproof.org TXT "path=3D/mesh/&qu= ot;
Assume the DNS settings are protected using DNSSEC.

<= div>I have put a security policy attribute in this example but it could equ= ally well be a statement 'also supports QUIC'. HTTP really is not i= deal for a Web Service transport. QUIC plus a very minimal presentation lay= er, basically the ability to specify the Web Service Endpoint would be bett= er.


So obviously, the first ste= p in resolution is to resolve the SRV record and the associated TXT records= . The TXT record for host1.prismproof.org takes priority over the service record that se= ts defaults. So we have two services with the following attributes:

host1.prismproof.org:80 "policy=3D.. udf=3D.. path=3D/mesh/&qu= ot;
= host2.prismproof.org:80 "policy=3D.. udf=3D.. "

These correspond to the following Web Service Endpoints:


<= /div>
The reason for changing the DNS address in the URI to the host na= me is a little involved. Basically, not changing the DNS address would rend= er large amounts of support library code unusable because they are hardwire= d to the platform DNS resolver. Providing a supplemental DNS resolver just = to do SRV and TXT lookup is a lot easier than replacing the platform resolv= er.

The downside to this is that we have in effect= performed an internal HTTP redirect. And this is going to mess things up f= or TLS unless we require prismproof.org as the subjectAltName.

Fortun= ately, most libraries seem to allow apps to override the cert checking so t= his is not a problem on my systems. It might be an issue with some scriptin= g level languages though. Another reason for adopting this approach is that= the security policy might say 'just use this certificate and don't= check validity'. Which would be nonsense for a Web site but might make= a lot of sense for a lightbulb or other IoT device


Alternative approaches

The= TXT records could be replaced with a new DNS record but this does not actu= ally help anything unless that is done for the purpose of making prefixes w= ork with wildcards and DNSSEC. =C2=A0
The DNS URI record has been= proposed but it offers no practical advantage over the TXT approach and is= limited to expressing path attributes. For DNSSEC to provide any value to = me, I need to be able to put a security policy in there. I also want to be = able to advertise alternative transports.

At prese= nt, the policy is specified as a url and fingerprint. This allows the polic= y to be specified as a document on a Web site. It could also be a DNS recor= d. Obviously, some very simple policies such as 'must use TLS' coul= d be encoded in the DNS.=C2=A0

The simplest polici= es could be specified in DANE. But as with the use of URI records, that doe= sn't seem to offer any advantage over putting the same information in t= he TXT record.=C2=A0




--001a114697bca145540541973b51-- From nobody Tue Nov 22 03:45:28 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DDE1299BE for ; Tue, 22 Nov 2016 03:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocUQ-BNJsDNJ for ; Tue, 22 Nov 2016 03:45:25 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 822DE1299C3 for ; Tue, 22 Nov 2016 03:45:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1479815124; d=isode.com; s=june2016; i=@isode.com; bh=pNX90U4T7HuT2Oove/yU+9ZAp8YNriBTBlhgt6DG3xA=; 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=bD94/c3aK0j82bsx4kczc5E/UtqXzJug5l6+6sSQrr+EXY+1jD0v77FgJB4AICAg039o5S gt2ZjCqOFuNvr/m4u5fYIa7Aa1zwTmHFI8uecwSUtzxDKjjaTnWi6rR2tp0KsPnXr3LekQ CghoQvZEjZQgFrXDmA08PuxRtyPrUyI=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 22 Nov 2016 11:45:24 +0000 To: art@ietf.org From: Alexey Melnikov Message-ID: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> Date: Tue, 22 Nov 2016 11:44:36 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 11:45:27 -0000 Hi, I think the document is generally in a good state, but I have a couple of minor things to discuss: 1) In Section 4: When a file URI is produced, characters not allowed by the syntax in Section 2 SHOULD be percent-encoded as characters using UTF-8 encoding, as per [RFC3986], Section 2.5. This text is confusing. Are you trying to say that first Unicode characters are encoded in UTF-8 and then that encoding is percent encoded? 2) Section 6 doesn't include all IANA registration template fields specified in RFC 7595, Section 7.4. I would like these to be fixed before the document reaches IESG, but I don't think this needs to cause delay before starting IETF Last Call. Best Regards, Alexey From nobody Tue Nov 22 08:17:46 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3070512946D for ; Mon, 21 Nov 2016 23:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRmkNwNHICxK for ; Mon, 21 Nov 2016 23:28:46 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C18E12963E for ; Mon, 21 Nov 2016 23:28:45 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D74F622E1F3 for ; Tue, 22 Nov 2016 02:28:38 -0500 (EST) From: Mark Nottingham Content-Type: multipart/alternative; boundary="Apple-Mail=_FBE7B78E-F590-4F21-81BE-26493A558304" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: References: <147979961739.16128.13436096424751543726.idtracker@ietfa.amsl.com> To: IETF Apps Discuss Date: Tue, 22 Nov 2016 18:28:35 +1100 X-Mailer: Apple Mail (2.3251) Archived-At: X-Mailman-Approved-At: Tue, 22 Nov 2016 08:17:44 -0800 Subject: [art] Fwd: New Version Notification for draft-nottingham-rfc5988bis-02.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 07:28:49 -0000 --Apple-Mail=_FBE7B78E-F590-4F21-81BE-26493A558304 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-rfc5988bis-02.txt > Date: 22 November 2016 at 6:26:57 pm AEDT > To: "Mark Nottingham" >=20 >=20 > A new version of I-D, draft-nottingham-rfc5988bis-02.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Name: draft-nottingham-rfc5988bis > Revision: 02 > Title: Web Linking > Document date: 2016-11-22 > Group: Individual Submission > Pages: 22 > URL: = https://www.ietf.org/internet-drafts/draft-nottingham-rfc5988bis-02.txt > Status: = https://datatracker.ietf.org/doc/draft-nottingham-rfc5988bis/ > Htmlized: = https://tools.ietf.org/html/draft-nottingham-rfc5988bis-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-rfc5988bis-02 >=20 > Abstract: > This specification defines a way to indicate the relationships > between resources on the Web ("links") and the type of those > relationships ("link relation types"). >=20 > It also defines the serialisation of such links in HTTP headers with > the Link header field. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 -- Mark Nottingham https://www.mnot.net/ --Apple-Mail=_FBE7B78E-F590-4F21-81BE-26493A558304 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI.


Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-nottingham-rfc5988bis-02.txt
Date: = 22 November 2016 at 6:26:57 pm = AEDT
To: = "Mark Nottingham" <mnot@mnot.net>

A new version of I-D, draft-nottingham-rfc5988bis-02.txt
has been successfully submitted by Mark Nottingham and posted = to the
IETF repository.

Name: = = draft-nottingham-rfc5988bis
Revision: 02
Title:= = Web Linking
Document date: = 2016-11-22
Group: Individual Submission
Pages:= = 22
URL: =            https://www.ietf.org/internet-drafts/draft-nottingham-rfc5988bi= s-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-nottingham-rfc5988bis/
Htmlized:       https://tools.ietf.org/html/draft-nottingham-rfc5988bis-02<= br class=3D"">Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-rfc5988bis= -02

Abstract:
=   This specification defines a way to indicate the = relationships
  between resources on the Web = ("links") and the type of those
  relationships = ("link relation types").

  It = also defines the serialisation of such links in HTTP headers with
  the Link header field.




Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--
Mark Nottingham =   https://www.mnot.net/

= --Apple-Mail=_FBE7B78E-F590-4F21-81BE-26493A558304-- From nobody Tue Nov 22 10:16:37 2016 Return-Path: X-Original-To: art@ietf.org Delivered-To: art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6B7129AB2; Tue, 22 Nov 2016 10:16:33 -0800 (PST) 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: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147983859320.30315.16078992789846980558.idtracker@ietfa.amsl.com> Date: Tue, 22 Nov 2016 10:16:33 -0800 Archived-At: Cc: alexey.melnikov@isode.com, appsawg-chairs@ietf.org, dcrocker@bbiw.net, draft-ietf-appsawg-file-scheme@ietf.org, art@ietf.org Subject: [art] Last Call: (The file URI Scheme) to Proposed Standard X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 18:16:33 -0000 The IESG has received a request from the ART Area General Applications Working Group WG (appsawg) to consider the following document: - 'The file URI Scheme' 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 2016-12-06. 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 specifies the "file" Uniform Resource Identifier (URI) scheme, replacing the definition in RFC 1738. It defines a common syntax which is intended to interoperate across the broad spectrum of existing usages. At the same time it notes some other current practices around the use of file URIs. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Nov 22 17:18:24 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2855D129547 for ; Tue, 22 Nov 2016 17:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ryXCYbCP-hQ for ; Tue, 22 Nov 2016 17:18:21 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1710312953F for ; Tue, 22 Nov 2016 17:18:20 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id a124so18601704ioe.2 for ; Tue, 22 Nov 2016 17:18:20 -0800 (PST) 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:message-id :subject:to:cc; bh=WAyBuJYkp0dLkAo7gFx9mdV50IngeDQhPcY8GwUhoc8=; b=ew9KBU5nZi6IK8FuEXGEITkDLysEIeSkJwgDN15LYdtLvSl898h+1P0iLJ0cNu/9KQ tQq77rNed4T/kRppVNz/zf1LtIXKo9b8bE45BHyB95oWFt/kh2537xzQcJYy8277LO1+ AYbAklMSkWx45nznlWddled9P9A90rOdu1jZGz+Q26Is1X7IyF6d7CZYj2MwAB2k4/O1 /lmxxKdbNzvjI3HSjjfZPYV7UD/ZgOJalhw3vAEW1KTndNMhMJkmVzleDYjr/eUn/JQL SPV6n0R5dTp3SgBNc4NxE5Y118dOLyRs3jCVTW1L9Yy4NZhHC7p0Mpl8G0m7pYiPTMCi LyMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WAyBuJYkp0dLkAo7gFx9mdV50IngeDQhPcY8GwUhoc8=; b=V6tbl3iLdQErv13VD+OT6czP0f/KrMNvq7fJKVyEUOWlU3O2re9HfRdktf5sDMy/Bd 5wLmk66TxlftYMiIAsJ4dQ+99sD1Yp1Q+5woOyc8cxgApClLmh/oBleInc0vvoPyjEkB L4L0NboQF1C7ffeOuQp8yureXvhj/OwDzJZguXIrlVTGGadQk0vWsx0N0PZywBrU1rAE iypHM+4/SATc8mo44+R2U5+65pXsPNUfFnnSekDpXuOAa0mIydlDCgV+YTRqSFky4Ijs pM8Wx40lpvQLVo2VS47tLlcynh4eYitBZ5afYaISZkiwIy8W6doezkyn6MGnp6LxUbVK 5Jow== X-Gm-Message-State: AKaTC01jy7mex28woBpH6cWv1CWZoyCjgBW5hrszvuQ9O2LEVUfF3lcHT76tF+yWCztFn8psqSIhUx7PYEGWNA== X-Received: by 10.36.53.69 with SMTP id k66mr1034192ita.18.1479863899464; Tue, 22 Nov 2016 17:18:19 -0800 (PST) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.135.84 with HTTP; Tue, 22 Nov 2016 17:18:19 -0800 (PST) In-Reply-To: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> From: Matthew Kerwin Date: Wed, 23 Nov 2016 11:18:19 +1000 X-Google-Sender-Auth: F6mR1CXrhciRtOzuV7XMhh1Cu2A Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a114ac1a80b28710541edaa6c Archived-At: Cc: "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 01:18:23 -0000 --001a114ac1a80b28710541edaa6c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alexey, On 22 November 2016 at 21:44, Alexey Melnikov wrote: > Hi, > > I think the document is generally in a good state, but I have a couple of > minor things to discuss: > > > 1) In Section 4: > > When a file URI is produced, characters not allowed by the syntax in > Section 2 SHOULD be percent-encoded as characters using UTF-8 encoding, a= s > per [RFC3986], Section 2.5. > > This text is confusing. Are you trying to say that first Unicode > characters are encoded in UTF-8 and then that encoding is percent encoded= ? > > =E2=80=8BYeah, pretty much. @mnot originally proposed it, and I never real= ly improved on his first suggestion. It speaks to RFC 3986: "When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding [STD63]; then only those octets that do not correspond to characters in the unreserved set should be percent- encoded." Would you prefer I switched it from descriptive to imperative, like this?: "When a file URI is produced, characters not allowed by the syntax in Section 2 SHOULD be encoded using UTF-8 and percent-encoded, as per [RFC3986], Section 2.5."=E2=80=8B > > 2) Section 6 doesn't include all IANA registration template fields > specified in RFC 7595, Section 7.4. > > =E2=80=8BIt's just the 'References' that's missing, correct? In my working = draft I've added it with: "See Section 8 of this document." I think that covers it. Turns out I last substantially updated that section just before RFC 7595 was published.=E2=80=8B > > I would like these to be fixed before the document reaches IESG, but I > don't think this needs to cause delay before starting IETF Last Call. > > =E2=80=8BI can publish -14 pretty quickly once we resolve the working in Se= ction 4, if that's what you want. (Assuming we don't mind the XML upload being broken.) Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a114ac1a80b28710541edaa6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alexey,

On 22 November 2016 at 21:44, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
Hi,

I think the document is generally in a good state, but I have a couple of m= inor things to discuss:


1) In Section 4:

=C2=A0 When a file URI is produced, characters not allowed by the syntax in= Section 2 SHOULD be percent-encoded as characters using UTF-8 encoding, as= per [RFC3986], Section 2.5.

This text is confusing. Are you trying to say that first Unicode characters= are encoded in UTF-8 and then that encoding is percent encoded?


=E2=80=8BYeah, pretty much. = =C2=A0@mnot originally proposed it, and I never really improved on his firs= t suggestion.

It speaks to RFC 3986:
=

=C2=A0 =C2=A0"When a new URI scheme define= s a component that represents textual
=C2=A0 =C2=A0data consi= sting of characters from the Universal Character Set [UCS],
= =C2=A0 =C2=A0the data should first be encoded as octets according to the UT= F-8
=C2=A0 =C2=A0character encoding [STD63]; then only those = octets that do not
=C2=A0 =C2=A0correspond to characters in t= he unreserved set should be percent-
=C2=A0 =C2=A0encoded.&qu= ot;

Would you prefer I switched it from de= scriptive to imperative, like this?:

"When a = file URI is produced, characters not allowed by the syntax in Section 2 SHO= ULD be encoded using UTF-8 and percent-encoded, as per [RFC3986], Section 2= .5."=E2=80=8B

=C2=A0

2) Section 6 doesn't include all IANA registration template fields spec= ified in RFC 7595, Section 7.4.


=E2=80=8BIt's just the &#= 39;References' that's missing, correct? In my working draft I'v= e added it with:

"See Section 8 of this docum= ent."

I think that covers it.=C2=A0 Turns out I last substantially u= pdated that section just before RFC 7595 was published.=E2=80=8B

<= /div>
=C2=A0

I would like these to be fixed before the document reaches IESG, but I don&= #39;t think this needs to cause delay before starting IETF Last Call.

=E2=80=8BI can publish -14 pretty quickly o= nce we resolve the working in Section 4, if that's what you want. =C2= =A0(Assuming we don't mind the XML upload being broken.)
=
Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a114ac1a80b28710541edaa6c-- From nobody Tue Nov 22 17:23:34 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5063012950A for ; Tue, 22 Nov 2016 17:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wccRWwVhltTD for ; Tue, 22 Nov 2016 17:23:32 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431801293E4 for ; Tue, 22 Nov 2016 17:23:32 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id x23so13372312pgx.1 for ; Tue, 22 Nov 2016 17:23:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:reply-to:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=gq7eYSUdYRGfnBRNLSvYYoDIWqZmVpcgivMl+mqD1eE=; b=Renl+LUdKZ3ySglMUNNvo9ZmMucbx1u07a8BJoQ0JRsfopW9Hk4XA8jJTAlDJBjFQM 71IYl8vJrIKK5dAO9jgkWmsj4vKtKWl2pCVn8vWzIPvJMamJhVmzScWCerMfvBhuGYyT fdz+WRTPJWI2QgFv+xYHGMOpMqTUoaYi/dZZ1vn3faESeVNg4nIZEu8iRKpJW8rU9oSG 6MWsbAyOoIBqcHCroULsHc/LTT65JcpUxs49PgBJpr7kE87O19WSuctn537wJobjGm+T 2JT8z0AhQUSO698yFNWCTu6igVZ3+AlTTdjgeGtkxwfWN2t00qFBjB+r6S0TCmTk0GCQ YyEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:reply-to :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=gq7eYSUdYRGfnBRNLSvYYoDIWqZmVpcgivMl+mqD1eE=; b=dJo2+GD+CiUNxSCYT21KlQzchbG227TgfGQl5ysteyA7u1pvYpr/SddK7eOPkgHVDK rcl8oPQnUv7ZaXtKKd0vhTzOhtxq2xupQ5pXEcAlqYl60kKaltJ0WJyroR6ZONsEm6nD fTzXyVAPfGffiU3KxCAiYouVSfs2Gy62DoLYG8BPaMv5xOCcesGWhFYRjGZjDZcH3NGh JX368Kit+GRKndbRfJTx+CxAU2sHhkBixwN7mZHUMyT5xXDlGl6wB5FIJlXc32G1/1yL HPcvM3WcZUCUZfkUG2UQAGdgazix6X/Los2JZ+D7TWv7RAiEUGp9akWlcg1fqy/33j3q ZIBg== X-Gm-Message-State: AKaTC02JDPLpJXrwaroVCA95erB9uBiX5EDE7VggvHAecZuEy7M2KfzsK//u47FEboD/ow== X-Received: by 10.84.210.73 with SMTP id z67mr1271356plh.112.1479864211715; Tue, 22 Nov 2016 17:23:31 -0800 (PST) Received: from [172.16.5.144] ([45.24.116.177]) by smtp.gmail.com with ESMTPSA id n24sm47839707pfb.0.2016.11.22.17.23.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2016 17:23:31 -0800 (PST) From: Dave Crocker X-Google-Original-From: Dave Crocker To: Matthew Kerwin , Alexey Melnikov References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 22 Nov 2016 17:23:25 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 01:23:33 -0000 On 11/22/2016 5:18 PM, Matthew Kerwin wrote: > Would you prefer I switched it from descriptive to imperative, like this?: > > "When a file URI is produced, characters not allowed by the syntax in > Section 2 SHOULD be encoded using UTF-8 and percent-encoded, as per > [RFC3986], Section 2.5."​ The oddity in the language is that the phrasing implies that the characters that /are/ allowed won't be in UTF-8. I would have thought that the entire string is always UTF-8, but the non-allowed characters need to be percent-encoded. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 22 17:47:45 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6087A129495 for ; Tue, 22 Nov 2016 17:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xydqrPLnEEMN for ; Tue, 22 Nov 2016 17:47:42 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF064126D74 for ; Tue, 22 Nov 2016 17:47:42 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id c21so79829ioj.1 for ; Tue, 22 Nov 2016 17:47:42 -0800 (PST) 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:message-id :subject:to:cc; bh=UoJV3yOLzfvpRbOCnzlXngfA0ouaZpfjPUm/iCWFdsw=; b=gJNkw03GeG66Q1Eq0skJ4zM3I2L6gHgWHsTuxmdY3aL7pngf2MBdlG4IqNvLCpwE6r XEYx5/OY/zMQe862DdLmFxDJmn9t/2FIRhMBBtAKNRB14XwvSED2LVaLjy8yXaTVeJRg SVwE0GqUzlVFPsQeN3FPGkcDDs/gqbhlSxliBGx/rV1uPteWukFm0B6QkuN1J++3Xtvx //PAnArkoWp5AzNw/xhyW3gnClh31z3jQj3ZnEfmVkLhwi9fz9BE8z1/wGVsC8rqoYh4 iYz6ys3RCf0h4D3PRgwl7MqnZEBE46o0Ozvhx6oTe/xyaGe/0USu5l8w8o45HBg3agTw pvjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UoJV3yOLzfvpRbOCnzlXngfA0ouaZpfjPUm/iCWFdsw=; b=HjfW6tY8G1h+h9MXSeXx2st22MafCOCkNTMKU02xkRZpw1N+S8DIkc46lFktPA12vZ UV/oQ+q4foVTR106Z+IA3b1RHnrVRDcBMne58XfANKQk6e3GfpnR16qu99rIZxLHxi0T k1leV3alYe7HMhjQ4DMOFEM6sBd6Rj+ZRlvk1AedM59VmAyAU7wqW53/zZIwWohQr/su NCLkqqFsLwXxh5VCLLyZ3Ak0COnphVzJ5gzTFN7+WXdCITk0XaOIm3QpkV6pJWOGG8cs ZE7bLbRFeXnMQwTkWdMETRr47yXxp8/TknGAuXQEMUfZRTgTi0fdqAq5GeLrJfTj6ikh sY3Q== X-Gm-Message-State: AKaTC030jSaviSvUKWnrTRwZgxJNcoPecIfvvVAPbdceNTcDy0BoJ4vnkydhBmRR5rZJnEpzkxS0l0pIk2bt6A== X-Received: by 10.107.195.204 with SMTP id t195mr1133249iof.46.1479865662019; Tue, 22 Nov 2016 17:47:42 -0800 (PST) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.135.84 with HTTP; Tue, 22 Nov 2016 17:47:41 -0800 (PST) In-Reply-To: References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> From: Matthew Kerwin Date: Wed, 23 Nov 2016 11:47:41 +1000 X-Google-Sender-Auth: _tL--D1SD2taFoLYJNsTHTlBQfo Message-ID: To: Dave Crocker Content-Type: multipart/alternative; boundary=94eb2c189cee19a4c20541ee138f Archived-At: Cc: Alexey Melnikov , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 01:47:45 -0000 --94eb2c189cee19a4c20541ee138f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 23 November 2016 at 11:23, Dave Crocker wrote: > On 11/22/2016 5:18 PM, Matthew Kerwin wrote: > >> Would you prefer I switched it from descriptive to imperative, like this= ?: >> >> "When a file URI is produced, characters not allowed by the syntax in >> Section 2 SHOULD be encoded using UTF-8 and percent-encoded, as per >> [RFC3986], Section 2.5."=E2=80=8B >> > > The oddity in the language is that the phrasing implies that the > characters that /are/ allowed won't be in UTF-8. > > I would have thought that the entire string is always UTF-8, but the > non-allowed characters need to be percent-encoded. > > d/ > > =E2=80=8BOh, yeah, I think I overlooked UTF-16 and EBCDIC, which contain ch= aracters that are allowed by the syntax but don't encode to US-ASCII-compatible octets. How about this?: " When a file URI is produced, characters SHOULD be encoded using UTF-8, and any characters not allowed by the syntax in Section 2 MUST be percent-encoded. " I think that recaptures the original intent better as well, now I look at it. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --94eb2c189cee19a4c20541ee138f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 November 2016 at 11:23, Dave Crocker = <dcrocker@gmail.= com> wrote:
On 11/22/2016 5:18 PM, Matthew Kerwin wrote:
Would you prefer I switched it from descriptive to imperative, like this?:<= br>
"When a file URI is produced, characters not allowed by the syntax in<= br> Section 2 SHOULD be encoded using UTF-8 and percent-encoded, as per
[RFC3986], Section 2.5."=E2=80=8B

 The oddity in the language is that the phrasing implies that the characters= that /are/ allowed won't be in UTF-8.

I would have thought that the entire string is always UTF-8, but the non-al= lowed characters need to be percent-encoded.

d/


=E2=80=8BOh, yeah, I think I overlooked UTF-16 and EBCDIC, which cont= ain characters that are allowed by the syntax but don't encode to US-AS= CII-compatible octets.=C2=A0 How about this?:

"
When a file URI is produced, characters = SHOULD be encoded using UTF-8, and any characters not allowed by the syntax= in Section 2 MUST be percent-encoded.
= "

I think that recaptures the original intent better as well= , now I look at it.

Cheers
--
=C2=A0= Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--94eb2c189cee19a4c20541ee138f-- From nobody Tue Nov 22 18:04:02 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A26129456 for ; Tue, 22 Nov 2016 18:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdg9X_lnn72p for ; Tue, 22 Nov 2016 18:03:57 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C691294A0 for ; Tue, 22 Nov 2016 18:03:57 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id 3so13760015pgd.0 for ; Tue, 22 Nov 2016 18:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:reply-to:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=j/KysrJa4kQ319OlWWc+w0DJ58s+fEaVx6cW3cqyBMo=; b=KXV/n5FfQSI6l5s35NFI9rJXCKmm8zwybtgi1F8hCaV+bR0Ns/d4aSCwTEftHFIXC0 5eMMT0+PjZpiOx+Wv/XFOR1yyluGSyHBI84ecZj4s5hDbbHUKEhd8dgBuAWwuGT4neRM fxMwq1RO5Pq4dgY5GLp5MlShIV2OyAyO3TrB+D45AcnrIBODkegydDh6zefY0o5CWSYM GA7d5uxTVbwqhBMahNEcFe1m5LbbIGpzY+jji3Uo4KB94f+0g4zm50AXyi0oC8kJ5vLs 6JrQf3KP437jnibM81L6Vm9bnCe/cYWm2cghToFWJ8/IY5O5IE+IXrHjvTMx4ttZog07 2m0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:reply-to :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=j/KysrJa4kQ319OlWWc+w0DJ58s+fEaVx6cW3cqyBMo=; b=bwuksa+4EnZEh61SNtGoOX56Al5PGANK9jfarxHvZxUMlLvMKp22F+soSbCL8PBIfR Xjt/W4kjIgq/Yyj27wB80ZUg/A8Od2YixSE8MP6oEd1CAOpVkC/dREJdmvD61Li3/JWs 6nzW0XRNCcAtr2OppdUP0YDaHR4CRJPL54dDbUQQ97HsMqSAW8SlDBL251K10Ocsm+2i k8wkDYBLkRb2MttEJ/0YGE+jmMYXTQwnLvKhsDFnisnBZ0PnbJIBTB/6AUpkGeLYlxPQ d0UK812ibxsB0QLYRc72qz5UITWW+z2gTL2ly+x6NwUosfqo9a9PyP2Tx+2iWqvBzc02 fnTg== X-Gm-Message-State: AKaTC02ZiTmgLJe1EP9n4xPmK2Xy+5lEYXOWhSR6G5QKoIUH4wuC1k4rNxPYEQKhfBSRQQ== X-Received: by 10.84.143.1 with SMTP id 1mr1561281ply.86.1479866636728; Tue, 22 Nov 2016 18:03:56 -0800 (PST) Received: from [172.16.5.144] ([45.24.116.177]) by smtp.gmail.com with ESMTPSA id l69sm47939095pfk.34.2016.11.22.18.03.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2016 18:03:56 -0800 (PST) From: Dave Crocker X-Google-Original-From: Dave Crocker To: Matthew Kerwin References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> Organization: Brandenburg InternetWorking Message-ID: <6e9ffa5e-47b6-95aa-5807-c8f7a7cd6c24@dcrocker.net> Date: Tue, 22 Nov 2016 18:03:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Alexey Melnikov , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 02:03:58 -0000 On 11/22/2016 5:47 PM, Matthew Kerwin wrote: > > I would have thought that the entire string is always UTF-8, but the > non-allowed characters need to be percent-encoded. > > d/ > > > ​ Oh, yeah, I think I overlooked UTF-16 and EBCDIC, which contain > characters that are allowed by the syntax but don't encode to > US-ASCII-compatible octets. How about this?: Overlooking UTF-16 and EBCDIC has always seemed like simple good hygiene to me... But I assume you really mean that those might be the 'native' form and the issue is mapping to the canonical form in the standard... > When a file URI is produced, characters SHOULD be encoded using UTF-8, > and any characters not allowed by the syntax in Section 2 MUST be > percent-encoded. That sounds much more like what I'd expect to see. (My comment is waffling only because I try to be careful not to sound as if think I know anything about UTF-*...) > I think that recaptures the original intent better as well, now I look > at it. dandy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 22 19:01:44 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A1E129508 for ; Tue, 22 Nov 2016 19:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrjs9Es86yNS for ; Tue, 22 Nov 2016 19:01:42 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EDE51294CD for ; Tue, 22 Nov 2016 19:01:42 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1c9NoP-000KxP-Au; Tue, 22 Nov 2016 22:01:29 -0500 Date: Tue, 22 Nov 2016 22:01:24 -0500 From: John C Klensin To: dcrocker@bbiw.net, Matthew Kerwin , Alexey Melnikov Message-ID: In-Reply-To: References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 03:01:44 -0000 --On Tuesday, November 22, 2016 17:23 -0800 Dave Crocker wrote: > On 11/22/2016 5:18 PM, Matthew Kerwin wrote: >> Would you prefer I switched it from descriptive to >> imperative, like this?: >>=20 >> "When a file URI is produced, characters not allowed by the >> syntax in Section 2 SHOULD be encoded using UTF-8 and >> percent-encoded, as per [RFC3986], Section 2.5."=E2=80=8B >=20 > The oddity in the language is that the phrasing implies that > the characters that /are/ allowed won't be in UTF-8. Dave, I don't read the statement that way although it is certainly confusing and easy to interpret the way you read it. I agree that it should probably be improved. The minimum change, which I don't think is good enough for the reasons below, would be to insert "then" after "using UTF-8 and". Matthew, IMO the problem is that the productions/ definitions you are co-opting from 3986 prohibit two types of characters: assorted ASCII "specials" and everything non-ASCII. Both are required to be percent-encoded, but, while Unicode characters outside the ASCII repertoire require encoding into UTF-8 first, ASCII characters do not -- they are precisely one octet each and one just applies the percent-encoding algorithm as it was originally defined to each octet in turn. =20 What makes your statement technically correct if the missing word is assumed is that, because the ASCII repertoire is a strict subset of Unicode and the only encoding for ASCII that has, AFAIK, _ever_ been used on the Internet is a strict subset of Unicode in UTF-8 with a one-one mapping, "encoding ASCII into UTF-8" is a trivial identity operation, so encoding the relevant ASCII characters into UTF-8 and then percent-encoding will actually work just fine. However, that formulation will also create a lot of confusion, not only the way in which Dave was confused but because, if one is being precise, "UTF-8" is just an encoding method that is not specific to a particular coded character set or character repertoire. There is no reason why one could not encode an ISO 8859-1 string in UTF-8. So, while you can say "ASCII" (a character repertoire, a coded character set (i.e., a mapping from each characters in the repertoire to a code point), and an encoding (on the Internet, one octet per character with the 7bit ASCII right aligned in an octet with a leading zero bit per RFC 20)), you should be saying "Unicode encoded in UTF-8", not just "UTF-8". > I would have thought that the entire string is always UTF-8, > but the non-allowed characters need to be percent-encoded. See above. Certainly one hopes that the entire string is in Unicode encoded in UTF-8 and making a statement that can imply UTF-8 is an alternative to percent-encoding would just be wrong. = That, however, gets me to the issue that has always bothered me about efforts to completely nail down the "file:" scheme. The examples in Appendix D are not comprehensive (and should, by the way, be identified as examples). One can imagine (and some of us have encountered and used) file systems that are far more different from those four than any of them are from each other _and_ that do not use ASCII (at least as the IETF and everyone else these days encodes it) or Unicode for files names or paths. In doing file operations on those systems, one would really prefer that a file URL track the conventions of the local system, if only because the transcoding processes may require additional information that there is no obvious place to put or, without that information, may be ambiguous. If one goes down that path, either UTF-8 may not be appropriate or specifying "Unicode in UTF-8" or "whatever you have in UTF-8" may be an important distinction. One may also need to understand the path elements and file system well enough to talk in terms of access methods, not just "file". FWIW, we dealt with most of those issues in a file retrieval protocol more than forty years ago -- a careful reading of the evolution of the ARPANET/ Internet File Transfer Protocol specs will provide insight into a lot of them in the context of a much more diverse collection of file system models than we typically encounter today. I don't think the document needs to reflect those issues in any significant way -- if we reach a point at which the model it (and 3986) use is obsolete or even significantly challenged, we are going to have enough other problems to make the issues with this spec fairly minor. However, I do believe the spec would be improved by being a little more sensitive to the possibilities. Making sure that Appendix D is clear that those are examples rather than a comprehensive list of operating systems in which "file:" can be used would be an example of such sensitivity. best, john=20 From nobody Tue Nov 22 19:05:26 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C54129508 for ; Tue, 22 Nov 2016 19:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkOk5ZcOdN89 for ; Tue, 22 Nov 2016 19:05:23 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556E1129540 for ; Tue, 22 Nov 2016 19:05:23 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id x94so2287540ioi.3 for ; Tue, 22 Nov 2016 19:05:23 -0800 (PST) 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:message-id :subject:to:cc; bh=mKAs0+LWrUqxra2509zhfccWAsOc1s4uf8LbIlCoM/s=; b=mhC+HMGJytPxr1E8RquS1qCVJ+fNLYkFYjRnqnxSs399r/io29J3xpjT7mxKDlmjnl 5Pp49VauDfkFW9ZyYcI0FYYjw7nxXGOipNZj/PssANsxJ+4X465w6hrITrK7DBEumIEA rbulsMEGB6yas8sznhcsslFRSLE4OBo19WHRzakOsIO/8UqmtbBvAMvPENKHnsY2x95k FiDK5M8M4yC8jJArnetoGIPplvkbn4eXUJunEHkl8wTD3Z5i8irMFjopyEzIk6QGoyX0 ceO9rdkXE1lZI3D7tt9c2j4irIAbeLlkc71QefIWVjm90uscEoZGXqC4q9+pSoEX50sg WUDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mKAs0+LWrUqxra2509zhfccWAsOc1s4uf8LbIlCoM/s=; b=SpedU+/mpSqT5LZP5QWwVfpo4z5oLcaxe4QomG8T8we3ALimao+wQg86r9jXnHrLsT VEKGvEGw2vrlmrMuibXXUOm/MOM5fI2h/EjbdVHJXiGjmT5f9m68k1qoNQXjeBxOlLKp md3pwtlZlda3qCfdmYvlTvTvUuQPMHcQOj/xlwnM2mBU7etX3V09tFFVwQsC+oAC9bUE sPWUPGAWQ18paEg/hEFrhK6g/8pJ6zhqMpMfn4yQ+TGOtXFLuFydMU9WZgXZwupL3SvW Z345SSHl0TFoTc11LVm/6Z0TFHJdERSzlOa8gYCVvzSra/J9QSFPWFmfIqSsg/eZhwC1 Xi1A== X-Gm-Message-State: AKaTC01/wD5whKLTLQqPbHt+wO38wXw6dygsM8Gm2xY1bLbi/B+7ls1+FZc45+YD+9svaGS7gq5sY0+Jf9Y7Dw== X-Received: by 10.107.175.94 with SMTP id y91mr1339756ioe.86.1479870322545; Tue, 22 Nov 2016 19:05:22 -0800 (PST) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.135.84 with HTTP; Tue, 22 Nov 2016 19:05:22 -0800 (PST) In-Reply-To: <6e9ffa5e-47b6-95aa-5807-c8f7a7cd6c24@dcrocker.net> References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> <6e9ffa5e-47b6-95aa-5807-c8f7a7cd6c24@dcrocker.net> From: Matthew Kerwin Date: Wed, 23 Nov 2016 13:05:22 +1000 X-Google-Sender-Auth: EcHi34q3hb0ZYuA6t3F2EDmSeNk Message-ID: To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11448aaee398a50541ef28cd Archived-At: Cc: Alexey Melnikov , Dave Thaler , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 03:05:25 -0000 --001a11448aaee398a50541ef28cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 23 November 2016 at 12:03, Dave Crocker wrote: > On 11/22/2016 5:47 PM, Matthew Kerwin wrote: > > When a file URI is produced, characters SHOULD be encoded using UTF-8, >> and any characters not allowed by the syntax in Section 2 MUST be >> percent-encoded. >> > > That sounds much more like what I'd expect to see. (My comment is > waffling only because I try to be careful not to sound as if think I know > anything about UTF-*...) > > > I think that recaptures the original intent better as well, now I look >> at it. >> > > dandy. > > =E2=80=8BActually on reflection I think this butts up against one of the ea= rliest contentions the draft had. This comment was from Dave Thaler, a couple of years ago: > As draft-montenegro-httpbis-uri-encoding summarizes: > >> The URI RFC [RFC3986] talks about the generic syntax for URI >> components: >> >> * Legacy URI components (before 2005) tend to use UTF-8 "or some >> other superset of the US-ASCII character encoding" >> >> * New schemes (after 2005) use UTF-8 with percent encoding for >> reserved characters. > > The file URI is a legacy (pre-2005) scheme for which the encoding is > not deterministic, and indeed varies across implementation. And this > is unlikely to ever change. Unlike HTTP, file has no protocol. For > HTTP, the problem is =E2=80=9Cfixable=E2=80=9D in the protocol, as > draft-montenegro-httpbis-uri-encoding proposes. > > A generic URI parser can never assume percent-encoded octets are > UTF-8 (for file, http, https, or any scheme for which it has no > scheme-specific knowledge). By changing this paragraph to say that all characters should be UTF-8, we're adding a new restriction to the scheme which is likely incompatible with a bunch of current stuff (especially in Microsoft world), and not strictly necessary to bring the scheme in line with RFC 3986. It's not so much an issue for UTF-16, since that's not a superset of US-ASCII, but it could matter for windows-1252 (which is.) It's a question of whether " %C3%83" means " =C3=83" or "=C3=83=C6=92 =E2=80=8B=E2=80=8B " In this case I'd want to confirm that that's how people were already interpreting the paragraph, before changing it to make it more explicit. I don't want to rewrite any consensus here. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11448aaee398a50541ef28cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 November 2016 at 12:03, Dave Crocker <dcrocker@g= mail.com> wrote:
On 11/22/2016 5:47 PM, Matthew Kerwin wro= te:
When a file URI is produced, characters SHOULD be encoded using UTF-8,
and any characters not allowed by the syntax in Section 2 MUST be
percent-encoded.

 That sounds much more like what I'd expect to see.=C2=A0 (My comment is= waffling only because I try to be careful not to sound as if think I know = anything about UTF-*...)


I think that recaptures the original intent better as well, now I look
at it.

 dandy.

<= /blockquote>

=E2=80=8BActually o= n reflection I think this butts up against one of the earliest contentions = the draft had.=C2=A0 This comment was from Dave Thaler, a couple of years a= go:

> As draft-montenegro-httpbis-uri-en= coding summarizes:
>
>> The URI RFC [RFC3986] = talks about the generic syntax for URI
>> components:
=
>>
>> * Legacy URI components (before 2005) tend= to use UTF-8 "or some
>> =C2=A0 other superset of the= US-ASCII character encoding"
>>
>> * = New schemes (after 2005) use UTF-8 with percent encoding for
>= > =C2=A0 reserved characters.
>
> The file URI= is a legacy (pre-2005) scheme for which the encoding is
> not= deterministic, and indeed varies across implementation. And this
> is unlikely to ever change. Unlike HTTP, file has no protocol. For
> HTTP, the problem is =E2=80=9Cfixable=E2=80=9D in the protocol= , as
> draft-montenegro-httpbis-uri-encoding proposes.
>
> A generic URI parser can never assume percent-encode= d octets are
> UTF-8 (for file, http, https, or any scheme for= which it has no
> scheme-specific knowledge).

By changing this paragraph to say that all characters should be UTF= -8, we're adding a new restriction to the scheme which is likely incomp= atible with a bunch of current stuff (especially in Microsoft world), and n= ot strictly necessary to bring the scheme in line with RFC 3986.

= It's not so much an issue for UTF-16, since that's not a superset o= f US-ASCII, but it could matter for windows-1252 (which is.) It's a que= stion of whether "
%C3%= 83" means "
=C3=83" or "=C3=83=C6=92
=E2=80=8B=E2=80=8B
"

In this ca= se I'd want to confirm that that's how people were already interpre= ting the paragraph, before changing it to make it more explicit.=C2=A0 I do= n't want to rewrite any consensus here.

Cheers
--
=C2=A0 Matthew Ke= rwin
=C2=A0 = http://matthew.kerwin.net.au/
--001a11448aaee398a50541ef28cd-- From nobody Tue Nov 22 19:36:14 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C32912943A for ; Tue, 22 Nov 2016 19:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tW9p9enAy1-Q for ; Tue, 22 Nov 2016 19:36:11 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7423D1293F0 for ; Tue, 22 Nov 2016 19:36:10 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1c9OLo-000Kzc-Ix; Tue, 22 Nov 2016 22:36:00 -0500 Date: Tue, 22 Nov 2016 22:35:55 -0500 From: John C Klensin To: Matthew Kerwin , Dave Crocker Message-ID: In-Reply-To: References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Alexey Melnikov , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 03:36:13 -0000 --On Wednesday, November 23, 2016 11:47 +1000 Matthew Kerwin wrote: > =E2=80=8BOh, yeah, I think I overlooked UTF-16 and EBCDIC, = which > contain characters that are allowed by the syntax but don't > encode to US-ASCII-compatible octets.=20 You are confusing "encoding" with "coded character set". The _characters_ available in Unicode encoded in UTF-16 are, by definition, exactly the same as the _characters_ available in Unicode encoded in UTF-8. EBCDIC is another matter. The character repertoire and code point assignments depend on selection of code pages; some have exact and unambiguous mappings to Unicode but I wouldn't count on that being true for all of them. I also don't know what a "US-ASCII-compatible octet" is. Unless one turns that high bit on, bits are bits. > How about this?: =20 > " > When a file URI is produced, characters SHOULD be encoded > using UTF-8, and any characters not allowed by the syntax in > Section 2 MUST be percent-encoded. > " =20 > I think that recaptures the original intent better as well, > now I look at it. See my previous note. First of all, percent-encoding really encodes octets, not characters. That may have been a mistake (see RFC 5137) but it is far too late to consider changing that now. Outside the ASCII range (and _only_ outside the ASCII range), the thing that makes [Unicode in] UTF-8 important is that percent-encoding of, e.g., "=CE=A9" (U+03A9) yields = "%CE%A9" and not, e.g., %0e%A9 which is what one would get if one encoded the UTF-16 octets instead. Again, RFC 3986 (and hence Section 2) disallow "/" (U+002F) but it is a (by definition single-octet) ASCII character and its percent-encoding is %2F for reasons that have everything to do with the original definition of percent-encoding and just about nothing to do with the ASCII<->UTF-8 relationship. There actually is a protocol issue here and, if you are going to say "SHOULD" rather than "MUST", perhaps we should make you address it. If I have a file system whose file names and paths are natively expressed in Unicode encoded in UTF-16, then it actually is a big deal whether you expect that, at least outside the ASCII repertoire and maybe including it) to be transcoded to UTF-8 and then percent-encoded or whether, since 3986 doesn't make specific allowances for other character sets or encodings, you want to treat _all_ file names and paths expressed in the native form of that file system as "not allowed by the syntax" end percent-encode the native octets. If you want to allow the latter, you need to explain it. If you intend the former, then non-ASCII character MUST be in (or converted to) Unicode and encoded in UTF-8 because anything else will result in ambiguity and nasty interoperability problems. john From nobody Tue Nov 22 19:53:14 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58350129438 for ; Tue, 22 Nov 2016 19:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX23FnoWXQbH for ; Tue, 22 Nov 2016 19:53:11 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D19129418 for ; Tue, 22 Nov 2016 19:53:10 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id f188so780298pgc.3 for ; Tue, 22 Nov 2016 19:53:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:organization:reply-to:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SrfdZvCCjRGJLr6AefnyPXFxnBgfCyoj4kdP7xpQxeg=; b=hDXahM6n6T9aaKC+jAMj4mU2cLSGQhV0w449zXlUJy41T0aWukR+NvpAyQhQMv6Jo+ qfwtD3lP4QcjORqdWwE4xRV7tndllconDTqzAWE7GvDFFwD0QZtTrfpiaKA0qZBYM84i HqHkGv6i+IIje4ziPsHIlCq5UOXhyjXZvT2yRiRj9yPiUCNM/9ypsYu3//PvFu9e58oM lUQadoPiz14U1oFisp5ughmAMhm16vivarEKBlLxv353zID7NX50hNv+nY3ya/kt3RpV 5yniJSLjaXOeSGE+7RHACQiBXPVdlfGXIfQGG8UtofK3mSshGiyqdtCgz/EkJwBMOjpc O+4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:organization :reply-to:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=SrfdZvCCjRGJLr6AefnyPXFxnBgfCyoj4kdP7xpQxeg=; b=JG0SfTbvwfIlBOmdlIbvlwpdJWOKBAjzT4/I58GsBYPIiUltdUd6wmLeVVLUoR+7lT 8mD7jW0A3DGpRLVr/ZUORpXnAQCAwWv2OxKLfx8lxqmaWr/vT59AInV3503f1ITI8bEw d/v4T1iZG5iIKzGD6Ua8qF8Cluh+20a/8GsfgXwrjlABc57+VRZurknxmhXRZDCprdZO MgdKU+YExdIyuReiCj1ryYdsuOqQeVhPm9i++xI4RQ1pLRdHfavfcSp3A9XmBQenVgNb qEGZACiqgPjr8PxjtX/tNqEXPr87c8i5UjdfEeL2kYZg2gRxY8Ra3cxDaUcf6NBBSYs4 xH+A== X-Gm-Message-State: AKaTC03rQeLaZYSr+xOASq+ZXJAyrIG2ihKtxQcnhpiQXgdUu7kO0Z4w19h1VBiCYS09Bw== X-Received: by 10.84.202.12 with SMTP id w12mr2423042pld.156.1479873190365; Tue, 22 Nov 2016 19:53:10 -0800 (PST) Received: from [172.16.1.67] ([45.24.116.177]) by smtp.gmail.com with ESMTPSA id f14sm48352664pfk.5.2016.11.22.19.53.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2016 19:53:09 -0800 (PST) From: Dave Crocker X-Google-Original-From: Dave Crocker To: Matthew Kerwin References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> <6e9ffa5e-47b6-95aa-5807-c8f7a7cd6c24@dcrocker.net> Organization: Brandenburg InternetWorking Message-ID: <095ec432-3280-bb22-ec4d-42754df2f08c@dcrocker.net> Date: Tue, 22 Nov 2016 19:53:03 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Alexey Melnikov , Dave Thaler , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 03:53:12 -0000 On 11/22/2016 7:05 PM, Matthew Kerwin wrote: > > When a file URI is produced, characters SHOULD be encoded using UTF-8, > and any characters not allowed by the syntax in Section 2 MUST be > percent-encoded. > > > That sounds much more like what I'd expect to see. (My comment is > waffling only because I try to be careful not to sound as if think I > know anything about UTF So, I'm quoting the same text I did last time, but this time I'm responding to some of the more recent concerns: To the extent the above simplifies the range of supported data to be a single, common standard (utf-8) where the history has been multiple, competing ones, I'd class that as an enormous and fundamental improvement. The simplification is well worth it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 22 19:58:25 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E66F129438 for ; Tue, 22 Nov 2016 19:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3rv4j4PZgtx for ; Tue, 22 Nov 2016 19:58:23 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB2D129418 for ; Tue, 22 Nov 2016 19:58:23 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1c9OhG-000L1n-IH; Tue, 22 Nov 2016 22:58:10 -0500 Date: Tue, 22 Nov 2016 22:58:05 -0500 From: John C Klensin To: Matthew Kerwin , Dave Crocker Message-ID: <88A3D1C42786D208F18ED079@JcK-HP8200> In-Reply-To: References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> <6e9ffa5e-47b6-95aa-5807-c8f7a7cd6c24@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Alexey Melnikov , Dave Thaler , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 03:58:24 -0000 --On Wednesday, November 23, 2016 13:05 +1000 Matthew Kerwin wrote: > On 23 November 2016 at 12:03, Dave Crocker = > wrote: >... >> That sounds much more like what I'd expect to see. (My >> comment is waffling only because I try to be careful not to >> sound as if think I know anything about UTF-*...) I'm trying to fill that little gap in... see earlier notes in this thread and the discussion in RFC 5198. >... > =E2=80=8BActually on reflection I think this butts up against = one of > the earliest contentions the draft had. This comment was from > Dave Thaler, a couple of years ago: >... >> A generic URI parser can never assume percent-encoded octets >> are UTF-8 (for file, http, https, or any scheme for which it >> has no scheme-specific knowledge). See previous comment about percent-encoding encoding octets, not, e.g., Unicode code points or any particular encoding. > By changing this paragraph to say that all characters should > be UTF-8, we're adding a new restriction to the scheme which > is likely incompatible with a bunch of current stuff > (especially in Microsoft world), and not strictly necessary to > bring the scheme in line with RFC 3986. >=20 > It's not so much an issue for UTF-16, since that's not a > superset of US-ASCII, On an octet by octet basis, sure it is, at least for selected sets of code points. Consider "=E2=84=A2" (U+2122). It isn't = a valid character in the syntax, so needs to be percent-encoded. Its UTF-16 encoding consists of two octets which, in a slightly different notation to reduce confusion, would be x'21' x'22'. But, if you percent-encode that directly and don't have external knowledge, it looks like %21%22 or ASCII '!"' -- two perfectly good ASCII characters that happen to require percent-encoding in at least some 3986 contexts. =20 > but it could matter for windows-1252 > (which is.) It's a question of whether " > %C3%83" means " > =C3=83" or "=C3=83=C6=92=E2=80=8B > " Yep. > In this case I'd want to confirm that that's how people were > already interpreting the paragraph, before changing it to make > it more explicit. I don't want to rewrite any consensus here. Whatever you decide, you need to be sure that, at least outside the ASCII range, you are very precise about exactly what percent-encoding is applied to. If that is a local option, say so and move on. best, john From nobody Tue Nov 22 20:06:53 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97266129490 for ; Tue, 22 Nov 2016 20:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nkq1uE83u1eP for ; Tue, 22 Nov 2016 20:06:50 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0B8129418 for ; Tue, 22 Nov 2016 20:06:49 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1c9OpR-000L2d-I2; Tue, 22 Nov 2016 23:06:37 -0500 Date: Tue, 22 Nov 2016 23:06:32 -0500 From: John C Klensin To: dcrocker@bbiw.net, Matthew Kerwin Message-ID: In-Reply-To: <095ec432-3280-bb22-ec4d-42754df2f08c@dcrocker.net> References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> <6e9ffa5e-47b6-95aa-5807-c8f7a7cd6c24@dcrocker.net> <095ec432-3280-bb22-ec4d-42754df2f08c@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Alexey Melnikov , Dave Thaler , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 04:06:51 -0000 --On Tuesday, November 22, 2016 19:53 -0800 Dave Crocker wrote: > On 11/22/2016 7:05 PM, Matthew Kerwin wrote: >> >> When a file URI is produced, characters SHOULD be encoded >> using UTF-8, and any characters not allowed by the syntax >> in Section 2 MUST be percent-encoded. >> >> >> That sounds much more like what I'd expect to see. (My >> comment is waffling only because I try to be careful not to >> sound as if think I know anything about UTF > > So, I'm quoting the same text I did last time, but this time > I'm responding to some of the more recent concerns: > > To the extent the above simplifies the range of > supported data to be a single, common standard (utf-8) where > the history has been multiple, competing ones, I'd class that > as an enormous and fundamental improvement. > > The simplification is well worth it. Agreed. More generally, if we could get rid of everything in protocols and on the wire other than Unicode in UTF-8, we'd be better off for all sorts of reasons. However, making that simplification involves invalidating some, probably a lot of, existing uses. To some degree, it shifts the document from describing current and historical practice to describing a new scheme with properties similar to, but much more clear, precise, and consistent than, the historical "file:" one. Normally that would call for creating a new scheme ("file1:", "filebis:" ?) and then discouraging use of the old one. Do we want to do that? If not, does an "it is always Unicode in UTF-8 except when the URL, reference, or usage are old" situation create, e.g., any security problems? best, john From nobody Tue Nov 22 20:12:25 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AA61294D1 for ; Tue, 22 Nov 2016 20:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xhs-B0iCLEZ for ; Tue, 22 Nov 2016 20:12:21 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1234712947F for ; Tue, 22 Nov 2016 20:12:21 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id j65so4404812iof.0 for ; Tue, 22 Nov 2016 20:12:21 -0800 (PST) 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:message-id :subject:to:cc; bh=ySxqkvkjEfXrDh0UB8PtaqHxxxaQETHzhJm2MTKLjzk=; b=AXaTFiPl/KUL77nO/rqMlVHw8a7VcDVJnA8TOQynnR77mBZov6xdUZd+cI6Qzk8Nny BaK2md+KOtI0jpams1CAstQGNTN7Z1A7DSEV861+1QZy+jpmi4hUKouX9RpEn4qnPO3+ eLSD9sFi0RF+57+W7yrVUQjv652YBjkOyOa/SeFdNAlc6m6t69f/UYsfnYXt5ekgsb/y bNPGATaTI9Eq3Mxh11/0JzaIWJMPWnjH9+l2J573wjOUqiLdU5lVA5zl5QdeqfacCpBD 3U4Q3B0aIJun4IDMh7WAU4FmU17z/xUPGaNe3DVLUw+r0uq/boc4nbRFzqBs0YKOiSgc bszw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ySxqkvkjEfXrDh0UB8PtaqHxxxaQETHzhJm2MTKLjzk=; b=H9UX//YKi6IrRiECJ0jY9Q2e/VLP9/iLy56qIIy/YM/QOz6sZnJR3h1QO1JUu5mKp/ jsvfNGVmwxE7WW5/CFzug80ujU2BrbAu4hpYqVOTfl6xWBm0XieuXcEaLNVTiFtY7vIu FclCjJ7IQJPLNegyAPTJObSwj4Llp3Q/m7s/ne1nUhPtQTE2tV41DCN3dqCE+rB1twgN LkHVa33vQTfs09NIIFIGRfJEuu3ASfnuELVGUL78LGOn4QYg4XuguYVBiqwxP68o1rBn dySC+8h4pDslLCrhSpkqhGXLgmqURruhk4jAczlH178c1aDcvXvcQ6BaCxltBbD5k6LG l6UQ== X-Gm-Message-State: AKaTC01B4DhIPRWvIFxwTM2vm3UGFe8xjXDt7vpcAcDbYqwWdlJqrPb3foCT8xO38HDWFmm4df/HhHbI57F67A== X-Received: by 10.36.77.207 with SMTP id l198mr5360934itb.18.1479874340278; Tue, 22 Nov 2016 20:12:20 -0800 (PST) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.135.84 with HTTP; Tue, 22 Nov 2016 20:12:19 -0800 (PST) In-Reply-To: References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> From: Matthew Kerwin Date: Wed, 23 Nov 2016 14:12:19 +1000 X-Google-Sender-Auth: fnfagaqSSovslULld5C7Sjk7hEA Message-ID: To: John C Klensin Content-Type: multipart/alternative; boundary=001a1144e0d25d58a00541f0181b Archived-At: Cc: Alexey Melnikov , Dave Crocker , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 04:12:23 -0000 --001a1144e0d25d58a00541f0181b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 23 November 2016 at 13:01, John C Klensin wrote: > > > --On Tuesday, November 22, 2016 17:23 -0800 Dave Crocker > wrote: > > > On 11/22/2016 5:18 PM, Matthew Kerwin wrote: > >> Would you prefer I switched it from descriptive to > >> imperative, like this?: > >> > >> "When a file URI is produced, characters not allowed by the > >> syntax in Section 2 SHOULD be encoded using UTF-8 and > >> percent-encoded, as per [RFC3986], Section 2.5."=E2=80=8B > > > > The oddity in the language is that the phrasing implies that > > the characters that /are/ allowed won't be in UTF-8. > > Dave, I don't read the statement that way although it is > certainly confusing and easy to interpret the way you read it. > I agree that it should probably be improved. The minimum > change, which I don't think is good enough for the reasons > below, would be to insert "then" after "using UTF-8 and". > > Matthew, IMO the problem is that the productions/ definitions > you are co-opting from 3986 prohibit two types of characters: > assorted ASCII "specials" and everything non-ASCII. Both are > required to be percent-encoded, but, while Unicode characters > outside the ASCII repertoire require encoding into UTF-8 first, > ASCII characters do not -- they are precisely one octet each and > one just applies the percent-encoding algorithm as it was > originally defined to each octet in turn. > =E2=80=8BActually RFC 3986, Section 2 explicitly doesn't forbid non-US-ASCII-encoded octets in URIs, only characters that don't have an equivalent in US-ASCII. It's goes to lengths to clarify how to map between US-ASCII ABNF terminals and not-necessarily-ASCII URI characters. I think we're now suffering from the same thing those authors did in 2005 -- we have to live with crappy implementations that don't play nice. > > What makes your statement technically correct if the missing > word is assumed is that, because the ASCII repertoire is a > strict subset of Unicode and the only encoding for ASCII that > has, AFAIK, _ever_ been used on the Internet is a strict subset > of Unicode in UTF-8 with a one-one mapping, "encoding ASCII into > UTF-8" is a trivial identity operation, so encoding the relevant > ASCII characters into UTF-8 and then percent-encoding will > actually work just fine. > However, that formulation will also > create a lot of confusion, not only the way in which Dave was > confused but because, if one is being precise, "UTF-8" is just > an encoding method that is not specific to a particular coded > character set or character repertoire. There is no reason why > one could not encode an ISO 8859-1 string in UTF-8. =E2=80=8BNot so, UTF-8 covers both encoding and charset. RFC 3629 explicitl= y says it's for encoding ISO/IEC 10646-1 UCS / Unicode characters. "UTF-8 encodes UCS characters as a varying number of octets, where the number of octets, and the value of each, depend on the integer value assigned to the character in ISO/IEC 10646..." [RFC 3986] "UTF-8 is a Unicode encoding form that assigns each Unicode scalar value to an unsigned byte sequence..." < http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf>, D92. Etc. I'm pretty sure it's widely recognised that UTF-8 always only encodes UCS codepoints. (Not to mention the fact that "UTF-8" is in IANA's Character Set registry.)=E2=80=8B > So, while > you can say "ASCII" (a character repertoire, a coded character > set (i.e., a mapping from each characters in the repertoire to a > code point), and an encoding (on the Internet, one octet per > character with the 7bit ASCII right aligned in an octet with a > leading zero bit per RFC 20)), you should be saying "Unicode > encoded in UTF-8", not just "UTF-8". > > > I would have thought that the entire string is always UTF-8, > > but the non-allowed characters need to be percent-encoded. > > See above. Certainly one hopes that the entire string is in > Unicode encoded in UTF-8 and making a statement that can imply > UTF-8 is an alternative to percent-encoding would just be wrong. > =E2=80=8BI don't understand what you're saying here. I don't think anyone e= ver said UTF-8 (even just the encoding part of it) could be an alternative to percent-encoding.=E2=80=8B > > > That, however, gets me to the issue that has always bothered me > about efforts to completely nail down the "file:" scheme. The > examples in Appendix D are not comprehensive (and should, by the > way, be identified as examples). =E2=80=8B"...highlights some observed behaviours..." isn't enough? Sure, I = can fluff it out. I'll stop responding here because there are half a dozen new messages in the thread which I'll read first. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a1144e0d25d58a00541f0181b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 23 November 2016 at 13:01, John C Klensin <john-ie= tf@jck.com> wrote:


--On Tuesday, November 22, 2016 17:23 -0800 Dave Crocker
<dcrocker@g= mail.com> wrote:

> On 11/22/2016 5:18 PM, Matthew Kerwin wrote:
>> Would you prefer I switched it from descriptive to
>> imperative, like this?:
>>
>> "When a file URI is produced, characters not allowed by the >> syntax in Section 2 SHOULD be encoded using UTF-8 and
>> percent-encoded, as per [RFC3986], Section 2.5."=E2=80=8B
>
> The oddity in the language is that the phrasing implies that
> the characters that /are/ allowed won't be in UTF-8.

Dave, I don't read the statement that way although it is
certainly confusing and easy to interpret the way you read it.
I agree that it should probably be improved.=C2=A0 The minimum
change, which I don't think is good enough for the reasons
below, would be to insert "then" after "using UTF-8 and"= ;.

Matthew, IMO the problem is that the productions/ definitions
you are co-opting from 3986 prohibit two types of characters:
assorted ASCII "specials" and everything non-ASCII.=C2=A0 =C2=A0B= oth are
required to be percent-encoded, but, while Unicode characters
outside the ASCII repertoire require encoding into UTF-8 first,
ASCII characters do not -- they are precisely one octet each and
one just applies the percent-encoding algorithm as it was
originally defined to each octet in turn.

=E2=80=8BActually RFC 3986, Section 2 explicitly doesn't fo= rbid non-US-ASCII-encoded octets in URIs, only characters that don't ha= ve an equivalent in US-ASCII. It's goes to lengths to clarify how to ma= p between US-ASCII ABNF terminals and not-necessarily-ASCII URI characters.=

I think we're now suffering fro= m the same thing those authors did in 2005 -- we have to live with crappy i= mplementations that don't play nice.
=C2=A0

What makes your statement technically correct if the missing
word is assumed is that, because the ASCII repertoire is a
strict subset of Unicode and the only encoding for ASCII that
has, AFAIK, _ever_ been used on the Internet is a strict subset
of Unicode in UTF-8 with a one-one mapping, "encoding ASCII into
UTF-8" is a trivial identity operation, so encoding the relevant
ASCII characters into UTF-8 and then percent-encoding will
actually work just fine.
=C2=A0
However, that formulation will also
create a lot of confusion, not only the way in which Dave was
confused but because, if one is being precise, "UTF-8" is just an encoding method that is not specific to a particular coded
character set or character repertoire.=C2=A0 There is no reason why
one could not encode an ISO 8859-1 string in UTF-8.

=E2=80=8BNot so, UTF-8 covers both encoding and charset. = RFC 3629 explicitly says it's for encoding ISO/IEC 10646-1 UCS=C2=A0/ U= nicode=C2=A0characters.

"UTF-8 encode= s UCS characters as a varying number of octets, where the
= =C2=A0 =C2=A0number of octets, and the value of each, depend on the integer= value
=C2=A0 =C2=A0assigned to the character in ISO/IEC 1064= 6..." [RFC 3986]

"UTF-8 is a Uni= code encoding form that assigns each Unicode scalar value to an unsigned by= te sequence..." <http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf&g= t;, D92.

Etc.

I'm pretty sure it's widely recognised that UTF-8 always only = encodes UCS codepoints. =C2=A0(Not to mention the fact that "UTF-8&quo= t; is in IANA's Character Set registry.)=E2=80=8B

= =C2=A0
=C2=A0 =C2=A0= So, while
you can say "ASCII" (a character repertoire, a coded character set (i.e., a mapping from each characters in the repertoire to a
code point), and an encoding (on the Internet, one octet per
character with the 7bit ASCII right aligned in an octet with a
leading zero bit per RFC 20)), you should be saying "Unicode
encoded in UTF-8", not just "UTF-8".

> I would have thought that the entire string is always UTF-8,
> but the non-allowed characters need to be percent-encoded.

See above.=C2=A0 Certainly one hopes that the entire string is in Unicode encoded in UTF-8 and making a statement that can imply
UTF-8 is an alternative to percent-encoding would just be wrong.

=E2=80=8BI don't understand what you= 're saying here. I don't think anyone ever said UTF-8 (even just th= e encoding part of it) could be an alternative to percent-encoding.=E2=80= =8B

=C2=A0

<rant>
That, however, gets me to the issue that has always bothered me
about efforts to completely nail down the "file:" scheme.=C2=A0 = =C2=A0The
examples in Appendix D are not comprehensive (and should, by the
way, be identified as examples).

= =E2=80=8B"...highlights some observed behaviours..." isn't en= ough? Sure, I can fluff it out.

I= 9;ll stop responding here because there are half a dozen new messages in th= e thread which I'll read first.

Cheers=
--
=C2=A0 M= atthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a1144e0d25d58a00541f0181b-- From nobody Tue Nov 22 21:08:36 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4951294C8 for ; Tue, 22 Nov 2016 21:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3cWz2LnJDQo for ; Tue, 22 Nov 2016 21:08:32 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284AF129401 for ; Tue, 22 Nov 2016 21:08:32 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id c21so5849035ioj.1 for ; Tue, 22 Nov 2016 21:08:32 -0800 (PST) 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:message-id :subject:to:cc; bh=APaupRDcXgxMTu4BJ3JVz9+/DLhVEeCY2h+BRv01fJU=; b=FyyUIfVXRO68hPczlJFlaRpTnCi/hJLSclN/HOkDOQLmAyDx9IMdC5uF5EzPGvQdRz ocMrX8uvV3iX/apg33UcmBp7cuFb+KNK86j/+nTgAR8Ou6Stlt64bOwBywOIjmczhaPp 5BB14XRjxnpT891eYYkkiGmfS/JG721twjiOjCxbI/Oqcs0Kqb7kXwUKn2mQ2uB3L265 ughSrzERwF3ia+Ab/IrKwRw4UQBSvBb7jApK+0aNQs1/4rXcs+7LyXVtB4/XBWIDO+nI 0/ATD/L3/dr+InxBcnch+Lhn7NPszdC6PqKHamMRnDoQ1a8Q+Zv4MACLVzNyMBAqaKNU R9JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=APaupRDcXgxMTu4BJ3JVz9+/DLhVEeCY2h+BRv01fJU=; b=WVUBOOzIDCf9uWzOVfnrMDMabgB3hh7htFTA3KW1LKeSM0XzjaJQfa0tI3s0KNwgZP RjPdEuw46XQPToKFOgVu6JrEbOXhs+DBfHoJeMofsz8IGnWMfznBNw/bn2TCSMbn55sV 7mgPsHa4kTGSyER9EoaMBJBye+sSjm8KRkNLZiDA6FuW9tWFWhXD0b+Hbk5QV29DQwYn 6YX1INdcYkc1HCeZCT87MRKSIsmfbxclY+sqSHlLoICLpP/aKupuJBWoY+lI//AtqS+f fey3jNmCkJE1MS4jKu7kzF7HsOpOg6xn6K9YXzEUqUn68/NA2tPV2mbXBEx5q3c+6PNz rX+g== X-Gm-Message-State: AKaTC02WL6+Ipk/dDLBy/6C1MuiTvNxpgjBhjGVcd9yJ9xI2rvfQFV5Ath7KgQbeWrlqULAp3CTQTxngm0wWTw== X-Received: by 10.107.59.88 with SMTP id i85mr1707242ioa.198.1479877711484; Tue, 22 Nov 2016 21:08:31 -0800 (PST) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.135.84 with HTTP; Tue, 22 Nov 2016 21:08:30 -0800 (PST) In-Reply-To: <88A3D1C42786D208F18ED079@JcK-HP8200> References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> <6e9ffa5e-47b6-95aa-5807-c8f7a7cd6c24@dcrocker.net> <88A3D1C42786D208F18ED079@JcK-HP8200> From: Matthew Kerwin Date: Wed, 23 Nov 2016 15:08:30 +1000 X-Google-Sender-Auth: sv-ZrrcosmHxqkM7ilq7UcXnXhM Message-ID: To: John C Klensin Content-Type: multipart/alternative; boundary=94eb2c05be944dde8a0541f0e1e3 Archived-At: Cc: Alexey Melnikov , Dave Crocker , Dave Thaler , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 05:08:34 -0000 --94eb2c05be944dde8a0541f0e1e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here's the point I can jump back in after my last (abridged) response. On 23 November 2016 at 13:58, John C Klensin wrote: > > > --On Wednesday, November 23, 2016 13:05 +1000 Matthew Kerwin > wrote: > > > By changing this paragraph to say that all characters should > > be UTF-8, we're adding a new restriction to the scheme which > > is likely incompatible with a bunch of current stuff > > (especially in Microsoft world), and not strictly necessary to > > bring the scheme in line with RFC 3986. > > > > It's not so much an issue for UTF-16, since that's not a > > superset of US-ASCII, > > On an octet by octet basis, sure it is, at least for selected > sets of code points. Consider "=E2=84=A2" (U+2122). It isn't a > valid character in the syntax, so needs to be percent-encoded. > Its UTF-16 encoding consists of two octets which, in a slightly > different notation to reduce confusion, would be x'21' x'22'. > But, if you percent-encode that directly and don't have external > knowledge, it looks like %21%22 or ASCII '!"' -- two perfectly > good ASCII characters that happen to require percent-encoding in > at least some 3986 contexts. Sorry, I've been imprecise in my words. I meant to say that UTF-16 does not have the property that, for any given sequence of US-ASCII characters (repertoire, charset, and encoding), the same sequence of characters encoded in UCS-2 (repertoire) using UTF-16 (charset and encoding) results in the same sequence of octets. Windows-1252 does have that property, and doesn't come under the "Unicode" umbrella, which is what made it seem dangerous to me. Although I agree that U+2122/%21%22/!" is interestingly ambiguous, and just as (or even more) dangerous in a different way.=E2=80=8B > > > but it could matter for windows-1252 > > (which is.) It's a question of whether " > > %C3%83" means " > > =C3=83" or "=C3=83=C6=92=E2=80=8B > > " > > Yep. > > > In this case I'd want to confirm that that's how people were > > already interpreting the paragraph, before changing it to make > > it more explicit. I don't want to rewrite any consensus here. > > Whatever you decide, you need to be sure that, at least outside > the ASCII range, you are very precise about exactly what > percent-encoding is applied to. If that is a local option, say > so and move on. > > [then]: > More generally, if we could get rid of everything in > protocols and on the wire other than Unicode in UTF-8, we'd be > better off for all sorts of reasons. > Which begs the question, what does "on the wire" mean for this URI scheme? Most of the uses I, personally, am familiar with are: locally-minted, locally-used. > > However, making that simplification involves invalidating some, > probably a lot of, existing uses. To some degree, it shifts the > document from describing current and historical practice to > describing a new scheme with properties similar to, but much > more clear, precise, and consistent than, the historical "file:" > one. Normally that would call for creating a new scheme > ("file1:", "filebis:" ?) and then discouraging use of the old > one. Do we want to do that? If not, does an "it is always > Unicode in UTF-8 except when the URL, reference, or usage are > old" situation create, e.g., any security problems? I just want to write down what happens now, and try to realign the scheme with RFC 3986. (Originally I just wanted to disassociate the "obsolete" flag from the scheme, so it could be used with Ruby's OpenURI library.) Whatever gets us to that place is good with me, especially if it avoids stalling in the same encoding quagmire that killed the last attempt (a decade ago.) I'm not aware of any specific security issues. There is a mention in Security Considerations: "=E2=80=8BCare MUST be taken to avoid issues resulting from possibly unex= pected aliasing from [...] mismatched encodings or Unicode equivalences [UTR15] (see Section 4)." Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --94eb2c05be944dde8a0541f0e1e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here's the point I can jump back in after my = last (abridged) response.

On 23 November 2016 at 13:58, John C Klensin <john-ietf@jck.= com> wrote:


--On Wednesday, November 23, 2016 13:05 +1000 Matthew Kerwin
<matthew= @kerwin.net.au> wrote:

> By changing this paragraph to say that all characters should
> be UTF-8, we're adding a new restriction to the scheme which
> is likely incompatible with a bunch of current stuff
> (especially in Microsoft world), and not strictly necessary to
> bring the scheme in line with RFC 3986.
>
> It's not so much an issue for UTF-16, since that's not a
> superset of US-ASCII,

On an octet by octet basis, sure it is, at least for selected
sets of code points.=C2=A0 =C2=A0Consider "=E2=84=A2" (U+2122).= =C2=A0 It isn't a
valid character in the syntax, so needs to be percent-encoded.
Its UTF-16 encoding consists of two octets which, in a slightly
different notation to reduce confusion, would be x'21' x'22'= ;.
But, if you percent-encode that directly and don't have external
knowledge, it looks like %21%22 or ASCII '!"' -- two perfectly=
good ASCII characters that happen to require percent-encoding in
at least some 3986 contexts.

Sorry= , I've been imprecise in my words. I meant to say that UTF-16 does not = have the property that, for any given sequence of US-ASCII characters (repe= rtoire, charset, and encoding), the same sequence of characters encoded in = UCS-2 (repertoire) using UTF-16 (charset and encoding) results in the same = sequence of octets.

Window= s-1252 does have that property, and doesn't come under the "Unicod= e" umbrella, which is what made it seem dangerous to me.=C2=A0 Althoug= h I agree that U+2122/%21%22/!"=C2=A0is inte= restingly ambiguous, and just as (or even more) dangerous in a different wa= y.=E2=80=8B

=C2=A0
=C2=A0
> but it could matter for windows-1252
> (which is.) It's a question of whether "
> %C3%83" means "
> =C3=83" or "=C3=83=C6=92=E2=80=8B
> "

Yep.

> In this case I'd want to confirm that that's how people were > already interpreting the paragraph, before changing it to make
> it more explicit.=C2=A0 I don't want to rewrite any consensus here= .

Whatever you decide, you need to be sure that, at least outside
the ASCII range, you are very precise about exactly what
percent-encoding is applied to.=C2=A0 If that is a local option, say
so and move on.


[then]:

> More generally, if we could get = rid of everything in
> protocols and on the = wire other than Unicode in UTF-8, we'd be
&= gt; better off for all sorts of reasons.
>= =C2=A0

Which be= gs the question, what does "on the wire" mean for this URI scheme= ? Most of the uses I, personally, am familiar with are: locally-minted, loc= ally-used.

>=C2=A0
> However, making th= at simplification involves invalidating some,
&= gt; probably a lot of, existing uses.=C2=A0 To some degree, it shifts the
> document from describing current and histor= ical practice to
> describing a new scheme w= ith properties similar to, but much
> more c= lear, precise, and consistent than, the historical "file:"=
> one. =C2=A0 Normally that would call for creatin= g a new scheme
> ("file1:", "= filebis:" ?) and then discouraging use of the old
> one. =C2=A0 Do we want to do that?=C2=A0 If not, does an "= ;it is always
> Unicode in UTF-8 except when= the URL, reference, or usage are
= > old"= ; situation create, e.g., any security problems?

I just want to write down what happens now, and try to = realign the scheme with RFC 3986. (Originally I just wanted to disassociate= the "obsolete" flag from the scheme, so it could be used with Ru= by's OpenURI library.) =C2=A0Whatever gets us to that place is good wit= h me, especially if it avoids stalling in the same encoding quagmire that k= illed the last attempt (a decade ago.)

I= 'm not aware of any specific security issues. There is a mention in Sec= urity Considerations:

=C2=A0 "=E2=80= =8BCare MUST be taken to avoid issues resulting from possibly unexpected al= iasing from [...] mismatched encodings or Unicode equivalences [UTR15] (see= Section 4)."

Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0= http://matthew= .kerwin.net.au/
--94eb2c05be944dde8a0541f0e1e3-- From nobody Tue Nov 22 23:15:34 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0BD129502 for ; Tue, 22 Nov 2016 23:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2_XxJpBcYaa for ; Tue, 22 Nov 2016 23:15:30 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A5AD3129540 for ; Tue, 22 Nov 2016 23:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1479885329; d=isode.com; s=june2016; i=@isode.com; bh=Wq4hEJSybDBoYXB4KWqhD06BsxvzcWx8vsNLBfhs9gg=; 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=dd8vRWvZwQXaJahwLpso4fFHY6P67WGUddN6+v+YnnfiHGHP2EDauNX7HoES4EwBu4NApA TaCBpPSLwpU2Iaj5t9ntiKvLpHGSQDxMdIVYkKoGoYlwIakkjyzy04Vb7N6KqKkVTZUl78 JhxeRycDyaOQkvHKodtYJQYbXMrNDhg=; Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 23 Nov 2016 07:15:29 +0000 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (14A456) In-Reply-To: Date: Wed, 23 Nov 2016 07:30:58 +0000 Message-Id: References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> To: Matthew Kerwin MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-9CC3B21E-D41F-4607-88C5-FD5C51D26064 Content-Transfer-Encoding: 7bit Archived-At: Cc: "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 07:15:32 -0000 --Apple-Mail-9CC3B21E-D41F-4607-88C5-FD5C51D26064 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 23 Nov 2016, at 01:18, Matthew Kerwin wrote: >=20 > Hi Alexey, >=20 >> On 22 November 2016 at 21:44, Alexey Melnikov = wrote: >> Hi, >>=20 >> I think the document is generally in a good state, but I have a couple of= minor things to discuss: >>=20 >>=20 >> 1) In Section 4: >>=20 >> When a file URI is produced, characters not allowed by the syntax in Se= ction 2 SHOULD be percent-encoded as characters using UTF-8 encoding, as per= [RFC3986], Section 2.5. >>=20 >> This text is confusing. Are you trying to say that first Unicode characte= rs are encoded in UTF-8 and then that encoding is percent encoded? >=20 > =E2=80=8BYeah, pretty much. @mnot originally proposed it, and I never rea= lly improved on his first suggestion. >=20 > It speaks to RFC 3986: >=20 > "When a new URI scheme defines a component that represents textual > data consisting of characters from the Universal Character Set [UCS], > the data should first be encoded as octets according to the UTF-8 > character encoding [STD63]; then only those octets that do not > correspond to characters in the unreserved set should be percent- > encoded." >=20 > Would you prefer I switched it from descriptive to imperative, like this?:= >=20 > "When a file URI is produced, characters not allowed by the syntax in Sect= ion 2 SHOULD be encoded using UTF-8 and percent-encoded, as per [RFC3986], S= ection 2.5."=E2=80=8B This is better. Thank you. --Apple-Mail-9CC3B21E-D41F-4607-88C5-FD5C51D26064 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 23 Nov 2016, at 01:1= 8, Matthew Kerwin <matthew@kerwi= n.net.au> wrote:

Hi Alexey,

On 22 November 2016 at 21:44, Alexey Melnikov <alexey.= melnikov@isode.com> wrote:
Hi,

I think the document is generally in a good state, but I have a couple of mi= nor things to discuss:


1) In Section 4:

  When a file URI is produced, characters not allowed by the syntax in S= ection 2 SHOULD be percent-encoded as characters using UTF-8 encoding, as pe= r [RFC3986], Section 2.5.

This text is confusing. Are you trying to say that first Unicode characters a= re encoded in UTF-8 and then that encoding is percent encoded?

=E2=80=8BYeah, pretty much.  @mnot origi= nally proposed it, and I never really improved on his first suggestion.

It speaks to RFC 3986:

   "When a new URI scheme defines a component that represents= textual
   data consisting of characters from the Un= iversal Character Set [UCS],
   the data should first= be encoded as octets according to the UTF-8
   chara= cter encoding [STD63]; then only those octets that do not
 = ;  correspond to characters in the unreserved set should be percent-
   encoded."

Would you p= refer I switched it from descriptive to imperative, like this?:

"When a file URI is produced, characters not allowed by the syntax= in Section 2 SHOULD be encoded using UTF-8 and percent-encoded, as per [RFC= 3986], Section 2.5."=E2=80=8B

This is better.= Thank you.

= --Apple-Mail-9CC3B21E-D41F-4607-88C5-FD5C51D26064-- From nobody Wed Nov 23 00:19:46 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A641129620 for ; Wed, 23 Nov 2016 00:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w78vAvWGAC-U for ; Wed, 23 Nov 2016 00:19:44 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B2A129617 for ; Wed, 23 Nov 2016 00:19:43 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1c9SmB-000Lh3-1U; Wed, 23 Nov 2016 03:19:31 -0500 Date: Wed, 23 Nov 2016 03:19:26 -0500 From: John C Klensin To: Matthew Kerwin Message-ID: <0699564EDC0CD2773E0FB25B@JcK-HP8200> In-Reply-To: References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Alexey Melnikov , Dave Crocker , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 08:19:45 -0000 Matthew, I'm going to drop back out of this .. other things to do, but... --On Wednesday, November 23, 2016 14:12 +1000 Matthew Kerwin wrote: >> However, that formulation will also >> create a lot of confusion, not only the way in which Dave was >> confused but because, if one is being precise, "UTF-8" is = just >> an encoding method that is not specific to a particular coded >> character set or character repertoire. There is no reason = why >> one could not encode an ISO 8859-1 string in UTF-8. >=20 > =E2=80=8BNot so, UTF-8 covers both encoding and charset. RFC = 3629 > explicitly says it's for encoding ISO/IEC 10646-1 UCS / > Unicode characters. >=20 > "UTF-8 encodes UCS characters as a varying number of octets, > where the number of octets, and the value of each, depend > on the integer value assigned to the character in ISO/IEC > 10646..." [RFC 3986] Then make it clear --much more clear than I think the simple citation in your Section 4 implies -- that you are using a specific definition. There are others, equally authoritative. Note too that the statement in 3986 says "encodes UCS characters", not that the coding system cannot encode anything else. FWIW, I'd need to go back and check exactly what they say and how they say it, but, after years of insisting on references to ISO 10646 rather than Unicode, the IETF is now normally using Unicode references. That is, in part, because 10646 changes more slowly but, more important, because "Unicode" normatively includes properties and definitions that have become important to us, which the ISO / IEC Standard does not. IIR, many versions of ISO/IEC 10646 did not even define/standardize the collection of Unicode encoding forms. Similarly, the term UCS-2 (from your later note) is obsolescent and has probably (again, I'd have to check and am not going to do it at this hour) been formally depreciated. If you must refer to the first 65535 code points in Unicode / 10646 (a restriction that RFC 3986 does not make), the preferred terminology is "Basic Multilingual Plane (BMP)" because there is no separate Standard or Part of a Standard for that subset of the Unicode / 10646 repertoire and, btw, it has always been a little ambiguous as to whether the surrogate-introducing code points were part of UCS-2 or not since they are invalid (create nonsense) if mechanically encoded into UTF-8 or UTF-32. But that was the point of my first note in this thread. The original form of your statement was, I believe, correct (if it was what you intended to say). It was also confusing to people with at least a moderate amount of knowledge (e.g., had seen the term "UTF-8" before, who might start thinking in terms of Windows code pages, or who remembered when character coding for the web was defined in terms of ISO/IEC 8859-1 or 8859-9) who were reading quickly through the text rather that looking up and checking every reference, a group that included myself and presumably Dave. I decided to step in because it looked to me as if you and Dave were heading in a direction of confusing each other further as the later discussion of whether it was appropriate to require [Unicode and] UTF-8 seemed to illustrate. The terminology around these character coding and i18n issues can confuse people very easily; I think it is worth putting in a bit of extra effort to be super-clear and precise if you are going to use that vocabulary in a context in which it makes a difference, as it does, or at least appears to do, here. best, john john From nobody Wed Nov 23 01:19:33 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46CB12945B for ; Wed, 23 Nov 2016 01:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvPIPIo3wZ2N for ; Wed, 23 Nov 2016 01:19:30 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3D3129445 for ; Wed, 23 Nov 2016 01:19:30 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id j65so13662263iof.0 for ; Wed, 23 Nov 2016 01:19:30 -0800 (PST) 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:message-id :subject:to:cc; bh=bSdcL2mfRhFBCNq7MpofPJCczGXR+kndMyeKIZXptbQ=; b=DnLqbZ016HQLncDOPb88QH2cho0oZIa4qutr4g91rRwKYvbOfOAKdUVEhMQNP5kXsJ t+oBMR0QUu5GGpLIv7b1VkjMhefOMG3QXEWw9y1wCXqoQMYpvSxr09eZjsLvVA0iBaHN zTMJYHGqQi9SJu9SoqetVK2nxzgkOyHA1zPtIyq+/eFAJRjS2aiHmKnWI6gAfi1qoIKV 3t9hc13C3T3RczdTliAjp8bsVtzgEDmXj8F8DcGQu3V5PHpCpqEcXIJXLrYXcv1Hid/D vf3k1HDF6DFUdRsx0+6kUuee3H0Il76HzezasBu+aUavZrhdZkg7aAG5KIfsGU18ydNE o80g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bSdcL2mfRhFBCNq7MpofPJCczGXR+kndMyeKIZXptbQ=; b=B/4NnCGjB1TG1Zic82nNUXe0mLu2DZUlFHuMSbL9FKoc5sdNDjg1eysWEnOeDJo3ea prV4x/Y/YZL2kuLwvnxsit8Qdrk1V68BwF+DHDqBo5zgkupiBmvB/9aku1fqKdYqooHU bxPwigRvSsJFQ7L4kv35vElBTtgwaM7ElWpRq8mc4Ffun2mm6raGKyPSuJRxLMCNtWpq 5zoJeeYLADrzMRbLRcrhmUxG1+191TSGeBwuWUPOvTJWSA9CBDXpe5fFd3OV5PPN7SPF HA7HxufCcdCbnOlEjmlQHKjKfHDEwCnlmXQZjC6BGSCaImu9wMXGFmOZDf6fib/qODeN jKAw== X-Gm-Message-State: AKaTC00pD4N2D8RBdAkj14KvK+AKJ1H5nW6O7qCgd+mMJX0CoD3Zu67VL1eeNHfHb5C2G30mAt5UGPJDxr3b9Q== X-Received: by 10.36.77.207 with SMTP id l198mr6060480itb.18.1479892769913; Wed, 23 Nov 2016 01:19:29 -0800 (PST) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.135.84 with HTTP; Wed, 23 Nov 2016 01:19:29 -0800 (PST) In-Reply-To: <0699564EDC0CD2773E0FB25B@JcK-HP8200> References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> <0699564EDC0CD2773E0FB25B@JcK-HP8200> From: Matthew Kerwin Date: Wed, 23 Nov 2016 19:19:29 +1000 X-Google-Sender-Auth: vakIi80fBl3h726inm7sTaLmbTk Message-ID: To: John C Klensin Content-Type: multipart/alternative; boundary=001a1144e0d2db408f0541f46294 Archived-At: Cc: Alexey Melnikov , Dave Crocker , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 09:19:32 -0000 --001a1144e0d2db408f0541f46294 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For those playing along, if any still are: On 23 November 2016 at 18:19, John C Klensin wrote: > Matthew, > > I'm going to drop back out of this .. other things to do, but... > > --On Wednesday, November 23, 2016 14:12 +1000 Matthew Kerwin > wrote: > > > > > "UTF-8 encodes UCS characters as a varying number of octets, > > where the number of octets, and the value of each, depend > > on the integer value assigned to the character in ISO/IEC > > 10646..." [RFC 3986] > =E2=80=8BSorry, typo, I meant RFC 3629 (i.e. STD 63, our UTF-8 standard.) =E2=80=8B > > Then make it clear --much more clear than I think the simple > citation in your Section 4 implies -- that you are using a > specific definition. There are others, equally authoritative. > > =E2=80=8BI realise that I should probably make STD 63 a normative reference= , since it's at the pointy end of a 'SHOULD' requirement. That doesn't address the request for more words, though. I'll try to think of a way to make it clear that my "UTF-8" also means Unicode.=E2=80=8B > > FWIW, I'd need to go back and check exactly what they say and > how they say it, but, after years of insisting on references to > ISO 10646 rather than Unicode, the IETF is now normally using > Unicode references. That is, in part, because 10646 changes > more slowly but, more important, because "Unicode" normatively > includes properties and definitions that have become important > to us, which the ISO / IEC Standard does not. IIR, many > versions of ISO/IEC 10646 did not even define/standardize the > collection of Unicode encoding forms. Similarly, the term UCS-2 > (from your later note) is obsolescent and has probably (again, > I'd have to check and am not going to do it at this hour) been > formally depreciated. =E2=80=8BYeah, that was another typo, I meant UCS (the repertoire), not UCS= -2 (the encoding.) I call it "UCS" rather than "the Unicode character repertoire" because it's shorter, and because that's what STD 63 uses. If the differences are important enough, I'll try to use "Unicode" more from now on.=E2=80=8B > > > But that was the point of my first note in this thread. The > original form of your statement was, I believe, correct (if it > was what you intended to say). =E2=80=8BWell, that was the real question: how did everyone who didn't obje= ct to the text interpret it? Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a1144e0d2db408f0541f46294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For those playing along, if any still are:
<= div class=3D"gmail_extra">
On 23 November 201= 6 at 18:19, John C Klensin <john-ietf@jck.com> wrote:
Matthew,

I'm going to drop back out of this .. other things to do, but...

--On Wednesday, November 23, 2016 14:12 +1000 Matthew Kerwin
<matthew= @kerwin.net.au> wrote:

>
> "UTF-8 encodes UCS characters as a varying number of octets,
> where the=C2=A0 =C2=A0 number of octets, and the value of each, depend=
> on the integer value assigned to the character in ISO/IEC
> 10646..." [RFC 3986]

<= div class=3D"gmail_default" style=3D"font-family:georgia,serif;color:rgb(7,= 55,99);display:inline">=E2=80=8BSorry, typo, I meant RFC 3629 (i.e. STD 63,= our UTF-8 standard.)
=E2=80=8B=C2=A0

Then make it clear --much more clear than I think the simple
citation in your Section 4 implies -- that you are using a
specific definition.=C2=A0 There are others, equally authoritative.

=

=E2=80=8BI realise that I should = probably make STD 63 a normative reference, since it's at the pointy en= d of a 'SHOULD' requirement.=C2=A0 That doesn't address the req= uest for more words, though.=C2=A0 I'll try to think of a way to make i= t clear that my "UTF-8" also means Unicode.=E2=80=8B

=C2=A0

FWIW, I'd need to go back and check exactly what they say and
how they say it, but, after years of insisting on references to
ISO 10646 rather than Unicode, the IETF is now normally using
Unicode references.=C2=A0 That is, in part, because 10646 changes
more slowly but, more important, because "Unicode" normatively includes properties and definitions that have become important
to us, which the ISO / IEC Standard does not.=C2=A0 IIR, many
versions of ISO/IEC 10646 did not even define/standardize the
collection of Unicode encoding forms.=C2=A0 Similarly, the term UCS-2
(from your later note) is obsolescent and has probably (again,
I'd have to check and am not going to do it at this hour) been
formally depreciated.

=E2=80=8BYea= h, that was another typo, I meant UCS (the repertoire), not UCS-2 (the enco= ding.) =C2=A0I call it "UCS" rather than "the Unicode charac= ter repertoire" because it's shorter, and because that's what = STD 63 uses.=C2=A0 If the differences are important enough, I'll try to= use "Unicode" more from now on.=E2=80=8B

=C2= =A0


But that was the point of my first note in this thread.=C2=A0 The
original form of your statement was, I believe, correct (if it
was what you intended to say).

= =E2=80=8BWell, that was the real question: how did everyone who didn't = object to the text interpret it?

C= heers
--
=C2= =A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a1144e0d2db408f0541f46294-- From nobody Thu Nov 24 02:53:21 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D5A129F79 for ; Thu, 24 Nov 2016 02:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o8EbiHwF00n for ; Thu, 24 Nov 2016 02:53:14 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40116.outbound.protection.outlook.com [40.107.4.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A9B129B3C for ; Thu, 24 Nov 2016 02:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ioh2KmOsaKDVQGGQQlx6xXU68PdztNlYAALTB0IP2Yo=; b=bHFgvqhBZ+MOUcmW51a/IT4E6tRKCQvblmlI0M5hpp5Uxgxpdkb106WDc0wMhWlT2ddE7Kr4VXkJXMJy4inCo2/Yst68A8bQo6fZk+f0mRIfwzLyB7O70p1UuOe1tbt0n7mp7PXwGqUzrMlwUUUmcPBe6Hbh2K7nrJwjzPf/Ggg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.135.210.62) by VI1PR0701MB3008.eurprd07.prod.outlook.com (10.173.72.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Thu, 24 Nov 2016 10:51:56 +0000 Message-ID: <02c101d24640$4fc49420$4001a8c0@gateway.2wire.net> From: t.petch To: Matthew Kerwin , John C Klensin References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com> <0699564EDC0CD2773E0FB25B@JcK-HP8200> Date: Thu, 24 Nov 2016 10:47:56 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.135.210.62] X-ClientProxiedBy: HE1PR0402CA0018.eurprd04.prod.outlook.com (10.175.27.28) To VI1PR0701MB3008.eurprd07.prod.outlook.com (10.173.72.150) X-MS-Office365-Filtering-Correlation-Id: 325cd873-8e53-4e82-b1a9-08d41457e95c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:VI1PR0701MB3008; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 3:YcrKnwE7rmIrgC5TWCkreanTtt6HEvM57i72mBvNWVrzC83bjPdr6R98E/WTRJNDr3qsRLxzwS9NGdyuAY8M4csneCUME07hFgGt89B6lKewudYkOyAsBt6Zq86uKrg5KLsHn8JrNfYfgQksyd35psajZCSlKqA6w2VKqS7SmjH8FTqgw1Cs/3SCZGjAP683D9vlMR+AIijowp5p/JFrRz3sPl1jk44iwl34wdImwbj2IoxLdDAKSna1/oaI+C/xD+XSbaO8S1VwJIvdpkuC4A== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 25:xz/ps/wfP0X3pwfzdxubZYLG58ZU+tBOZYXPb1wcdihfJFEeLKs4uAJZTg00OcFxYlpZCw9Ho0TFemAtOmBqGxZaAXWVqi/LiAWOKLZcAZYEV05v/jCcqTnHuntehQ+rGqL1KGn56Uy6oGlbFjhfH97v7I2nE+/KCecvVC90aRhhijQdVQJqLiLRLBc2UYv3tmzzslqWGF/5lLiScEFx/pLSG+JeCFQX2zzP6IXDR4jfOWhUDqTlrPqNUDRjGLMlk2PO9pW7wfN3Bw2umettEp1vQaAK+fJlkfSzI7fZRjTb/hdO/zINECJd4kLC/XMFgBJiQgWvldSXU/4zh7DKzzm3g9EOhmovz/nSnIJG6h+Qp8Bz1cxvVx/ukBBvxEYWSDsNB4JCOdLiWjJaRdZhkS6et/Bs3KTIyNnldQltU33dHR9HM+u+ZzppXuZMUW4/DgVdEUNQNDC3YFQ0rauf3Qgrt6Uqb9PlJCdEwEnhi442Hf8+zZ7yOcvfi3CtObRkV8JPfiDh9/0IPfr0QWr4vr/5aL5eGvc7+KBw2uE1SXNYR1D7zTNiXY8arStB4ur0vuIHAR4LJ9wTA1pqNABdvsONYtikdTVjlsx/knJhE0y11JAXWfA0Z9bF0hU9mP6tzkvwSRua7Ll3wh3v0pCHNoWJ2lZqHgSpELNWNQQ+yV/qJBHCP8GRUvGOCGnxM1BB3omBTr/aWkyx9WGK2ewGSzhKqDBAkMmbGJUTXI9rtmQ5RCZhkVVgRFBdNxAIBrzKVav5xzp3z4K6zIUBFYs1FSW7faPKM3tFCxJAMHLuAUScVkCxmQvHcWvFhEFmWTYd8DC3/fAR2F22ODptuSfWg79CzAwAr/h+tgwSO0kRXms= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 31:LsFh3bekDkdjYAy0Qo5TPltwjMpZYUEew5TgH1IxYpyJjLGBsXfGZDKyBJEzuZMhvq1HJEB7nBjN24m2Ej8DImnOA0U64JFqet2UF38KOJfJXYneJkQsiNNFow16ejvem7FLRfpsZtoslp5Xvw0wsnwZddw8aSm3EF1Y5m+M9+FD4uwntQlvorprpSJ+QFZ0LNDZo12BM2b9OxeMzX7zhQF3WgpzT2XdFiufbAkMWuc3NDpVNWdjsp/Zw3INTxFUKZepuCIL2gK5UuOnt/UEffcmo2u4AfjkBU/st1UmgLY=; 4:c6CVdrrzB6D+cwdn2/OVZDqvk+j1WdygfR39y+LRw/L6UGLnrM87ZNaDCQ3J2bMoyKH1rTLLsWwR7wbz5FH2Dz61IBWjuV5v6yAZUo05l7zBbbCOeTpM7Ty/KP5k0HEundVDFUVSt5qFlnBgzIUAfbeqwBEeHwRVhItKPdIBho2mof0tU2M9/oOBi7ULISjAuHukP/+3DpYXt2CID+75F5LLzqlxaUGTpR8B1dam2S8lmrb815qNSQ/Xjutex5NcUXF7Oil9ehjqOYuTmez28xZM1x6DCj1fvm0422u7yqFlSmol3biAeuhs915x9xto8BNRuQsEccVphK1Bd1w2WFT1E6ZDDKzH6VWAOPgnsk671FgZIpkELQKsstb9RYhxYSbYQby8QuwVXk9jGbTP7sWY1tVuVICrOG5v5VN7wMQseG/BvyZuA1vsQ3SQrUsSvzMejTo4MZtlTsGO5x6zmjwy763twiNQlZFB2VKZa8LEkTezF4fTqs1sZYWcGfdxubKz0KuaOkMMtHKbJ7py0nRhciubxy+VnGmUiD2ifgGOiy+o+YKXfbLee0HKP2/MAUgCWFY1AQKYk1O1u8cmAirqM0ZuUjVA/3iut6632QA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6060326)(6045199)(6040361)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(6061324)(20161123555025)(20161123564025)(20161123560025)(20161123562025); SRVR:VI1PR0701MB3008; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3008; X-Forefront-PRVS: 0136C1DDA4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(377454003)(13464003)(199003)(24454002)(189002)(39410400001)(81686999)(105586002)(76176999)(4720700003)(61296003)(106356001)(77096005)(23676002)(1556002)(33646002)(50466002)(81816999)(116806002)(93886004)(42186005)(6116002)(230783001)(44736004)(1456003)(7736002)(5660300001)(305945005)(50986999)(44716002)(38730400001)(92566002)(5820100001)(86362001)(8676002)(101416001)(4326007)(3846002)(14496001)(66066001)(229853002)(7846002)(84392002)(81156014)(2906002)(81166006)(68736007)(97736004)(62236002)(5001770100001)(47776003)(189998001)(50226002)(9686002)(2870700001)(39400400001)(39380400001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3008; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3MDFNQjMwMDg7MjM6R1FEQ0FES0xZWENXWWJKYm5ic0RMcnZZ?= =?utf-8?B?cHI0S2ZEbTNFQkQxbHA2UUZROEVjSHJ2MFhRMWczYzZEbmd5ZHlZdmJva2xy?= =?utf-8?B?Q1AzWkh2L0lGbktlY2RDY0dPMzdXM1NDZFY5UFJSMXRadWVZVld5cU55ZmIv?= =?utf-8?B?bU5tWFFHOHJYYkRNaUdRRnhCRzcwY2E1R3o5dWl0czRHem5ZY0lZS2praDhr?= =?utf-8?B?Qyt6WkV0c05QQnhNakdTOHVhQUFyNXlMdlBMMm5XcmlCb2srSzZpZ0JKYzZw?= =?utf-8?B?d1RDVmlKMXhFWVNVaWd6am9DOWZtNTAyMVJRc2l5VUlFQkdqNmRmWExuMFJS?= =?utf-8?B?YTJCeXJEUjdXV3JoTkYzWEk4MkFoN3kxVGZFTzllYW1Wd0lqNUp6d3F2Vlpi?= =?utf-8?B?Nm45LzU0MTN3UmgrTEFpL2dOclFhYk9tSGR2MmJZVlVqSzBKQW5xR3FvQS8v?= =?utf-8?B?TWk2cUQ5U3loanRpWDVvdHhCc1F4WDA3RU8zNldSWUYzZkdER3diTkwvbk93?= =?utf-8?B?VEVuTDBpRDlDbVlaeE1TdzBKVVFYMWFZZzZnVkJRNU9hbVlPUllLNE9aVGtT?= =?utf-8?B?Njl1R2JlM3p0NE9RSEJiTzdLT0NQNjBQSVBDN2dPZjh0VGdNbTRCYWdPZ0tu?= =?utf-8?B?VXc3dTZHYURVM1d2ZXcvK0VnMVpCYXlLVmtSSWJDS0JWeVRTTFlrdFJVdjdo?= =?utf-8?B?ajRlR0dSTDE4UWVLbUwxTlJpc2ZoaDNMcEVvZlJtb2RCd1ZsMWIxOWx3UytM?= =?utf-8?B?SDlFM2hiK25OSEJuRlNEV3lmcWo5K2E0YWRmQ0lOam9ObjRHZWJaS2NUZmpC?= =?utf-8?B?NmVITDRTSUNMdXdlVGk1bEVFOVdRSkMvck9TK1dFNEtLVmp1MWFWbTlCcFVK?= =?utf-8?B?aXpuWi9zVWtUd3o4TU1vUTIreFlDbUpoS3RLZHNYSS9lVzFJWlZOVjhYemtV?= =?utf-8?B?YlZERHU1WnY4eFV1ejRnNHVyL3VSSEF2MmovNVl5TklFNlJQdmZyT09FamJl?= =?utf-8?B?Z2Nzd21IaVZmdXd0M052ejQySnRBZnRnQTU1ckJpajM1ZGREK05mY04xc2pD?= =?utf-8?B?OEZSQUFCRi85TXp5Uk5KdThvWjFWQXNUY204N1RpTTJqUjdzbVI4ZkprZVRV?= =?utf-8?B?N29CZUZuTmRFZVJ5ajh3QndtTVYyOHhDN0J5MUNrUk5YUGFzenY5MTRBcWox?= =?utf-8?B?NUFDVnNXYmpMVHJNRVdpbHN1azhVVENrVzQvWVZIaHRMQzNhaHVaZ0syRjZE?= =?utf-8?B?MTBIekdlMUkyMUNOMEpya0p1b2V1S2themtVZCt3Z1h0MnlzTUtGV3YxODN5?= =?utf-8?B?Q0wyUVRvR01vcDgvajVVQXBFOU1CZUY0dFB1bHVXNUlBdkJ5V08rekI1MHNz?= =?utf-8?B?WFB6WVRlcmZwYXZZWTFrcnBuS0tOamRZa2F1QmZoSUUzK1ZnSnFNRkt3Y05E?= =?utf-8?B?by9OUGJDSjUzeFhjcWVlSkZNRFVhVDlvZW1KSG00c3MrUVZ2UUhPZXhxbElt?= =?utf-8?B?SFdPZURldGV0YUZ5Vms0ZW9BL0h5cWZ3WVpPcG5xNmpleXI3QVpidStGd1N5?= =?utf-8?B?U1drc1k4TDF4cUR0UG0yS090SGoxUkJaV1ZsMmJqQ3lOQzBXbE5tRHRHdWtH?= =?utf-8?B?dFBtTnp2UDZYVWNGV1RVdjAybWxMNzZpVTdZS2J6ZlZoUzRpQ3huNW95RXJy?= =?utf-8?B?YXdDcTV5c2YvQUhqNzRsZmxQVmJrTTZzeHpNZlBlSHRrZFFteExxUjlTdXFL?= =?utf-8?B?S2FWTUFBY0wrRFQrdWo1MjRzZXJLNGRQWVNjMlltRXRYNFF4U0N0Vk12SUFF?= =?utf-8?B?NzJaN3I0RjExOEVoaS9zQ2RLMGpnYzNYZE9PQXYwYjY4TnM3bVZ1L3UvMUsx?= =?utf-8?B?VDBZM0xvd0FpYXlOVzhySUpnVmlZTW1vM0p3OUU2cE1NOFZReEJSaGE2MS9m?= =?utf-8?B?VnVjcFRlWm93Vnpmai9majlNZWpnVVJCS2crZERhOGVhMkZTZDRPdGN3eFcw?= =?utf-8?B?SGVYN1pNNDNkM01FVStzaVRjdjdDTVMzZUpGVmVnPT0=?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 6:JmgTtzax8NAn/zeJFJcU6SPkYFm1RiF+OID9ysUMoii015EYV7InAp93yEaQzu+1GCed4KSrFZH0nvAQXgmO9h1Gw01r5CjQsOf6fIirW12q1NMnavFGnZgQq1AypuLMiuSVl3a5kFzmogTYTyN7/d66FGMNIYmg9Gma22JWNeKYiZ7ma6AXigKykkd8MDNiF96tE4G23ihjxJ0c2j1YiPNt1odgNB5LakV8fFpVLoXPUfJzkGvRe0LUagXaMlinmjwPga4BFHFP5rCvRjMZ+DHKS4yfI4cfKN8rx+qXdZAcCI5/rlt1LSMGnpjE3bSoe+gulqkZp/qb/JW6Lg80lOdLoDPSkzXVguqLxp3pSeAhJ+0AXXWTzNbMvg4PsQB0Z4U3kGIxP/q6/7G1oDwHaqT/rFRFiIjbz/Go4RypYotxzYqkAa9QYim/JeWjQxf1eiBZhqRC7+bkUB3+fx2jvA==; 5:GRtqXv3vTTR5AdNxofS9r78tB2ChAhIeNc0NX7xGNyGB14n0qdVCfbnZGXB3i7qi7RX6UoA8QgwXqRhNegv0Uj0cC5bKqXc3RbGa7jABGaSirtUbrPDIRD6o3EcdFDaThqgtHbEo2zsFaYtTS6RlCcBzylrj6IFXF3cJrzghyJM=; 24:SQK0DMjfDKlj0urkvK63CQ7NzztOsZJghzAjVj7jDD8c6rGWiqAYXWu480i75n0NzbvTpSBZYR7k+CXRU+KNcnNq9O5tvgAMsV4pUWsRtOU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 7:XN+DzNhhKqmuikgUnJNkulDQquynUThloP8KFzAJoX6QDoC6dxnBTMWUFlABKeUV7D/bfgG5ct0t5Y2VCtfAkO7m9DLBCXjuoLD3+QFTim0RjbdoYyZVRhEtX9rAGtB7mvqeBEytMJU+PguAiAf+7mEC8MqDlwPvO8l8EkeTYx+DtiVkN7PjtGsFnb2M5IfSHSZRl9vl1GySAZVcLopVycE2Bifmyup5uK26sejDjJSQDkJfIUPAiXosdEVDCmqr2IpnBanTatPUOpO1fQqafLAtIWkQA8ws71x8PqfLhfa2+ogiKPHrWjRiveEqLsR0mJbZdmwKrFj5YdvgNX7jR3M1nJWaBvk7hogIZ9U+cry39CeyCDb25ADVwHGRJ7dgMeJx9f6XK/UtdPFjyvFyEUZszIR2seUGMfPm48TRgn8dU2tGJ+E5jtjAx6utGa0RBSHhJdGihUez82r3OZ3z8g== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2016 10:51:56.7892 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3008 Archived-At: Cc: Alexey Melnikov , Dave Crocker , art@ietf.org Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 10:53:20 -0000 ----- Original Message ----- From: "Matthew Kerwin" To: "John C Klensin" Cc: "Alexey Melnikov" ; "Dave Crocker" ; Sent: Wednesday, November 23, 2016 9:19 AM For those playing along, if any still are: On 23 November 2016 at 18:19, John C Klensin wrote: > Matthew, > > I'm going to drop back out of this .. other things to do, but... > > --On Wednesday, November 23, 2016 14:12 +1000 Matthew Kerwin > wrote: > > > > > "UTF-8 encodes UCS characters as a varying number of octets, > > where the number of octets, and the value of each, depend > > on the integer value assigned to the character in ISO/IEC > > 10646..." [RFC 3986] ​Sorry, typo, I meant RFC 3629 (i.e. STD 63, our UTF-8 standard.) > But that was the point of my first note in this thread. The > original form of your statement was, I believe, correct (if it > was what you intended to say). ​Well, that was the real question: how did everyone who didn't object to the text interpret it? Since we have been here a hundred times before, I assumed that it was the same as those hundred times, such as In particular, non-ASCII characters MUST first be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence MUST be percent-encoded to be represented as URI characters. [RFC6068] Tom Petch Cheers -- Matthew Kerwin http://matthew.kerwin.net.au/ ------------------------------------------------------------------------ -------- > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > From nobody Thu Nov 24 18:50:01 2016 Return-Path: X-Original-To: art@ietf.org Delivered-To: art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8C312A207; Thu, 24 Nov 2016 18:49:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148004219732.2554.16221429047602041161.idtracker@ietfa.amsl.com> Date: Thu, 24 Nov 2016 18:49:57 -0800 Archived-At: Cc: art@ietf.org Subject: [art] I-D Action: draft-ietf-appsawg-file-scheme-14.txt X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 02:49:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group of the IETF. Title : The file URI Scheme Author : Matthew Kerwin Filename : draft-ietf-appsawg-file-scheme-14.txt Pages : 18 Date : 2016-11-24 Abstract: This document specifies the "file" Uniform Resource Identifier (URI) scheme, replacing the definition in RFC 1738. It defines a common syntax which is intended to interoperate across the broad spectrum of existing usages. At the same time it notes some other current practices around the use of file URIs. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 29 10:49:33 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3505129649; Tue, 29 Nov 2016 10:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvcAzOXa4q8N; Tue, 29 Nov 2016 10:49:17 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B26A1294A2; Tue, 29 Nov 2016 10:49:14 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id n6so164909653qtd.1; Tue, 29 Nov 2016 10:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=H0UrE3vTj5vBbw2LNTHWDQD2tutCxtRL6SUZ7rfHudE=; b=oD2dW2R/MbUfjYzRoRDgKKXSuCIeAhVmx7LQ4D9PM1cdNg8iN84Nv22N3cVZpf0bdR E2sPmsC3azx6A8zfmRhiw3cOwxYBmYSkCmxSbdMkOumr238QaNInWZOQR7VRMgxLUfB9 fw1+i44k4WN+G4zd9TXyYTfgt+xNkM4EsPy97XU6nRPemmxs1VC8JJOd61OOzPIVaZVw fcfR3gq8Mo3vfXFY8KJ+YnDvXYTQXlsIctzjKmM0Iu6iABzYqB3O3IQn9epfpJT2Rkm7 U8JW6cu+/amJ66WayvN9hVXZg0wO/79t+W578Gt8MR00eKw/4pdLU+g2PBBEfitvbbCB 4mGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc:content-transfer-encoding; bh=H0UrE3vTj5vBbw2LNTHWDQD2tutCxtRL6SUZ7rfHudE=; b=mlgnSmMMfs91j3uWiB5PnZLtWX9qCFDs0CdDJKFVGvHaFdIT2GHc2S7zUSkgGm29Lr YLygzFNfFSkSbvPbcjjwTZqZtsfsqekH6xYxP9UKT5KY9i5KYLOKl+Rizi1H8mrdvXY+ AKHRdRifAXLNzQOEQQYr8u6zW2gf0HLemL6gCad5Fo9Y17GDie92tfnGWmKk8rBqF8Uw 36+DwzuKJ9L4owGazVHagJczwXMkw+FpRuw2AEULBX1W6mAbqJauQTq03TYb6rWK2JYr NKn44ir+Z7KVzyHPf4utxfkwzgMVpDwpSwe1ZtF4uAczhjFAb30hkJWe/6wGtQMQpPwM +0nw== X-Gm-Message-State: AKaTC01oy4mFqkDzpDgMcGCtb197m4GuHGnWxABHUtdqHB67QSIzuVrzD+mTN4a4NEOqKNKICbwcOTQrIiNpVg== X-Received: by 10.200.38.239 with SMTP id 44mr26470724qtp.91.1480445353329; Tue, 29 Nov 2016 10:49:13 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.140.41.177 with HTTP; Tue, 29 Nov 2016 10:49:12 -0800 (PST) From: Barry Leiba Date: Tue, 29 Nov 2016 13:49:12 -0500 X-Google-Sender-Auth: Y_oH2YhpFtKbsQknNx-7fFQEDCE Message-ID: To: draft-ietf-appsawg-file-scheme.all@ietf.org, "secdir@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: art@ietf.org, IETF discussion list Subject: [art] SecDir review of draft-ietf-appsawg-file-scheme-14 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 18:49:24 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Thanks for finally getting this through. I think the document is ready with nits; my detailed comments are below. It=E2=80=99s a tiny thing, but where the abstract says =E2=80=9Creplacing t= he definition in RFC 1738,=E2=80=9D one may be led to think (I was) that 1738 = has a more robust definition than it does. D=E2=80=99you mind changing that to something like this: =E2=80=98This document provides a full specification o= f the "file" Uniform Resource Identifier (URI) scheme, replacing the very brief definition in Section 3.10 of RFC 1738.=E2=80=99 The Security Considerations section is well thought out; thanks. The only thing I can think of that might be added is a few words about non-local file URIs. Section 3 says two significant things that should be highlighted in a security consideration: 1. A file URI can be dependably dereferenced or translated to a local file path only if it is local. 2. This specification neither defines nor forbids any set of operations that might be performed on a file identified by a non-local file URI. Given those two things, I think it would be worth explicitly saying that treating a non-local URI as local or otherwise attempting to perform local operations on a non-local URI can result in security problems. Matthew=E2=80=99s name and address will be on the RFC, of course, but is th= at really the best choice for contact information for the scheme in the registry? Or would it be better to point people to =E2=80=9CApplications a= nd Real-Time Area =E2=80=9D ? In general, we seem to have mixed feelings about listing individuals as contact points for things registered by working group documents (and I fall on the =E2=80=9Cavoid usi= ng specific individuals=E2=80=9D side, because individuals often come and go o= ver relatively short time). The =E2=80=9CReferences=E2=80=9D in the registry template should just be = =E2=80=9Cthis RFC=E2=80=9D, and this RFC number will appear in the registry. A bit of process geekery: In the Acknowledgments, you say=E2=80=A6 This specification is derived from [RFC1738], [RFC3986], and [I-D.hoffman-file-uri] (expired); the acknowledgements in those documents still apply. I don=E2=80=99t imagine there=E2=80=99s actually text from 1738 in here (is= there?). How much text is here from 3986? I=E2=80=99m not talking about concepts, b= ut actual text that was brought over. If there is, have you made sure that all authors of the documents you got text from agree to the terms of BCPs 78 & 79 ? If not, there might need to be a pre-5378 disclaimer in the boilerplate. I suspect we=E2=80=99re OK, because we=E2= =80=99re mostly talking about Larry, Roy, and TimBL, but I just wanted to check. (I personally think the acknowledgments text above is a bit much, unless you=E2=80=99ve really copied a lot of text from those RFCs. But tha= t=E2=80=99s your section to do with as you think best.) References: I don=E2=80=99t think BCP35 is normative, and I=E2=80=99d move it to inform= ative. I don=E2=80=99t think UAX15 is normative, and I=E2=80=99d move it to inform= ative. I think UTF-8 is normative (as you have it), but UNICODE is not. Others might disagree with that. I think I would make RFC 6454 normative, only because it=E2=80=99s listed a= s a reference for =E2=80=9Cthe most secure option=E2=80=9D in the Security Cons= iderations. Barry From nobody Tue Nov 29 11:04:48 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479D4129C31; Tue, 29 Nov 2016 11:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cc6Tz4Kvsk04; Tue, 29 Nov 2016 11:04:28 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64471129C29; Tue, 29 Nov 2016 11:04:28 -0800 (PST) Received: from [10.32.60.81] (50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id uATJ44VU008806 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Nov 2016 12:04:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163] claimed to be [10.32.60.81] From: "Paul Hoffman" To: "Barry Leiba" Date: Tue, 29 Nov 2016 11:04:25 -0800 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: art@ietf.org, draft-ietf-appsawg-file-scheme.all@ietf.org, IETF discussion list , "secdir@ietf.org" Subject: Re: [art] SecDir review of draft-ietf-appsawg-file-scheme-14 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 19:04:30 -0000 On 29 Nov 2016, at 10:49, Barry Leiba wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Thanks for finally getting this through. I think the document is > ready with nits; my detailed comments are below. > > It’s a tiny thing, but where the abstract says “replacing the > definition in RFC 1738,” one may be led to think (I was) that 1738 > has > a more robust definition than it does. D’you mind changing that to > something like this: ‘This document provides a full specification of > the "file" Uniform Resource Identifier (URI) scheme, replacing the > very brief definition in Section 3.10 of RFC 1738.’ Agree. (Humorously, I have some standing here; see below.) > > The Security Considerations section is well thought out; thanks. The > only thing I can think of that might be added is a few words about > non-local file URIs. Section 3 says two significant things that > should be highlighted in a security consideration: > 1. A file URI can be dependably dereferenced or translated to a local > file path only if it is local. > 2. This specification neither defines nor forbids any set of > operations that might be performed on a file identified by a non-local > file URI. > > Given those two things, I think it would be worth explicitly saying > that treating a non-local URI as local or otherwise attempting to > perform local operations on a non-local URI can result in security > problems. Agree. > Matthew’s name and address will be on the RFC, of course, but is > that > really the best choice for contact information for the scheme in the > registry? Or would it be better to point people to “Applications > and > Real-Time Area ” ? In general, we seem to have mixed > feelings about listing individuals as contact points for things > registered by working group documents (and I fall on the “avoid > using > specific individuals” side, because individuals often come and go > over > relatively short time). Agree. > The “References” in the registry template should just be “this > RFC”, > and this RFC number will appear in the registry. > > A bit of process geekery: > In the Acknowledgments, you say… > This specification is derived from [RFC1738], [RFC3986], and > [I-D.hoffman-file-uri] (expired); the acknowledgements in those > documents still apply. > > I don’t imagine there’s actually text from 1738 in here (is > there?). > How much text is here from 3986? I’m not talking about concepts, > but > actual text that was brought over. If there is, have you made sure > that all authors of the documents you got text from agree to the terms > of BCPs 78 & 79 ? If not, there might need to be a pre-5378 > disclaimer in the boilerplate. I suspect we’re OK, because we’re > mostly talking about Larry, Roy, and TimBL, but I just wanted to > check. > > (I personally think the acknowledgments text above is a bit much, > unless you’ve really copied a lot of text from those RFCs. But > that’s > your section to do with as you think best.) I remember that draft-hoffman-file-uri copied from 1739 and 3986. I also remember running away sobbing from the draft, so I appreciate that someone with more fortitude took it up again. > References: > I don’t think BCP35 is normative, and I’d move it to informative. > I don’t think UAX15 is normative, and I’d move it to informative. > I think UTF-8 is normative (as you have it), but UNICODE is not. > Others might disagree with that. I agree with all those. > I think I would make RFC 6454 normative, only because it’s listed as > a > reference for “the most secure option” in the Security > Considerations. Sure. --Paul Hoffman From nobody Tue Nov 29 14:50:49 2016 Return-Path: X-Original-To: art@ietf.org Delivered-To: art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F78129CCB; Tue, 29 Nov 2016 14:50:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.38.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148045984479.11658.9871297229137288131.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2016 14:50:44 -0800 Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-mdn-3798bis@ietf.org, superuser@gmail.com, Barry Leiba , art@ietf.org Subject: [art] Alia Atlas' No Objection on draft-ietf-appsawg-mdn-3798bis-15: (with COMMENT) X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 22:50:45 -0000 Alia Atlas has entered the following ballot position for draft-ietf-appsawg-mdn-3798bis-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Should the Media-Type registration go to the authors of the draft, as specified, or instead to the appsawg & eventually defaulting to the IESG? From nobody Tue Nov 29 15:41:10 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE4F129CD1; Tue, 29 Nov 2016 15:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DsaPjRnFT_o; Tue, 29 Nov 2016 15:41:02 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47669129527; Tue, 29 Nov 2016 15:40:56 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id p16so171794184qta.0; Tue, 29 Nov 2016 15:40:56 -0800 (PST) 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:message-id :subject:to:cc; bh=hhircBLhxcuLmbFAqxUWjowKB8kJ9GWQ1cvbfQdgaxg=; b=zPfvSILr0jdCY7W3uemEgqL15JCCUuCRVx+a7Qncm2ITQRQ/4eyiHFmbm1Zlt5nD5e t/ugbUfenQ9UgPEE4Y1i/Nm0uCbbiyQgTSgkCkheYEfNU59BPeQSLSXYCm2MWkMBVxuG RpYlkP6w+udob4Oa3K42DuUdV7GJ6IYtEBbBh6b/wsDgvmlVmMmAfIpMRvAgKdl2bw82 XHVUnSqgWwdfAiw5/AoTRAFU0Ix0CAy5KbhGqjFsFln//N2QME15XsBAbfrBQbL0+WOW wp5Qi+hIXVrQ3Cn7Dj2YR5E7kCwqeNJ+HBzxVpmR/6h8g0q8HJcKSd0YTf4M1adk/XyU +9ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hhircBLhxcuLmbFAqxUWjowKB8kJ9GWQ1cvbfQdgaxg=; b=gmyYLlRg7chKjgT9VCHvIUO2Ha/a9HrbBItgvLdtv7KpsW9s0ZtP9iaUnmzz2+kyNo Kika52xm6IFJsJYZ2RwVyKKGiWRwYYLiv2bOyLh4JfJHRXs6KooDg9XedCXEf0f0j8q6 kyHJz1j96xbXm27GZTO9kfmP+vpxuAZ5mKLanrcbfu25wve5gzXAfhYmVzTkGqqFnhzc PhMCsAHdLt+U5BFANPsI+c/Ikm2m2VKvLYmxxdcLAsQW9Pvw55uEkRxOPcnXl8Sm0KE8 SVhC7+th90W5XqOYhDo7WxXYaAFmNp9hNTxwS1Mw/tekW0D5RUFB1ELeAhksr9MwK/TA oV3A== X-Gm-Message-State: AKaTC01H4RAqq8epHSP4P+lDxdvxAXHH2XGQg00xjVnBaKGlEEiC9KvLNB99vt0x9bR5tBHwtj6tkYn1cQHSGQ== X-Received: by 10.200.53.138 with SMTP id k10mr29738092qtb.4.1480462855349; Tue, 29 Nov 2016 15:40:55 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.140.41.177 with HTTP; Tue, 29 Nov 2016 15:40:54 -0800 (PST) In-Reply-To: <148045984479.11658.9871297229137288131.idtracker@ietfa.amsl.com> References: <148045984479.11658.9871297229137288131.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Tue, 29 Nov 2016 18:40:54 -0500 X-Google-Sender-Auth: LjqsnQkhJoRZz_Bbv27oi_Xoeow Message-ID: To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "appsawg-chairs@ietf.org" , draft-ietf-appsawg-mdn-3798bis@ietf.org, Murray Kucherawy , The IESG , art@ietf.org Subject: Re: [art] Alia Atlas' No Objection on draft-ietf-appsawg-mdn-3798bis-15: (with COMMENT) X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 23:41:03 -0000 > Should the Media-Type registration go to the authors of the draft, as > specified, or instead to the appsawg & eventually defaulting to the IESG? We're inconsistent about whether we do or don't like having individual contributors as contact points for these things. I'm one of those who don't like it, preferring a (relatively speaking) stable address over an individual who may change jobs (and thus change email addresses), leave IETF work, retire, die, whatever. For my part, I'd prefer to stop using individuals as contact points for registrations that come from working groups or areas, and always use a working-group or area mailing list. Barry From nobody Tue Nov 29 15:44:00 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A97C1295B4; Tue, 29 Nov 2016 15:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4YLnevv_pER; Tue, 29 Nov 2016 15:43:50 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC3412952D; Tue, 29 Nov 2016 15:43:49 -0800 (PST) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uATNhkfk084049 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 29 Nov 2016 17:43:47 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Barry Leiba" Date: Tue, 29 Nov 2016 17:43:46 -0600 Message-ID: In-Reply-To: References: <148045984479.11658.9871297229137288131.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: "appsawg-chairs@ietf.org" , art@ietf.org, Alia Atlas , Murray Kucherawy , The IESG , draft-ietf-appsawg-mdn-3798bis@ietf.org Subject: Re: [art] Alia Atlas' No Objection on draft-ietf-appsawg-mdn-3798bis-15: (with COMMENT) X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 23:43:51 -0000 On 29 Nov 2016, at 17:40, Barry Leiba wrote: >> Should the Media-Type registration go to the authors of the draft, as >> specified, or instead to the appsawg & eventually defaulting to the >> IESG? > > We're inconsistent about whether we do or don't like having individual > contributors as contact points for these things. I'm one of those who > don't like it, preferring a (relatively speaking) stable address over > an individual who may change jobs (and thus change email addresses), > leave IETF work, retire, die, whatever. > > For my part, I'd prefer to stop using individuals as contact points > for registrations that come from working groups or areas, and always > use a working-group or area mailing list. I agree with Barry in general, though I don't have a strong opinion one way or another for this particular document. Alexey, thoughts? Ben. From nobody Tue Nov 29 15:48:04 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE63129532; Tue, 29 Nov 2016 15:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0JjuWutkJTL; Tue, 29 Nov 2016 15:48:02 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0476B12952D; Tue, 29 Nov 2016 15:48:01 -0800 (PST) Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uATNlx96084430 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 29 Nov 2016 17:48:00 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21] From: "Ben Campbell" To: "Barry Leiba" Date: Tue, 29 Nov 2016 17:47:59 -0600 Message-ID: <45734A55-BF3F-4407-BC7B-FEF0F81E69CE@nostrum.com> In-Reply-To: References: <148045984479.11658.9871297229137288131.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: "appsawg-chairs@ietf.org" , art@ietf.org, Alia Atlas , Murray Kucherawy , The IESG , draft-ietf-appsawg-mdn-3798bis@ietf.org Subject: Re: [art] Alia Atlas' No Objection on draft-ietf-appsawg-mdn-3798bis-15: (with COMMENT) X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 23:48:03 -0000 On 29 Nov 2016, at 17:43, Ben Campbell wrote: > On 29 Nov 2016, at 17:40, Barry Leiba wrote: > >>> Should the Media-Type registration go to the authors of the draft, >>> as >>> specified, or instead to the appsawg & eventually defaulting to the >>> IESG? >> >> We're inconsistent about whether we do or don't like having >> individual >> contributors as contact points for these things. I'm one of those >> who >> don't like it, preferring a (relatively speaking) stable address over >> an individual who may change jobs (and thus change email addresses), >> leave IETF work, retire, die, whatever. >> >> For my part, I'd prefer to stop using individuals as contact points >> for registrations that come from working groups or areas, and always >> use a working-group or area mailing list. > > I agree with Barry in general, though I don't have a strong opinion > one way or another for this particular document. Oops, I meant to go on to say that I prefer not to use mailing lists that don't already have some reason to live mostly forever--At least without making it clear that the contact may change over time. From nobody Wed Nov 30 02:20:12 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BFE129655; Wed, 30 Nov 2016 02:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=TKpG0EQm; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=osz47H7n Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynDc5ZkYiDJ8; Wed, 30 Nov 2016 02:20:01 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D0C129634; Wed, 30 Nov 2016 02:19:57 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2551820565; Wed, 30 Nov 2016 05:19:57 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 30 Nov 2016 05:19:57 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=ZvfYmhvnnIK49UYQFaVJ9DD/xQ w=; b=TKpG0EQm2CIkzV1uz0+ekV7kgfDqkiPzhMjLd8n/vSy3kScNA3LKggA7wY PXv5UQVXMU/HuOdi8uApCy8LBsdxLVVp8j29ELmat9PAP/DKS9Erif26k81GmOim zfwdqMhGYtZtYmEPP7YFLWRbdhFN1tZbM8FCblL0+RGlFyhpo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=Zv fYmhvnnIK49UYQFaVJ9DD/xQw=; b=osz47H7nYWHdizCS7aGPe+4iHEE1+PGR1n +kwRBMhFhTYZjgdTZy8TK6fEcxDLOadOVziJPntJL8p6A9D1WXwud7+P5fl26rgD GbMKrd8tBn5ioGEEkX7YTWqnX6eniEzOUKdqI5tle+vyKBynvWuBv5rbOppEVOx3 fGZwv4fkE= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0544B5A67C; Wed, 30 Nov 2016 05:19:56 -0500 (EST) Message-Id: <1480501196.3793049.803543041.07AE0575@webmail.messagingengine.com> From: Alexey Melnikov To: Ben Campbell , Barry Leiba MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-d142962a References: <148045984479.11658.9871297229137288131.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 10:19:56 +0000 In-Reply-To: Archived-At: Cc: appsawg-chairs@ietf.org, art@ietf.org, Alia Atlas , Murray Kucherawy , The IESG , draft-ietf-appsawg-mdn-3798bis@ietf.org Subject: Re: [art] Alia Atlas' No Objection on draft-ietf-appsawg-mdn-3798bis-15: (with COMMENT) X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 10:20:03 -0000 Hi Ben/Barry, On Tue, Nov 29, 2016, at 11:43 PM, Ben Campbell wrote: > On 29 Nov 2016, at 17:40, Barry Leiba wrote: > > >> Should the Media-Type registration go to the authors of the draft, as > >> specified, or instead to the appsawg & eventually defaulting to the > >> IESG? > > > > We're inconsistent about whether we do or don't like having individual > > contributors as contact points for these things. I'm one of those who > > don't like it, preferring a (relatively speaking) stable address over > > an individual who may change jobs (and thus change email addresses), > > leave IETF work, retire, die, whatever. > > > > For my part, I'd prefer to stop using individuals as contact points > > for registrations that come from working groups or areas, and always > > use a working-group or area mailing list. > > I agree with Barry in general, though I don't have a strong opinion one > way or another for this particular document. > > Alexey, thoughts? Are you talking about the following in 3.1: Author: See the Authors' Addresses section of [RFCXXXX] Change controller: IETF I am happy to change "Author" to art@ietf.org or whatever you think is more appropriate. From nobody Wed Nov 30 07:22:48 2016 Return-Path: X-Original-To: art@ietf.org Delivered-To: art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CF3129417; Wed, 30 Nov 2016 07:22:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148051936421.14054.3370105373759594391.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 07:22:44 -0800 Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-mdn-3798bis@ietf.org, superuser@gmail.com, Barry Leiba , art@ietf.org Subject: [art] Alissa Cooper's No Objection on draft-ietf-appsawg-mdn-3798bis-15: (with COMMENT) X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 15:22:44 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-appsawg-mdn-3798bis-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the good work to improve the privacy properties here. = Section 6.2 = "Disposition mode (Section 3.2.6.1) can leak information about recipient's MUA configuration, in particular whether MDNs are acknowledged manually or automatically. If this is a concern, MUAs can return "manual-action/MDN-sent-manually" disposition mode in generated MDNs." I see why this is here, but doesn't recommending falsifying these fields put their integrity in question whenever they are set to manual? I mean, why would recipients trust this information if the RFC actually suggests sending a field that lies about an MDN being automatically acknowledged? = Section 6.2.2 = "The "Reporting-UA" field (Section 3.2.1) might contain enough information to uniquely identify a specific device, usually when combined with other characteristics, particularly if the user agent sends excessive details about the user's system or extensions. However, the source of unique information that is least expected by users is proactive negotiation, including the Accept-Language header fields." I think the use of "However" is tripping me up here. Earlier in the document you have good recommendations about how to mitigate the risk of fingerprinting based on the Reporting-UA field. That guidance is valid regardless of whether other header fields might also contribute to fingerprinting or whether users would expect that (frankly, I don't see how user expectations are relevant here, since most users don't understand fingerprinting anyway). I think something along the following lines to replace the last sentence above would be more accurate: "Even when the guidance in Section 3.2.1 is followed to avoid fingerprinting, other sources of unique information may still be present, including the Accept-Language header fields." From nobody Wed Nov 30 08:45:28 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C6512957F; Wed, 30 Nov 2016 08:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VpFbJGW_SEg; Wed, 30 Nov 2016 08:45:03 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCAA9129A5F; Wed, 30 Nov 2016 08:34:18 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id n21so215101656qka.3; Wed, 30 Nov 2016 08:34:18 -0800 (PST) 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:message-id :subject:to:cc; bh=r9+fOMFza4W1jMlwBDvk+VSH8tcXwVXbjOd5CuzrtPE=; b=dEzCCTJxUc0Cpu0NLVdKYpB1ag3nb5jfDC35cdYWOy7MWUT1+CG15eV04Gsopdbzlz 7GHzM2KhDLM48J/lvo2fET3KwoIdxJzM+5JOJJaudG5sSNDQS1VNc74oXivjM4QkGn14 aSpRCMtm9zsRK42F+xCfBJHdAhahR5s6QQGbL8Zbaj4X2NCgisb8LV9vb9jCn7uR/Um+ eMxqW4R69hORa25h6jTs0RLIpoqKjgjQQT4NArhppOnqi9rL1iIhKobHHCYnP26aAum7 ZHDe6aauuA38/sYfupTi2SxK3bq2EXzGpthJLGBBIAYs2yQ/7UHz0FuFm3l65Rm4dlW1 9kUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=r9+fOMFza4W1jMlwBDvk+VSH8tcXwVXbjOd5CuzrtPE=; b=OTtTKXIXFVl37kVMM97o+Te/gKK2JjQn09CeCciCbrk6UkxQw2awRNLArh1FbCZvuF TOI/OHBaUxlNKNohCvwg2B1pxmf6HJydlbP41m9LUs/xnwzyZc/0Q1zHK9n6dkOW42y8 ZrqRYsx75u8eHOMnC898j0T+htWJ068Ogj6OQjGa/3IOccx334SfchyhT8ahW0pZHfEQ kR6ysi/l9CNOBNVa8E88lPALVWDDroRUrQIJ+DvRH365Eqq1Q1Bt6JkIgVwt2L5TENDX SXX/mZ5GymXAd2hm28F786iGPdI2hqBA45UvpDzeaDco70Le6uOqNQsyT/rl8+G1Olen 505Q== X-Gm-Message-State: AKaTC01h8fAfisxiInZ9DykL4PK6bDR5+vNIjhPdADMnSwrVwKG+Dq140hwoYnp+SXYrsPdW76Desv1iCLaqTw== X-Received: by 10.55.134.1 with SMTP id i1mr29501958qkd.219.1480523657857; Wed, 30 Nov 2016 08:34:17 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.140.41.177 with HTTP; Wed, 30 Nov 2016 08:34:16 -0800 (PST) In-Reply-To: <148051936421.14054.3370105373759594391.idtracker@ietfa.amsl.com> References: <148051936421.14054.3370105373759594391.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Wed, 30 Nov 2016 11:34:16 -0500 X-Google-Sender-Auth: 4oHgSidzuwAHhfRSsUqkwy0KWsA Message-ID: To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "appsawg-chairs@ietf.org" , draft-ietf-appsawg-mdn-3798bis@ietf.org, Murray Kucherawy , The IESG , art@ietf.org Subject: Re: [art] Alissa Cooper's No Objection on draft-ietf-appsawg-mdn-3798bis-15: (with COMMENT) X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 16:45:10 -0000 > = Section 6.2 = > > "Disposition mode (Section 3.2.6.1) can leak information about > recipient's MUA configuration, in particular whether MDNs are > acknowledged manually or automatically. If this is a concern, MUAs > can return "manual-action/MDN-sent-manually" disposition mode in > generated MDNs." > > I see why this is here, but doesn't recommending falsifying these fields > put their integrity in question whenever they are set to manual? I mean, > why would recipients trust this information if the RFC actually suggests > sending a field that lies about an MDN being automatically acknowledged? This comes from my pushing on the point, and is the only reasonable mediation we could come up with. Here's the summary of the discussion: - I don't see any use in having this field at all. There's nothing useful the MDN recipient's mail system can do with it, and it only serves to expose information about the MDN sender's configuration unnecessarily. I'd rather see it removed entirely. - That said, it's been required from the beginning, so (1) all existing implementations send it, (2) existing implementations expect to receive it, and are likely to consider the MDN invalid if it's not present, and (3) implementations are not expected to be reworked to match this spec if we should change that now. - Because of (2) above, we can't just recommend not sending it. Further, the field wasn't designed to be extensible, so we can't use some value such as "unknown" -- that would most likely have the same effect as in (2), that implementations would consider those to be invalid MDNs. - The only thing that leaves is recommending a "standard" value to send if you don't want to expose the real information. That value has to be one of the two defined values, and "manual" is the less bad option (as opposed to telling the recipient's system that you're configured to automatically send MDNs). - And because of the first bullet above (that there's nothing useful to be done with this information anyway), lying about it doesn't hurt anything. It's a bad, but usable solution to an unfortunate problem. Barry From nobody Wed Nov 30 10:03:17 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5905129929; Wed, 30 Nov 2016 10:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=mpfGjUia; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=BuWNz9Zw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgbSWtWyS16C; Wed, 30 Nov 2016 10:03:07 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73F61298BF; Wed, 30 Nov 2016 10:03:07 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 31C14205FC; Wed, 30 Nov 2016 13:03:07 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 30 Nov 2016 13:03:07 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=8k2DbAHAejtp9Rg NU6ocbLaKwMM=; b=mpfGjUiaitfewBVgzfF2nJggiQ26zh6HQddD0mQtwKddZEG Fh7ErbQZ2KmRCOD/K7/5obMO1QdPsT0uBVq6xxNGxVswM+26Ixf6BW73wFOJVnWD twzzV9wQUnGOgDXrBpBQkOddGsFGmolw14RR3b5mdWqHzUBkYTA0n7vITuUY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=8k2DbAHAejtp9RgNU6ocbLaKwMM=; b=BuWNz9ZwsbKirUo0tf7+ Qdj1VoSprEJmcwzyLy7BhQ8dwlgQ85koPR/hk5I67gOiH/tg9UGpNVwa/6xFSqtN sfT0HEdOvDxn94DORfEsPMs6mYw3gB3awyIEzGyJSlVkuADiw0oRNKc/Sl4Fy71f eYGBrW6Y6ewTalOUI83wcFw= X-ME-Sender: X-Sasl-enc: T7dgzFAPNjBA5g04huxHsSCZTFesoBfe6ReylC3ocLDf 1480528986 Received: from sjc-alcoop-8819.cisco.com (unknown [128.107.241.181]) by mail.messagingengine.com (Postfix) with ESMTPA id A87397EEF7; Wed, 30 Nov 2016 13:03:05 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Wed, 30 Nov 2016 13:03:04 -0500 Content-Transfer-Encoding: 7bit Message-Id: <47A9DB1A-CA6E-4C07-B3FE-B31853B3372A@cooperw.in> References: <148051936421.14054.3370105373759594391.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "appsawg-chairs@ietf.org" , draft-ietf-appsawg-mdn-3798bis@ietf.org, Murray Kucherawy , IESG , art@ietf.org Subject: Re: [art] Alissa Cooper's No Objection on draft-ietf-appsawg-mdn-3798bis-15: (with COMMENT) X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 18:03:12 -0000 > On Nov 30, 2016, at 11:34 AM, Barry Leiba wrote: > >> = Section 6.2 = >> >> "Disposition mode (Section 3.2.6.1) can leak information about >> recipient's MUA configuration, in particular whether MDNs are >> acknowledged manually or automatically. If this is a concern, MUAs >> can return "manual-action/MDN-sent-manually" disposition mode in >> generated MDNs." >> >> I see why this is here, but doesn't recommending falsifying these fields >> put their integrity in question whenever they are set to manual? I mean, >> why would recipients trust this information if the RFC actually suggests >> sending a field that lies about an MDN being automatically acknowledged? > > This comes from my pushing on the point, and is the only reasonable > mediation we could come up with. Here's the summary of the > discussion: > > - I don't see any use in having this field at all. There's nothing > useful the MDN recipient's mail system can do with it, and it only > serves to expose information about the MDN sender's configuration > unnecessarily. I'd rather see it removed entirely. > > - That said, it's been required from the beginning, so (1) all > existing implementations send it, (2) existing implementations expect > to receive it, and are likely to consider the MDN invalid if it's not > present, and (3) implementations are not expected to be reworked to > match this spec if we should change that now. > > - Because of (2) above, we can't just recommend not sending it. > Further, the field wasn't designed to be extensible, so we can't use > some value such as "unknown" -- that would most likely have the same > effect as in (2), that implementations would consider those to be > invalid MDNs. > > - The only thing that leaves is recommending a "standard" value to > send if you don't want to expose the real information. That value has > to be one of the two defined values, and "manual" is the less bad > option (as opposed to telling the recipient's system that you're > configured to automatically send MDNs). > > - And because of the first bullet above (that there's nothing useful > to be done with this information anyway), lying about it doesn't hurt > anything. > > It's a bad, but usable solution to an unfortunate problem. Got it, thanks for the explanation. Alissa > > Barry From nobody Wed Nov 30 23:26:49 2016 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE411126BF7; Wed, 30 Nov 2016 23:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8B6mhg8G2Of; Wed, 30 Nov 2016 23:26:37 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34F51294E0; Wed, 30 Nov 2016 23:26:37 -0800 (PST) Received: from mbp-4.local ([IPv6:2601:647:4201:9e61:74b9:1e46:8869:d0e]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id uB17QXxu059169 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 1 Dec 2016 07:26:34 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:74b9:1e46:8869:d0e] claimed to be mbp-4.local To: Ben Campbell , Barry Leiba References: <148045984479.11658.9871297229137288131.idtracker@ietfa.amsl.com> <45734A55-BF3F-4407-BC7B-FEF0F81E69CE@nostrum.com> From: joel jaeggli Message-ID: Date: Wed, 30 Nov 2016 23:26:31 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: <45734A55-BF3F-4407-BC7B-FEF0F81E69CE@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Of0cI2LXFJpm00OXSRENuICEsubC6foOW" Archived-At: Cc: "appsawg-chairs@ietf.org" , art@ietf.org, Alia Atlas , Murray Kucherawy , The IESG , draft-ietf-appsawg-mdn-3798bis@ietf.org Subject: Re: [art] Alia Atlas' No Objection on draft-ietf-appsawg-mdn-3798bis-15: (with COMMENT) X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 07:26:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Of0cI2LXFJpm00OXSRENuICEsubC6foOW Content-Type: multipart/mixed; boundary="l164FEFcE92QMGITxjrX5mFdreiV9AFBm"; protected-headers="v1" From: joel jaeggli To: Ben Campbell , Barry Leiba Cc: "appsawg-chairs@ietf.org" , art@ietf.org, Alia Atlas , Murray Kucherawy , The IESG , draft-ietf-appsawg-mdn-3798bis@ietf.org Message-ID: Subject: Re: [art] Alia Atlas' No Objection on draft-ietf-appsawg-mdn-3798bis-15: (with COMMENT) References: <148045984479.11658.9871297229137288131.idtracker@ietfa.amsl.com> <45734A55-BF3F-4407-BC7B-FEF0F81E69CE@nostrum.com> In-Reply-To: <45734A55-BF3F-4407-BC7B-FEF0F81E69CE@nostrum.com> --l164FEFcE92QMGITxjrX5mFdreiV9AFBm Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 11/29/16 3:47 PM, Ben Campbell wrote: > On 29 Nov 2016, at 17:43, Ben Campbell wrote: > >> On 29 Nov 2016, at 17:40, Barry Leiba wrote: >> >>>> Should the Media-Type registration go to the authors of the draft, a= s >>>> specified, or instead to the appsawg & eventually defaulting to the >>>> IESG? >>> >>> We're inconsistent about whether we do or don't like having individua= l >>> contributors as contact points for these things. I'm one of those wh= o >>> don't like it, preferring a (relatively speaking) stable address over= >>> an individual who may change jobs (and thus change email addresses), >>> leave IETF work, retire, die, whatever. >>> >>> For my part, I'd prefer to stop using individuals as contact points >>> for registrations that come from working groups or areas, and always >>> use a working-group or area mailing list. >> >> I agree with Barry in general, though I don't have a strong opinion >> one way or another for this particular document. > > Oops, I meant to go on to say that I prefer not to use mailing lists > that don't already have some reason to live mostly forever--At least > without making it clear that the contact may change over time. speaking as the one-time culler of mailing lists. we used to have quite a few that had zero traffic for years, I don't thing there's much more assurance that an official mailing list is manned then an email address. joel > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --l164FEFcE92QMGITxjrX5mFdreiV9AFBm-- --Of0cI2LXFJpm00OXSRENuICEsubC6foOW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlg/0KgACgkQ8AA1q7Z/VrLXlACfZinAt/CvgII7f4X5o8+CkOtg jJQAn2UBKvHz3BmF4Bnlag9DVoQdM9Ey =AGqK -----END PGP SIGNATURE----- --Of0cI2LXFJpm00OXSRENuICEsubC6foOW--