Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme
"Mykyta Yevstifeyev (М. Євстіфеєв)" <evnikita2@gmail.com> Mon, 21 November 2011 11:46 UTC
Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F069621F8BBB for <apps-discuss@ietfa.amsl.com>; Mon, 21 Nov 2011 03:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.012
X-Spam-Level:
X-Spam-Status: No, score=-3.012 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+aW6YPdWBXX for <apps-discuss@ietfa.amsl.com>; Mon, 21 Nov 2011 03:46:03 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9BBC21F84A9 for <apps-discuss@ietf.org>; Mon, 21 Nov 2011 03:46:02 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so7389504bkb.31 for <apps-discuss@ietf.org>; Mon, 21 Nov 2011 03:46:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hcG/P+g4WtmYh4kptu6Z3/iC/7B+aWfTebVVU6n71GA=; b=rVy98Y4APnQx4gxZq993Bn8mKTV+hkz+TgOhBqa/VfnKEQPQI/m99CpexLcVXcVyFK VboS3MlgSy+Lnk21YGMsLhMRdibcD60p2Z7SlTV8DvrGMHZSuOxUmt/HyS6dQi2XhdyO lmNAO51nZ2MVmXBZveGZPyBSU1CYGGiggEoFg=
Received: by 10.205.141.73 with SMTP id jd9mr14303601bkc.21.1321875961741; Mon, 21 Nov 2011 03:46:01 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id x14sm7052587bkf.10.2011.11.21.03.46.00 (version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 03:46:01 -0800 (PST)
Message-ID: <4ECA3A2C.1010606@gmail.com>
Date: Mon, 21 Nov 2011 13:46:52 +0200
From: "\"Mykyta Yevstifeyev (М. Євстіфеєв )\"" <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>
References: <4EC16815.80501@gmail.com> <4EC1D4C1.7080406@isode.com> <4EC40EC3.9080304@gmail.com> <4EC8B870.7070105@isode.com>
In-Reply-To: <4EC8B870.7070105@isode.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Apps-discuss list <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-about-uri-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Nov 2011 11:46:04 -0000
20.11.2011 10:21, Alexey Melnikov wrote: > On 16/11/2011 19:28, "Mykyta Yevstifeyev (М. Євстіфеєв)" wrote: >> 15.11.2011 4:56, Alexey Melnikov wrote: >>> Hi Mykyta, >> Hello Alexey. > Hi, > > [...] >>> The 'about' URI MUST syntactically conform to the <about-uri> rule >>> below, expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]: >>> >>> about-uri = "about:" about-token [ about-query ] >>> about-token = segment >>> about-query = "?" query >>> segment = <as specified in RFC 3986, Appendix A> >>> query = <as specified in RFC 3986, Appendix A> >>> >>> In terms of RFC 3986, <about-token> part corresponds to <hier-part>, >>> and <about-query> to the query component of URI. >>> >>> s/query/<query> ? (I didn't check RFC 3986) >> 2.1. URI Scheme Syntax >> >> <query> doesn't include "?" - so query component. > You misunderstood. You have "about-token" enclosed in <>, I think you > need <> around "query" as well. The RFC 3986 <query> production does not include "?" delimiter but only the range of chars allowed in the query component while <about-query> stands for query itself and the delimiter. That would be technically inaccurate if I mentioned <query>. >> >>> >>> >>> 2.2. URI Scheme Semantics >>> >>> However, it is impossible to specify binding between all the >>> possible >>> tokens and the semantics of 'about' URIs that would contain such >>> tokens. Therefore any application MAY resolve an 'about' URI to any >>> desired resource, and MAY redirect such URIs. >>> >>> The meaning of redirection is not defined here. Do you mean >>> redirection in HTTP sense? >>> If yes, I think a reference to HTTP (RFC 2616) is needed. >> Yes, redirection needs clarification. That is not HTTP sense here - >> I meant they can be replaced by some other URIs and than resolved to >> what these URIs refer to, and the latter of them needn't necessarily >> be 'http' URIs. > I don't know of any better reference than RFC 2616. Conceptually one > URI is replaced with another, so even if a non HTTP URI is used, this > should work. I've added the following text: > > and MAY redirect such URIs, i.e. resolve it to a resource commonly > referred to by an other URI. >>> 2.2.1. Special-Purpose 'about' URIs >>> >>> A small, though expandable, range of <about-token>s are reserved for >>> use in special-purpose 'about' URIs, abbreviated "SPU" (special- >>> purpose URI). Such tokens are named "special-purpose 'about' URI >>> tokens", and abbreviated "SPT" (special-purpose token). >>> >>> An SPU is an 'about' URI containing one of the registered SPTs as >>> the >>> <about-token> part. An SPU MUST be handled in strict accordance with >>> the rules defined for SPT contained therein. The SPT specification >>> MAY define additional provisions on handling of <about-query> >>> part in >>> the corresponding SPU; by default, it MUST be ignored for the >>> purpose >>> of handling SPU. >>> >>> Where is this requirement coming from? Is this common behaviour among >>> existing browsers? >> >> We still haven't had such a term as 'special-purpose about URI', and >> so we can't speak of common behavior. IMO, taking into account the >> intended semantics of SPUs, if the meaning of query isn't defined, it >> must be ignored not to eliminate the said semantics and their utility. > It looks like the first part of the sentence is as a recommendation > for new SPU designers, the second part is a recommendation for > developers. This adds to confusion and I suggest you reword this, for > example: > > The SPT specification MAY define additional provisions on handling > of <about-query> part in > the corresponding SPU. Unless specified otherwise, implementations > MUST ignore the <about-query> > part when processing SPUs. Agreed. > > This also avoids passive voice. What's bad of passive voice, BTW? :-) >>> SPU MAY be defined to be unresolvable. This means that an >>> application MUST NOT resolve it in some particular resource. > Did you mean "context" instead of "resource" here? I meant "to" instead of "in" actually. >>> Such >>> SPUs may be used as placeholders, or in some other way. >>> >>> I fail to see utility in this. Can you maybe provide an example >>> of an unresolvable about URI? >>> (This might also affect the IANA registration section which includes >>> this flag in the token registration template.) >> That is what HTML5 wants to define (actually, defines). we had a >> discussion on this previously. > I think that if the document wants to talk about these, it needs to > provide more details. What are such possible details? > > The fact that some URIs might be unresolvable in some contexts is kind > of self evident. But maybe it is just me. >>> 2.2.2. Unrecognized 'about' URIs >>> >>> Naturally, an application will support only a particular range of >>> 'about' URIs; also, some applications will support 'about' URIs that >>> are not supported by an other one. This document specifies the >>> rules >>> for handling unrecognized 'about' URIs. >>> >>> An unrecognized 'about' URIs as a URI that may not be recognized by >>> an application. (Correspondingly, such categorization is per- >>> application, not per-fact.) >>> >>> I don't understand the comment in () and I don't think it adds any >>> value >>> anyway. >> It means that 'about' URI can't be defined to be unrecognized - this >> all depends on application. > The first sentence quoted above already says that. Besides, I don't > understand the meaning of "per-fact" in this context. "per-fact" is meant to be predefined for some particular URI. However, if you insist, I don't object to removing that sentence. >>> An unrecognized 'about' URI SHOULD be >>> handled as the <about:blank> URI, although other behavior is >>> possible. >>> >>> Is there a reason why this is a SHOULD? This seems rather strong here. >>> I am thinking that displaying an error about unrecognized token >>> would be >>> another reasonable choice. In fact it would be my preferred choice. >> This is for what I place SHOULD. And this *is* common behavior. >>> 2.3. Encoding Considerations >>> >>> 'about' URIs are subject to encoding rules defined in RFC 3986 >>> [RFC3986]. 'about' IRIs [RFC3987] are not permitted. >>> >>> The last quoted sentence: why? >>> If an about URI is used to edit configuration, I can see some >>> Unicode being >>> passed in the query part of such URI. >> We have no evidence of use. That is the reason. > I suppose I should test browser behaviour in the 2 cases mentioned above. Case 1 (testing about:yevstifeyev): FF 7.0.1: a warning and about:blank IE8: tried to load the error page (res://ieframe.dll/navcancl.htm) but failed Chrome 15: redirected to chrome://yevstifeyev and displayed an error. Safari 3.2.1 for Win: about:blank. Conclusion: let's remove the recognized/unrecognized section at all, and leave this to app designers. Case 2: (testing about:євстіфеєв - that's my surname in Ukrainian) FF: the same IE: the same Chrome: translated to chrome://xn--b1aai1cfm2ifp/ and showed an error Safari: the same However, that's really not the case for such testing as all currently-in-use 'about' RIs are URIs and not IRIs. Conclusion: no change, I think (we'll be able to change this at any time, should we need that). Mykyta Yevstifeyev > > >
- [apps-discuss] draft-ietf-appsawg-about-uri-scheme Mykyta Yevstifeyev (М. Євстіфеєв)
- [apps-discuss] Comments on draft-ietf-appsawg-abo… Alexey Melnikov
- Re: [apps-discuss] Comments on draft-ietf-appsawg… Mykyta Yevstifeyev (М. Євстіфеєв)
- Re: [apps-discuss] Comments on draft-ietf-appsawg… Barry Leiba
- Re: [apps-discuss] Comments on draft-ietf-appsawg… Frank Ellermann
- Re: [apps-discuss] draft-ietf-appsawg-about-uri-s… Alexey Melnikov
- Re: [apps-discuss] Comments on draft-ietf-appsawg… Alexey Melnikov
- Re: [apps-discuss] draft-ietf-appsawg-about-uri-s… Mykyta Yevstifeyev (М. Євстіфеєв)
- Re: [apps-discuss] Comments on draft-ietf-appsawg… Mykyta Yevstifeyev (М. Євстіфеєв)
- Re: [apps-discuss] Comments on draft-ietf-appsawg… Barry Leiba
- Re: [apps-discuss] Comments on draft-ietf-appsawg… Mykyta Yevstifeyev (М. Євстіфеєв)
- Re: [apps-discuss] Comments on draft-ietf-appsawg… Barry Leiba
- Re: [apps-discuss] Comments on draft-ietf-appsawg… Mykyta Yevstifeyev (М. Євстіфеєв)
- Re: [apps-discuss] Comments on draft-ietf-appsawg… Barry Leiba
- Re: [apps-discuss] Comments on draft-ietf-appsawg… Frank Ellermann
- Re: [apps-discuss] Comments on draft-ietf-appsawg… Barry Leiba
- Re: [apps-discuss] Comments on draft-ietf-appsawg… t.petch
- Re: [apps-discuss] Comments on draft-ietf-appsawg… Mykyta Yevstifeyev (М. Євстіфеєв)
- Re: [apps-discuss] Comments on draft-ietf-appsawg… Jiankang YAO