From duerst@it.aoyama.ac.jp  Mon Nov  1 02:03:43 2010
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB2233A677D for <apps-discuss@core3.amsl.com>; Mon,  1 Nov 2010 02:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.376
X-Spam-Level: 
X-Spam-Status: No, score=-97.376 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3qyGD7ckiFz for <apps-discuss@core3.amsl.com>; Mon,  1 Nov 2010 02:03:42 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by core3.amsl.com (Postfix) with ESMTP id 1305D3A659C for <apps-discuss@ietf.org>; Mon,  1 Nov 2010 02:03:41 -0700 (PDT)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id oA193b6c012779 for <apps-discuss@ietf.org>; Mon, 1 Nov 2010 18:03:37 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 04f8_f9a2_e9afd7fe_e596_11df_826c_001d096c566a; Mon, 01 Nov 2010 18:03:37 +0900
Received: from [IPv6:::1] ([133.2.210.1]:46178) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S147999B> for <apps-discuss@ietf.org> from <duerst@it.aoyama.ac.jp>; Mon, 1 Nov 2010 18:03:37 +0900
Message-ID: <4CCE8263.8090300@it.aoyama.ac.jp>
Date: Mon, 01 Nov 2010 18:03:31 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>
References: <AANLkTimNSDJJTNyUKgKHAUUPXxvmQ8iYbiZAnk=-LA8r@mail.gmail.com>
In-Reply-To: <AANLkTimNSDJJTNyUKgKHAUUPXxvmQ8iYbiZAnk=-LA8r@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Startup of the APPSAWG
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 01 Nov 2010 09:03:44 -0000

Two points:

On 2010/10/31 18:23, Barry Leiba wrote:
> As y'all may have seen, the IESG approved the creation of the
> Applications Area Working Group (appsawg), and appointed Jiankang Yao
> and me as working group chairs.  The charter is here:
>     http://www.ietf.org/dyn/wg/charter/appsawg-charter
> In order to get things started, we need to do two things:
>
> 1. Set up procedures for how the working group will operate.

I think we shouldn't spend too much time on this. If we can come up with 
some general guidelines over time based on actual cases that worked and 
didn't, then fine. But working more on process than on actual work is 
counterproductive.

> 2. Choose some documents to work on.
>
> To that end, we'll be having the first face-to-face meeting of the
> appsawg during (as part of) the Applications Area open meeting at IETF
> 79, in the Monday morning slot (9 to 11:30 a.m., 8 Nov).  Email
> discussion related to appsawg will happen on this mailing list, the
> apps-discuss list.
>
> For item 1, here's a set of sub-items the chairs think we need to decide:
>
> 1a. What criteria will we use to decide that a document should be
> handled by appsawg?  Implicit in this is how we decide that the
> document doesn't belong in an existing working group, and that the
> authors shouldn't be working on forming a new one.  I note that it may
> be the case that the ADs are already, by suggesting a document to us,
> advising that they don't want a new working group for the work.  I
> suggest that sometimes, part of this working group's job may be to
> push back on that and say, "We disagree.  The scope of this work is
> beyond what appsawg should be taking up, and you should reconsider
> your advice to the authors."

> As for initial documents, the ADs have suggested the following ones,
> and if there's time in Beijing to go over them and have some initial
> discussion about adoption, we'll put them on the agenda.  Please try
> to review them before then.
>
> 2a. draft-merrick-jms-uri
> 2b. draft-nottingham-http-portal
> 2c. draft-faltstrom-5892bis (update of IDNA to handle Unicode 6.0)

Especially in respect to 2c (but also 2a), while there is no IDNAbis WG 
anymore, the mailing list of the WG is still alive. As far as I know, 
that mailing list has more experts (in particular also from the Unicode 
side) subscribed than the apps-discuss list (i.e. this WG). So one way 
to reword these questions would be:

- Is there a mailing list (maybe of a past WG) that can provide better 
review than this WG?
- How can we make sure we get that review?
- Would it be better in some cases to defer completely to such a mailing 
list (and handle the document as an individual submission)?

For 2b, this question is how to get review from an existing WG.

Regards,    Martin.

> Comments on any of this prior to IETF 79 are also, of course, welcome.
>
> Barry and Jiankang, your friendly neighbourhood chairs
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

From alexey.melnikov@isode.com  Tue Nov  2 04:09:09 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410033A69A1 for <apps-discuss@core3.amsl.com>; Tue,  2 Nov 2010 04:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level: 
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3slV1fvcNCU for <apps-discuss@core3.amsl.com>; Tue,  2 Nov 2010 04:09:08 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 1042828C0E7 for <apps-discuss@ietf.org>; Tue,  2 Nov 2010 04:09:08 -0700 (PDT)
Received: from [192.168.20.2] ((unknown) [212.183.140.22])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <TM=xUgAEeYU7@rufus.isode.com>; Tue, 2 Nov 2010 11:09:09 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4CCFF148.2050006@isode.com>
Date: Tue, 02 Nov 2010 11:08:56 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
References: <AANLkTimNSDJJTNyUKgKHAUUPXxvmQ8iYbiZAnk=-LA8r@mail.gmail.com> <4CCE8263.8090300@it.aoyama.ac.jp>
In-Reply-To: <4CCE8263.8090300@it.aoyama.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: quoted-printable
Cc: Barry Leiba <barryleiba@computer.org>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Startup of the APPSAWG
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 02 Nov 2010 11:09:09 -0000

Hi Martin,

Martin J. D=FCrst wrote:

> Two points:
>
> On 2010/10/31 18:23, Barry Leiba wrote:
>
>> As y'all may have seen, the IESG approved the creation of the
>> Applications Area Working Group (appsawg), and appointed Jiankang Yao
>> and me as working group chairs.  The charter is here:
>>     http://www.ietf.org/dyn/wg/charter/appsawg-charter
>> In order to get things started, we need to do two things:
>>
>> 1. Set up procedures for how the working group will operate.
>
> I think we shouldn't spend too much time on this. If we can come up=20
> with some general guidelines over time based on actual cases that=20
> worked and didn't, then fine. But working more on process than on=20
> actual work is counterproductive.

I tend to agree. However any rules currently in force should be clearly=20
stated on the mailing list, so that people know what to expect.

>> 2. Choose some documents to work on.
>>
>> To that end, we'll be having the first face-to-face meeting of the
>> appsawg during (as part of) the Applications Area open meeting at IETF
>> 79, in the Monday morning slot (9 to 11:30 a.m., 8 Nov).  Email
>> discussion related to appsawg will happen on this mailing list, the
>> apps-discuss list.
>>
>> For item 1, here's a set of sub-items the chairs think we need to=20
>> decide:
>>
>> 1a. What criteria will we use to decide that a document should be
>> handled by appsawg?  Implicit in this is how we decide that the
>> document doesn't belong in an existing working group, and that the
>> authors shouldn't be working on forming a new one.  I note that it may
>> be the case that the ADs are already, by suggesting a document to us,
>> advising that they don't want a new working group for the work.  I
>> suggest that sometimes, part of this working group's job may be to
>> push back on that and say, "We disagree.  The scope of this work is
>> beyond what appsawg should be taking up, and you should reconsider
>> your advice to the authors."
>
>> As for initial documents, the ADs have suggested the following ones,
>> and if there's time in Beijing to go over them and have some initial
>> discussion about adoption, we'll put them on the agenda.  Please try
>> to review them before then.
>>
>> 2a. draft-merrick-jms-uri
>> 2b. draft-nottingham-http-portal
>> 2c. draft-faltstrom-5892bis (update of IDNA to handle Unicode 6.0)
>
> Especially in respect to 2c (but also 2a), while there is no IDNAbis=20
> WG anymore, the mailing list of the WG is still alive. As far as I=20
> know, that mailing list has more experts (in particular also from the=20
> Unicode side) subscribed than the apps-discuss list (i.e. this WG). So=20
> one way to reword these questions would be:
>
> - Is there a mailing list (maybe of a past WG) that can provide better=20
> review than this WG?
> - How can we make sure we get that review?

If there are active mailing lists for closed WGs, we should be asking=20
for reviews there. However, this doesn't mean that all WGLCs will only=20
be issued on such mailing lists, they need to happen on=20
apps-discuss@ietf.org.

> - Would it be better in some cases to defer completely to such a=20
> mailing list (and handle the document as an individual submission)?

My personal answer to this is likely to be "no". With several individual=20
submissions I handled which were reviewed on such IETF mailing lists, I=20
got comments from some of the reviewers (mostly from outside of IESG)=20
that any claims of rough consensus on such mailing lists are not valid,=20
due to the fact that the document is not a WG document. While I=20
personally disagreed with such comments, I had no way of arguing against=20
them.

I.e., I don't believe that "that document should be processed as an=20
individual submission because there is an existing IETF mailing list for=20
a closed WG" should be a valid outcome.

> For 2b, this question is how to get review from an existing WG.


From sm@elandsys.com  Tue Nov  2 07:17:19 2010
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4F4C3A687F for <apps-discuss@core3.amsl.com>; Tue,  2 Nov 2010 07:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZH87z6mNJr4 for <apps-discuss@core3.amsl.com>; Tue,  2 Nov 2010 07:17:16 -0700 (PDT)
Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 3B5B03A68DB for <apps-discuss@ietf.org>; Tue,  2 Nov 2010 07:17:16 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.232.26]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oA2EHCtH015878 for <apps-discuss@ietf.org>; Tue, 2 Nov 2010 07:17:18 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1288707439; bh=bYFBvusDoVEVh080XfYWjf5kEa0=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type; b=GfRduTM9M9hjfRjvQ7DGJZMAs/1UczZyjijj+PlciPTT7oBWg/yvcAFspP1Z+uoYA HdEFcXGK4Ax7gBVL4HeFsv/89bbEOjJKaEfLfwJCNUepULzARURWu+TpTMyIDciwXj r3dybI2Nuo2rl7MtA11svTlfXRFf76rPbZhnXY20=
Message-Id: <6.2.5.6.2.20101102063839.0b523458@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 02 Nov 2010 06:52:20 -0700
To: apps-discuss@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [apps-discuss] Apps Area Review Team Report for October 2010
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 02 Nov 2010 14:17:19 -0000

Hello,

The Applications Area Review Team provides semi-formal reviews of 
Internet-Drafts as a way to improve the quality of IETF 
specifications.  The members of the team are selected from the IETF 
community, especially from among active participants and recognized 
experts in the Applications Area.

The following reviews have been performed in October 2010:

    Reviewer             I-D

  Ted Hardie      draft-zeilenga-ldap-dontusecopy-08
  Xiaodong Lee    draft-cridland-acap-vendor-registry-01
  Barry Leiba     draft-ietf-csi-hash-threat-10
  Scott Lawrence  draft-ietf-geopriv-held-identity-extensions-04


Regards,
S. Moonesamy
On behalf of the Apps Review Team
http://www.apps.ietf.org/content/applications-area-review-team


From Kurt.Zeilenga@Isode.COM  Tue Nov  2 20:56:32 2010
Return-Path: <Kurt.Zeilenga@Isode.COM>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3467C3A6A55 for <apps-discuss@core3.amsl.com>; Tue,  2 Nov 2010 20:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.239
X-Spam-Level: 
X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kqH1al6FhSx for <apps-discuss@core3.amsl.com>; Tue,  2 Nov 2010 20:56:30 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CAC9A3A68AB for <apps-discuss@ietf.org>; Tue,  2 Nov 2010 20:56:28 -0700 (PDT)
Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <TNDdcAAEeXIO@rufus.isode.com>; Wed, 3 Nov 2010 03:56:33 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
In-Reply-To: <4CBDE23C.7050904@stpeter.im>
Date: Tue, 2 Nov 2010 20:56:30 -0700
Message-Id: <33432E57-C1EF-4258-A2F9-7CBD730C302D@Isode.COM>
References: <4CBDE23C.7050904@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1081)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 03 Nov 2010 03:56:32 -0000

This is completely counter to BCP 82 which argues that "Assigning =
Experimental and Testing Numbers Considered Useful" [published 2004], =
and BCP 26 [published 2008].  Has our operational experience in the last =
few years been so different than that the previous decades that =
consensus shifted 180 degrees? =20

I generally oppose publication of this I-D as a BCP and give +1 to =
Nathaniel's comments.

(If consensus has shifted 180 degrees, this I-D really ought to obsolete =
BCP 82 and update BCP 26.)

-- Kurt=

From dhc@dcrocker.net  Tue Nov  2 21:10:16 2010
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2605B3A6867 for <apps-discuss@core3.amsl.com>; Tue,  2 Nov 2010 21:10:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWIxtHOE2hz0 for <apps-discuss@core3.amsl.com>; Tue,  2 Nov 2010 21:10:14 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 41F283A6A5A for <apps-discuss@ietf.org>; Tue,  2 Nov 2010 21:10:13 -0700 (PDT)
Received: from [192.168.1.7] (ppp-67-124-89-109.dsl.pltn13.pacbell.net [67.124.89.109]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oA34ADAh012020 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 2 Nov 2010 21:10:19 -0700
Message-ID: <4CD0E09C.40303@dcrocker.net>
Date: Tue, 02 Nov 2010 21:10:04 -0700
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
References: <4CBDE23C.7050904@stpeter.im> <33432E57-C1EF-4258-A2F9-7CBD730C302D@Isode.COM>
In-Reply-To: <33432E57-C1EF-4258-A2F9-7CBD730C302D@Isode.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 02 Nov 2010 21:10:19 -0700 (PDT)
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 03 Nov 2010 04:10:16 -0000

On 11/2/2010 8:56 PM, Kurt Zeilenga wrote:
> Has our operational experience in the last few years been so different than
> that the previous decades that consensus shifted 180 degrees?


X- was first introduced as a construct in RFC 822 in 1982.

It was dropped as a construct in the revision, RFC 2822, in 2001.

That's longer than "last few years".

The construct actually /impedes/ standardization.

It was a clever idea.  It turned out to be misguided.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From Claudio.Allocchio@garr.it  Wed Nov  3 05:06:48 2010
Return-Path: <Claudio.Allocchio@garr.it>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9E03A6AA2 for <apps-discuss@core3.amsl.com>; Wed,  3 Nov 2010 05:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TPX+VLKI17f for <apps-discuss@core3.amsl.com>; Wed,  3 Nov 2010 05:06:47 -0700 (PDT)
Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id EB8F43A6A9D for <apps-discuss@ietf.org>; Wed,  3 Nov 2010 05:06:46 -0700 (PDT)
Received: from i2conf-776-168.sox.net (i2conf-776-168.sox.net [143.215.176.168]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id oA3C6ZP6030010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Nov 2010 13:06:39 +0100 (CET)
X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it oA3C6ZP6030010
DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=AHRSULYmV0YQUOXruxX2eJ+r5gOF/PPwqitqWjLjS+RJAuounh7rofpzjD9L6wm7b QRKebQW/Oh49lVlloDXvssGdT3IwgyFzs4xzYOtRFQDCE4noJ23xpHcivdzaV77Nx6s IkBTpesrQ5nQzLEIUSLDEpxLPdAbtqHt9U4eUtw=
Date: Wed, 3 Nov 2010 13:06:35 +0100 (CET)
From: Claudio Allocchio <Claudio.Allocchio@garr.it>
X-X-Sender: claudio@i2conf-776-168.sox.net
To: dcrocker@bbiw.net
In-Reply-To: <4CD0E09C.40303@dcrocker.net>
Message-ID: <Pine.OSX.4.64.1011031304390.1278@i2conf-776-168.sox.net>
References: <4CBDE23C.7050904@stpeter.im> <33432E57-C1EF-4258-A2F9-7CBD730C302D@Isode.COM> <4CD0E09C.40303@dcrocker.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: I-D	Action:draft-saintandre-xdash-considered-harmful-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 03 Nov 2010 12:06:48 -0000

> On 11/2/2010 8:56 PM, Kurt Zeilenga wrote:
>> Has our operational experience in the last few years been so different than
>> that the previous decades that consensus shifted 180 degrees?
>
>
> X- was first introduced as a construct in RFC 822 in 1982.
>
> It was dropped as a construct in the revision, RFC 2822, in 2001.
>
> That's longer than "last few years".
>
> The construct actually /impedes/ standardization.

we can provide a collection of X-stuff doing the same thing... with 
different names and syntax... thus it has turned into a problem. At least 
some guidance to track it back from wilderness is needed.

> It was a clever idea.  It turned out to be misguided.

I'd say: not enough monitored...

>
> d/
> -- 
>
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

From Kurt.Zeilenga@Isode.COM  Wed Nov  3 06:21:00 2010
Return-Path: <Kurt.Zeilenga@Isode.COM>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0F33A6838 for <apps-discuss@core3.amsl.com>; Wed,  3 Nov 2010 06:20:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENV65lfoGu7i for <apps-discuss@core3.amsl.com>; Wed,  3 Nov 2010 06:20:56 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5C11D3A6881 for <apps-discuss@ietf.org>; Wed,  3 Nov 2010 06:20:56 -0700 (PDT)
Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <TNFhvAAEeSSu@rufus.isode.com>; Wed, 3 Nov 2010 13:21:02 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
In-Reply-To: <4CD0E09C.40303@dcrocker.net>
Date: Wed, 3 Nov 2010 06:20:57 -0700
Message-Id: <EC15EB0A-8184-4CCF-B6D1-FB387FB7477E@Isode.COM>
References: <4CBDE23C.7050904@stpeter.im> <33432E57-C1EF-4258-A2F9-7CBD730C302D@Isode.COM> <4CD0E09C.40303@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.1081)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 03 Nov 2010 13:21:00 -0000

On Nov 2, 2010, at 9:10 PM, Dave CROCKER wrote:

>=20
>=20
> On 11/2/2010 8:56 PM, Kurt Zeilenga wrote:
>> Has our operational experience in the last few years been so =
different than
>> that the previous decades that consensus shifted 180 degrees?
>=20
>=20
> X- was first introduced as a construct in RFC 822 in 1982.
>=20
> It was dropped as a construct in the revision, RFC 2822, in 2001.
>=20
> That's longer than "last few years".

A few years since we last approved BCP 26.

>=20
> The construct actually /impedes/ standardization.
>=20
> It was a clever idea.  It turned out to be misguided.
>=20
> d/
> --=20
>=20
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From royersoftwareandservices@gmail.com  Wed Nov  3 07:56:47 2010
Return-Path: <royersoftwareandservices@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848743A6AC9 for <apps-discuss@core3.amsl.com>; Wed,  3 Nov 2010 07:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.27
X-Spam-Level: 
X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6EBd14t1+91 for <apps-discuss@core3.amsl.com>; Wed,  3 Nov 2010 07:56:46 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 50D243A6AC5 for <apps-discuss@ietf.org>; Wed,  3 Nov 2010 07:56:46 -0700 (PDT)
Received: by iwn40 with SMTP id 40so836164iwn.31 for <apps-discuss@ietf.org>; Wed, 03 Nov 2010 07:56:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=oUfg4xsTCCNLbdSoTjYC0Y0EIBPvUYuDEIZ5C2ua2WU=; b=IzcwhHCwrHFZgiuo38/IK9EEXFXSyq/HqfbcUYB94S9z1q7ymF43YC5aq5B0TJZpmg aFExdp1xGb//QAxKTjk29ra544wPsBEDuT/XgdEn2uUc2qRLD7Qix2TunGlTN6gPTXrf iKSzzKvKfTZqsIhHDmipFnKIaRSSPo/5+ja6Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=iKQuLhwxwsVNKaDHOZJtf3hx+IPwN9/lTGR+MNt0/xtzPlO3TPP9Jkoghuh+Ej2DXI vqr78Pfkc3TUg/710M6pRS0ETYJL0nFUMYqDy1XnamVveqE4EhjfGNpSpT5hOF57o5GA 10ZJ9YR7kFXI4zZWo2kOgvi2DefGSKG8iIe6c=
Received: by 10.231.39.205 with SMTP id h13mr4239923ibe.148.1288796213246; Wed, 03 Nov 2010 07:56:53 -0700 (PDT)
Received: from [192.168.0.58] ([63.227.129.161]) by mx.google.com with ESMTPS id fw4sm939620ibb.7.2010.11.03.07.56.51 (version=SSLv3 cipher=RC4-MD5); Wed, 03 Nov 2010 07:56:52 -0700 (PDT)
Message-ID: <4CD17826.40002@gmail.com>
Date: Wed, 03 Nov 2010 08:56:38 -0600
From: Royer Software and Services <royersoftwareandservices@gmail.com>
Organization: http://Project-Contracting.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4CBDE23C.7050904@stpeter.im>	<33432E57-C1EF-4258-A2F9-7CBD730C302D@Isode.COM> <4CD0E09C.40303@dcrocker.net>
In-Reply-To: <4CD0E09C.40303@dcrocker.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 03 Nov 2010 14:56:47 -0000

Stop producing 'X-' == good idea.

There was an annoyingly long X- debate on calsch years ago.

The problem there was vendors hijacking the protocol with tons of their 
vendor specific extensions such
that it was difficult to have real interoperability.

Another problem was when vendors used their extensions to alter the flow 
or meaning of the data. With their
application it works just fine, with their competitors, it would 
sometimes work depending on the rest of the data.
So calsch said that those not approved by the working group, are 
considered experimental and must start
with X- .

A registration process with some additional instructions would have 
solved the problem. I can see in the future
it would be written as, those extensions not approved by the working 
groups must be registered vendor specific
and must not alter the flow or meaning of the data.

--

Doug - Royer Software and Services
http://Project-Contracting.com
(208) 806-1358 / (714) 989-6135



From alexey.melnikov@isode.com  Sat Nov  6 19:24:22 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7333A6974 for <apps-discuss@core3.amsl.com>; Sat,  6 Nov 2010 19:24:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.99
X-Spam-Level: 
X-Spam-Status: No, score=-101.99 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41imVkVfgp1u for <apps-discuss@core3.amsl.com>; Sat,  6 Nov 2010 19:24:21 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 8261D3A6768 for <apps-discuss@ietf.org>; Sat,  6 Nov 2010 19:24:21 -0700 (PDT)
Received: from [130.129.119.237] (dhcp-77ed.meeting.ietf.org [130.129.119.237])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <TNYN4wAEeV=T@rufus.isode.com>; Sun, 7 Nov 2010 02:24:36 +0000
Message-ID: <4CD60DE4.7000402@isode.com>
Date: Sun, 07 Nov 2010 02:24:36 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] Agenda for the Apps Area meeting on Monday
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 07 Nov 2010 02:24:22 -0000

Hi,
This is the proposed agenda from your slightly disorganized Apps ADs:

[ 5 mins] A proposal to host TZ database at IANA/IETF: 
draft-lear-iana-timezone-database-00.txt
[15 mins] Alexey Melnikov: MIME and the Web 
<http://www.ietf.org/id/draft-masinter-mime-web-info-01.txt>
[15 mins] John C Klensin: IDNA and Unicode 6.0 
(https://datatracker.ietf.org/doc/draft-faltstrom-5892bis/)
[15 mins] Alain Durand <adurand@juniper.net>: 
http://www.ietf.org/id/draft-durand-server-logging-recommendations-00.txt
[20 mins] Brian Carpenter: Problem statement for Referral objects 
(draft-carpenter-referral-ps-01)
[10 mins] Open mic and other issues

[30 mins] Initial meeting of the APPSAWG


From hannes.tschofenig@gmx.net  Sat Nov  6 19:56:33 2010
Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78403A69A8 for <apps-discuss@core3.amsl.com>; Sat,  6 Nov 2010 19:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlPNhIlQ2dU8 for <apps-discuss@core3.amsl.com>; Sat,  6 Nov 2010 19:56:33 -0700 (PDT)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 3A6F73A69A7 for <apps-discuss@ietf.org>; Sat,  6 Nov 2010 19:56:33 -0700 (PDT)
Received: (qmail invoked by alias); 07 Nov 2010 02:56:48 -0000
Received: from dhcp-7730.meeting.ietf.org (EHLO dhcp-7730.meeting.ietf.org) [130.129.119.48] by mail.gmx.net (mp004) with SMTP; 07 Nov 2010 03:56:48 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/PwfVkD5DPqSEI4sP18/Z6BoHOoAIeMx/z6K/C7r GYdUg5h2pmIdqS
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1081)
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Date: Sat, 6 Nov 2010 21:56:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FCF452D-7108-400F-9992-0079D52B279F@gmx.net>
References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net>
To: apps-discuss@ietf.org
X-Mailer: Apple Mail (2.1081)
X-Y-GMX-Trusted: 0
Subject: [apps-discuss] ** OAuth Tutorial & OAuth Security Session **
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 07 Nov 2010 02:56:33 -0000

Hi all,=20

please consider attending the following two meetings!=20

** OAuth Security Session **

	=95 Date: Monday, 13:00-15:00
	=95 Location: IAB breakout room (Jade 2)
	=95 Contact: Hannes Tschofenig hannes.tschofenig@gmx.net
The security consideration section of OAuth 2.0 (draft -10) is still =
empty. Hence, we would like to put some time aside to discuss what =
security threats, requirements, and countermeasures need to be =
described. We will use the Monday, November 8, 1300-1500 slot to have a  =
discussion session.

As a starting point I suggest to look at the following documents:

	=95 =
http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
	=95 http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy
	=95 =
http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt

Note: If you are unfamiliar with OAuth then the OAuth tutorial session =
might be more suitable for you!



** OAuth Tutorial **

	=95 Date: Wednesday, 19:30 (after the plenary)
	=95 Location: IAB breakout room (Jade 2)
	=95 Contact: Hannes Tschofenig hannes.tschofenig@gmx.net
OAuth allows a user to grant a third-party Web site or application =
access to their resources, without necessarily revealing their =
credentials, or even their identity. The OAuth working group, =
seehttp://datatracker.ietf.org/wg/oauth/charter/, is currently trying to =
finalize their main specification, namely OAuth v2: =
http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/

Based on the positive response at the last IETF meeting (in Maastricht) =
we decided to hold another OAuth tutorial, namely on *Wednesday, =
starting at 19:30 (after the IETF Operations and Administration Plenary) =
till about 21:00. (Note: I had to switch the day because of the social =
event!)

It is helpful to read through the documents available int he working =
group but not required.

Up-to-date information can be found here: =
http://www.ietf.org/registration/MeetingWiki/wiki/79bofs

Ciao
Hannes

From msk@cloudmark.com  Sun Nov  7 21:25:23 2010
Return-Path: <msk@cloudmark.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8C73A694A for <apps-discuss@core3.amsl.com>; Sun,  7 Nov 2010 21:25:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.432
X-Spam-Level: 
X-Spam-Status: No, score=-104.432 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05Bl4W69AV+E for <apps-discuss@core3.amsl.com>; Sun,  7 Nov 2010 21:25:21 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id D84F13A6900 for <apps-discuss@ietf.org>; Sun,  7 Nov 2010 21:25:20 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 7 Nov 2010 21:25:41 -0800
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: "ietf-dkim@mipassoc.org" <ietf-dkim@mipassoc.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Date: Sun, 7 Nov 2010 21:25:40 -0800
Thread-Topic: New Version Notification for draft-kucherawy-authres-vbr-00 
Thread-Index: Act/BKqYB/7Ls7DOTfW9Mm/P+7ZwGQAAH9Xw
Message-ID: <F5833273385BB34F99288B3648C4F06F1340E63E1A@EXCH-C2.corp.cloudmark.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed; boundary="_002_F5833273385BB34F99288B3648C4F06F1340E63E1AEXCHC2corpclo_"
MIME-Version: 1.0
Subject: [apps-discuss] FW: New Version Notification for draft-kucherawy-authres-vbr-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 08 Nov 2010 05:25:23 -0000

--_002_F5833273385BB34F99288B3648C4F06F1340E63E1AEXCHC2corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I've introduced a draft to register the relaying of VBR results via Authent=
ication-Results header fields.  I imagine this will be something the new AP=
PS area working group can pick up, but it also seems appropriate to let the=
 DKIM WG know about it.

Comments welcome, even if it's just "I read this, looks good to me" so that=
 some support or consensus can be recorded.

-MSK

--_002_F5833273385BB34F99288B3648C4F06F1340E63E1AEXCHC2corpclo_
Content-Type: message/rfc822

Received: from mail.cloudmark.com (208.83.136.59) by ht1.cloudmark.com
 (172.22.10.78) with Microsoft SMTP Server id 8.2.254.0; Sun, 7 Nov 2010
 21:20:32 -0800
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32])	by
 mail.cloudmark.com (8.14.3/8.12.10) with ESMTP id oA85KWpv028330	for
 <msk@cloudmark.com>; Sun, 7 Nov 2010 21:20:32 -0800
Received: by core3.amsl.com (Postfix, from userid 30)	id B92B63A697C; Sun,  7
 Nov 2010 21:20:11 -0800 (PST)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: "Murray S. Kucherawy" <msk@cloudmark.com>
Date: Sun, 7 Nov 2010 21:20:11 -0800
Subject: New Version Notification for draft-kucherawy-authres-vbr-00 
Thread-Topic: New Version Notification for draft-kucherawy-authres-vbr-00 
Thread-Index: Act/BKqYB/7Ls7DOTfW9Mm/P+7ZwGQ==
Message-ID: <20101108052011.B92B63A697C@core3.amsl.com>
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: malice.corp.cloudmark.com
X-MS-Has-Attach: 
X-MS-Exchange-Organization-SenderIdResult: Fail
X-MS-Exchange-Organization-SCL: 0
X-MS-Exchange-Organization-PRD: ietf.org
X-MS-TNEF-Correlator: 
received-spf: Fail (malice.corp.cloudmark.com: domain of
 idsubmission@ietf.org does not designate 208.83.136.59 as permitted sender)
 receiver=malice.corp.cloudmark.com; client-ip=208.83.136.59;
 helo=mail.cloudmark.com;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0

DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQta3VjaGVyYXd5LWF1dGhyZXMtdmJyLTAwLnR4
dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE11cnJheSBLdWNoZXJhd3kgYW5k
IHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWt1Y2hl
cmF3eS1hdXRocmVzLXZicg0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgQXV0aGVudGljYXRpb24t
UmVzdWx0cyBSZWdpc3RyYXRpb24gRm9yIFZvdWNoIEJ5IFJlZmVyZW5jZSBSZXN1bHRzDQpDcmVh
dGlvbl9kYXRlOgkgMjAxMC0xMS0wNw0KV0cgSUQ6CQkgSW5kZXBlbmRlbnQgU3VibWlzc2lvbg0K
TnVtYmVyX29mX3BhZ2VzOiA3DQoNCkFic3RyYWN0Og0KVGhpcyBtZW1vIHVwZGF0ZXMgdGhlIHJl
Z2lzdHJ5IG9mIHByb3BlcnRpZXMgaW4gQXV0aGVudGljYXRpb24tDQpSZXN1bHRzOiBtZXNzYWdl
IGhlYWRlciBmaWVsZHMgdG8gYWxsb3cgcmVsYXlpbmcgb2YgdGhlIHJlc3VsdHMgb2YgYQ0KVm91
Y2ggQnkgUmVmZXJlbmNlIHF1ZXJ5Lg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRo
ZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQoNCg==

--_002_F5833273385BB34F99288B3648C4F06F1340E63E1AEXCHC2corpclo_--

From msk@cloudmark.com  Mon Nov  8 10:38:18 2010
Return-Path: <msk@cloudmark.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6F53A697A for <apps-discuss@core3.amsl.com>; Mon,  8 Nov 2010 10:38:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.777
X-Spam-Level: 
X-Spam-Status: No, score=-103.777 tagged_above=-999 required=5 tests=[AWL=-2.044, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, SARE_URI_EQUALS=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfGA2zpAOexo for <apps-discuss@core3.amsl.com>; Mon,  8 Nov 2010 10:38:16 -0800 (PST)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id AF8EA3A694F for <apps-discuss@ietf.org>; Mon,  8 Nov 2010 10:38:16 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 8 Nov 2010 10:38:38 -0800
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: Alessandro Vesely <vesely@tana.it>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Date: Mon, 8 Nov 2010 10:38:38 -0800
Thread-Topic: draft-kucherawy-authres-vbr-00
Thread-Index: Act/Qtw1UOBYdgrkQJmWs9ESogyVjwAL+9ZA
Message-ID: <F5833273385BB34F99288B3648C4F06F1340E63E3E@EXCH-C2.corp.cloudmark.com>
References: <F5833273385BB34F99288B3648C4F06F1340E63E1A@EXCH-C2.corp.cloudmark.com> <4CD7E726.5050505@tana.it>
In-Reply-To: <4CD7E726.5050505@tana.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] draft-kucherawy-authres-vbr-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 08 Nov 2010 18:38:19 -0000

> -----Original Message-----
> From: ietf-dkim-bounces@mipassoc.org [mailto:ietf-dkim-bounces@mipassoc.o=
rg] On Behalf Of Alessandro Vesely
> Sent: Monday, November 08, 2010 4:04 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] FW: New Version Notification for draft-kucherawy=
-authres-vbr-00
>=20
> Nice one, Murray!
>=20
> Section 4 (Definition) is ambiguous, though.  It says "the DNS domain
> name used to perform the VBR query", but a VBR query takes two domain
> names.  I think mentioning the tag (md, according to the example)
> would make it clearer.

I'd be fine with changing it to "md=3D".  It's more consistent with the oth=
er registrations, now that you mention it.

> However, why not structure all the available domains?  E.g. delivering
> something like (modified from section A.1)
>=20
>   Authentication-Results: mail-router.example.net;
>         dkim=3Dpass (good signature) header.d=3Dnewyork.example.com
>               header.b=3DoINEO8hg;
>         vbr=3Dpass (all) header.mv=3Dvoucher.example.net
>               header.md=3Dnewyork.example.com
>=20
> where the comment contains the actual content of the TXT record.  A
> machine readable voucher name could be used by clients to learn what
> vouchers a server trusts.

I'm not sure about this part.  One of the main purposes of A-R is to obviat=
e the need for MUAs to do any authentication work.  That all gets done at t=
he border, and agents within the border simply consume the results thus rep=
orted inbound.

What would an internal agent do with the name of the voucher?  Something li=
ke "this domain was certified by X"?  Would that be useful, or potentially =
confusing?

> Another item that may need clarification is the "positive response"
> given in the definitions of "pass" and "fail".  It could be expanded
> as, say,
>=20
>   pass:  A VBR query was completed and the vouching service queried
>      gave a positive response.  That is to say, it returned a record
>      consisting of strings of lowercase letters separated by spaces,
>      as per section 5 of [VBR].
>=20
> The added sentence is meant to dispel any question on whether the
> verifier should attempt to match the text in the RR with the content
> of the mc=3D tag in the VBR-Info header field, if any.

I think that's redundant to the algorithm VBR's RFC defines.  The "mc" in t=
he message has to match the type assertion made by the voucher.  So I'd act=
ually propose the opposite, that "fail" be expanded to include the case whe=
re voucher did make a positive assertion but the message types don't match.=
  For that matter, "fail" might also cover the case where the message conta=
ined multiple VBR-Info header fields with different "mc" values, also in vi=
olation of the VBR RFC.

-MSK

From vesely@tana.it  Mon Nov  8 11:45:10 2010
Return-Path: <vesely@tana.it>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297443A686D for <apps-discuss@core3.amsl.com>; Mon,  8 Nov 2010 11:45:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.899
X-Spam-Level: 
X-Spam-Status: No, score=-4.899 tagged_above=-999 required=5 tests=[AWL=-1.046, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, SARE_URI_EQUALS=1.666]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8tYtHqtbuQM for <apps-discuss@core3.amsl.com>; Mon,  8 Nov 2010 11:45:08 -0800 (PST)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 633493A6800 for <apps-discuss@ietf.org>; Mon,  8 Nov 2010 11:45:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1289245526; bh=Dm8H65vEHJ5SMYoXKsigX5JVyYRYUE1TP1K8nPWK1is=; l=4151; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=iENbECBTi/x0OizTlFrUSHH8yTelCwL4YT2nqMNf0bnrvBQ5TeQqGLXNm0u6vdIsN 3h2VDARxfVwEqJtLGl+OA4n4uIeke+BzVhLY3mmGGt2YhRuFCgGk/iDQDID29nqgT4 U6l0GEz4x4aRGT1ebJwzjqXRD7dsKuh6oMOF9U5I=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 08 Nov 2010 20:45:26 +0100 id 00000000005DC064.000000004CD85356.00006D65
Message-ID: <4CD85355.6040203@tana.it>
Date: Mon, 08 Nov 2010 20:45:25 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: "Murray S. Kucherawy" <msk@cloudmark.com>
References: <F5833273385BB34F99288B3648C4F06F1340E63E1A@EXCH-C2.corp.cloudmark.com>	<4CD7E726.5050505@tana.it> <F5833273385BB34F99288B3648C4F06F1340E63E3E@EXCH-C2.corp.cloudmark.com>
In-Reply-To: <F5833273385BB34F99288B3648C4F06F1340E63E3E@EXCH-C2.corp.cloudmark.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: John L <johnl@iecc.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-kucherawy-authres-vbr-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 08 Nov 2010 19:45:10 -0000

On 08/Nov/10 19:38, Murray S. Kucherawy wrote:
>>  -----Original Message-----
>>  From: ietf-dkim-bounces@mipassoc.org [mailto:ietf-dkim-bounces@mipassoc.org] On Behalf Of Alessandro Vesely
>>  Sent: Monday, November 08, 2010 4:04 AM
>>  To: ietf-dkim@mipassoc.org
>>  Subject: Re: [ietf-dkim] FW: New Version Notification for draft-kucherawy-authres-vbr-00
>>
>>  Nice one, Murray!
>>
>>  Section 4 (Definition) is ambiguous, though.  It says "the DNS domain
>>  name used to perform the VBR query", but a VBR query takes two domain
>>  names.  I think mentioning the tag (md, according to the example)
>>  would make it clearer.
>
> I'd be fine with changing it to "md=".  It's more consistent with the other registrations, now that you mention it.

And shorter :-)

>>  However, why not structure all the available domains?  E.g. delivering
>>  something like (modified from section A.1)
>>
>>    Authentication-Results: mail-router.example.net;
>>          dkim=pass (good signature) header.d=newyork.example.com
>>                header.b=oINEO8hg;
>>          vbr=pass (all) header.mv=voucher.example.net
>>                header.md=newyork.example.com
>>
>>  where the comment contains the actual content of the TXT record.  A
>>  machine readable voucher name could be used by clients to learn what
>>  vouchers a server trusts.
>
> I'm not sure about this part.  One of the main purposes of A-R is
> to obviate the need for MUAs to do any authentication work.  That
> all gets done at the border, and agents within the border simply
> consume the results thus reported inbound.

Yes.

> What would an internal agent do with the name of the voucher?
> Something like "this domain was certified by X"?  Would that be
> useful, or potentially confusing?

I cannot tell about what kind of presentation is worth.  The datum 
itself is interesting, because end users have no other way to infer 
it.  It characterizes a server.  I imagine a careful client may 
collect and display them as some kind of MTA's properties.

>>  Another item that may need clarification is the "positive response"
>>  given in the definitions of "pass" and "fail".  It could be expanded
>>  as, say,
>>
>>    pass:  A VBR query was completed and the vouching service queried
>>       gave a positive response.  That is to say, it returned a record
>>       consisting of strings of lowercase letters separated by spaces,
>>       as per section 5 of [VBR].
>>
>>  The added sentence is meant to dispel any question on whether the
>>  verifier should attempt to match the text in the RR with the content
>>  of the mc= tag in the VBR-Info header field, if any.
>
> I think that's redundant to the algorithm VBR's RFC defines.  The
> "mc" in the message has to match the type assertion made by the
> voucher.  So I'd actually propose the opposite, that "fail" be
> expanded to include the case where voucher did make a positive
> assertion but the message types don't match.  For that matter,
> "fail" might also cover the case where the message contained
> multiple VBR-Info header fields with different "mc" values, also in
> violation of the VBR RFC.

Isn't that overly complicated, since the "type" of a message is a 
somewhat subjective datum?  In addition, a verifier may query a 
voucher even without having been prompted by a VBR-Info field.  (For 
example, the string "VBR-Info" does not appear in 
http://www.spamhauswhitelist.com/en/techfaq.php)  In that case no "mc" 
is given.  Can positive results still be reported?

RFC 5518 section 3 does not mention matching.

Section 4 indeed says "All of the VBR-Info header fields in a single 
message MUST have identical mc= values."  (In-transit forgeries?)

Section 5 has that "Verifiers MUST then check that the TXT record 
consists of strings of lowercase letters separated by spaces".

Section 6 says "The purpose of this element is for auditing." But the 
VBR-Info field is as accessible as A-R itself, so I don't think it is 
worth repeating it.

I'm confused.  I CC to John in the hope he will shed some light on this.

From msk@cloudmark.com  Mon Nov  8 11:49:37 2010
Return-Path: <msk@cloudmark.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099573A68C1 for <apps-discuss@core3.amsl.com>; Mon,  8 Nov 2010 11:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.506
X-Spam-Level: 
X-Spam-Status: No, score=-104.506 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7OJPPT-Leqb for <apps-discuss@core3.amsl.com>; Mon,  8 Nov 2010 11:49:36 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 23E523A6800 for <apps-discuss@ietf.org>; Mon,  8 Nov 2010 11:49:36 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 8 Nov 2010 11:49:58 -0800
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: Alessandro Vesely <vesely@tana.it>
Date: Mon, 8 Nov 2010 11:49:56 -0800
Thread-Topic: [apps-discuss] draft-kucherawy-authres-vbr-00
Thread-Index: Act/fX7TIwCXKt0UQv2wbBvuOpcaoAAAD1hQ
Message-ID: <F5833273385BB34F99288B3648C4F06F1340E63E54@EXCH-C2.corp.cloudmark.com>
References: <F5833273385BB34F99288B3648C4F06F1340E63E1A@EXCH-C2.corp.cloudmark.com> <4CD7E726.5050505@tana.it> <F5833273385BB34F99288B3648C4F06F1340E63E3E@EXCH-C2.corp.cloudmark.com> <4CD85355.6040203@tana.it>
In-Reply-To: <4CD85355.6040203@tana.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: John L <johnl@iecc.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-kucherawy-authres-vbr-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 08 Nov 2010 19:49:37 -0000

> -----Original Message-----
> From: Alessandro Vesely [mailto:vesely@tana.it]
> Sent: Monday, November 08, 2010 11:45 AM
> To: Murray S. Kucherawy
> Cc: apps-discuss@ietf.org; John L
> Subject: Re: [apps-discuss] draft-kucherawy-authres-vbr-00
>=20
> Isn't that overly complicated, since the "type" of a message is a
> somewhat subjective datum?  In addition, a verifier may query a
> voucher even without having been prompted by a VBR-Info field.  (For
> example, the string "VBR-Info" does not appear in
> http://www.spamhauswhitelist.com/en/techfaq.php)  In that case no "mc"
> is given.  Can positive results still be reported?

That's a good point.  One possible approach in that case: Act like there wa=
s an implicit VBR-Info field and apply the same reporting mechanism as if i=
t were indeed there.

But otherwise, as with DKIM, I think it's sufficient to define pass/fail in=
 terms of the algorithm RFC5518 defined, and leave it at that.  Enumerating=
 all the ways one could get a "fail" result just makes this document needle=
ssly big.

From msk@cloudmark.com  Mon Nov  8 13:17:52 2010
Return-Path: <msk@cloudmark.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B7E3A6970 for <apps-discuss@core3.amsl.com>; Mon,  8 Nov 2010 13:17:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.48
X-Spam-Level: 
X-Spam-Status: No, score=-104.48 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCV4sNDyS7KS for <apps-discuss@core3.amsl.com>; Mon,  8 Nov 2010 13:17:51 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 86A923A68D5 for <apps-discuss@ietf.org>; Mon,  8 Nov 2010 13:17:51 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 8 Nov 2010 13:18:13 -0800
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: "John R. Levine" <johnl@iecc.com>
Date: Mon, 8 Nov 2010 13:18:12 -0800
Thread-Topic: [apps-discuss] draft-kucherawy-authres-vbr-00
Thread-Index: Act/idovJedwb+x3Rxi/LXGkpO2M1AAAIQlg
Message-ID: <F5833273385BB34F99288B3648C4F06F1340E63E68@EXCH-C2.corp.cloudmark.com>
References: <F5833273385BB34F99288B3648C4F06F1340E63E1A@EXCH-C2.corp.cloudmark.com> <4CD7E726.5050505@tana.it> <F5833273385BB34F99288B3648C4F06F1340E63E3E@EXCH-C2.corp.cloudmark.com> <4CD85355.6040203@tana.it> <F5833273385BB34F99288B3648C4F06F1340E63E54@EXCH-C2.corp.cloudmark.com> <alpine.BSF.2.00.1011081612440.29615@joyce.lan>
In-Reply-To: <alpine.BSF.2.00.1011081612440.29615@joyce.lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, Alessandro Vesely <vesely@tana.it>
Subject: Re: [apps-discuss] draft-kucherawy-authres-vbr-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 08 Nov 2010 21:17:52 -0000

> -----Original Message-----
> From: John R. Levine [mailto:johnl@iecc.com]
> Sent: Monday, November 08, 2010 1:14 PM
> To: Murray S. Kucherawy
> Cc: Alessandro Vesely; apps-discuss@ietf.org
> Subject: RE: [apps-discuss] draft-kucherawy-authres-vbr-00
>=20
> >> In that case no "mc" is given.  Can positive results still be reported=
?
>=20
> Sure, in the common case that the VBR record contains "all".

That's specific to VBR implementation and not this registration, so I don't=
 think I need to cover it here.

From jdfalk-lists@cybernothing.org  Mon Nov  8 15:55:33 2010
Return-Path: <jdfalk-lists@cybernothing.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1533A6904 for <apps-discuss@core3.amsl.com>; Mon,  8 Nov 2010 15:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcXqM3Emxx8J for <apps-discuss@core3.amsl.com>; Mon,  8 Nov 2010 15:55:32 -0800 (PST)
Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 5B43A3A68B3 for <apps-discuss@ietf.org>; Mon,  8 Nov 2010 15:55:32 -0800 (PST)
Received: from [192.168.11.35] (c-67-180-233-98.hsd1.ca.comcast.net [67.180.233.98]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oA8NtlpR024746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 8 Nov 2010 15:55:49 -0800
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: "J.D. Falk" <jdfalk-lists@cybernothing.org>
In-Reply-To: <F5833273385BB34F99288B3648C4F06F1340E63E3E@EXCH-C2.corp.cloudmark.com>
Date: Mon, 8 Nov 2010 15:55:46 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <00E0B5D8-3282-4F5D-84BB-D1068F70975F@cybernothing.org>
References: <F5833273385BB34F99288B3648C4F06F1340E63E1A@EXCH-C2.corp.cloudmark.com> <4CD7E726.5050505@tana.it> <F5833273385BB34F99288B3648C4F06F1340E63E3E@EXCH-C2.corp.cloudmark.com>
To: "Murray S. Kucherawy" <msk@cloudmark.com>
X-Mailer: Apple Mail (2.1081)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-kucherawy-authres-vbr-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 08 Nov 2010 23:55:33 -0000

On Nov 8, 2010, at 10:38 AM, Murray S. Kucherawy wrote:

> What would an internal agent do with the name of the voucher?  =
Something like "this domain was certified by X"?  Would that be useful, =
or potentially confusing?

That's a UI question, so I think the answer is "sometimes."  *grin*

That said, there are already MUAs which do show messages like "this =
domain was certified by X," so I think it'd make sense to support that =
here.


From brian.e.carpenter@gmail.com  Tue Nov  9 01:54:17 2010
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16553A693C for <apps-discuss@core3.amsl.com>; Tue,  9 Nov 2010 01:54:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.513
X-Spam-Level: 
X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57p3MGAW6WwC for <apps-discuss@core3.amsl.com>; Tue,  9 Nov 2010 01:54:16 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 3A6663A6953 for <apps-discuss@ietf.org>; Tue,  9 Nov 2010 01:54:16 -0800 (PST)
Received: by gya6 with SMTP id 6so4428112gya.31 for <apps-discuss@ietf.org>; Tue, 09 Nov 2010 01:54:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=UeEBKk2YIlmINRli9us3jE7fI/J8I+Gbjm+kwGCjgdI=; b=kMGVuidKxMqVZSLK2z23OhojTy+nZ+o4FxaDBzRVkg/qWM5K0V8/vesDLR5nG2CTnI wqt8l5IGxhVKPiXU2IYyXiu2Gv48Jzk63b+wdWzkxoiS0bCmOIKh2s+Umgi3dR0WYgmK OwUEqyBKb/Og4gFWAWKWAOSQHaxIF9flXmUnk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=jbGHyqVDFFckIV/1OwNROkV8FI0Lcx1H/z3xmZxPYIwLnh1XkyrPSVGFZM3EStW6Mp m1+uDR0ZtZJDVhBRNeWf0N9j8AUixTydAfR7eGaNp3H6vnOICRxSION1aY3WZiNqgdYT 0usEKnuLHRAmipISQlDj6iCDgez4qdyxZKmHs=
Received: by 10.151.79.11 with SMTP id g11mr1591295ybl.276.1289296478966; Tue, 09 Nov 2010 01:54:38 -0800 (PST)
Received: from [130.129.35.35] (dhcp-2323.meeting.ietf.org [130.129.35.35]) by mx.google.com with ESMTPS id q4sm458184yba.2.2010.11.09.01.54.37 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Nov 2010 01:54:38 -0800 (PST)
Message-ID: <4CD91A59.8060009@gmail.com>
Date: Tue, 09 Nov 2010 22:54:33 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] Venue for discussing draft-carpenter-referral-ps-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 09 Nov 2010 09:54:17 -0000

Referring to the discussion yesterday at the APP area meeting:

Discussion is encouraged on the grobj@ietf.org list
https://www.ietf.org/mailman/listinfo/grobj

The strange name refers to 'generic referral object', a
possible solution, but for now we are discussing the problem
statement.

-- 
Regards
   Brian Carpenter




From johnl@iecc.com  Mon Nov  8 13:13:33 2010
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FCC03A68CB for <apps-discuss@core3.amsl.com>; Mon,  8 Nov 2010 13:13:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.949
X-Spam-Level: 
X-Spam-Status: No, score=-108.949 tagged_above=-999 required=5 tests=[AWL=2.250, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-jEWojmfbrS for <apps-discuss@core3.amsl.com>; Mon,  8 Nov 2010 13:13:32 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id B8B6D3A68B1 for <apps-discuss@ietf.org>; Mon,  8 Nov 2010 13:13:31 -0800 (PST)
Received: (qmail 3835 invoked from network); 8 Nov 2010 21:13:53 -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:vbr-info:user-agent:cleverness; s=efa.4cd86811.k1011; i=johnl@submit.iecc.com; bh=JLcncKmVHr9P6HLtzBtMPTSJHXVvASRL0KTfjY5e1iI=; b=Zw9j8+0uWxtOljifR4K63XpexOZy+VQAIq7KWLOAThp4uE0eYvOxfTqLlCuV2WwEdiaMDBZJ9BmqOfNoIOEoxujVfiaNe8ysMYIGB1MJl2j6oa/qiboM+f8l/B5Z0zHLkw6msbn05goE6oZV7TbDku1W7JSW7+mayye/rqBl/qY=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Nov 2010 21:13:31 -0000
Date: 8 Nov 2010 16:13:52 -0500
Message-ID: <alpine.BSF.2.00.1011081612440.29615@joyce.lan>
From: "John R. Levine" <johnl@iecc.com>
To: "Murray S. Kucherawy" <msk@cloudmark.com>
In-Reply-To: <F5833273385BB34F99288B3648C4F06F1340E63E54@EXCH-C2.corp.cloudmark.com>
References: <F5833273385BB34F99288B3648C4F06F1340E63E1A@EXCH-C2.corp.cloudmark.com> <4CD7E726.5050505@tana.it> <F5833273385BB34F99288B3648C4F06F1340E63E3E@EXCH-C2.corp.cloudmark.com> <4CD85355.6040203@tana.it> <F5833273385BB34F99288B3648C4F06F1340E63E54@EXCH-C2.corp.cloudmark.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Mailman-Approved-At: Tue, 09 Nov 2010 08:04:42 -0800
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, Alessandro Vesely <vesely@tana.it>
Subject: Re: [apps-discuss] draft-kucherawy-authres-vbr-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 08 Nov 2010 21:13:33 -0000

>> voucher even without having been prompted by a VBR-Info field.  (For
>> example, the string "VBR-Info" does not appear in
>> http://www.spamhauswhitelist.com/en/techfaq.php)

Humph.  See http://www.spamhauswhitelist.com/en/usage.html
I'll put it in the FAQ, too.

>> In that case no "mc" is given.  Can positive results still be reported?

Sure, in the common case that the VBR record contains "all".

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

From msk@cloudmark.com  Fri Nov 12 15:20:36 2010
Return-Path: <msk@cloudmark.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B44F3A6B5F for <apps-discuss@core3.amsl.com>; Fri, 12 Nov 2010 15:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.912
X-Spam-Level: 
X-Spam-Status: No, score=-103.912 tagged_above=-999 required=5 tests=[AWL=-1.313, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8snJ2VG0YA3c for <apps-discuss@core3.amsl.com>; Fri, 12 Nov 2010 15:20:29 -0800 (PST)
Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 199FC3A6778 for <apps-discuss@ietf.org>; Fri, 12 Nov 2010 15:20:29 -0800 (PST)
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 12 Nov 2010 15:21:03 -0800
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: John Levine <johnl@iecc.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Date: Fri, 12 Nov 2010 15:21:01 -0800
Thread-Topic: FW: New Version Notification for draft-kucherawy-authres-vbr-00
Thread-Index: AcuCvwgj+gYMCRO1SsGV7buW50Ie+QAAPNxQ
Message-ID: <F5833273385BB34F99288B3648C4F06F1340E63F75@EXCH-C2.corp.cloudmark.com>
References: <F5833273385BB34F99288B3648C4F06F1340E63E1A@EXCH-C2.corp.cloudmark.com> <20101112231207.15526.qmail@joyce.lan>
In-Reply-To: <20101112231207.15526.qmail@joyce.lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [apps-discuss] FW: New Version Notification for draft-kucherawy-authres-vbr-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 12 Nov 2010 23:20:36 -0000

W21vdmluZyB0aGlzIGZyb20gaWV0Zi1ka2ltIHRvIGFwcHMtZGlzY3Vzc10NCg0KPiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRvOmpvaG5sQGll
Y2MuY29tXQ0KPiBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDEyLCAyMDEwIDM6MTIgUE0NCj4gVG86
IGlldGYtZGtpbUBtaXBhc3NvYy5vcmcNCj4gQ2M6IE11cnJheSBTLiBLdWNoZXJhd3kNCj4gU3Vi
amVjdDogUmU6IFtpZXRmLWRraW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy
YWZ0LWt1Y2hlcmF3eS1hdXRocmVzLXZici0wMA0KPiANCj4gPkNvbW1lbnRzIHdlbGNvbWUsIGV2
ZW4gaWYgaXQncyBqdXN0ICJJIHJlYWQgdGhpcywgbG9va3MgZ29vZCB0byBtZSINCj4gPnNvIHRo
YXQgc29tZSBzdXBwb3J0IG9yIGNvbnNlbnN1cyBjYW4gYmUgcmVjb3JkZWQuDQo+IA0KPiBJIHJl
YWQgaXQsIGl0IGFsbW9zdCBsb29rcyBnb29kIHRvIG1lLiAgQSBWQlItSW5mbyBoZWFkZXIgY2Fu
IGxpc3QNCj4gbXVsdGlwbGUgY2VydGlmaWVycywgc28gdW5sZXNzIHRoZXJlJ3Mgc29tZXRoaW5n
IEkgbWlzc2VkLCB0aGUgdmJyDQo+IGNsYXVzZSBpbiB0aGUgQS1SIGhlYWRlciBzaG91bGQgaW5j
bHVkZSB0aGUgbmFtZSBvZiB0aGUgY2VydGlmaWVyLg0KPiBJIGltYWdpbmUgdGhhdCBpbiBhIHNj
b3Jpbmcgc3lzdGVtIGRpZmZlcmVudCBjZXJ0aWZpZXJzIHdvdWxkIGJlDQo+IHdlaWdodGVkIGRp
ZmZlcmVudGx5LCBlLmcuLCBhIGxpc3Qgb2Ygc3BhbWxlc3Mgc2lnbmVycyB2cy4gYSBsaXN0DQo+
IG9mIHNpZ25lcnMgdGhhdCBzZW5kIGEgbWl4IGJ1dCBpdCdzIG5vdCBhbGwgc3BhbS4NCg0KVGhl
IHZpc2lvbiBJIGhhdmUgZm9yIEEtUiBpcyB0aGF0IGl0IHByb3ZpZGVzIHJlc3VsdHMgb25seSBh
bmQgYW4gZXhwcmVzc2lvbiBvZiB3aGF0IHdhcyBldmFsdWF0ZWQsIGJ1dCBzdG9wcyBzaG9ydCBv
ZiBnaXZpbmcgaXQgbW9yZSB0aGFuIHRoYXQuICBTbyBpbiB0aGUgY2FzZSBvZiBWQlIgaXQgd291
bGQgc2F5ICJzb21lb25lIHRoZSBib3JkZXIgdHJ1c3RzIHZvdWNoZWQgZm9yIGRvbWFpbiBleGFt
cGxlLmNvbSIsIG1lYW5pbmcgdGhlICJtZD0iIGlzIGltcG9ydGFudCBidXQgdGhlICJtdj0iIGlz
IG5vdC4NCg0KVGhhdCBzYWlkLCBJJ3ZlIGdvdCBhIG5ldyB2ZXJzaW9uIGFscmVhZHkgcGVuZGlu
ZywgdGhhbmtzIHRvIHByZXZpb3VzIGZlZWRiYWNrLCB0aGF0IGNoYW5nZXMgdGhlIHRhZyBzZXQg
YWRkZWQgZnJvbSAiaGVhZGVyLnZici1pbmZvIiB0byAiaGVhZGVyLm1kIiBhbmQgImhlYWRlci5t
diIuDQoNCkRvZXMgdGhhdCB3b3JrIGZvciB5b3U/DQoNCi1NU0sNCg==

From johnl@iecc.com  Fri Nov 12 18:44:46 2010
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663FF3A689A for <apps-discuss@core3.amsl.com>; Fri, 12 Nov 2010 18:44:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.224
X-Spam-Level: 
X-Spam-Status: No, score=-109.224 tagged_above=-999 required=5 tests=[AWL=1.975, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6nl61sub1Wt for <apps-discuss@core3.amsl.com>; Fri, 12 Nov 2010 18:44:38 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 0AA583A6848 for <apps-discuss@ietf.org>; Fri, 12 Nov 2010 18:44:37 -0800 (PST)
Received: (qmail 52069 invoked from network); 13 Nov 2010 02:45:11 -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:vbr-info:user-agent:cleverness; s=cb64.4cddfbb7.k1011; i=johnl@submit.iecc.com; bh=Ur87gOQOygYs1oxFfAiO03Jq5IiXdujz40Hco5m4g2o=; b=obDkr1+/F7FPxRjDJTkcM4adjJAM4QflTQZ8GFd0fH0Keq0HpQhRbSNRrTKnU5HPW0MThPCCIIT/tHdde52e7/ZcNk8YJWZRL+fSAdKmxqV9lKqRm9YEf0XVjP0F7OBOshpJdT6qSy41Dzv2BU8dwlY7pNyZj2HRoUwlrpSqzC0=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Received: (ofmipd johnl@64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Nov 2010 02:44:48 -0000
Date: 12 Nov 2010 21:45:09 -0500
Message-ID: <alpine.BSF.2.00.1011122144530.66875@joyce.lan>
From: "John R. Levine" <johnl@iecc.com>
To: "Murray S. Kucherawy" <msk@cloudmark.com>
In-Reply-To: <F5833273385BB34F99288B3648C4F06F1340E63F75@EXCH-C2.corp.cloudmark.com>
References: <F5833273385BB34F99288B3648C4F06F1340E63E1A@EXCH-C2.corp.cloudmark.com> <20101112231207.15526.qmail@joyce.lan> <F5833273385BB34F99288B3648C4F06F1340E63F75@EXCH-C2.corp.cloudmark.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Mailman-Approved-At: Sat, 13 Nov 2010 08:05:13 -0800
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] FW: New Version Notification for draft-kucherawy-authres-vbr-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 13 Nov 2010 02:44:46 -0000

> That said, I've got a new version already pending, thanks to previous feedback, that changes the tag set added from "header.vbr-info" to "header.md" and "header.mv".
>
> Does that work for you?

Looks good to me, those are the two interesting items.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

From moore@network-heretics.com  Sat Nov 13 09:40:30 2010
Return-Path: <moore@network-heretics.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51ABB3A6BED for <apps-discuss@core3.amsl.com>; Sat, 13 Nov 2010 09:40:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOtGP0MPhkbh for <apps-discuss@core3.amsl.com>; Sat, 13 Nov 2010 09:40:22 -0800 (PST)
Received: from new1.smtp.messagingengine.com (new1.smtp.messagingengine.com [66.111.4.221]) by core3.amsl.com (Postfix) with ESMTP id AB22C3A6BEC for <apps-discuss@ietf.org>; Sat, 13 Nov 2010 09:40:22 -0800 (PST)
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 7214220265; Sat, 13 Nov 2010 12:40:58 -0500 (EST)
Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 13 Nov 2010 12:40:58 -0500
X-Sasl-enc: hgxwhEEL30LpxrAcq/YY9rXsK/aIlzCb6ZcW12R6V4Ju 1289670053
Received: from 70-11-145-166.pools.spcsdns.net (70-11-145-166.pools.spcsdns.net [70.11.145.166]) by mail.messagingengine.com (Postfix) with ESMTPA id A052240B67C; Sat, 13 Nov 2010 12:40:52 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <4CBDE23C.7050904@stpeter.im>
Date: Sat, 13 Nov 2010 12:40:49 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <19188711-AAB7-472F-998D-CA05961B0A95@network-heretics.com>
References: <4CBDE23C.7050904@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1081)
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 13 Nov 2010 17:40:30 -0000

SIgh.

I'm really tired of one-sided arguments about X-.

X- is useful.  It's especially useful when you're defining something =
that you fully expect to be of limited use.  The last thing we need is =
for random implementors to be choosing keywords at random and =
(implicitly) expecting others to not chose the same keywords.

Sure, there are cases where something that was named with X- ends up =
being a de facto standard.  In those cases it should be okay to document =
that use, or even standardize it.  But there are also far too many cases =
when some vendor picks a keyword not beginning with X- and defines the =
associated semantics so haphazardly (if indeed the behavior is actually =
defined anywhere) that it should never be standardized. =20

I am currently working on a project where one of the vendors insists on =
using URNs to name things that don't have registered namespaces, and =
without establishing any discipline to ensure uniqueness of the names. I =
might be able to convince them to use a namespace beginning with X-.  If =
this document were published as an RFC they would insist on not using a =
namespace beginning with X-.

I don't think it's at all appropriate for this document to retroactively =
change the behavior of every protocol now using X-.  The consequences of =
using unregistered or poorly designed extensions are not the same for =
all protocols.

I do think that maybe the "we won't ever standardize X-" rule is poorly =
stated.  I'm okay with standardizing a keyword that begins with X- if =
the facility associated with the keyword is found to be generally useful =
and if, in general, it seems to be used consistently in the wild.   =
Really we can already do that.   A community consensus action can always =
override another community consensus action.

But unilaterally declaring X- harmful, IMO, goes too far.

Keith


On Oct 19, 2010, at 2:23 PM, Peter Saint-Andre wrote:

> I finally got around to updating this one. It's still incomplete, in =
the
> sense that it doesn't discuss recommendations or desired changes to
> behavior. However, I figured a revised I-D was in order because the
> issue came up recently on the HTTPBIS list -- see thread starting =
here:
>=20
> http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0105.html
>=20
> -------- Original Message --------
> Subject: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt
> Date: Tue, 19 Oct 2010 11:15:01 -0700 (PDT)
> From: Internet-Drafts@ietf.org
> Reply-To: internet-drafts@ietf.org
> To: i-d-announce@ietf.org
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>=20
> 	Title           : "X-" Considered Harmful
> 	Author(s)       : P. Saint-Andre
> 	Filename        : =
draft-saintandre-xdash-considered-harmful-01.txt
> 	Pages           : 6
> 	Date            : 2010-10-19
>=20
> Many application protocols use named parameters to represent data
> (for example, header fields in Internet mail messages and HTTP
> requests).  Historically, protocol designers and implementers have
> often differentiated between "standard" and "experimental" parameters
> by prefixing experimental parameters with the string "X-".  This
> document argues that, on balance, the "X-" convention has more costs
> than benefits.
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-saintandre-xdash-considered-harm=
ful-01.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20
> <draft-saintandre-xdash-considered-harmful-01.txt><Attached Message =
Part.txt>_______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From ted.ietf@gmail.com  Sat Nov 13 19:20:33 2010
Return-Path: <ted.ietf@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479343A67FD for <apps-discuss@core3.amsl.com>; Sat, 13 Nov 2010 19:20:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.356
X-Spam-Level: 
X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rilDHZzM9yWB for <apps-discuss@core3.amsl.com>; Sat, 13 Nov 2010 19:20:26 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 096043A63CB for <apps-discuss@ietf.org>; Sat, 13 Nov 2010 19:20:25 -0800 (PST)
Received: by qwd6 with SMTP id 6so180768qwd.31 for <apps-discuss@ietf.org>; Sat, 13 Nov 2010 19:21:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bgMhpz9h2TfgYduanKfutbKM+KAGSl/B3wRliNvaQ/I=; b=mIRWB7kseDdLfztI/SHygoQF+Cj/53eO4PgA/nXL6c2L24RFk3lyxdwPX89BNciUvx XSSFPlShe24xofZjudfIjmm+SmxGugtp+qw5FwgN339iR9N5Y/egZKhGsEbw9UaDh2ky bAS27D6v/r5xbXM1NLSQPbl4esi+EnXYB+YS0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YZRhzmMlsRIUJZMXx8P/MOAyaOW89N6dbQplx/liNt+RL3/cY2ul6tgT1tUg0S2Yv3 QjNpiSd6CqXsDnxnpnTM1cEHq4WjHuFVctRaI/WsIonBIDB2Ih9fV3dnXiEC31Q9I/Dy Zp1HtM9pRxake1zl6cH7+WfL2TcYwmSQy5fao=
MIME-Version: 1.0
Received: by 10.229.241.9 with SMTP id lc9mr2183516qcb.112.1289704861732; Sat, 13 Nov 2010 19:21:01 -0800 (PST)
Received: by 10.229.211.210 with HTTP; Sat, 13 Nov 2010 19:21:01 -0800 (PST)
In-Reply-To: <19188711-AAB7-472F-998D-CA05961B0A95@network-heretics.com>
References: <4CBDE23C.7050904@stpeter.im> <19188711-AAB7-472F-998D-CA05961B0A95@network-heretics.com>
Date: Sun, 14 Nov 2010 11:21:01 +0800
Message-ID: <AANLkTi=XJT1wjK_BFprK_9W74f63qZhQjZOo0qdgonQ6@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Keith Moore <moore@network-heretics.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 14 Nov 2010 03:20:33 -0000

On Sun, Nov 14, 2010 at 1:40 AM, Keith Moore <moore@network-heretics.com> w=
rote:

> I am currently working on a project where one of the vendors insists on u=
sing URNs to name things that don't have registered namespaces, and without=
 establishing any discipline to ensure uniqueness of the names. I might be =
able to convince them to use a namespace beginning with X-. =A0If this docu=
ment were published as an RFC they would insist on not using a namespace be=
ginning with X-.

RFC 3406 actually discusses both x- URNs and informal namespaces.  See
http://tools.ietf.org/html/rfc3406#section-3.1 .  Note that informal namesp=
aces
are very rare (I can see only RFC-6050-to-be in the registry).  Whether x-
namespaces are more common or not is hard to say.  I have never seen one in
the wild.

regards,

Ted






>
> I don't think it's at all appropriate for this document to retroactively =
change the behavior of every protocol now using X-. =A0The consequences of =
using unregistered or poorly designed extensions are not the same for all p=
rotocols.
>
> I do think that maybe the "we won't ever standardize X-" rule is poorly s=
tated. =A0I'm okay with standardizing a keyword that begins with X- if the =
facility associated with the keyword is found to be generally useful and if=
, in general, it seems to be used consistently in the wild. =A0 Really we c=
an already do that. =A0 A community consensus action can always override an=
other community consensus action.
>
> But unilaterally declaring X- harmful, IMO, goes too far.
>
> Keith
>
>
> On Oct 19, 2010, at 2:23 PM, Peter Saint-Andre wrote:
>
>> I finally got around to updating this one. It's still incomplete, in the
>> sense that it doesn't discuss recommendations or desired changes to
>> behavior. However, I figured a revised I-D was in order because the
>> issue came up recently on the HTTPBIS list -- see thread starting here:
>>
>> http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0105.html
>>
>> -------- Original Message --------
>> Subject: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt
>> Date: Tue, 19 Oct 2010 11:15:01 -0700 (PDT)
>> From: Internet-Drafts@ietf.org
>> Reply-To: internet-drafts@ietf.org
>> To: i-d-announce@ietf.org
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : "X-" Considered Harmful
>> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : P. Saint-Andre
>> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-saintandre-xdash-considered-=
harmful-01.txt
>> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 6
>> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-10-19
>>
>> Many application protocols use named parameters to represent data
>> (for example, header fields in Internet mail messages and HTTP
>> requests). =A0Historically, protocol designers and implementers have
>> often differentiated between "standard" and "experimental" parameters
>> by prefixing experimental parameters with the string "X-". =A0This
>> document argues that, on balance, the "X-" convention has more costs
>> than benefits.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-saintandre-xdash-considered-ha=
rmful-01.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>> <draft-saintandre-xdash-considered-harmful-01.txt><Attached Message Part=
.txt>_______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From Martin.Thomson@andrew.com  Sun Nov 14 19:32:48 2010
Return-Path: <Martin.Thomson@andrew.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CDE63A6C2B for <apps-discuss@core3.amsl.com>; Sun, 14 Nov 2010 19:32:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.823
X-Spam-Level: 
X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_20=-0.74, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yy9mLRnT2IIH for <apps-discuss@core3.amsl.com>; Sun, 14 Nov 2010 19:32:48 -0800 (PST)
Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id D511D3A6A20 for <apps-discuss@ietf.org>; Sun, 14 Nov 2010 19:32:47 -0800 (PST)
Received: from [10.86.20.102] ([10.86.20.102]:49197 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S38417260Ab0KODd1 (ORCPT <rfc822;apps-discuss@ietf.org>); Sun, 14 Nov 2010 21:33:27 -0600
Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 14 Nov 2010 21:33:27 -0600
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 15 Nov 2010 11:33:24 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "ietf@adambarth.com" <ietf@adambarth.com>
Date: Mon, 15 Nov 2010 11:33:21 +0800
Thread-Topic: web origins and URIs
Thread-Index: AcuEddon2CLs3B4bRrCCoilE/zrGiQ==
Message-ID: <8B0A9FCBB9832F43971E38010638454F03F33EA089@SISPE7MB1.commscope.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
Cc: Discuss Apps IETF <apps-discuss@ietf.org>
Subject: [apps-discuss] web origins and URIs
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 15 Nov 2010 03:32:48 -0000

SGkgQWRhbSwNCg0KTG9va2luZyBhdCBhIGRpc2N1c3Npb24gb24gb3JpZ2lucyB0b2RheSwgbXkg
TVRBIGRlY2lkZWQgdG8gaW50ZXJwcmV0IGFsbCBvcmlnaW5zIGFzIFVSSXMuDQoNCk9idmlvdXNs
eSwgdGhpcyBpcyBub3QgYW4gaW50ZW50aW9uYWwgb3V0Y29tZS4gIEFzIEkgcmVhZCBpdCwgdGhl
IGludGVudCBpcyB0byBleHRyYWN0IGEgY2hhcmFjdGVyIHNlcXVlbmNlIGZyb20gYSBVUkkvSVJJ
IHRoYXQgaXMgY29tcGFyZWQgd2l0aCBvdGhlciBzdWNoIGNoYXJhY3RlciBzZXF1ZW5jZXMgZm9y
IGEgdmFyaWV0eSBvZiBwdXJwb3NlcyAodGhvdWdoIG1vc3RseSByZWxhdGVkIHRvIHRoZSBzYW1l
LW9yaWdpbiBwb2xpY3kgaW4gYnJvd3NlcnMpLg0KDQpUaG91Z2ggYW4gb3JpZ2luIG1pZ2h0IHRh
a2UgdGhlIGZvcm0gb2YgYSB2YWxpZCBVUkksIGl0IGlzIG5vdCBhIFVSSS4gIFRoaXMgbWlnaHQg
bGVhZCB0byBtaXNpbnRlcnByZXRhdGlvbi4NCg0KSSdsbCBhZG1pdCB0aGF0IHRoZSBlZmZlY3Qg
KGZvciBIVFRQIGF0IGxlYXN0KSBpcyB1bmxpa2VseSB0byBiZSBzZXZlcmUsIGJ1dCBpdCBzaG91
bGQgYmUgcG9zc2libGUgdG8gYXZvaWQgdGhpcyBhbHRvZ2V0aGVyLiAgV2h5IG5vdCBkZWZpbmUg
YSBuZXcgVVJJIHNjaGVtZSBmb3IgdGhpcyBwdXJwb3NlPw0KDQogICBvcmlnaW46aHR0cHM6Ly93
d3cuZXhhbXBsZS5jb206ODQ0Mw0KDQpNb3N0IGFwcHMgd29udCBjYXJlIGFib3V0IHRoZSBwcmVm
aXgsIGJ1dCB3aGVuIHRoZXNlIGxlYWsgb3V0IG9mIHRoZWlyIHVzYWdlIGNvbnRleHQsIHRoZXkg
YXJlIGxlc3MgbGlrZWx5IHRvIGJlIG1pc2ludGVycHJldGVkIGlmIHRoZXkgYXJlIHByZWZpeGVk
IGluIHRoaXMgZmFzaGlvbi4gIChNeSBNVEEgZG9lc24ndCBtaXNpbnRlcnByZXQgdGhlIGFib3Zl
LCB0aG91Z2ggb3RoZXJzIG1pZ2h0IHN0aWxsLikNCg0KLS1NYXJ0aW4NCg==

From ietfc@btconnect.com  Tue Nov 16 08:00:25 2010
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA713A6DEA for <apps-discuss@core3.amsl.com>; Tue, 16 Nov 2010 08:00:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.307
X-Spam-Level: 
X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtdzKltZzJOP for <apps-discuss@core3.amsl.com>; Tue, 16 Nov 2010 08:00:24 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by core3.amsl.com (Postfix) with ESMTP id 3EBBF3A6E02 for <apps-discuss@ietf.org>; Tue, 16 Nov 2010 08:00:23 -0800 (PST)
Received: from host86-141-16-167.range86-141.btcentralplus.com (HELO pc6) ([86.141.16.167]) by c2bthomr14.btconnect.com with SMTP id ARF73810; Tue, 16 Nov 2010 16:00:58 +0000 (GMT)
Message-ID: <00f101cb859e$d166e6e0$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
References: <20101026185224.E5A1E3A6877@core3.amsl.com>
Date: Tue, 16 Nov 2010 15:59:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CE2AAB9.0031, actions=tag
X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4CE2AABA.0297,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Cc: barryleiba@computer.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] WG Action: Applications Area Working Group (appsawg)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 16 Nov 2010 16:00:25 -0000

I just tried to subscribe to the mailing list for this new WG, to be told of a
possible breach of security; I was already subscribed and someone might be
trying to do something nasty.

Doh!  it's apps-discuss, of course, which I have been on for years, but ... what
then is the difference between appsawg and apps-discuss?  same mailing list,
same archives, same recipients, same messages, same posters, ....

Non capisco!

Tom Petch

----- Original Message -----
From: "IESG Secretary" <iesg-secretary@ietf.org>
To: "IETF Announcement list" <ietf-announce@ietf.org>
Cc: <yaojk@cnnic.cn>; <barryleiba@computer.org>; <apps-discuss@ietf.org>
Sent: Tuesday, October 26, 2010 7:52 PM
Subject: [apps-discuss] WG Action: Applications Area Working Group (appsawg)


> A new IETF working group has been formed in the Applications Area.
> For additional information, please contact the Area Directors or the WG
> Chairs.
>
> Applications Area Working Group (appsawg)
> ---------------------------------------------------
> Current Status: Active Working Group
>
> Chairs:
>   Barry Leiba <barryleiba@computer.org>
>   Jiankang YAO <yaojk@cnnic.cn>
>
> Applications Area Directors:
>  Alexey Melnikov <alexey.melnikov@isode.com>
>  Peter Saint-Andre <stpeter@stpeter.im>
>
> Applications Area Advisor:
>  Alexey Melnikov <alexey.melnikov@isode.com>
>
> Mailing Lists:
>   General Discussion: apps-discuss@ietf.org
>   To Subscribe: https://www.ietf.org/mailman/listinfo/apps-discuss
>   Archive: http://www.ietf.org/mail-archive/web/apps-discuss/
>
> Description of Working Group:
>
> The Applications Area sometimes receives proposals for the development
> of specifications dealing with application-related topics that are not
> in scope for an existing working group and do not justify the formation
> of a new working group.
>
> The Applications Area Working Group (APPSAWG) can serve as a forum for
> such work in the IETF.  The APPSAWG accepts work items in accordance
> with the consensus of the Working Group and the best judgment of the
> Applications Area Directors, who are responsible for updating the
> working group milestones as needed.  The working group meets if there
> are active proposals that require intensive discussion.
>
> Work items that are appropriate for the APPSAWG mostly fall under the
> following topics:
>
> (A) Well-defined security issues that are relevant to multiple
> application technologies (e.g., draft-saintandre-tls-server-id-check).
>
> (B) Small-scale additions to the protocol stack for HTTP and other
> application technologies, mostly related to service discovery and
> meta-data (e.g., RFC 5785, draft-nottingham-http-link-header, and
> draft-hammer-hostmeta).
>
> (C) Selected other work items addressing topics that historically fall
> within the Applications Area, such as calendaring, date and time
> formats, HTTP, internationalization, language tags, MIME, URIs and XML.
>
> When considering whether to accept a proposed work item, the APPSAWG and
> the Applications Area Directors shall take into account the following
> factors, among others:
>
> * There is no existing related Working Group that is willing to
> recharter to take on this work, and the document doesn't justify the
> formation of a new working group.
>
> * Whether the WG has consensus on the suitability, importance, and
> projected quality of the proposed work item.
>
> * Whether there is a core team of WG participants with sufficient energy
> and expertise to advance the proposed work item according to the
> proposed schedule.
>
> * Whether there are enough WG participants who are willing to review
> the work produced by the document authors or editors.
>
> * Whether the Area Directors judge that wider input is needed before
> accepting the proposed work item (e.g., from the IESG, IAB, or another
> standards development organization).
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From A.Hoenes@TR-Sys.de  Wed Nov 17 12:49:10 2010
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597483A699E; Wed, 17 Nov 2010 12:49:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.094
X-Spam-Level: 
X-Spam-Status: No, score=-98.094 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVGDi1aNIO-U; Wed, 17 Nov 2010 12:49:09 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id DE5A63A6998; Wed, 17 Nov 2010 12:49:07 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA242476977; Wed, 17 Nov 2010 21:49:37 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA14181; Wed, 17 Nov 2010 21:49:36 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@TR-Sys.de>
Message-Id: <201011172049.VAA14181@TR-Sys.de>
To: uri-review@ietf.org
Date: Wed, 17 Nov 2010 21:49:36 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] [Fwd: I-D Action:draft-melnikov-mailserver-uri-to-historic-00.txt]
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 17 Nov 2010 20:49:10 -0000

My apologies for cross-posting, but this should perhaps reach a
broader audience.   I suggest to send feedback to the uri-review
at ietf.org mailing list, because Alexey sent his I-D announcement
there as well.


At Wed, 17 Nov 2010 17:26:32 +0000 , Alexey Melnikov wrote:

> FYI. I've asked on Apps-discuss about deprecating the mailserver:
> URIs and I've heard several voices in favor of doing that.
>
> I will be asking Peter Saint-Andre to sponsor this document.
>
> ...
>
>    Filename        : draft-melnikov-mailserver-uri-to-historic-00.txt
> ...


There are two more, apparently natively orphaned URI schemes listed
as 'provisional' in the IANA registry, both mentioned in RFC 1630
for the first time, and later again in RFC 1738, but never formally
registered and, AFAICS, still lacking any publicly available
specification:

   a)  tn3270

   b)  afs


A quick Google search does not reveal any hints on definitions and/or
actual use.  Some W3C web pages consider these as "reserved" names.

Apparently none of the various RFCs on Telnet extensions for TN3270
and the somehow related MIB module specifications mention the 'tn3270'
URI scheme.
Even stronger, for 'afs', archived mail (from 1993) seems to confirm
that 'afs' as a URI scheme was a very poor idea from its beginning
(see "afs: considered harmful",
<http://wwwwbs.cs.tu-berlin.de/html/urls/0148.html> ).

I suggest to consider deprecating these reserved URI scheme names
as well, in a single draft together with the 'mailserver' scheme
(to save work in the process).

Thereby, the registrations would be moved to "Historic", which,
according to the definition of that RFC status, does not immediately
invalidate existing use cases (if any), but serves to clarify that
new implementations should not try to support the subject.
The scheme names would remain in the registry, thus keeping the names
"reserved", i.e. out of availability for incompatible new use.

So there are a few questions, for both cases:

1)  Is anybody aware of a specification for the above provisional
    URI schemes ?

2)  If "yes" for 1), are there interoperable implementations?

3)  Are these URI schemes in actual use anywhere
    (even if only intended for interpretation by brainware) ?

4)  Do the answers to the above questions support deprecation?



Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+


From barryleiba.mailing.lists@gmail.com  Wed Nov 17 19:24:37 2010
Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0EE3A66B4 for <apps-discuss@core3.amsl.com>; Wed, 17 Nov 2010 19:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.009
X-Spam-Level: 
X-Spam-Status: No, score=-102.009 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt2VR46VhN4C for <apps-discuss@core3.amsl.com>; Wed, 17 Nov 2010 19:24:35 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A53523A635F for <apps-discuss@ietf.org>; Wed, 17 Nov 2010 19:24:34 -0800 (PST)
Received: by iwn40 with SMTP id 40so3047425iwn.31 for <apps-discuss@ietf.org>; Wed, 17 Nov 2010 19:25:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=2nLGRAHVhZ00ymw+IKs1AAzX9+jdW9TJTk7CCAxgewk=; b=wniWLRlJOLyinYisjc5yP/PBF+9d8sgyYVhIeeUWTXKXGlcby8pumKOGARakbK+3KM 8pI56vznS8zuES0fdYoORKC79YmV3KdwKWLX2rY2uYfhljmcD/e7Z0qguTBRivL0yHc+ r4icyrORJDIjMTiOvukmJNI61AKLJJ7FxUxQA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=DrW96lERm+xrCavGKttNCBgu4beyNI2LmYiy9n8xRULqSfKBZ8OUPNSFO6SxBlIlWi TXa7+DYRzBQFcw/pGHSozJTCH8HelxYh5TFeAK9G9c+yJwfariLIvYC7AE8YmF8W1oIJ 5zuj2L125bMtkXmCGJLN3IwJ5gBQwJlbKCZBo=
MIME-Version: 1.0
Received: by 10.231.37.200 with SMTP id y8mr30497ibd.174.1290050716231; Wed, 17 Nov 2010 19:25:16 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.42.1.81 with HTTP; Wed, 17 Nov 2010 19:25:16 -0800 (PST)
In-Reply-To: <00f101cb859e$d166e6e0$4001a8c0@gateway.2wire.net>
References: <20101026185224.E5A1E3A6877@core3.amsl.com> <00f101cb859e$d166e6e0$4001a8c0@gateway.2wire.net>
Date: Thu, 18 Nov 2010 11:25:16 +0800
X-Google-Sender-Auth: zBB4_gwS4bQogpgZBs9LcWIJuYo
Message-ID: <AANLkTikfGWF6rgLRo8zQZF84yJiaNGW6abiHdz3+OfaG@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: "t.petch" <ietfc@btconnect.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] WG Action: Applications Area Working Group (appsawg)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 18 Nov 2010 03:24:37 -0000

> Doh! =A0it's apps-discuss, of course, which I have been on for years, but=
 ... what
> then is the difference between appsawg and apps-discuss? =A0same mailing =
list,
> same archives, same recipients, same messages, same posters, ....

I thought we'd explained that adequately.  It's exactly *because*
people are already here that we want to keep the discussions here.
The structure of a working group is a process thing, which need not
affect the way people already discuss applications-area issues and
review documents for apps-related things.

Barry

From stpeter@stpeter.im  Wed Nov 17 19:26:21 2010
Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77F73A635F for <apps-discuss@core3.amsl.com>; Wed, 17 Nov 2010 19:26:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxmzLA194VDz for <apps-discuss@core3.amsl.com>; Wed, 17 Nov 2010 19:26:18 -0800 (PST)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 72D1F3A63D3 for <apps-discuss@ietf.org>; Wed, 17 Nov 2010 19:26:17 -0800 (PST)
Received: from squire.local (ip-216-17-182-51.rev.frii.com [216.17.182.51]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B86DC40BB9 for <apps-discuss@ietf.org>; Wed, 17 Nov 2010 20:37:03 -0700 (MST)
Message-ID: <4CE49D06.8090204@stpeter.im>
Date: Wed, 17 Nov 2010 20:27:02 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20101026185224.E5A1E3A6877@core3.amsl.com>	<00f101cb859e$d166e6e0$4001a8c0@gateway.2wire.net> <AANLkTikfGWF6rgLRo8zQZF84yJiaNGW6abiHdz3+OfaG@mail.gmail.com>
In-Reply-To: <AANLkTikfGWF6rgLRo8zQZF84yJiaNGW6abiHdz3+OfaG@mail.gmail.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050909050804060207010508"
Subject: Re: [apps-discuss] WG Action: Applications Area Working Group	(appsawg)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 18 Nov 2010 03:26:22 -0000

This is a cryptographically signed message in MIME format.

--------------ms050909050804060207010508
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/17/10 8:25 PM, Barry Leiba wrote:
>> Doh!  it's apps-discuss, of course, which I have been on for years, bu=
t ... what
>> then is the difference between appsawg and apps-discuss?  same mailing=
 list,
>> same archives, same recipients, same messages, same posters, ....
>=20
> I thought we'd explained that adequately.  It's exactly *because*
> people are already here that we want to keep the discussions here.
> The structure of a working group is a process thing, which need not
> affect the way people already discuss applications-area issues and
> review documents for apps-related things.

+1



--------------ms050909050804060207010508
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEx
ODAzMjcwMlowIwYJKoZIhvcNAQkEMRYEFMSPeWJ4CszvlpsOTLBpl8wPzGAzMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQAxvVaL443VBLRHAPUIx85dL+GZXHgxqhUVeByYP/C3/DRP+Tjo40nHgDF0
iyX/em8TKj5Of1/iYeZxbVca6GZCo40Iq4fI8nzYrJeRzKD3nA4nn+M6Wm1fuNu6elsMviCC
qIFC8AnxHnUXp7NQYqjNCwgA1eVrSKX3S9/Iu3E0Wxv3BwHpBJF1XBDUIysORjDp9bDKYvyL
S0hvIVadjd4dGkngjjCvJA/Fi/LSr3nodSBZJEXExzNSaRWjEB2Q2WPu+e3k44urGnf2+ZF7
b6uz3n8AKGl4bO+cLjYTQDKJNRx0BSflQdzNMEq6ixeLt1GW7r8+8CA3ewJqsO+In9G5AAAA
AAAA
--------------ms050909050804060207010508--

From A.Hoenes@TR-Sys.de  Thu Nov 18 09:53:03 2010
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C713A687A; Thu, 18 Nov 2010 09:53:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.24
X-Spam-Level: 
X-Spam-Status: No, score=-98.24 tagged_above=-999 required=5 tests=[AWL=0.509,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pGqIHCETcAn; Thu, 18 Nov 2010 09:53:02 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id B9D4C3A6804; Thu, 18 Nov 2010 09:53:00 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA248302811; Thu, 18 Nov 2010 18:53:31 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA16070; Thu, 18 Nov 2010 18:53:29 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@TR-Sys.de>
Message-Id: <201011181753.SAA16070@TR-Sys.de>
To: evnikita2@gmail.com
Date: Thu, 18 Nov 2010 18:53:29 +0100 (MEZ)
In-Reply-To: <4CE55558.7010300@gmail.com> from Mykyta Yevstifeyev at Nov "18, " 2010 "06:33:28" pm
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] [Fwd: I-D Action:draft-melnikov-mailserver-uri-to-historic-00.txt]
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 18 Nov 2010 17:53:03 -0000

Mykyta,
thanks for your contribution.  A few comments inline below.

> Hello all,
>
> Some notes on discussed topic. At the moment
> there are some implementatiom of AFS mentioned
> below. One of them is in the Linux kernel starting
> from 2.6.10, but it is incomplete. There are some
> other implemenations. You can find some information
> on this topic here:
>
> http://en.wikipedia.org/wiki/Andrew_file_system

Yes, I'm well aware of implementations of AFS that reach far beyond
the original proprietary range.  However the question here is ...

a)  whether it makes sense to use a special URI scheme to access AFS
    related resources.

    All I could find is that due to the way AFS is used and the
    variability in the mount points et al., using an identifier that
    refers to the AFS server does not help in practice; 'file' URIs
    can be used on AFS clients for mounted AFS volumes since the
    mounted volumes are intended to behave transparently, like local
    file system volumes -- same as for NFS, e.g.

b)  in case the above is answered afffirmative, whether there is an
    accepted specification for afs: URIs, with interoperable usage.

AFAICS, neither the page you point to above nor the references
quoted in the recent RFC 5864 (on DNS SRV Records for AFS) contain
indications that would lead me to evidence that the above questions
have affirmative answers.


> As for tns3720 it is a telnet scheme for access to
> IBM 3720 terminal. As this terminal were started to
> be produced in 1972, so now it is OK to
> move it to 'Historic'. This service is not
> being used any more.

Well, AFAIK, 3270 emulation is still in some limited use in commercial
legacy mixed-platform environments, but I've never heard of practical
usage of the 'tn3270' URI scheme in that context -- all such business
applications are likely to operate based on tightly controlled local
configuration of the access points and not driven by some kind of
browser software operating on 'tn3270' URIs.

There's a single RFC (RFC 3049) that contains a few embedded examples
of 'tn3270' URIs, but it remains rather vague and does not give a
reference for the definition of such scheme either.

So I'm also in support of declaring that provisional URI scheme
Historic.


> As for AFS, I think it shouldn't be moved to
> 'Historic' - there are some implementation
> and it remains been used somewhere.

See my remarks above.
Do you have more information on definition and use of 'afs' URIs?
The thread I had pointed to yesterday seemed to indicate that active
AFS users didn't like the idea at all (already 17 years ago!).


> As for 'mailserver', it really needs to be moves
> to 'historic' as there are really no specifications of use.

Indeed.

The IETF process is very fast in this case.  IETF LC already has been
announced today for draft-melnikov-mailserver-uri-to-historic-00.

So I conclude that we both are in support of that draft. :-)


Kind regards,
  Alfred.


>
> Thank you for your time.
>
> All the best,
> Mykyta Yevstifeyev
>
> 17.11.2010 22:49, Alfred HÎnes wrote:
>> My apologies for cross-posting, but this should perhaps reach a
>> broader audience.   I suggest to send feedback to the uri-review
>> at ietf.org mailing list, because Alexey sent his I-D announcement
>> there as well.
>>
>>
>> At Wed, 17 Nov 2010 17:26:32 +0000 , Alexey Melnikov wrote:
>>
>>> FYI. I've asked on Apps-discuss about deprecating the mailserver:
>>> URIs and I've heard several voices in favor of doing that.
>>>
>>> I will be asking Peter Saint-Andre to sponsor this document.
>>>
>>> ...
>>>
>>>     Filename        : draft-melnikov-mailserver-uri-to-historic-00.txt
>>> ...
>>
>> There are two more, apparently natively orphaned URI schemes listed
>> as 'provisional' in the IANA registry, both mentioned in RFC 1630
>> for the first time, and later again in RFC 1738, but never formally
>> registered and, AFAICS, still lacking any publicly available
>> specification:
>>
>>     a)  tn3270
>>
>>     b)  afs
>>
>>
>> A quick Google search does not reveal any hints on definitions and/or
>> actual use.  Some W3C web pages consider these as "reserved" names.
>>
>> Apparently none of the various RFCs on Telnet extensions for TN3270
>> and the somehow related MIB module specifications mention the 'tn3270'
>> URI scheme.
>> Even stronger, for 'afs', archived mail (from 1993) seems to confirm
>> that 'afs' as a URI scheme was a very poor idea from its beginning
>> (see "afs: considered harmful",
>> <http://wwwwbs.cs.tu-berlin.de/html/urls/0148.html>  ).
>>
>> I suggest to consider deprecating these reserved URI scheme names
>> as well, in a single draft together with the 'mailserver' scheme
>> (to save work in the process).
>>
>> Thereby, the registrations would be moved to "Historic", which,
>> according to the definition of that RFC status, does not immediately
>> invalidate existing use cases (if any), but serves to clarify that
>> new implementations should not try to support the subject.
>> The scheme names would remain in the registry, thus keeping the names
>> "reserved", i.e. out of availability for incompatible new use.
>>
>> So there are a few questions, for both cases:
>>
>> 1)  Is anybody aware of a specification for the above provisional
>>      URI schemes ?
>>
>> 2)  If "yes" for 1), are there interoperable implementations?
>>
>> 3)  Are these URI schemes in actual use anywhere
>>      (even if only intended for interpretation by brainware) ?
>>
>> 4)  Do the answers to the above questions support deprecation?
>>
>>
>> Kind regards,
>>    Alfred.


From lyndon@gandalf.orthanc.ca  Thu Nov 18 21:57:04 2010
Return-Path: <lyndon@gandalf.orthanc.ca>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980163A67AD; Thu, 18 Nov 2010 21:57:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2hzc34WEk1P; Thu, 18 Nov 2010 21:57:03 -0800 (PST)
Received: from orthanc.ca (ve6bbm-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:139::2]) by core3.amsl.com (Postfix) with ESMTP id 9DA7F3A67B0; Thu, 18 Nov 2010 21:57:03 -0800 (PST)
Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (8.14.4/8.14.4) with ESMTP id oAJ5vp79008558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2010 21:57:51 -0800 (PST) (envelope-from lyndon@gandalf.orthanc.ca)
Received: (from uucp@localhost) by orthanc.ca (8.14.4/8.14.4/Submit) with UUCP id oAJ5vp3G008557; Thu, 18 Nov 2010 21:57:51 -0800 (PST) (envelope-from lyndon@gandalf.orthanc.ca)
Received: from gandalf.orthanc.ca (frodo.orthanc.ca [172.16.0.3]) by legolas.orthanc.ca (8.14.4/8.14.4) with ESMTP id oAJ5vn5U042218; Thu, 18 Nov 2010 21:57:49 -0800 (PST) (envelope-from lyndon@gandalf.orthanc.ca)
Message-ID: <55895239d7e7df2d41b9da075c4f149c@gandalf.orthanc.ca>
To: uri-review@ietf.org, apps-discuss@ietf.org
From: "Lyndon Nerenberg (VE6BBM/VE7TFX)"  <lyndon@orthanc.ca>
Date: Thu, 18 Nov 2010 21:57:49 -0800
In-Reply-To: <201011181753.SAA16070@TR-Sys.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] tn3270
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 05:58:29 -0000

> Well, AFAIK, 3270 emulation is still in some limited use in commercial
> legacy mixed-platform environments, but I've never heard of practical
> usage of the 'tn3270' URI scheme in that context -- all such business
> applications are likely to operate based on tightly controlled local
> configuration of the access points and not driven by some kind of
> browser software operating on 'tn3270' URIs.

That's an awfully presumptive generalization to make about how other
people's businesses operate.  That aside, "must be accessible to the
global Internet" isn't a criteria for (or against) standardization (or
registration).  Standards can also apply inside walled gardens.

> There's a single RFC (RFC 3049) that contains a few embedded examples
> of 'tn3270' URIs, but it remains rather vague and does not give a
> reference for the definition of such scheme either.

I strongly suspect that's because the community of users for this scheme
are painfully aware of what the service represents, and therefore didn't
see a need to write it up.  It wouldn't take much effort to document it
in an RFC.

> So I'm also in support of declaring that provisional URI scheme
> Historic.

What is gained by doing this?  tn3270 is a very distinct service from
the NVT-ASCII terminal presumed by telnet:, even though both are
served over the TELNET protocol.  And the TN3270 service is far from
dead (e.g.  there are more than a few AS/400 systems connected to the
Internet).

Someone mentioned the tn3270 scheme made no sense being typed into a
browser.  URIs are used in *many* places other than browsers.  (On the
terminal I'm typing this on, right-clicking on any string prefixed
with 'tn3270://' will launch a tn3270 terminal emulator connection to
the specified host.)  While there's no formal specification for the
tn3270 scheme, it's pretty obvious what to do with the URI if you're
handed one in a context where you can establish the connection.

So let me turn this around and ask: what harm is actively being caused
by the tn3270 scheme that requires us to kick it to the curb?

--lyndon


From john-ietf@jck.com  Fri Nov 19 00:10:44 2010
Return-Path: <john-ietf@jck.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0358228C113; Fri, 19 Nov 2010 00:10:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3tyNa4J3nQg; Fri, 19 Nov 2010 00:10:40 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id A878B28C0CF; Fri, 19 Nov 2010 00:10:39 -0800 (PST)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PJM46-000INd-St; Fri, 19 Nov 2010 03:11:27 -0500
Date: Fri, 19 Nov 2010 03:11:26 -0500
From: John C Klensin <john-ietf@jck.com>
To: "Lyndon Nerenberg (VE6BBM/VE7TFX)" <lyndon@orthanc.ca>, uri-review@ietf.org, apps-discuss@ietf.org
Message-ID: <175AC1CC70EF63F569DB1757@PST.JCK.COM>
In-Reply-To: <55895239d7e7df2d41b9da075c4f149c@gandalf.orthanc.ca>
References: <55895239d7e7df2d41b9da075c4f149c@gandalf.orthanc.ca>
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
Subject: Re: [apps-discuss] tn3270
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 08:10:44 -0000

While I'm no fan of the 3270 (and wasn't back when I was doing
programming that depended on them), I have to agree with Lyndon.
There is almost certainly no harm in keeping the URI definition
and probably some harm in getting rid of it.   One could argue
that the spec should be retired because it is inadequate and
obsolete, but inventing and applying that criterion is IMO
unreasonable unless we intend to start applying the "time out
and die" provisions of RFC 2026 for the first time in history.

    john


--On Thursday, November 18, 2010 21:57 -0800 "Lyndon Nerenberg
(VE6BBM/VE7TFX)" <lyndon@orthanc.ca> wrote:

>> Well, AFAIK, 3270 emulation is still in some limited use in
>> commercial legacy mixed-platform environments, but I've never
>> heard of practical usage of the 'tn3270' URI scheme in that
>> context -- all such business applications are likely to
>> operate based on tightly controlled local configuration of
>> the access points and not driven by some kind of browser
>> software operating on 'tn3270' URIs.
> 
> That's an awfully presumptive generalization to make about how
> other people's businesses operate.  That aside, "must be
> accessible to the global Internet" isn't a criteria for (or
> against) standardization (or registration).  Standards can
> also apply inside walled gardens.
>...


From Claudio.Allocchio@garr.it  Fri Nov 19 00:30:45 2010
Return-Path: <Claudio.Allocchio@garr.it>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0599428B797; Fri, 19 Nov 2010 00:30:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xg6Zz+q9tPQf; Fri, 19 Nov 2010 00:30:43 -0800 (PST)
Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 4CD2728B23E; Fri, 19 Nov 2010 00:30:43 -0800 (PST)
Received: from webcam1-all.garrtest.units.it (webcam1-all.garrtest.units.it [140.105.201.5]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id oAJ8VRwe045599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Nov 2010 09:31:28 +0100 (CET)
X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it oAJ8VRwe045599
DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=XGTH549+dcTzulQTvH+slZtUvjnIoWnfonN1jLVWsJPxiIgVmzE/+I61p+5b/ZiJV qQkwWpsFrR5Esbx73zbv00wtBWMXGjumle5MxzA+6q4Srw6bKWt91sa7Yx2vaO8hLin 8EcFFKGzBS+uDo9Te7IGoCHgOENRmNjyI3nWXTk=
Date: Fri, 19 Nov 2010 09:31:26 +0100 (CET)
From: Claudio Allocchio <Claudio.Allocchio@garr.it>
X-X-Sender: claudio@webcam1-all.garrtest.units.it
To: John C Klensin <john-ietf@jck.com>
In-Reply-To: <175AC1CC70EF63F569DB1757@PST.JCK.COM>
Message-ID: <Pine.OSX.4.64.1011190928150.746@webcam1-all.garrtest.units.it>
References: <55895239d7e7df2d41b9da075c4f149c@gandalf.orthanc.ca> <175AC1CC70EF63F569DB1757@PST.JCK.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] tn3270
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 08:30:45 -0000

On Fri, 19 Nov 2010, John C Klensin wrote:

> While I'm no fan of the 3270 (and wasn't back when I was doing
> programming that depended on them), I have to agree with Lyndon.
> There is almost certainly no harm in keeping the URI definition
> and probably some harm in getting rid of it.   One could argue
> that the spec should be retired because it is inadequate and
> obsolete, but inventing and applying that criterion is IMO
> unreasonable unless we intend to start applying the "time out
> and die" provisions of RFC 2026 for the first time in history.

+1 John!

never assume anything about obsolete applications in general. Unless we 
really need to deprecate some, because it creates serious dangers to the 
network security, let the old stuff there. You will find a still non 
neglegible amount of use around.

... I still by time to time receive e-mails originated in X.400 via a 
gateway... and I still have a PDP 11 running incredibly fast on a virtual 
machine on my laptop mac. :-)

claudio
>
>    john
>
>
> --On Thursday, November 18, 2010 21:57 -0800 "Lyndon Nerenberg
> (VE6BBM/VE7TFX)" <lyndon@orthanc.ca> wrote:
>
>>> Well, AFAIK, 3270 emulation is still in some limited use in
>>> commercial legacy mixed-platform environments, but I've never
>>> heard of practical usage of the 'tn3270' URI scheme in that
>>> context -- all such business applications are likely to
>>> operate based on tightly controlled local configuration of
>>> the access points and not driven by some kind of browser
>>> software operating on 'tn3270' URIs.
>>
>> That's an awfully presumptive generalization to make about how
>> other people's businesses operate.  That aside, "must be
>> accessible to the global Internet" isn't a criteria for (or
>> against) standardization (or registration).  Standards can
>> also apply inside walled gardens.
>> ...
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

From ietfc@btconnect.com  Fri Nov 19 01:59:56 2010
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF543A68FC; Fri, 19 Nov 2010 01:59:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUtaZRcySljJ; Fri, 19 Nov 2010 01:59:56 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by core3.amsl.com (Postfix) with ESMTP id 842F13A67D3; Fri, 19 Nov 2010 01:59:55 -0800 (PST)
Received: from host81-156-207-177.range81-156.btcentralplus.com (HELO pc6) ([81.156.207.177]) by c2bthomr13.btconnect.com with SMTP id ASF93639; Fri, 19 Nov 2010 10:00:19 +0000 (GMT)
Message-ID: <00b401cb87c7$ed6a4f00$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: "John C Klensin" <john-ietf@jck.com>, "Lyndon Nerenberg \(VE6BBM/VE7TFX\)" <lyndon@orthanc.ca>, <uri-review@ietf.org>, <apps-discuss@ietf.org>
References: <55895239d7e7df2d41b9da075c4f149c@gandalf.orthanc.ca> <175AC1CC70EF63F569DB1757@PST.JCK.COM>
Date: Fri, 19 Nov 2010 09:58:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CE64AA5.03B5, actions=tag
X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4CE64ABB.029D,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Subject: Re: [apps-discuss] tn3270
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 09:59:57 -0000

----- Original Message -----
From: "John C Klensin" <john-ietf@jck.com>
To: "Lyndon Nerenberg (VE6BBM/VE7TFX)" <lyndon@orthanc.ca>;
<uri-review@ietf.org>; <apps-discuss@ietf.org>
Sent: Friday, November 19, 2010 9:11 AM
Subject: Re: [apps-discuss] tn3270


> While I'm no fan of the 3270 (and wasn't back when I was doing
> programming that depended on them), I have to agree with Lyndon.
> There is almost certainly no harm in keeping the URI definition
> and probably some harm in getting rid of it.   One could argue
> that the spec should be retired because it is inadequate and
> obsolete, but inventing and applying that criterion is IMO
> unreasonable unless we intend to start applying the "time out
> and die" provisions of RFC 2026 for the first time in history.
>
>     john

I agree; I would even offer to review an updated specification
(although I think that that would be overkill).

Tom Petch


> --On Thursday, November 18, 2010 21:57 -0800 "Lyndon Nerenberg
> (VE6BBM/VE7TFX)" <lyndon@orthanc.ca> wrote:
>
> >> Well, AFAIK, 3270 emulation is still in some limited use in
> >> commercial legacy mixed-platform environments, but I've never
> >> heard of practical usage of the 'tn3270' URI scheme in that
> >> context -- all such business applications are likely to
> >> operate based on tightly controlled local configuration of
> >> the access points and not driven by some kind of browser
> >> software operating on 'tn3270' URIs.
> >
> > That's an awfully presumptive generalization to make about how
> > other people's businesses operate.  That aside, "must be
> > accessible to the global Internet" isn't a criteria for (or
> > against) standardization (or registration).  Standards can
> > also apply inside walled gardens.
> >...
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From A.Hoenes@TR-Sys.de  Fri Nov 19 06:09:30 2010
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287113A67E9; Fri, 19 Nov 2010 06:09:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.291
X-Spam-Level: 
X-Spam-Status: No, score=-98.291 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WRDZj9r-ELc; Fri, 19 Nov 2010 06:09:29 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id D6F983A684F; Fri, 19 Nov 2010 06:08:31 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA252705632; Fri, 19 Nov 2010 15:07:12 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA17572; Fri, 19 Nov 2010 15:06:14 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@TR-Sys.de>
Message-Id: <201011191406.PAA17572@TR-Sys.de>
To: ietfc@btconnect.com
Date: Fri, 19 Nov 2010 15:06:14 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [uri-review] tn3270 URIs
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 14:09:30 -0000

Tom, all,

Tom Petch wrote:

>   [...]   I would even offer to review an updated specification
> (although I think that that would be overkill).

I'm fine with a specification if the 'tn3270' scheme actually is
in use and new implementations (of the scheme) might be expected
as well, but I could not find an old spec that could be "updated".
So please provide a virgin registration document per RFC 4395,
if you are interested.

What I'm opposing to is letting a "provisional" registration linger
around in the registry for decades / forever.
"Provisional" is intended as a transient state, but it also requires
a registration per RFC 4395.  'tn3270' never got that so far.

RFC 1738 said (sect. 4, pg 17):

|  The following scheme have been proposed at various times, but this
|  document does not define their syntax or use at this time. It is
|  suggested that IANA reserve their scheme names for future definition:
|
|  afs              Andrew File System global file names.
|  mid              Message identifiers for electronic mail.
|  cid              Content identifiers for MIME body parts.
|  nfs              Network File System (NFS) file names.
|  tn3270           Interactive 3270 emulation sessions.
|  mailserver       Access to data available from mail servers.
|  z39.50           Access to ANSI Z39.50 services.

That's all what it says about 'tn3270'; no single additional word.
Notably, it uses verbiage like "have been proposed"  and
"reserve ... names for future definition".

Three entries from that list are still pending -- 'mid' and 'cid'
(per RFC 2392) and 'nfs' (per RFC 2224) have been formally specified,
'z39.50' has been obsoleted and replaced by 2 schemes (per RFC 2056).

Alexey's draft retires 'mailserver'.

For 'afs', it looks like support for declaring it Historic is emerging.

If there's no spec for 'tn3270' by the end of next year, I'll revisit
the topic of declaring this scheme Historic.

Note that even arguably "dead" schemes like 'wais' and 'prospero'
have at least been formally specified before they have been declared
Historic (RFCs 4156 + 4157).

RFC 4395 requires for the registration of Provisional URI schemes:

   [...]
   o  Contact information identifying the person supplying the
      registration is included.  Previously unregistered URI schemes
      discovered in use may be registered by third parties on behalf of
      those who created the URI scheme; in this case, both the
      registering party and the scheme creator SHOULD be identified.
   o  If no permanent, citable specification for the URI scheme
      definition is included, credible reasons for not providing it
      should be given.
   o  A valid Security Considerations section, as required by Section 6
      of [3].
   o  If the scheme definition does not meet the guidelines laid out in
      Section 2, the differences and reasons SHOULD be noted.

The RFC and historic I-D repositories apparently do not contain
any document that could be taken as qualifying for such registry
entry for 'tn3270' under these provisions.


Kind regards,
  Alfred HÎnes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+


From Michael.Wojcik@microfocus.com  Fri Nov 19 07:10:01 2010
Return-Path: <Michael.Wojcik@microfocus.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283ED3A6818; Fri, 19 Nov 2010 07:10:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F46bpZUG3eB3; Fri, 19 Nov 2010 07:10:00 -0800 (PST)
Received: from wgateout.microfocus.com (wgateout.microfocus.com [213.83.72.248]) by core3.amsl.com (Postfix) with ESMTP id E22BE3A680A; Fri, 19 Nov 2010 07:09:59 -0800 (PST)
Received: from MTV-EXCHANGE.microfocus.com (mtv-exchange.microfocus.com [10.20.11.215]) by wgateout.microfocus.com (8.13.6/8.13.6) with ESMTP id oAJFWwRQ004340; Fri, 19 Nov 2010 15:33:00 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 19 Nov 2010 07:10:45 -0800
Message-ID: <81F42F63D5BB344ABF294F8E80990C7902782A40@MTV-EXCHANGE.microfocus.com>
In-Reply-To: <55895239d7e7df2d41b9da075c4f149c@gandalf.orthanc.ca>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Uri-review] tn3270
Thread-Index: AcuHzy2FgGO5bDYUQvqArqnWsmvUNwAKCzVw
References: <201011181753.SAA16070@TR-Sys.de> <55895239d7e7df2d41b9da075c4f149c@gandalf.orthanc.ca>
From: "Michael Wojcik" <Michael.Wojcik@microfocus.com>
To: <uri-review@ietf.org>, <apps-discuss@ietf.org>
X-Mailman-Approved-At: Fri, 19 Nov 2010 08:20:12 -0800
Subject: Re: [apps-discuss] [Uri-review] tn3270
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 15:10:01 -0000

> From: uri-review-bounces@ietf.org [mailto:uri-review-bounces@ietf.org]
> On Behalf Of Lyndon Nerenberg (VE6BBM/VE7TFX)
> Sent: Friday, 19 November, 2010 00:58
>=20
> > Well, AFAIK, 3270 emulation is still in some limited use in
commercial
> > legacy mixed-platform environments, but I've never heard of
practical
> > usage of the 'tn3270' URI scheme in that context -- all such
business
> > applications are likely to operate based on tightly controlled local
> > configuration of the access points and not driven by some kind of
> > browser software operating on 'tn3270' URIs.

I don't know whom Lyndon was quoting here, but "limited use" is only
true for rather large values of "limited". Here at Micro Focus we
continue to have strong sales of our TN3270-based products, and most of
our customers who are migrating mainframe applications to other
platforms continue to use TN3270 as the front-end protocol.

> What is gained by doing this?  tn3270 is a very distinct service from
> the NVT-ASCII terminal presumed by telnet:, even though both are
served
> over the TELNET protocol.  And the TN3270 service is far from dead
> (e.g.  there are more than a few AS/400 systems connected to the
> Internet).

True, though AS/400 (now System i) systems are more comfortably accessed
with TN5250 clients. But there are System z (IBM mainframe) systems that
are Internet-accessible too, eg at some educational institutions; and in
any case, as Lyndon pointed out, "Internet-accessible" isn't a criterion
for a URI scheme.

--=20
Michael Wojcik
Principal Software Systems Developer, Micro Focus


From evnikita2@gmail.com  Thu Nov 18 08:32:46 2010
Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36DC28C0F7; Thu, 18 Nov 2010 08:32:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.489
X-Spam-Level: 
X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.96]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjmtQURkrssa; Thu, 18 Nov 2010 08:32:42 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 042F128C0E6; Thu, 18 Nov 2010 08:32:39 -0800 (PST)
Received: by ywp6 with SMTP id 6so2111299ywp.31 for <multiple recipients>; Thu, 18 Nov 2010 08:33:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=g3NIWGj0naEQEizJ09RLr8MUSeyZEqP1hXN/emkS5vc=; b=rha3MCHQN5oqZZ+F9oFYZkdFIGsDL5tTl7PnCDlawO1m47Qa4OUGUBxyHCkVd7bF/k jVkwxN31LBZQR3hCd0QGrgIWHkp3P40RqxJThEmmHQcRQo4D7HpbFviX/7sWeis5h89J zfOwPrwljZoT+kQUzOnRiSRWuMuBmtodW2JWc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=kNxyUMhHD387CjGEa3+x5mrkxw+JCsQL61rmLjzSD4icAzWN4VfH/B+Hh1V+L4OmAG N683vKwReDllTxGTByrbkH/Wc8AP2WkmOxju7DKeSDUW7O6TBe7tA3Ak1uN4NpNCaDNX aEHFeO50iNpUegYtB9zYhdrememaYJppjCl3Y=
Received: by 10.204.59.193 with SMTP id m1mr796594bkh.176.1290098006980; Thu, 18 Nov 2010 08:33:26 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id v25sm322402bkt.6.2010.11.18.08.33.24 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Nov 2010 08:33:24 -0800 (PST)
Message-ID: <4CE55558.7010300@gmail.com>
Date: Thu, 18 Nov 2010 18:33:28 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= <ah@TR-Sys.de>, uri-review@ietf.org,  apps-discuss@ietf.org
References: <201011172049.VAA14181@TR-Sys.de>
In-Reply-To: <201011172049.VAA14181@TR-Sys.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Fri, 19 Nov 2010 08:20:23 -0800
Subject: Re: [apps-discuss] [Uri-review] [Fwd: I-D	Action:draft-melnikov-mailserver-uri-to-historic-00.txt]
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 18 Nov 2010 16:32:46 -0000

Hello all,

Some notes on discussed topic. At the moment
there are some implementatiom of AFS mentioned
below. One of them is in the Linux kernel starting
from 2.6.10, but it is incomplete. There are some
other implemenations. You can find some information
on this topic here:

http://en.wikipedia.org/wiki/Andrew_file_system

As for tns3720 it is a telnet scheme for access to
IBM 3720 terminal. As this terminal were started to
be produced in 1972, so now it is OK to
move it to 'Historic'. This service is not
being used any more.

As for AFS, I think it shouldn't be moved to
'Historic' - there are some implementation
and it remains been used somewhere.

As for 'mailserver', it really needs to be
moved to 'historic' as there are really no specifications
of use.

Thank you for your time.

All the best,
Mykyta Yevstifeyev

17.11.2010 22:49, Alfred � wrote:
> My apologies for cross-posting, but this should perhaps reach a
> broader audience.   I suggest to send feedback to the uri-review
> at ietf.org mailing list, because Alexey sent his I-D announcement
> there as well.
>
>
> At Wed, 17 Nov 2010 17:26:32 +0000 , Alexey Melnikov wrote:
>
>> FYI. I've asked on Apps-discuss about deprecating the mailserver:
>> URIs and I've heard several voices in favor of doing that.
>>
>> I will be asking Peter Saint-Andre to sponsor this document.
>>
>> ...
>>
>>     Filename        : draft-melnikov-mailserver-uri-to-historic-00.txt
>> ...
>
> There are two more, apparently natively orphaned URI schemes listed
> as 'provisional' in the IANA registry, both mentioned in RFC 1630
> for the first time, and later again in RFC 1738, but never formally
> registered and, AFAICS, still lacking any publicly available
> specification:
>
>     a)  tn3270
>
>     b)  afs
>
>
> A quick Google search does not reveal any hints on definitions and/or
> actual use.  Some W3C web pages consider these as "reserved" names.
>
> Apparently none of the various RFCs on Telnet extensions for TN3270
> and the somehow related MIB module specifications mention the 'tn3270'
> URI scheme.
> Even stronger, for 'afs', archived mail (from 1993) seems to confirm
> that 'afs' as a URI scheme was a very poor idea from its beginning
> (see "afs: considered harmful",
> <http://wwwwbs.cs.tu-berlin.de/html/urls/0148.html>  ).
>
> I suggest to consider deprecating these reserved URI scheme names
> as well, in a single draft together with the 'mailserver' scheme
> (to save work in the process).
>
> Thereby, the registrations would be moved to "Historic", which,
> according to the definition of that RFC status, does not immediately
> invalidate existing use cases (if any), but serves to clarify that
> new implementations should not try to support the subject.
> The scheme names would remain in the registry, thus keeping the names
> "reserved", i.e. out of availability for incompatible new use.
>
> So there are a few questions, for both cases:
>
> 1)  Is anybody aware of a specification for the above provisional
>      URI schemes ?
>
> 2)  If "yes" for 1), are there interoperable implementations?
>
> 3)  Are these URI schemes in actual use anywhere
>      (even if only intended for interpretation by brainware) ?
>
> 4)  Do the answers to the above questions support deprecation?
>
>
>
> Kind regards,
>    Alfred.
>


From evnikita2@gmail.com  Thu Nov 18 23:36:49 2010
Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF78D3A68B2; Thu, 18 Nov 2010 23:36:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.682
X-Spam-Level: 
X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3o9bDaEQW2i; Thu, 18 Nov 2010 23:36:47 -0800 (PST)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 856003A688C; Thu, 18 Nov 2010 23:36:47 -0800 (PST)
Received: by gwb10 with SMTP id 10so2666997gwb.31 for <multiple recipients>; Thu, 18 Nov 2010 23:37:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iiQvgx27WdWN/oe8xsT8dbbdwyCyNny9tvsySp0hBPY=; b=LQTtlvNtIZ0G7t9na8IlpK94oonJrmKSRH5i6VUjgUhp0LSCOV/Jf4KGtbLE2aQASU Gv5XPMrnpiix9bP12PJbHD1kM1zSeBH3rSzm+mLWqIi/O8DY2kqeDfNKp4DRqax9eIpH 0bJ4opGB+Z2pqg7r5gS6hwHug885CPYuOEKJk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=i+zDdoouUAdTN0KRWJBPkyac6iT92xbbSRknmSPhDkwDD3/jvPsAzI/F1XzvtcY914 GYzmvLiaxwQDaPOA9Qkdn3dA1RPuxfV67gzMwpcOHSDpT4e+kObGuvakEcHIBmbQZHQ4 G29M6orLOrsUJTr8ETY4d9mtVLy3ImBXen7dM=
MIME-Version: 1.0
Received: by 10.151.143.20 with SMTP id v20mr3044406ybn.114.1290152249690; Thu, 18 Nov 2010 23:37:29 -0800 (PST)
Received: by 10.150.97.7 with HTTP; Thu, 18 Nov 2010 23:37:29 -0800 (PST)
In-Reply-To: <201011181753.SAA16070@TR-Sys.de>
References: <4CE55558.7010300@gmail.com> <201011181753.SAA16070@TR-Sys.de>
Date: Fri, 19 Nov 2010 09:37:29 +0200
Message-ID: <AANLkTikVZSnMWD=UEyHJ53+eG7oYoeZuOwp5nx4abkX1@mail.gmail.com>
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
To: =?ISO-8859-1?Q?Alfred_H=CEnes?= <ah@tr-sys.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 19 Nov 2010 08:20:23 -0800
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] [Fwd: I-D Action:draft-melnikov-mailserver-uri-to-historic-00.txt]
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 07:36:49 -0000

Hello all,

An only note is if we move to 'Historic' the 'tns3720'
URI scheme, we need to move the corresponding RFC
(RFC 3049 and other if are) to 'Historic' too.

IMO it would be OK to create the I-D on this topic and
publish them simulteneously.

Best regards,
Mykyta Yevstifeyev

2010/11/18, Alfred H=CEnes <ah@tr-sys.de>:
> Mykyta,
> thanks for your contribution.  A few comments inline below.
>
>> Hello all,
>>
>> Some notes on discussed topic. At the moment
>> there are some implementatiom of AFS mentioned
>> below. One of them is in the Linux kernel starting
>> from 2.6.10, but it is incomplete. There are some
>> other implemenations. You can find some information
>> on this topic here:
>>
>> http://en.wikipedia.org/wiki/Andrew_file_system
>
> Yes, I'm well aware of implementations of AFS that reach far beyond
> the original proprietary range.  However the question here is ...
>
> a)  whether it makes sense to use a special URI scheme to access AFS
>     related resources.
>
>     All I could find is that due to the way AFS is used and the
>     variability in the mount points et al., using an identifier that
>     refers to the AFS server does not help in practice; 'file' URIs
>     can be used on AFS clients for mounted AFS volumes since the
>     mounted volumes are intended to behave transparently, like local
>     file system volumes -- same as for NFS, e.g.
>
> b)  in case the above is answered afffirmative, whether there is an
>     accepted specification for afs: URIs, with interoperable usage.
>
> AFAICS, neither the page you point to above nor the references
> quoted in the recent RFC 5864 (on DNS SRV Records for AFS) contain
> indications that would lead me to evidence that the above questions
> have affirmative answers.
>
>
>> As for tns3720 it is a telnet scheme for access to
>> IBM 3720 terminal. As this terminal were started to
>> be produced in 1972, so now it is OK to
>> move it to 'Historic'. This service is not
>> being used any more.
>
> Well, AFAIK, 3270 emulation is still in some limited use in commercial
> legacy mixed-platform environments, but I've never heard of practical
> usage of the 'tn3270' URI scheme in that context -- all such business
> applications are likely to operate based on tightly controlled local
> configuration of the access points and not driven by some kind of
> browser software operating on 'tn3270' URIs.
>
> There's a single RFC (RFC 3049) that contains a few embedded examples
> of 'tn3270' URIs, but it remains rather vague and does not give a
> reference for the definition of such scheme either.
>
> So I'm also in support of declaring that provisional URI scheme
> Historic.
>
>
>> As for AFS, I think it shouldn't be moved to
>> 'Historic' - there are some implementation
>> and it remains been used somewhere.
>
> See my remarks above.
> Do you have more information on definition and use of 'afs' URIs?
> The thread I had pointed to yesterday seemed to indicate that active
> AFS users didn't like the idea at all (already 17 years ago!).
>
>
>> As for 'mailserver', it really needs to be moves
>> to 'historic' as there are really no specifications of use.
>
> Indeed.
>
> The IETF process is very fast in this case.  IETF LC already has been
> announced today for draft-melnikov-mailserver-uri-to-historic-00.
>
> So I conclude that we both are in support of that draft. :-)
>
>
> Kind regards,
>   Alfred.
>
>
>>
>> Thank you for your time.
>>
>> All the best,
>> Mykyta Yevstifeyev
>>
>> 17.11.2010 22:49, Alfred H=CEnes wrote:
>>> My apologies for cross-posting, but this should perhaps reach a
>>> broader audience.   I suggest to send feedback to the uri-review
>>> at ietf.org mailing list, because Alexey sent his I-D announcement
>>> there as well.
>>>
>>>
>>> At Wed, 17 Nov 2010 17:26:32 +0000 , Alexey Melnikov wrote:
>>>
>>>> FYI. I've asked on Apps-discuss about deprecating the mailserver:
>>>> URIs and I've heard several voices in favor of doing that.
>>>>
>>>> I will be asking Peter Saint-Andre to sponsor this document.
>>>>
>>>> ...
>>>>
>>>>     Filename        : draft-melnikov-mailserver-uri-to-historic-00.txt
>>>> ...
>>>
>>> There are two more, apparently natively orphaned URI schemes listed
>>> as 'provisional' in the IANA registry, both mentioned in RFC 1630
>>> for the first time, and later again in RFC 1738, but never formally
>>> registered and, AFAICS, still lacking any publicly available
>>> specification:
>>>
>>>     a)  tn3270
>>>
>>>     b)  afs
>>>
>>>
>>> A quick Google search does not reveal any hints on definitions and/or
>>> actual use.  Some W3C web pages consider these as "reserved" names.
>>>
>>> Apparently none of the various RFCs on Telnet extensions for TN3270
>>> and the somehow related MIB module specifications mention the 'tn3270'
>>> URI scheme.
>>> Even stronger, for 'afs', archived mail (from 1993) seems to confirm
>>> that 'afs' as a URI scheme was a very poor idea from its beginning
>>> (see "afs: considered harmful",
>>> <http://wwwwbs.cs.tu-berlin.de/html/urls/0148.html>  ).
>>>
>>> I suggest to consider deprecating these reserved URI scheme names
>>> as well, in a single draft together with the 'mailserver' scheme
>>> (to save work in the process).
>>>
>>> Thereby, the registrations would be moved to "Historic", which,
>>> according to the definition of that RFC status, does not immediately
>>> invalidate existing use cases (if any), but serves to clarify that
>>> new implementations should not try to support the subject.
>>> The scheme names would remain in the registry, thus keeping the names
>>> "reserved", i.e. out of availability for incompatible new use.
>>>
>>> So there are a few questions, for both cases:
>>>
>>> 1)  Is anybody aware of a specification for the above provisional
>>>      URI schemes ?
>>>
>>> 2)  If "yes" for 1), are there interoperable implementations?
>>>
>>> 3)  Are these URI schemes in actual use anywhere
>>>      (even if only intended for interpretation by brainware) ?
>>>
>>> 4)  Do the answers to the above questions support deprecation?
>>>
>>>
>>> Kind regards,
>>>    Alfred.
>
>

From evnikita2@gmail.com  Fri Nov 19 06:13:56 2010
Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5864228C0D9; Fri, 19 Nov 2010 06:13:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.564
X-Spam-Level: 
X-Spam-Status: No, score=-0.564 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDL32Tf0sxza; Fri, 19 Nov 2010 06:13:55 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 020CC3A67F3; Fri, 19 Nov 2010 06:13:54 -0800 (PST)
Received: by bwz12 with SMTP id 12so4122975bwz.31 for <multiple recipients>; Fri, 19 Nov 2010 06:14:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=drJbxhWskUjQAz6hFHPlfvbs4hH6YKDuHJDoCgIwzy8=; b=GusNPmLkSRqxBFHijYdYr7n0gK9P/0IEkBoC2X1Kl351yvn8krStNbACToLiLeLeJQ NMmiy+KZzlKyWsow2kUwPfq5xnNarJOh1byptbSAxS5do0/HVZO9o/g7oeWL+z5b+qW1 jO5AgIiznPEpBp5VTokJ1wbAqCPkpivROIbvo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Pss0TM5Uo+2/RGnLMfD6Lo4Ts+L5xEXSmEEwSkhqwWKZX9zmseMgEy9RBZIkq+fgP9 sCSACQbp6YjuoYZqH6/0bddfV/MGDrjV+bNSuSBMatiMnAU1M9CMNnyBaYtjaesK2hI/ mVFeJPq7m8MOhasn4IO84JN3Qa8tY1JwIsbec=
Received: by 10.204.119.134 with SMTP id z6mr2069957bkq.166.1290176081921; Fri, 19 Nov 2010 06:14:41 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id a25sm878444bks.8.2010.11.19.06.14.37 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 06:14:39 -0800 (PST)
Message-ID: <4CE68651.5050705@gmail.com>
Date: Fri, 19 Nov 2010 16:14:41 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>, lyndon@orthanc.ca,  uri-review@ietf.org, apps-discuss@ietf.org, Claudio.Allocchio@garr.it
References: <55895239d7e7df2d41b9da075c4f149c@gandalf.orthanc.ca> <175AC1CC70EF63F569DB1757@PST.JCK.COM>
In-Reply-To: <175AC1CC70EF63F569DB1757@PST.JCK.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 19 Nov 2010 08:20:23 -0800
Subject: Re: [apps-discuss] [Uri-review]  tn3270
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 14:13:56 -0000

John,

As you say,
"There is almost certainly no harm in keeping the URI definition
and probably some harm in getting rid of it. ". So it should be asked -
what harm is there in moving the 'tns3270' URI scheme to
'Historic'. At the moment no acceptable definition seems to be
found. Some RFCs discussing issues connected with IBM 3270
Emulation are RFC 1041 and 2355, but they are Proposed and Draft
Standards. I should repeat that at the moment the technology
of IBM 3270 emulation is no longer used. It is not an acceptable
way for the Internet Community at all to remain any standards
no longer needed alive. Maybe this is harmful, but not revising
current standards to make them modern and needed.

So IMO there is no reason to leave the 'tns3270' URI scheme as current
as well as 'mailserver' one.

Best regards,
Mykyta Yevstifeyev

19.11.2010 10:11, John C Klensin wrote:
> While I'm no fan of the 3270 (and wasn't back when I was doing
> programming that depended on them), I have to agree with Lyndon.
> There is almost certainly no harm in keeping the URI definition
> and probably some harm in getting rid of it.   One could argue
> that the spec should be retired because it is inadequate and
> obsolete, but inventing and applying that criterion is IMO
> unreasonable unless we intend to start applying the "time out
> and die" provisions of RFC 2026 for the first time in history.
>
>      john
>
>
> --On Thursday, November 18, 2010 21:57 -0800 "Lyndon Nerenberg
> (VE6BBM/VE7TFX)"<lyndon@orthanc.ca>  wrote:
>
>>> Well, AFAIK, 3270 emulation is still in some limited use in
>>> commercial legacy mixed-platform environments, but I've never
>>> heard of practical usage of the 'tn3270' URI scheme in that
>>> context -- all such business applications are likely to
>>> operate based on tightly controlled local configuration of
>>> the access points and not driven by some kind of browser
>>> software operating on 'tn3270' URIs.
>> That's an awfully presumptive generalization to make about how
>> other people's businesses operate.  That aside, "must be
>> accessible to the global Internet" isn't a criteria for (or
>> against) standardization (or registration).  Standards can
>> also apply inside walled gardens.
>> ...
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review
>


From Michael.Wojcik@microfocus.com  Fri Nov 19 07:10:01 2010
Return-Path: <Michael.Wojcik@microfocus.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1243A680A; Fri, 19 Nov 2010 07:10:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.67
X-Spam-Level: 
X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930,  BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKo6lNH8nGpS; Fri, 19 Nov 2010 07:10:00 -0800 (PST)
Received: from wgateout.microfocus.com (wgateout.microfocus.com [213.83.72.248]) by core3.amsl.com (Postfix) with ESMTP id 591173A680B; Fri, 19 Nov 2010 07:10:00 -0800 (PST)
Received: from MTV-EXCHANGE.microfocus.com (mtv-exchange.microfocus.com [10.20.11.215]) by wgateout.microfocus.com (8.13.6/8.13.6) with ESMTP id oAJFWwRS004340; Fri, 19 Nov 2010 15:33:01 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Fri, 19 Nov 2010 07:10:46 -0800
Message-ID: <81F42F63D5BB344ABF294F8E80990C7902782A41@MTV-EXCHANGE.microfocus.com>
In-Reply-To: <4CE55558.7010300@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Uri-review] [Fwd:I-D	Action:draft-melnikov-mailserver-uri-to-historic-00.txt]
Thread-Index: AcuHPmA8wMEhTOD+QgmQMPMfik+1YgAuuj5Q
References: <201011172049.VAA14181@TR-Sys.de> <4CE55558.7010300@gmail.com>
From: "Michael Wojcik" <Michael.Wojcik@microfocus.com>
To: <uri-review@ietf.org>, <apps-discuss@ietf.org>
X-Mailman-Approved-At: Fri, 19 Nov 2010 08:20:22 -0800
Subject: Re: [apps-discuss] [Uri-review] [Fwd:I-D	Action:draft-melnikov-mailserver-uri-to-historic-00.txt]
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 15:10:01 -0000

PiBGcm9tOiB1cmktcmV2aWV3LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp1cmktcmV2aWV3LWJv
dW5jZXNAaWV0Zi5vcmddDQo+IE9uIEJlaGFsZiBPZiBNeWt5dGEgWWV2c3RpZmV5ZXYNCj4gU2Vu
dDogVGh1cnNkYXksIDE4IE5vdmVtYmVyLCAyMDEwIDExOjMzDQo+IA0KPiBBcyBmb3IgdG5zMzcy
MCBpdCBpcyBhIHRlbG5ldCBzY2hlbWUgZm9yIGFjY2VzcyB0byBJQk0gMzcyMCB0ZXJtaW5hbC4N
Cg0KVGhpcyBpcyBpbmNvcnJlY3QuIFRoZSB0bjMyNzAgc2NoZW1lIHJlZmVycyB0byBUTjMyNzAs
IGEgbG9vc2Ugc2V0IG9mIHJlY29tbWVuZGF0aW9ucyBmb3IgdXNpbmcgVGVsbmV0IHdpdGggaG9z
dCBzeXN0ZW1zIHRoYXQgc3VwcG9ydCBJQk0ncyAzMjcwIHByb3RvY29sLiAoSXQgY2FuJ3QgYmUg
dXNlZCAiZm9yIGFjY2VzcyB0byBJQk0gMzI3MCB0ZXJtaW5hbCIsIHNpbmNlIDMyNzAgdGVybWlu
YWxzIGFyZSBub3Qgc2VydmVycywgYW5kIGluZGVlZCBpdCdzIGludGVuZGVkIGFzIGFuIGFsdGVy
bmF0aXZlIHRvIGEgcGh5c2ljYWwgMzI3MCB0ZXJtaW5hbCBhbmQgdGhlIFNOQSAzMjcwIHByb3Rv
Y29scy4pDQoNCk5vdGUgdGhlcmUgaXMgbm8gc2luZ2xlIFROMzI3MCBzcGVjaWZpY2F0aW9uOyBu
ZWl0aGVyIGlzIGl0IGEgZGlzdGluY3QgcHJvdG9jb2wuICJDbGFzc2ljIiBvciAiQmFzaWMiIFRO
MzI3MCBpcyBUZWxuZXQgd2l0aCB2YXJpb3VzIG9wdGlvbnMgZW5hYmxlZCwgaW5jbHVkaW5nIEJp
bmFyeSwgRU9SLCBhbmQgVGVybWluYWwtdHlwZS4gQXMgc3VjaCwgaXQgaXMgZG9jdW1lbnRlZCBi
eSBhIHNlcmllcyBvZiBSRkNzLCBpbmNsdWRpbmcgODU0LCA4NTUsIDg1NiwgODU3LCA4ODUsIGFu
ZCAxMDkxLiBBZGRpdGlvbmFsIFJGQ3MgKDEwNDEsIDE1NzYsIDE2NDYpIGFkZCBvcHRpb25zIGFu
ZCByZWNvbW1lbmRhdGlvbnMuDQoNCiJUTjMyNzAgRW5oYW5jZWQiIG9yICJUTjMyNzBFIiAoUkZD
IDIzNTUpIGlzIGFuIGF0dGVtcHQgdG8gcHJvZHVjZSBhbiBpbXByb3ZlZCBUTjMyNzAgcGVyc29u
YWxpdHkgZm9yIFRlbG5ldC4gKFRoZXJlIHdhcyBhbiBJLUQgdG8gdXBkYXRlIDIzNTUsIGJ1dCBp
dCBleHBpcmVkIHdpdGhvdXQgYmVpbmcgYWRvcHRlZC4pIFROMzI3MEUgaXMgd2lkZWx5IHVzZWQs
IGJ1dCBoYXMgbm90IGRpc3BsYWNlZCBDbGFzc2ljIFROMzI3MCBlbnRpcmVseS4NCg0KPiBBcyB0
aGlzIHRlcm1pbmFsIHdlcmUgc3RhcnRlZCB0byBiZSBwcm9kdWNlZCBpbiAxOTcyLCBzbyBub3cg
aXQgaXMgT0sNCj4gdG8gbW92ZSBpdCB0byAnSGlzdG9yaWMnLiBUaGlzIHNlcnZpY2UgaXMgbm90
IGJlaW5nIHVzZWQgYW55IG1vcmUuDQoNClRoaXMgaXMgY29tcGxldGVseSBpbmNvcnJlY3QuIFRO
MzI3MCBpcyBzdGlsbCBpbiB3aWRlc3ByZWFkIHVzZS4NCg0KRnJhbmtseSwgSSdtIGEgYml0IGJh
ZmZsZWQgdGhhdCBzb21lb25lIGNvdWxkIHNpbXBseSBjbGFpbSBUTjMyNzAgd2FzIG5vIGxvbmdl
ciBpbiB1c2Ugd2l0aG91dCBkb2luZyBhbnkgcmVzZWFyY2ggaW50byB0aGUgcXVlc3Rpb24uDQoN
Ci0tIA0KTWljaGFlbCBXb2pjaWsNClByaW5jaXBhbCBTb2Z0d2FyZSBTeXN0ZW1zIERldmVsb3Bl
ciwgTWljcm8gRm9jdXMNCg0K

From Michael.Wojcik@microfocus.com  Fri Nov 19 07:15:10 2010
Return-Path: <Michael.Wojcik@microfocus.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8163A6801; Fri, 19 Nov 2010 07:15:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.134
X-Spam-Level: 
X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePQs1NGxrBRV; Fri, 19 Nov 2010 07:15:09 -0800 (PST)
Received: from wgateout.microfocus.com (wgateout.microfocus.com [213.83.72.248]) by core3.amsl.com (Postfix) with ESMTP id B2A0A3A680A; Fri, 19 Nov 2010 07:15:08 -0800 (PST)
Received: from MTV-EXCHANGE.microfocus.com (mtv-exchange.microfocus.com [10.20.11.215]) by wgateout.microfocus.com (8.13.6/8.13.6) with ESMTP id oAJFc9Ce004744; Fri, 19 Nov 2010 15:38:09 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 19 Nov 2010 07:14:13 -0800
Message-ID: <81F42F63D5BB344ABF294F8E80990C7902782A42@MTV-EXCHANGE.microfocus.com>
In-Reply-To: <4CE68651.5050705@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Uri-review] [apps-discuss] tn3270
Thread-Index: AcuH9CP8M1UjBXDfSEqwhLhFphb2/AACAF1A
References: <55895239d7e7df2d41b9da075c4f149c@gandalf.orthanc.ca><175AC1CC70EF63F569DB1757@PST.JCK.COM> <4CE68651.5050705@gmail.com>
From: "Michael Wojcik" <Michael.Wojcik@microfocus.com>
To: <uri-review@ietf.org>, <apps-discuss@ietf.org>
X-Mailman-Approved-At: Fri, 19 Nov 2010 08:20:23 -0800
Subject: Re: [apps-discuss] [Uri-review]  tn3270
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 15:15:10 -0000

> From: uri-review-bounces@ietf.org [mailto:uri-review-bounces@ietf.org]
> On Behalf Of Mykyta Yevstifeyev
> Sent: Friday, 19 November, 2010 09:15
>
> I should repeat that
> at the moment the technology of IBM 3270 emulation is no longer used.

No, you shouldn't, because that's completely false.

This sort of gross error throws the remainder of your argument into
considerable doubt, in my opinion.

--=20
Michael Wojcik
Principal Software Systems Developer, Micro Focus



From john-ietf@jck.com  Fri Nov 19 10:29:11 2010
Return-Path: <john-ietf@jck.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F823A6809; Fri, 19 Nov 2010 10:29:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkeynxHHz01v; Fri, 19 Nov 2010 10:29:09 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 7318F3A67FF; Fri, 19 Nov 2010 10:29:09 -0800 (PST)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PJVie-000A3n-Ap; Fri, 19 Nov 2010 13:29:56 -0500
Date: Fri, 19 Nov 2010 13:29:55 -0500
From: John C Klensin <john-ietf@jck.com>
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
Message-ID: <93F0919948C56C4A56FF658A@PST.JCK.COM>
In-Reply-To: <4CE68651.5050705@gmail.com>
References: <55895239d7e7df2d41b9da075c4f149c@gandalf.orthanc.ca> <175AC1CC70EF63F569DB1757@PST.JCK.COM> <4CE68651.5050705@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: uri-review@ietf.org, Claudio.Allocchio@garr.it, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review]  tn3270
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 18:29:11 -0000

--On Friday, November 19, 2010 16:14 +0200 Mykyta Yevstifeyev
<evnikita2@gmail.com> wrote:

> John,
> 
> As you say,
> "There is almost certainly no harm in keeping the URI
> definition
> and probably some harm in getting rid of it. ". So it should
> be asked -
> what harm is there in moving the 'tns3270' URI scheme to
> 'Historic'. At the moment no acceptable definition seems to be
> found. Some RFCs discussing issues connected with IBM 3270
> Emulation are RFC 1041 and 2355, but they are Proposed and
> Draft
> Standards. I should repeat that at the moment the technology
> of IBM 3270 emulation is no longer used. It is not an
> acceptable
> way for the Internet Community at all to remain any standards
> no longer needed alive. Maybe this is harmful, but not revising
> current standards to make them modern and needed.

Several of us -- including Lyndon, Michael, and myself -- have
observed counterexamples to your assertion that IBM 3270
emulation is no longer in use.  Can you explain the reasoning or
published research that supports your assertion in the light of
those counterexamples?

      john



From A.Hoenes@TR-Sys.de  Fri Nov 19 10:44:10 2010
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E8DE28C114; Fri, 19 Nov 2010 10:44:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.332
X-Spam-Level: 
X-Spam-Status: No, score=-98.332 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZFfhZ7i6JIv; Fri, 19 Nov 2010 10:44:09 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id EC9B328C0ED; Fri, 19 Nov 2010 10:44:07 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA253772280; Fri, 19 Nov 2010 19:44:40 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA17983; Fri, 19 Nov 2010 19:44:34 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@TR-Sys.de>
Message-Id: <201011191844.TAA17983@TR-Sys.de>
To: Michael.Wojcik@microfocus.com
Date: Fri, 19 Nov 2010 19:44:34 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] tn3270
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 18:44:10 -0000

Michael, all,

nobody (ehem, at least almost nobody) doubts that TN3270 service
is in use today.  But that isn't the question being discussed in
this thread.

The questions of interest are:

a)  Are 'tn3270' URIs used ?

b)  Where is the specification and a registration document ?

    Or is there only a semi-secret oral tradition that nobody has
    deemed worth being written up in a URI scheme registration
    document brought to IANA ?

and secondary to a), conditional under b) :

c)  Is it expected that new implementations of software making
    use of 'tn3270' URIs will be done ?

d)  Does the IETF want to encourage new URI implementations to support
    the 'tn3270' URI scheme (if it has been actually defined) ?

[ And I personally would like to add:
  If there actually is demand, why is there no specification that would
  allow an independent, yet interoperable, new implementation?
  But that's also not the basic question.
]

Unless all of a) through d) can be answered in an affirmative manner,
the correct conclusion to draw indeed would be to move the reserved
scheme name to Historic.

There seems to be some sublime, unspecific FUD about "Historic".
"Historic" for an RFC or an IANA registry entry does not mean
"no implementations" or "not used"; it is an indication that the
specification or technology
-  has been or is going to be superseded by something newer
   (you just have confirmed e.g., that indeed for "System i" there
   is a preferred, more recent successor technology for TN3270 service,
   and if 'tn3270' URIs were needed, there might be something other
   for use with TN5250 as well, isn't it?), and
-  the IETF does not recommend any more general implementation of
   the older technology.

Anybody is free to implement a Historic specification, but they should
not expect everybody to do so; and everybody is free to [continue to]
use implementations of a specification that has been moved to Historic
status.
(To reinforce it, "technology" here means use of 'tn3270' URIs,
not use of TN3270 service.)

I also rely in my work on lots of protocols that now are considered
Historic; this does not cause a disease; it's simply that neither
I myself nor my customers have an expectation that these are
implemented in common new hardware/firmware/software.
(E.g., RTELNET, RFC 818, comes to mind -- still used with numerous
factory floor devices -- but Status: HISTORIC.)

A short note on IANA processing:  Since a while, IANA can manage
timed processes; this hasn't been so in the past.  In more recent
IANA registries that make use of this capability, "provisional"
entries are bound to an expiry date, and without updates of such
entries or conversion to regular entries, they automagically
disappear from the registry after the time-out.
Conceptionally, this apparently was the idea in RFC 1738, where it
talked about "reserving the name, waiting for future specification"
(which had been expected to be provided in a reasonable timeframe).


To repeat my recommendation to stakeholders from my previous posting:

If there _is_ an agreed-upon spec for 'tn3270' URIs, write it up in a
short URI scheme registration draft (that should be possible in no
more than half a dozen of pages) and pursue publication as an RFC
(I assume that our APP ADs would support this in the same manner they
offered support for "blindly" moving to Historic a non-specified
scheme, via a dedicated memo).

If such effort doesn't happen, this will be taken as a strong
indication that there is no sustained interest in the provisionally
registered 'tn3270' URI scheme name and it actually SHOULD be moved
to Historic.


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+


From john-ietf@jck.com  Fri Nov 19 11:25:02 2010
Return-Path: <john-ietf@jck.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B193A6863; Fri, 19 Nov 2010 11:25:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id id0AzPvbm1HX; Fri, 19 Nov 2010 11:24:54 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 4DECF3A67FF; Fri, 19 Nov 2010 11:24:50 -0800 (PST)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PJWaZ-000BIg-Jh; Fri, 19 Nov 2010 14:25:39 -0500
Date: Fri, 19 Nov 2010 14:25:38 -0500
From: John C Klensin <john-ietf@jck.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <A232FF7C06EE5B1C0F886130@PST.JCK.COM>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: [apps-discuss] Provisional URI registrations (was: draft-melnikov-mailserver-uri-to-historic-00.txt)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 19:25:02 -0000

Alexey,

It seems to me that the TN3270 discussion has started to
conflate two separate issues and that we might derive something
useful from that discussion:

	(1) Whether the URI scheme is properly specified and in
	use
	
	(2) Whether the underlying applications protocol is
	well-specified, in use, and still useful.

For TN3270, the answer to "properly specified" is clearly "no"
because, as several people have pointed out, there really is no
spec, just a reservation.  It may still be in use, and several
people have made credible suggestions that is actually the case.
Certainly the answer to (2) is "yes".  

Having a tn3270 URI in use without a spec is actually troubling
because there is no way to tell whether all uses of the keyword
are consistent.   However, deprecating the keyword or dropping
it from the registry is not a solution to that problem.  Either
getting a spec or warning people off would be a superior
approach.

That situation is very different from the "mailserver" case,
where there really isn't an underlying application protocol in
active use, at least as far as I know.

Perhaps that difference is a useful differentiating factor.  For
some years, we had the implicit assumption that every
application protocol deserved a URI.  I've personally always
felt that was a bad assumption because of mismatches between the
operational model of some protocols and the URI model, but I
lost that argument.  Looking at the situation from the
perspective of today's environment, I suggest that:

(1) We move URI schemes to Historic only if we are justified and
willing to move the underlying applications protocol
specifications to Historic -or- if no such protocol spec exists
and there is no reasonable prospect of getting one.

I note that, using that criterion, "mailserver" would go to
Historic and "tn3270" would not.  I haven't done enough research
to have an opinion about "afs", but see below.

(2) We instruct IANA to separate the "Provisional" category of
the URI Scheme registry into two categories: 

	* Provisional (defined more or less as work in progress)
	and
	
	* Reserved keyword

and move any of the now-provisional keywords for which there are
adequate protocol specs but no adequate URI spec (existing or in
active progress) into it.  I note that RFC 1738 describes the
keywords it lists as "proposed at various times" with
"...suggested that IANA reserve...", not "Provisional".  After a
quick search, I haven't been able to discover any instructions
to IANA to identify them as Provisional.  Unless such
instructions exist, one could sensibly interpret the separation
suggested here as correcting an error.

It seems to me that, until and unless the IETF takes a strong
position against the "all application protocols can reasonably
be associated with a URI" model, having a facility to reserve
application-associated keywords for applications that are
well-defined and URI schemes that might be developed in the
future would promote interoperability by providing a warning
that the keyword should not be generally used until (and unless)
a spec is produced.

If we took that approach, we could safely put both tn3270 and
afs into "Reserved" if only because it is not clear to me that
making a more careful decision about the latter would be worth
the effort it would take.   We could similarly move anything
else in the Provisional list that is associated with an expired
I-D to Reserved.

If there is sympathy for this approach and an I-D is needed to
establish rules for adding new entries to the "Reserved"
category, I guess I'm willing to quickly turn out a first draft.
That draft could also formally create the category if needed
but, as noted above, I think its absence is an error on IANA's
part.

    john


From ietfc@btconnect.com  Fri Nov 19 11:27:44 2010
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81BA728C12F; Fri, 19 Nov 2010 11:27:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLKyQDjahNRN; Fri, 19 Nov 2010 11:27:21 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by core3.amsl.com (Postfix) with ESMTP id 245183A6907; Fri, 19 Nov 2010 11:26:59 -0800 (PST)
Received: from host81-156-207-177.range81-156.btcentralplus.com (HELO pc6) ([81.156.207.177]) by c2beaomr07.btconnect.com with SMTP id AUG12839; Fri, 19 Nov 2010 19:26:06 +0000 (GMT)
Message-ID: <003701cb8816$f6470a60$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: =?iso-8859-1?Q?Alfred_H=CEnes?= <ah@TR-Sys.de>
References: <201011191844.TAA17983@TR-Sys.de>
Date: Fri, 19 Nov 2010 19:24:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CE6CF4B.0343, actions=tag
X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4CE6CF50.01F5,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] tn3270
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 19:27:44 -0000

----- Original Message -----
From: "Alfred HÎnes" <ah@TR-Sys.de>
To: <Michael.Wojcik@microfocus.com>
Cc: <uri-review@ietf.org>; <apps-discuss@ietf.org>
Sent: Friday, November 19, 2010 7:44 PM

> Michael, all,
>
> nobody (ehem, at least almost nobody) doubts that TN3270 service
> is in use today.  But that isn't the question being discussed in
> this thread.
>
> The questions of interest are:
>
> a)  Are 'tn3270' URIs used ?
>
> b)  Where is the specification and a registration document ?
>
>     Or is there only a semi-secret oral tradition that nobody has
>     deemed worth being written up in a URI scheme registration
>     document brought to IANA ?
>
> and secondary to a), conditional under b) :
>
> c)  Is it expected that new implementations of software making
>     use of 'tn3270' URIs will be done ?
>
> d)  Does the IETF want to encourage new URI implementations to support
>     the 'tn3270' URI scheme (if it has been actually defined) ?
>
> [ And I personally would like to add:
>   If there actually is demand, why is there no specification that would
>   allow an independent, yet interoperable, new implementation?
>   But that's also not the basic question.
> ]
> Unless all of a) through d) can be answered in an affirmative manner,
> the correct conclusion to draw indeed would be to move the reserved
> scheme name to Historic.
>
> There seems to be some sublime, unspecific FUD about "Historic".
> "Historic" for an RFC or an IANA registry entry does not mean
> "no implementations" or "not used"; it is an indication that the
> specification or technology
> -  has been or is going to be superseded by something newer
>    (you just have confirmed e.g., that indeed for "System i" there
>    is a preferred, more recent successor technology for TN3270 service,
>    and if 'tn3270' URIs were needed, there might be something other
>    for use with TN5250 as well, isn't it?), and
> -  the IETF does not recommend any more general implementation of
>    the older technology.

A very IETF-centric view of the world.

Shock, horror; there are other people and places who produce and use
interoperable software without making it an RFC.  Some may have started here and
taken there custom elsewhere.  Which makes your arguments specious; you give no
valid reason to change the status of tn3270 and, in the absence of this, we
should leave well alone - we have no idea whose toes we might be treading on and
it would be presumptuous of us to assume that we know everything about this
topic (and if I knew more, I would reveal it).

Tom Petch





>
> Anybody is free to implement a Historic specification, but they should
> not expect everybody to do so; and everybody is free to [continue to]
> use implementations of a specification that has been moved to Historic
> status.
> (To reinforce it, "technology" here means use of 'tn3270' URIs,
> not use of TN3270 service.)
>
> I also rely in my work on lots of protocols that now are considered
> Historic; this does not cause a disease; it's simply that neither
> I myself nor my customers have an expectation that these are
> implemented in common new hardware/firmware/software.
> (E.g., RTELNET, RFC 818, comes to mind -- still used with numerous
> factory floor devices -- but Status: HISTORIC.)
>
> A short note on IANA processing:  Since a while, IANA can manage
> timed processes; this hasn't been so in the past.  In more recent
> IANA registries that make use of this capability, "provisional"
> entries are bound to an expiry date, and without updates of such
> entries or conversion to regular entries, they automagically
> disappear from the registry after the time-out.
> Conceptionally, this apparently was the idea in RFC 1738, where it
> talked about "reserving the name, waiting for future specification"
> (which had been expected to be provided in a reasonable timeframe).
>
>
> To repeat my recommendation to stakeholders from my previous posting:
>
> If there _is_ an agreed-upon spec for 'tn3270' URIs, write it up in a
> short URI scheme registration draft (that should be possible in no
> more than half a dozen of pages) and pursue publication as an RFC
> (I assume that our APP ADs would support this in the same manner they
> offered support for "blindly" moving to Historic a non-specified
> scheme, via a dedicated memo).
>
> If such effort doesn't happen, this will be taken as a strong
> indication that there is no sustained interest in the provisionally
> registered 'tn3270' URI scheme name and it actually SHOULD be moved
> to Historic.
>
>
> Kind regards,
>   Alfred.
>
> --
>
> +------------------------+--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
> | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
> | D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
> +------------------------+--------------------------------------------+
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From jsalowey@cisco.com  Fri Nov 19 12:57:53 2010
Return-Path: <jsalowey@cisco.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0844928C106; Fri, 19 Nov 2010 12:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.449
X-Spam-Level: 
X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9SmQD5avBN1; Fri, 19 Nov 2010 12:57:52 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 08D433A68DC; Fri, 19 Nov 2010 12:57:52 -0800 (PST)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAOJz5kyrR7H+/2dsb2JhbACiYXGiT5s4AoVJBIRagSqEDEuDDg
X-IronPort-AV: E=Sophos;i="4.59,225,1288569600"; d="scan'208";a="220475073"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 19 Nov 2010 20:58:42 +0000
Received: from [10.33.251.139] ([10.33.251.139]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAJKwfr0007603; Fri, 19 Nov 2010 20:58:41 GMT
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=iso-8859-1
From: Joe Salowey <jsalowey@cisco.com>
In-Reply-To: <201011191844.TAA17983@TR-Sys.de>
Date: Fri, 19 Nov 2010 12:58:51 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <6399CCB6-FB18-4776-BC1F-6B705228277F@cisco.com>
References: <201011191844.TAA17983@TR-Sys.de>
To: =?iso-8859-1?Q?Alfred_H=CEnes?= <ah@TR-Sys.de>
X-Mailer: Apple Mail (2.1081)
Cc: Michael.Wojcik@microfocus.com, uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] tn3270
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 19 Nov 2010 20:57:53 -0000

On Nov 19, 2010, at 10:44 AM, Alfred H=CEnes wrote:

> Michael, all,
>=20
> nobody (ehem, at least almost nobody) doubts that TN3270 service
> is in use today.  But that isn't the question being discussed in
> this thread.
>=20
> The questions of interest are:
>=20
> a)  Are 'tn3270' URIs used ?
>=20
[Joe] Yes, there are tn3270 terminal emulators that install themselves =
as a helper application for a web browser similar to a telnet =
application. =20


> b)  Where is the specification and a registration document ?
>=20
[Joe] Don't know


>    Or is there only a semi-secret oral tradition that nobody has
>    deemed worth being written up in a URI scheme registration
>    document brought to IANA ?
>=20
> and secondary to a), conditional under b) :
>=20
> c)  Is it expected that new implementations of software making
>    use of 'tn3270' URIs will be done ?
>=20

[Joe] Sure, people are still selling terminal emulators

> d)  Does the IETF want to encourage new URI implementations to support
>    the 'tn3270' URI scheme (if it has been actually defined) ?
>=20
> [ And I personally would like to add:
>  If there actually is demand, why is there no specification that would
>  allow an independent, yet interoperable, new implementation?
>  But that's also not the basic question.
> ]
>=20
[Joe] Why would they want to discourage it?  there may be no definition =
perhaps because the URI scheme is very similar to telnet (which was =
undocumented in the IETF for a long time). =20

> Unless all of a) through d) can be answered in an affirmative manner,
> the correct conclusion to draw indeed would be to move the reserved
> scheme name to Historic.
>=20
> There seems to be some sublime, unspecific FUD about "Historic".
> "Historic" for an RFC or an IANA registry entry does not mean
> "no implementations" or "not used"; it is an indication that the
> specification or technology
> -  has been or is going to be superseded by something newer
>   (you just have confirmed e.g., that indeed for "System i" there
>   is a preferred, more recent successor technology for TN3270 service,
>   and if 'tn3270' URIs were needed, there might be something other
>   for use with TN5250 as well, isn't it?), and
> -  the IETF does not recommend any more general implementation of
>   the older technology.
>=20

[Joe] I guess I don't particularly care if it is moved to historic or =
not because I don't think it will effect if anyone will use it or not., =
but I don't think either of the two above apply.  There is tn5250 and =
some use a URI for this as well, but it is different than 3270 and does =
not necessarily supersede it. =20


> Anybody is free to implement a Historic specification, but they should
> not expect everybody to do so; and everybody is free to [continue to]
> use implementations of a specification that has been moved to Historic
> status.
> (To reinforce it, "technology" here means use of 'tn3270' URIs,
> not use of TN3270 service.)
>=20
> I also rely in my work on lots of protocols that now are considered
> Historic; this does not cause a disease; it's simply that neither
> I myself nor my customers have an expectation that these are
> implemented in common new hardware/firmware/software.
> (E.g., RTELNET, RFC 818, comes to mind -- still used with numerous
> factory floor devices -- but Status: HISTORIC.)
>=20
> A short note on IANA processing:  Since a while, IANA can manage
> timed processes; this hasn't been so in the past.  In more recent
> IANA registries that make use of this capability, "provisional"
> entries are bound to an expiry date, and without updates of such
> entries or conversion to regular entries, they automagically
> disappear from the registry after the time-out.
> Conceptionally, this apparently was the idea in RFC 1738, where it
> talked about "reserving the name, waiting for future specification"
> (which had been expected to be provided in a reasonable timeframe).
>=20
>=20
> To repeat my recommendation to stakeholders from my previous posting:
>=20
> If there _is_ an agreed-upon spec for 'tn3270' URIs, write it up in a
> short URI scheme registration draft (that should be possible in no
> more than half a dozen of pages) and pursue publication as an RFC
> (I assume that our APP ADs would support this in the same manner they
> offered support for "blindly" moving to Historic a non-specified
> scheme, via a dedicated memo).
>=20
> If such effort doesn't happen, this will be taken as a strong
> indication that there is no sustained interest in the provisionally
> registered 'tn3270' URI scheme name and it actually SHOULD be moved
> to Historic.
>=20
>=20
> Kind regards,
>  Alfred.
>=20
> --=20
>=20
> =
+------------------------+--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  =
|
> | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         =
|
> | D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     =
|
> =
+------------------------+--------------------------------------------+
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From A.Hoenes@TR-Sys.de  Sun Nov 21 09:11:08 2010
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681583A6A8B; Sun, 21 Nov 2010 09:11:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.397
X-Spam-Level: 
X-Spam-Status: No, score=-98.397 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYxhC2qYhemM; Sun, 21 Nov 2010 09:11:06 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id E8C6A3A6A94; Sun, 21 Nov 2010 09:11:03 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA262089486; Sun, 21 Nov 2010 18:11:26 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA19931; Sun, 21 Nov 2010 18:11:24 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@TR-Sys.de>
Message-Id: <201011211711.SAA19931@TR-Sys.de>
To: john-ietf@jck.com, alexey.melnikov@isode.com
Date: Sun, 21 Nov 2010 18:11:24 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Provisional URI registrations (was: draft-melnikov-mailserver-uri-to-histori-00)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 21 Nov 2010 17:11:08 -0000

At Fri, 19 Nov 2010 14:25:38 -0500, John C Klensin wrote:

> ...
>
> (2) We instruct IANA to separate the "Provisional" category of
> the URI Scheme registry into two categories:
>
>       * Provisional (defined more or less as work in progress)
>         and
>       * Reserved keyword
>
> and move any of the now-provisional keywords for which there are
> adequate protocol specs but no adequate URI spec (existing or in
> active progress) into it.  ...

Good idea.   Hence: +1 !

>                       ...  I note that RFC 1738 describes the
> keywords it lists as "proposed at various times" with
> "...suggested that IANA reserve...", not "Provisional".  After a
> quick search, I haven't been able to discover any instructions
> to IANA to identify them as Provisional.  Unless such
> instructions exist, one could sensibly interpret the separation
> suggested here as correcting an error.

True.


> It seems to me that, until and unless the IETF takes a strong
> position against the "all application protocols can reasonably
> be associated with a URI" model, having a facility to reserve
> application-associated keywords for applications that are
> well-defined and URI schemes that might be developed in the
> future would promote interoperability by providing a warning
> that the keyword should not be generally used until (and unless)
> a spec is produced.
>
> If we took that approach, we could safely put both tn3270 and
> afs into "Reserved" if only because it is not clear to me that
> making a more careful decision about the latter would be worth
> the effort it would take.   We could similarly move anything
> else in the Provisional list that is associated with an expired
> I-D to Reserved.

Agreed.


> If there is sympathy for this approach and an I-D is needed to
> establish rules for adding new entries to the "Reserved"
> category, I guess I'm willing to quickly turn out a first draft.
> That draft could also formally create the category if needed
> but, as noted above, I think its absence is an error on IANA's
> part.
>
>     john

If the latter assumption holds (and the lack of explicit instructions
in RFC 4395 seems to indicate that), couldn't we do that in a more
lightweight manner?

I propose that the IANA Considerations section of Alexey's draft be
amended by a short statement that causes IANA to do the above during
the publication process of the 'mailserver to Historic" draft.

Stawman proposal (please feel free to improve):

   IANA is asked to revert the state of the entries in the URI scheme
   registry that originally have only been "reserved for use in future
   specification" and for which no registration document has been
   submitted ever that would qualify these entries for their current
   state (as defined in RFC 4395) back to their state prior to the
   publication of RFC 4395.  The related changes performed those days
   are deemed as not intended by RFC 4395 and hence inadvertant.

   Therefore, IANA is asked to create a new subheading and move two
   entries from the "provisional" category into this new category:

        Reserved URI Scheme Names
        -------------------------

        afs                                         [RFC1738]
        tn3270                                      [RFC1738]


Kind regards,
  Alfred HÎnes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+


From GK@ninebynine.org  Sun Nov 21 14:34:55 2010
Return-Path: <GK@ninebynine.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4711B3A6AB4; Sun, 21 Nov 2010 14:34:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSyEE4UWHKut; Sun, 21 Nov 2010 14:34:54 -0800 (PST)
Received: from relay5.mail.ox.ac.uk (relay5.mail.ox.ac.uk [163.1.2.163]) by core3.amsl.com (Postfix) with ESMTP id C89613A68E3; Sun, 21 Nov 2010 14:34:53 -0800 (PST)
Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay5.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from <GK@ninebynine.org>) id 1PKIVd-0004u2-IT; Sun, 21 Nov 2010 22:35:45 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK@ninebynine.org>) id 1PKIVd-0001uD-0n; Sun, 21 Nov 2010 22:35:45 +0000
Message-ID: <4CE99C5D.9040601@ninebynine.org>
Date: Sun, 21 Nov 2010 22:25:33 +0000
From: Graham Klyne <GK@ninebynine.org>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>
References: <A232FF7C06EE5B1C0F886130@PST.JCK.COM>
In-Reply-To: <A232FF7C06EE5B1C0F886130@PST.JCK.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 21 Nov 2010 22:34:55 -0000

John,

With reference to your suggestions about the registry (and in no way intending 
to challenge what you say about tn3270)

We have "permanent", "provisional" and "historical" registration classes for URI 
schemes.  For practical purposes, I think the "provisional" registry serves the 
same role as the "reserved" one you suggest [1].  I think the additional 
bureaucracy incurred to create a new registry class is not justified by 
practical benefit.  It's easy enough to add some commentary to the registration 
template

(For message headers, this is not quite true, as provisional registration is not 
required to be unique, but in all the time it's been running, in my role as 
reviewer I've never seen a request to register a new name that is already 
present in the provisional registry.)

#g
--

[1] http://tools.ietf.org/html/rfc4395 (sections 3 and 5.2)


John C Klensin wrote:
> Alexey,
> 
> It seems to me that the TN3270 discussion has started to
> conflate two separate issues and that we might derive something
> useful from that discussion:
> 
> 	(1) Whether the URI scheme is properly specified and in
> 	use
> 	
> 	(2) Whether the underlying applications protocol is
> 	well-specified, in use, and still useful.
> 
> For TN3270, the answer to "properly specified" is clearly "no"
> because, as several people have pointed out, there really is no
> spec, just a reservation.  It may still be in use, and several
> people have made credible suggestions that is actually the case.
> Certainly the answer to (2) is "yes".  
> 
> Having a tn3270 URI in use without a spec is actually troubling
> because there is no way to tell whether all uses of the keyword
> are consistent.   However, deprecating the keyword or dropping
> it from the registry is not a solution to that problem.  Either
> getting a spec or warning people off would be a superior
> approach.
> 
> That situation is very different from the "mailserver" case,
> where there really isn't an underlying application protocol in
> active use, at least as far as I know.
> 
> Perhaps that difference is a useful differentiating factor.  For
> some years, we had the implicit assumption that every
> application protocol deserved a URI.  I've personally always
> felt that was a bad assumption because of mismatches between the
> operational model of some protocols and the URI model, but I
> lost that argument.  Looking at the situation from the
> perspective of today's environment, I suggest that:
> 
> (1) We move URI schemes to Historic only if we are justified and
> willing to move the underlying applications protocol
> specifications to Historic -or- if no such protocol spec exists
> and there is no reasonable prospect of getting one.
> 
> I note that, using that criterion, "mailserver" would go to
> Historic and "tn3270" would not.  I haven't done enough research
> to have an opinion about "afs", but see below.
> 
> (2) We instruct IANA to separate the "Provisional" category of
> the URI Scheme registry into two categories: 
> 
> 	* Provisional (defined more or less as work in progress)
> 	and
> 	
> 	* Reserved keyword
> 
> and move any of the now-provisional keywords for which there are
> adequate protocol specs but no adequate URI spec (existing or in
> active progress) into it.  I note that RFC 1738 describes the
> keywords it lists as "proposed at various times" with
> "...suggested that IANA reserve...", not "Provisional".  After a
> quick search, I haven't been able to discover any instructions
> to IANA to identify them as Provisional.  Unless such
> instructions exist, one could sensibly interpret the separation
> suggested here as correcting an error.
> 
> It seems to me that, until and unless the IETF takes a strong
> position against the "all application protocols can reasonably
> be associated with a URI" model, having a facility to reserve
> application-associated keywords for applications that are
> well-defined and URI schemes that might be developed in the
> future would promote interoperability by providing a warning
> that the keyword should not be generally used until (and unless)
> a spec is produced.
> 
> If we took that approach, we could safely put both tn3270 and
> afs into "Reserved" if only because it is not clear to me that
> making a more careful decision about the latter would be worth
> the effort it would take.   We could similarly move anything
> else in the Provisional list that is associated with an expired
> I-D to Reserved.
> 
> If there is sympathy for this approach and an I-D is needed to
> establish rules for adding new entries to the "Reserved"
> category, I guess I'm willing to quickly turn out a first draft.
> That draft could also formally create the category if needed
> but, as noted above, I think its absence is an error on IANA's
> part.
> 
>     john
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 



From duerst@it.aoyama.ac.jp  Sun Nov 21 16:47:27 2010
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04B13A6ABA for <apps-discuss@core3.amsl.com>; Sun, 21 Nov 2010 16:47:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.672
X-Spam-Level: 
X-Spam-Status: No, score=-100.672 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj8fwO-CBMp2 for <apps-discuss@core3.amsl.com>; Sun, 21 Nov 2010 16:47:27 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by core3.amsl.com (Postfix) with ESMTP id B63233A68F5 for <apps-discuss@ietf.org>; Sun, 21 Nov 2010 16:47:26 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id oAM0mEOP011553 for <apps-discuss@ietf.org>; Mon, 22 Nov 2010 09:48:14 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 649f_b787_2fe62f20_f5d2_11df_a0ab_001d096c5782; Mon, 22 Nov 2010 09:48:13 +0900
Received: from [IPv6:::1] ([133.2.210.1]:46888) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S148C57B> for <apps-discuss@ietf.org> from <duerst@it.aoyama.ac.jp>; Mon, 22 Nov 2010 09:48:13 +0900
Message-ID: <4CE9BDCA.4010202@it.aoyama.ac.jp>
Date: Mon, 22 Nov 2010 09:48:10 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Graham Klyne <GK@ninebynine.org>
References: <A232FF7C06EE5B1C0F886130@PST.JCK.COM> <4CE99C5D.9040601@ninebynine.org>
In-Reply-To: <4CE99C5D.9040601@ninebynine.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 22 Nov 2010 00:47:27 -0000

On 2010/11/22 7:25, Graham Klyne wrote:

> We have "permanent", "provisional" and "historical" registration classes
> for URI schemes. For practical purposes, I think the "provisional"
> registry serves the same role as the "reserved" one you suggest [1]. I
> think the additional bureaucracy incurred to create a new registry class
> is not justified by practical benefit.

+1.

Regards,   Martin.

[1] http://tools.ietf.org/html/rfc4395 (sections 3 and 5.2)

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

From john-ietf@jck.com  Sun Nov 21 19:40:19 2010
Return-Path: <john-ietf@jck.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DFBE28C0F7; Sun, 21 Nov 2010 19:40:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level: 
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKK+fXDSasKw; Sun, 21 Nov 2010 19:40:18 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 210E228C0DC; Sun, 21 Nov 2010 19:40:18 -0800 (PST)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PKNHB-000FOR-Kb; Sun, 21 Nov 2010 22:41:09 -0500
Date: Sun, 21 Nov 2010 22:41:08 -0500
From: John C Klensin <john-ietf@jck.com>
To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= <duerst@it.aoyama.ac.jp>, Graham Klyne <GK@ninebynine.org>
Message-ID: <D8FA9230788A44981E86132F@PST.JCK.COM>
In-Reply-To: <4CE9BDCA.4010202@it.aoyama.ac.jp>
References: <A232FF7C06EE5B1C0F886130@PST.JCK.COM> <4CE99C5D.9040601@ninebynine.org> <4CE9BDCA.4010202@it.aoyama.ac.jp>
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
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 22 Nov 2010 03:40:19 -0000

--On Monday, November 22, 2010 09:48 +0900 "\"Martin J.
D=C3=BCrst\"" <duerst@it.aoyama.ac.jp> wrote:

> On 2010/11/22 7:25, Graham Klyne wrote:
>=20
>> We have "permanent", "provisional" and "historical"
>> registration classes for URI schemes. For practical purposes,
>> I think the "provisional" registry serves the same role as
>> the "reserved" one you suggest [1]. I think the additional
>> bureaucracy incurred to create a new registry class is not
>> justified by practical benefit.
>=20
> +1.

I would agree, except that:

(1) We now have proposals to remove things from Provisional that
have well-defined protocol specs and evidence of use because
they have been Provisional too long.  Fighting battles of that
sort is lots more painful than setting up a new registry
category, especially since...

(2) Not having a Reserved category from the beginning appears to
be an error on IANA's part, not something the IETF specified in
any way.   If that is correct, it should be possible to deal
with it as correcting an error, which is (or should be) an
extremely lightweight procedure.

   john




From duerst@it.aoyama.ac.jp  Sun Nov 21 22:51:02 2010
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261E73A6ABF for <apps-discuss@core3.amsl.com>; Sun, 21 Nov 2010 22:51:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.364
X-Spam-Level: 
X-Spam-Status: No, score=-100.364 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ECrPKq7RD5p for <apps-discuss@core3.amsl.com>; Sun, 21 Nov 2010 22:51:01 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id E93233A6ABD for <apps-discuss@ietf.org>; Sun, 21 Nov 2010 22:50:52 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id oAM6pfcv029743 for <apps-discuss@ietf.org>; Mon, 22 Nov 2010 15:51:41 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 5eb7_2fa5_f65e3fda_f604_11df_b333_001d096c566a; Mon, 22 Nov 2010 15:51:41 +0900
Received: from [IPv6:::1] ([133.2.210.1]:51715) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S148C926> for <apps-discuss@ietf.org> from <duerst@it.aoyama.ac.jp>; Mon, 22 Nov 2010 15:51:41 +0900
Message-ID: <4CEA12F9.2090106@it.aoyama.ac.jp>
Date: Mon, 22 Nov 2010 15:51:37 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>
References: <A232FF7C06EE5B1C0F886130@PST.JCK.COM> <4CE99C5D.9040601@ninebynine.org> <4CE9BDCA.4010202@it.aoyama.ac.jp> <D8FA9230788A44981E86132F@PST.JCK.COM>
In-Reply-To: <D8FA9230788A44981E86132F@PST.JCK.COM>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "public-iri@w3.org" <public-iri@w3.org>, uri-review@ietf.org, Graham Klyne <GK@ninebynine.org>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 22 Nov 2010 06:51:02 -0000

Hello John, others,

(cc'ing the IRI WG mailing list, because it is chartered to work on an 
update of RFC 4395 (Guidelines and Registration Procedures for New URI 
Schemes); please reduce cc list in replies whenever possible)

On 2010/11/22 12:41, John C Klensin wrote:
>
>
> --On Monday, November 22, 2010 09:48 +0900 "\"Martin J.
> Dürst\""<duerst@it.aoyama.ac.jp>  wrote:
>
>> On 2010/11/22 7:25, Graham Klyne wrote:
>>
>>> We have "permanent", "provisional" and "historical"
>>> registration classes for URI schemes. For practical purposes,
>>> I think the "provisional" registry serves the same role as
>>> the "reserved" one you suggest [1]. I think the additional
>>> bureaucracy incurred to create a new registry class is not
>>> justified by practical benefit.
>>
>> +1.
>
> I would agree, except that:
>
> (1) We now have proposals to remove things from Provisional that
> have well-defined protocol specs and evidence of use because
> they have been Provisional too long.  Fighting battles of that
> sort is lots more painful than setting up a new registry
> category, especially since...

I don't think fighting such battles should be painful. If A says a 
scheme (or protocol) is no longer in use, and B say it's in use, then B 
just wins. Having to say "the scheme (or protocol) is still in use" 
every two years or so may indeed some pain, but not too much.

> (2) Not having a Reserved category from the beginning appears to
> be an error on IANA's part, not something the IETF specified in
> any way.

In what way is it IANA's error? RFC 4395 
(http://tools.ietf.org/html/rfc4395) is pretty clear (as Graham has 
already explained) that there are three categories: Permanent, 
Provisional, and Historical.

> If that is correct, it should be possible to deal
> with it as correcting an error, which is (or should be) an
> extremely lightweight procedure.

I don't understand how it could be correct, but maybe I'm missing 
something. Anyway, I encourage everybody who thinks an additional 
Reserved category is needed, or some other clarifications could help, to 
submit their proposal as an issue on draft-ietf-iri-4395bis-irireg 
(http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg (Guidelines 
and Registration Procedures for New URI/IRI Schemes)) to the IRI WG 
(mailing list address: public-iri@w3.org). The current list of active 
issues of the WG can be found at 
http://trac.tools.ietf.org/wg/iri/trac/report/1.

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

From GK@ninebynine.org  Mon Nov 22 02:14:02 2010
Return-Path: <GK@ninebynine.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07BF228C0F3; Mon, 22 Nov 2010 02:14:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJo-LtmSGfuX; Mon, 22 Nov 2010 02:14:01 -0800 (PST)
Received: from relay4.mail.ox.ac.uk (relay4.mail.ox.ac.uk [129.67.1.163]) by core3.amsl.com (Postfix) with ESMTP id DEC6C3A6ACC; Mon, 22 Nov 2010 02:14:00 -0800 (PST)
Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay4.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from <GK@ninebynine.org>) id 1PKTQB-00079o-D7; Mon, 22 Nov 2010 10:14:51 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK@ninebynine.org>) id 1PKTQA-00033d-14; Mon, 22 Nov 2010 10:14:50 +0000
Message-ID: <4CEA413F.2080004@ninebynine.org>
Date: Mon, 22 Nov 2010 10:09:03 +0000
From: Graham Klyne <GK@ninebynine.org>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>
References: <A232FF7C06EE5B1C0F886130@PST.JCK.COM>	<4CE99C5D.9040601@ninebynine.org>	<4CE9BDCA.4010202@it.aoyama.ac.jp> <D8FA9230788A44981E86132F@PST.JCK.COM>
In-Reply-To: <D8FA9230788A44981E86132F@PST.JCK.COM>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 22 Nov 2010 10:14:02 -0000

John C Klensin wrote:
> 
> --On Monday, November 22, 2010 09:48 +0900 "\"Martin J.
> Dürst\"" <duerst@it.aoyama.ac.jp> wrote:
> 
>> On 2010/11/22 7:25, Graham Klyne wrote:
>>
>>> We have "permanent", "provisional" and "historical"
>>> registration classes for URI schemes. For practical purposes,
>>> I think the "provisional" registry serves the same role as
>>> the "reserved" one you suggest [1]. I think the additional
>>> bureaucracy incurred to create a new registry class is not
>>> justified by practical benefit.
>> +1.
> 
> I would agree, except that:
> 
> (1) We now have proposals to remove things from Provisional that
> have well-defined protocol specs and evidence of use because
> they have been Provisional too long.  Fighting battles of that
> sort is lots more painful than setting up a new registry
> category, especially since...

Having made a very quick review of that discussion (w.r.t. tn3270), I feel there 
is a consensus that the appropriate response to to say "that's fine, it has a 
definition, let's leave it there".  There is no explicit provision for time-out 
of provisional registrations - the general idea (at least in the formulation of 
the header registry, from which I believe this registry was derived) was to 
provide a place where schemes could be documented for the community without 
having to meet the properly high standards of IETF consensus.

One option in this case would be to move the tn3270 scheme to historic - I'm not 
sure if that's been suggested.  That's something I would support in this case.

You say "Fighting battles of that sort is lots more painful...".  My sense is 
that the more choices there are, the more painful the battles may be.  My 
reference to "bureaucracy" was intended to allude as much to the choices to be 
made on an ongoing basis as to the setting up of a new registry.  As scheme 
reviewer, I would find it harder to make a reasonable decisions if "reserved" 
were also an option, since that would require more detailed knowledge of the 
protocol's history than I can generally bring to bear.

> (2) Not having a Reserved category from the beginning appears to
> be an error on IANA's part, not something the IETF specified in
> any way.   If that is correct, it should be possible to deal
> with it as correcting an error, which is (or should be) an
> extremely lightweight procedure.

Well, as Martin says, if it's an error it's not one on IANA's part.  In this 
case, they follow what we (the IETF) asked of them.  So I suppose we should be 
careful what we ask for :)

#g




From evnikita2@gmail.com  Mon Nov 22 06:23:47 2010
Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AAE53A6A8F; Mon, 22 Nov 2010 06:23:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-q6CWUmjlfG; Mon, 22 Nov 2010 06:23:46 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E87AC28C0D0; Mon, 22 Nov 2010 06:23:45 -0800 (PST)
Received: by bwz12 with SMTP id 12so6611356bwz.31 for <multiple recipients>; Mon, 22 Nov 2010 06:24:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=NtKLdlQ8Svh8mDJ2iZPLxYCSJwcW67NG7U4JY/iTSsE=; b=lJ6+qIS8tFYXnrVFcYlHPU2Yzv05+LLZs6vMZaLokDtHqY0rV6RTTQk5Zg+6VjNBfg 9eniGdgjVTadzL8GV6DbFTKSdNFV9b7J5kfp00Eo9Z0gOs+Ir9tzSf3omcQ4qOyNBMAt WEoNLefWyD6LejvyHdEz02tRs/R9X2RVRQq1M=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Oc4nbpLl/3rOX7bYZbodGEoJaFsxfW7+wK1A+EQHF6zdkdhkRmwoiBtQA8QUSG8C2M FupvenDqcP+rqt++JWDZuUxcOK++8TAnepq26BnOX+VUXTtx/MWRjLBEb7ZNv4tEDsJn UX8D89Dt1xugnoUvs7hLcG85hwUHOACAy9wq8=
Received: by 10.204.79.131 with SMTP id p3mr5352329bkk.178.1290435861723; Mon, 22 Nov 2010 06:24:21 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id d27sm2452996bkw.14.2010.11.22.06.24.19 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Nov 2010 06:24:19 -0800 (PST)
Message-ID: <4CEA7D15.6000801@gmail.com>
Date: Mon, 22 Nov 2010 16:24:21 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Graham Klyne <GK@ninebynine.org>
References: <A232FF7C06EE5B1C0F886130@PST.JCK.COM> <4CE99C5D.9040601@ninebynine.org>
In-Reply-To: <4CE99C5D.9040601@ninebynine.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review]  Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 22 Nov 2010 14:23:47 -0000

22.11.2010 0:25, Graham Klyne wrote:
> We have "permanent", "provisional" and "historical" registration 
> classes for URI schemes.  For practical purposes, I think the 
> "provisional" registry serves the same role as the "reserved" one you 
> suggest [1].  I think the additional bureaucracy incurred to create a 
> new registry class is not justified by practical benefit.  It's easy 
> enough to add some commentary to the registration template
I can't agree with that. 'Provisional' means
'not to be used as not specified' while
'Reserved' means 'not to be used NOW and
not to be specified NOW (wait until are moved
to 'Provisional')'. We have difference between
these two terms.

Mykyta Yevstifeyev


From A.Hoenes@TR-Sys.de  Mon Nov 22 12:34:04 2010
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DE4C3A6AFC; Mon, 22 Nov 2010 12:34:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.422
X-Spam-Level: 
X-Spam-Status: No, score=-98.422 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNKnK6BdQImi; Mon, 22 Nov 2010 12:34:03 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 82F033A6AF9; Mon, 22 Nov 2010 12:34:01 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA271188077; Mon, 22 Nov 2010 21:34:37 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA22485; Mon, 22 Nov 2010 21:34:33 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@TR-Sys.de>
Message-Id: <201011222034.VAA22485@TR-Sys.de>
To: gk@ninebynine.org, duerst@it.aoyama.ac.jp
Date: Mon, 22 Nov 2010 21:34:33 +0100 (MEZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 22 Nov 2010 20:34:04 -0000

Graham Klyne wrote:

> Having made a very quick review of that discussion (w.r.t. tn3270),
> I feel there is a consensus that the appropriate response to to say
> "that's fine, it has a definition, let's leave it there".

Well, that's been one of the points where opinions seem to differ.
I could not find a definition, only RFC 1738 "reserving the name for
future definition".  The users of TN3270 service so far have claimed
there would be a definition, but nobody has shown it so far, and
some indications have been reported of different, non-interoperable
definitions as well.  I don't want to take a position on that now.


> There is no explicit provision for time-out of provisional
> registrations - the general idea (at least in the formulation
> of the header registry, from which I believe this registry was
> derived) was to provide a place where schemes could be documented
> for the community without having to meet the properly high standards
> of IETF consensus.

I would not have challenged "tn3270" as a provisional URI scheme
if there had been evidence that the procedures of RFC 4395 for such
scheme had been followed.


> One option in this case would be to move the tn3270 scheme to
> historic - I'm not sure if that's been suggested.

Exactly that was the starting point of the discussion.   :-)

I had suggested to add this status change to Alexey's draft that
aims at making 'mailserver' Historic, simply for the sake of
saving resources in drafting, draft approval, and RFC publication.
But i'm fine with defering that, doing that later, if still no spec
has be provided by that time.


> That's something I would support in this case.

Thanks.  I'll count on you when (and if) it turns sensical to retry.


John said:

>>   (2) Not having a Reserved category from the beginning appears to
>>   be an error on IANA's part, not something the IETF specified in
>>   any way.   If that is correct, it should be possible to deal
>>   with it as correcting an error, which is (or should be) an
>>   extremely lightweight procedure.

and you responded:

> Well, as Martin says, if it's an error it's not one on IANA's part.
> In this case, they follow what we (the IETF) asked of them.
> So I suppose we should be careful what we ask for :)

I disagree on the first two statements.

Actually, before the change of the URI Scheme registry triggered
by RFC 4395, 'afs', 'mailserver', and 'tn3270' had been listed
as "reserved".  I could not find instructions in RFC 4395 telling
IANA to convert these entries to "provisional" URI schemes,
and I observe that neither of these previously "reserved" keywords
would have qualified under the criteria for such registration in
RFC 4395.
So, since there apparently haven't been conversion rules; arguably,
something went wrong; achieving at consensus *now* that it likely
was a clerical error would allow us to perform a very lightweight
procedure to restore the 'status quo ante' (with three reserved
keywords), before Alexey's draft is published, or during that
process (but logically before 'mailserver' is made Historic).

Kind regards,
  Alfred.


From Michael.Wojcik@microfocus.com  Tue Nov 23 06:49:07 2010
Return-Path: <Michael.Wojcik@microfocus.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1140828C117; Tue, 23 Nov 2010 06:49:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.046
X-Spam-Level: 
X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNGrPurNc+Nt; Tue, 23 Nov 2010 06:49:05 -0800 (PST)
Received: from cluster-b.mailcontroller.altohiway.com (clusterb.mailcontroller.co.uk [213.83.66.209]) by core3.amsl.com (Postfix) with ESMTP id 7B8133A6936; Tue, 23 Nov 2010 06:49:04 -0800 (PST)
Received: from rlya5b.mailcontroller.altohiway.com (localhost.localdomain [127.0.0.1]) by rlya5b.mailcontroller.altohiway.com (MailController) with ESMTP id oANEo1DP013602; Tue, 23 Nov 2010 14:50:01 GMT
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rlya5b.mailcontroller.altohiway.com (MailControl) id oANEnFn3006338;  Tue, 23 Nov 2010 14:49:15 GMT
Received: from MTV-EXCHANGE.microfocus.com ([216.52.8.28]) by rlya5b-eth0.mailcontroller.altohiway.com (envelope-sender <Michael.Wojcik@microfocus.com>) (MIMEDefang) with ESMTP id oANEnENC006226; Tue, 23 Nov 2010 14:49:15 +0000 (GMT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Nov 2010 06:48:43 -0800
Message-ID: <81F42F63D5BB344ABF294F8E80990C7902782A63@MTV-EXCHANGE.microfocus.com>
In-Reply-To: <201011222034.VAA22485@TR-Sys.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Uri-review] [apps-discuss] Provisional URI registrations
Thread-Index: AcuKhMc2rIlZDXe2R3mdt6mSwjToPAAllUpA
References: <201011222034.VAA22485@TR-Sys.de>
From: "Michael Wojcik" <Michael.Wojcik@microfocus.com>
To: <uri-review@ietf.org>, <apps-discuss@ietf.org>
X-Scanned-By: MailControl A-09-22-20 (www.mailcontrol.com) on 10.61.1.115
Cc: =?iso-8859-1?Q?Alfred_H=CEnes?= <ah@TR-Sys.de>
Subject: Re: [apps-discuss] [Uri-review]  Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 23 Nov 2010 14:49:07 -0000

> From: uri-review-bounces@ietf.org [mailto:uri-review-bounces@ietf.org]
> On Behalf Of Alfred H=CEnes
> Sent: Monday, 22 November, 2010 15:35
>=20
> Graham Klyne wrote:
>=20
> > Having made a very quick review of that discussion (w.r.t. tn3270), I
> > feel there is a consensus that the appropriate response to to say
> > "that's fine, it has a definition, let's leave it there".
>=20
> Well, that's been one of the points where opinions seem to differ.
> I could not find a definition, only RFC 1738 "reserving the name for
> future definition".  The users of TN3270 service so far have claimed
> there would be a definition, but nobody has shown it so far, and some
> indications have been reported of different, non-interoperable
> definitions as well.  I don't want to take a position on that now.

As far as I can tell, the situation is this:

- There is no definition of the tn3270 scheme.

- There are applications which interpret tn3270 URIs, by starting a client =
that implements some flavor of TN3270.

- There is no single definition of a TN3270 service, which is what the sche=
me presumably refers to. There are definitions of various pieces of Classic=
 TN3270, definitions of "best practices" for Classic TN3270, and a definiti=
on of TN3270E.

- There are various implementations of TN3270 service (client and server), =
most or all of which are probably not fully compliant with the various defi=
nitions.

- Those implementations are generally interoperable, but sometimes with cav=
eats (eg reduced functionality).

So I think it's fair to say that:

1) There is no definition of the tn3270 scheme.

2) While there's a working understanding of what specifications contribute =
to a "standard" implementation of TN3270 service, there is no single defini=
tion of that service. That makes defining the scheme more difficult.

I'd also suggest that while a single definition of the TN3270 service, and =
a definition and proper registration of the tn3270 scheme, are desirable, i=
n practice I don't believe they'd have much effect. IBM hasn't shown any in=
clination to bring its client implementation into conformance with the exta=
nt TN3270E specification (RFC 2355), for example.

I don't have strong feelings about whether the "tn3270" scheme is labelled =
"provisional" or "historic". Again, I don't think it will make any differen=
ce to implementors, who will treat tn3270-scheme URIs however they like. (I=
'm an implementor myself, but thus far I've only dealt with the server side=
, which never sees such URIs, so it hasn't come up.)

--=20
Michael Wojcik
Principal Software Systems Developer, Micro Focus



This message has been scanned for viruses by MailController - www.MailContr=
oller.altohiway.com

From GK@ninebynine.org  Tue Nov 23 06:49:58 2010
Return-Path: <GK@ninebynine.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46BE83A6936; Tue, 23 Nov 2010 06:49:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.103
X-Spam-Level: 
X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L534dhF2MplR; Tue, 23 Nov 2010 06:49:57 -0800 (PST)
Received: from relay5.mail.ox.ac.uk (relay5.mail.ox.ac.uk [163.1.2.163]) by core3.amsl.com (Postfix) with ESMTP id 1CA4828C113; Tue, 23 Nov 2010 06:49:57 -0800 (PST)
Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay5.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from <GK@ninebynine.org>) id 1PKuCq-0001Ft-HX; Tue, 23 Nov 2010 14:50:52 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK@ninebynine.org>) id 1PKuCp-0006xA-3D; Tue, 23 Nov 2010 14:50:52 +0000
Message-ID: <4CEAF2F0.3060001@ninebynine.org>
Date: Mon, 22 Nov 2010 22:47:12 +0000
From: Graham Klyne <GK@ninebynine.org>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
References: <A232FF7C06EE5B1C0F886130@PST.JCK.COM> <4CE99C5D.9040601@ninebynine.org> <4CEA7D15.6000801@gmail.com>
In-Reply-To: <4CEA7D15.6000801@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review]  Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 23 Nov 2010 14:49:58 -0000

Mykyta Yevstifeyev wrote:
> 22.11.2010 0:25, Graham Klyne wrote:
>> We have "permanent", "provisional" and "historical" registration 
>> classes for URI schemes.  For practical purposes, I think the 
>> "provisional" registry serves the same role as the "reserved" one you 
>> suggest [1].  I think the additional bureaucracy incurred to create a 
>> new registry class is not justified by practical benefit.  It's easy 
>> enough to add some commentary to the registration template

> I can't agree with that. 'Provisional' means
> 'not to be used as not specified'

Well, that's not what I read in RFC4395 regarding "provisional":

[[
Within that namespace, there are values that are
approved as meeting a set of criteria for URI schemes.  Other scheme
names may also be registered provisionally, without necessarily
meeting those criteria.
]]
-- http://tools.ietf.org/html/rfc4395#section-1

[[
    o  encourage registration by setting a low barrier for provisional
       registrations.
]]
-- (ibid)

My interpretation of "reserved" was based on my reading of the criteria outlined 
in John Klensin's email to which I was responding.

And my response clearly stated "for practical purposes", which is not the same 
as claiming the words mean the same thing.  That is, for practical purposes, I 
don't think that having a "reserved" category adds any value to the process.

Further, I don't think that allowing registration without some level of 
specification, or registration of a scheme that is "not to be used now" would 
serve any useful purpose.  The main point of provisional registration here is to 
allow developers to experiment with a tentatively specified URI scheme without 
meeting all of the requirements for permanent registration, while allowing that 
permanent registration may follow if the experiments show value, and to provide 
a place where some information can be found about any registered scheme that 
might show up in the wild.

#g
--



From GK-lists@ninebynine.org  Tue Nov 23 08:12:31 2010
Return-Path: <GK-lists@ninebynine.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D3D328C131; Tue, 23 Nov 2010 08:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I7u9p8cnRQA; Tue, 23 Nov 2010 08:12:30 -0800 (PST)
Received: from relay3.mail.ox.ac.uk (relay3.mail.ox.ac.uk [163.1.2.165]) by core3.amsl.com (Postfix) with ESMTP id 1C08628C124; Tue, 23 Nov 2010 08:12:30 -0800 (PST)
Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay3.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from <GK-lists@ninebynine.org>) id 1PKvUj-0001Au-9v; Tue, 23 Nov 2010 16:13:25 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK-lists@ninebynine.org>) id 1PKvUi-0000np-1z; Tue, 23 Nov 2010 16:13:25 +0000
Message-ID: <4CEBE19C.6020408@ninebynine.org>
Date: Tue, 23 Nov 2010 15:45:32 +0000
From: Graham Klyne <GK-lists@ninebynine.org>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Michael Wojcik <Michael.Wojcik@microfocus.com>
References: <201011222034.VAA22485@TR-Sys.de> <81F42F63D5BB344ABF294F8E80990C7902782A63@MTV-EXCHANGE.microfocus.com>
In-Reply-To: <81F42F63D5BB344ABF294F8E80990C7902782A63@MTV-EXCHANGE.microfocus.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
Cc: uri-review@ietf.org, =?ISO-8859-1?Q?=CEnes?= <ah@TR-Sys.de>, apps-discuss@ietf.org, =?ISO-8859-1?Q?Alfred_H?=
Subject: Re: [apps-discuss] [Uri-review]  Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 23 Nov 2010 16:12:31 -0000

Michael, thanks for the clarification.  I clearly skimmed the discussion too 
quickly - I didn't pick up that the scheme was lacking a definition.  I think my 
latest response to Alfred applies.

#g
--

Michael Wojcik wrote:
>> From: uri-review-bounces@ietf.org [mailto:uri-review-bounces@ietf.org]
>> On Behalf Of Alfred HÎnes
>> Sent: Monday, 22 November, 2010 15:35
>>
>> Graham Klyne wrote:
>>
>>> Having made a very quick review of that discussion (w.r.t. tn3270), I
>>> feel there is a consensus that the appropriate response to to say
>>> "that's fine, it has a definition, let's leave it there".
>> Well, that's been one of the points where opinions seem to differ.
>> I could not find a definition, only RFC 1738 "reserving the name for
>> future definition".  The users of TN3270 service so far have claimed
>> there would be a definition, but nobody has shown it so far, and some
>> indications have been reported of different, non-interoperable
>> definitions as well.  I don't want to take a position on that now.
> 
> As far as I can tell, the situation is this:
> 
> - There is no definition of the tn3270 scheme.
> 
> - There are applications which interpret tn3270 URIs, by starting a client that implements some flavor of TN3270.
> 
> - There is no single definition of a TN3270 service, which is what the scheme presumably refers to. There are definitions of various pieces of Classic TN3270, definitions of "best practices" for Classic TN3270, and a definition of TN3270E.
> 
> - There are various implementations of TN3270 service (client and server), most or all of which are probably not fully compliant with the various definitions.
> 
> - Those implementations are generally interoperable, but sometimes with caveats (eg reduced functionality).
> 
> So I think it's fair to say that:
> 
> 1) There is no definition of the tn3270 scheme.
> 
> 2) While there's a working understanding of what specifications contribute to a "standard" implementation of TN3270 service, there is no single definition of that service. That makes defining the scheme more difficult.
> 
> I'd also suggest that while a single definition of the TN3270 service, and a definition and proper registration of the tn3270 scheme, are desirable, in practice I don't believe they'd have much effect. IBM hasn't shown any inclination to bring its client implementation into conformance with the extant TN3270E specification (RFC 2355), for example.
> 
> I don't have strong feelings about whether the "tn3270" scheme is labelled "provisional" or "historic". Again, I don't think it will make any difference to implementors, who will treat tn3270-scheme URIs however they like. (I'm an implementor myself, but thus far I've only dealt with the server side, which never sees such URIs, so it hasn't come up.)
> 



From GK@ninebynine.org  Tue Nov 23 08:12:32 2010
Return-Path: <GK@ninebynine.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D5F28C124; Tue, 23 Nov 2010 08:12:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.434
X-Spam-Level: 
X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.165,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jb5mKPUjYpn; Tue, 23 Nov 2010 08:12:31 -0800 (PST)
Received: from relay2.mail.ox.ac.uk (relay2.mail.ox.ac.uk [163.1.2.161]) by core3.amsl.com (Postfix) with ESMTP id E591E28C128; Tue, 23 Nov 2010 08:12:30 -0800 (PST)
Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay2.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from <GK@ninebynine.org>) id 1PKvUh-0003sw-8f; Tue, 23 Nov 2010 16:13:23 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK@ninebynine.org>) id 1PKvUh-0000ng-1f; Tue, 23 Nov 2010 16:13:23 +0000
Message-ID: <4CEBE07B.5080100@ninebynine.org>
Date: Tue, 23 Nov 2010 15:40:43 +0000
From: Graham Klyne <GK@ninebynine.org>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: =?windows-1252?Q?Alfred_=3F?= <ah@TR-Sys.de>
References: <201011222034.VAA22485@TR-Sys.de>
In-Reply-To: <201011222034.VAA22485@TR-Sys.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 23 Nov 2010 16:12:32 -0000

Alfred ? wrote:
> John said:
> 
>>>   (2) Not having a Reserved category from the beginning appears to
>>>   be an error on IANA's part, not something the IETF specified in
>>>   any way.   If that is correct, it should be possible to deal
>>>   with it as correcting an error, which is (or should be) an
>>>   extremely lightweight procedure.
> 
> and you responded:
> 
>> Well, as Martin says, if it's an error it's not one on IANA's part.
>> In this case, they follow what we (the IETF) asked of them.
>> So I suppose we should be careful what we ask for :)
> 
> I disagree on the first two statements.
> 
> Actually, before the change of the URI Scheme registry triggered
> by RFC 4395, 'afs', 'mailserver', and 'tn3270' had been listed
> as "reserved".  I could not find instructions in RFC 4395 telling
> IANA to convert these entries to "provisional" URI schemes,
> and I observe that neither of these previously "reserved" keywords
> would have qualified under the criteria for such registration in
> RFC 4395.
> So, since there apparently haven't been conversion rules; arguably,
> something went wrong; achieving at consensus *now* that it likely
> was a clerical error would allow us to perform a very lightweight
> procedure to restore the 'status quo ante' (with three reserved
> keywords), before Alexey's draft is published, or during that
> process (but logically before 'mailserver' is made Historic).

Ah, I wasn't of the prior "reserved" status (sorry if I skimmed over the prior 
discussion too quickly).  I think these 3 are an exceptional case.

In the circumstances described, as reviewer, my inclination would probably have 
been to recommend provisional registration (I don't recall being asked about 
these - I suspect they were grandfathered in when the registry was initially 
created, by some ad-hoc means; after all, provisional is very similar in its 
effect to reserved).  If the general consensus is that the provisional status is 
unlikely to be further developed, then moving to historic seems a reasonable 
course, allowing that in this case the precise requirements may not be perfectly 
satisfied.

#g
--




From ietfc@btconnect.com  Tue Nov 23 10:20:57 2010
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB303A699A; Tue, 23 Nov 2010 10:20:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HyCiUly+wBX; Tue, 23 Nov 2010 10:20:56 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by core3.amsl.com (Postfix) with ESMTP id E7D103A6999; Tue, 23 Nov 2010 10:20:54 -0800 (PST)
Received: from host81-156-71-67.range81-156.btcentralplus.com (HELO pc6) ([81.156.71.67]) by c2bthomr13.btconnect.com with SMTP id ATN98729; Tue, 23 Nov 2010 18:21:39 +0000 (GMT)
Message-ID: <029501cb8b32$9c378120$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: "Michael Wojcik" <Michael.Wojcik@microfocus.com>, <uri-review@ietf.org>, <apps-discuss@ietf.org>
References: <201011222034.VAA22485@TR-Sys.de> <81F42F63D5BB344ABF294F8E80990C7902782A63@MTV-EXCHANGE.microfocus.com>
Date: Tue, 23 Nov 2010 18:19:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CEC0633.0098, actions=tag
X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4CEC063E.0058,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Subject: Re: [apps-discuss] [Uri-review]  Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 23 Nov 2010 18:20:58 -0000

----- Original Message -----
From: "Michael Wojcik" <Michael.Wojcik@microfocus.com>
To: <uri-review@ietf.org>; <apps-discuss@ietf.org>
Cc: "Alfred HÎnes" <ah@TR-Sys.de>
Sent: Tuesday, November 23, 2010 3:48 PM

> From: uri-review-bounces@ietf.org [mailto:uri-review-bounces@ietf.org]
> On Behalf Of Alfred HÎnes
> Sent: Monday, 22 November, 2010 15:35
>
> Graham Klyne wrote:
>
> > Having made a very quick review of that discussion (w.r.t. tn3270), I
> > feel there is a consensus that the appropriate response to to say
> > "that's fine, it has a definition, let's leave it there".
>
> Well, that's been one of the points where opinions seem to differ.
> I could not find a definition, only RFC 1738 "reserving the name for
> future definition".  The users of TN3270 service so far have claimed
> there would be a definition, but nobody has shown it so far, and some
> indications have been reported of different, non-interoperable
> definitions as well.  I don't want to take a position on that now.

As far as I can tell, the situation is this:

- There is no definition of the tn3270 scheme.

- There are applications which interpret tn3270 URIs, by starting a client that
implements some flavor of TN3270.

- There is no single definition of a TN3270 service, which is what the scheme
presumably refers to. There are definitions of various pieces of Classic TN3270,
definitions of "best practices" for Classic TN3270, and a definition of TN3270E.

- There are various implementations of TN3270 service (client and server), most
or all of which are probably not fully compliant with the various definitions.

<tp>
Looking at recent IBM announcements, I found one from this year announcing
support for TN3270 over IPv6, which makes it more progressive, and likely to be
around longer, than some IETF protocols.

Tom Petch
</tp>




- Those implementations are generally interoperable, but sometimes with caveats
(eg reduced functionality).

So I think it's fair to say that:

1) There is no definition of the tn3270 scheme.

2) While there's a working understanding of what specifications contribute to a
"standard" implementation of TN3270 service, there is no single definition of
that service. That makes defining the scheme more difficult.

I'd also suggest that while a single definition of the TN3270 service, and a
definition and proper registration of the tn3270 scheme, are desirable, in
practice I don't believe they'd have much effect. IBM hasn't shown any
inclination to bring its client implementation into conformance with the extant
TN3270E specification (RFC 2355), for example.

I don't have strong feelings about whether the "tn3270" scheme is labelled
"provisional" or "historic". Again, I don't think it will make any difference to
implementors, who will treat tn3270-scheme URIs however they like. (I'm an
implementor myself, but thus far I've only dealt with the server side, which
never sees such URIs, so it hasn't come up.)

--
Michael Wojcik
Principal Software Systems Developer, Micro Focus



This message has been scanned for viruses by MailController -
www.MailController.altohiway.com
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


From eric@tibco.com  Tue Nov 23 11:57:58 2010
Return-Path: <eric@tibco.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0AA928C10B; Tue, 23 Nov 2010 11:57:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLrs0-9mKobY; Tue, 23 Nov 2010 11:57:58 -0800 (PST)
Received: from mx1-app.tibco.com (mx1-app.tibco.com [63.100.100.142]) by core3.amsl.com (Postfix) with ESMTP id 069F728C0FE; Tue, 23 Nov 2010 11:57:57 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.59,243,1288594800"; d="scan'208";a="18564892"
Received: from tibco-5.tibco.com (HELO na-pa-fe01.na.tibco.com) ([63.100.100.5]) by mx1-app.tibco.com with ESMTP; 23 Nov 2010 11:58:56 -0800
Received: from Eric-Johnsons-MacBook-Pro.local ([10.98.39.231]) by na-pa-fe01.na.tibco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 23 Nov 2010 11:58:55 -0800
Message-ID: <4CEC1CFF.1030008@tibco.com>
Date: Tue, 23 Nov 2010 11:58:55 -0800
From: Eric Johnson <eric@tibco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Apps Discuss <apps-discuss@ietf.org>, uri-review@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Nov 2010 19:58:55.0810 (UTC) FILETIME=[DC2E0220:01CB8B48]
X-TM-AS-Product-Ver: SMEX-10.0.0.1412-6.500.1024-17784.006
X-TM-AS-Result: No--8.613400-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
Subject: [apps-discuss] Latest of draft-merrick-jms-uri posted - feedback welcome
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 23 Nov 2010 19:57:58 -0000

After many weeks of help, and back and forth resolving some issues 
raised by various individuals on these mailing lists, I've posted a new 
version of draft-merrick-jms-uri:

https://datatracker.ietf.org/doc/draft-merrick-jms-uri/

Feedback welcome.  Sorry for the cross-posting, but I couldn't think of 
a better way....

-Eric.



From evnikita2@gmail.com  Wed Nov 24 01:19:13 2010
Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E85A3A67CC; Wed, 24 Nov 2010 01:19:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.232
X-Spam-Level: 
X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+c6KZKWNkAt; Wed, 24 Nov 2010 01:19:11 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 9A3A13A67C2; Wed, 24 Nov 2010 01:19:11 -0800 (PST)
Received: by gxk27 with SMTP id 27so5857847gxk.31 for <multiple recipients>; Wed, 24 Nov 2010 01:20:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DJim5USSUnZyjDlAQpc6ThL24Dej0iUtM+syUoPXMng=; b=OtSMHjJ8ztZY61T7rXyuTAtCwPq9IAAc10C/MPZ80uGIREXDsXwxwtO9iuR9aJ6n8H YwyUMLmFIL7bgte1cOPBO3/Pl5dMoEoJFUCk7kveJon2phogb+Dp0DSOzK4tCW9R43JB nmEeVJ1HbYKYWnJMkBLwLgJZdjC68H+KikTWM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Z3B00TVZI43YzbvqjSwocRAzQ7pyYJCJ2FJppOKtVO3G4gZ38kNZuf6g4a7Nu27VvM TPtR8FYMHBTN0MBNj7qvNyjJ9EDhdsLbD6notwL41vzr5ipaou4cBTuVB6ArsYxIbsZ2 HwV3bQJ/M452Nsoa0N5skcl5sHcUzktN68fnw=
MIME-Version: 1.0
Received: by 10.150.95.3 with SMTP id s3mr558274ybb.285.1290590410349; Wed, 24 Nov 2010 01:20:10 -0800 (PST)
Received: by 10.150.97.7 with HTTP; Wed, 24 Nov 2010 01:20:09 -0800 (PST)
In-Reply-To: <029501cb8b32$9c378120$4001a8c0@gateway.2wire.net>
References: <201011222034.VAA22485@TR-Sys.de> <81F42F63D5BB344ABF294F8E80990C7902782A63@MTV-EXCHANGE.microfocus.com> <029501cb8b32$9c378120$4001a8c0@gateway.2wire.net>
Date: Wed, 24 Nov 2010 11:20:09 +0200
Message-ID: <AANLkTimkKq2xM-91J0tWOR7QR=xsC4Ektj_9MnYzDjEL@mail.gmail.com>
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
To: "t.petch" <ietfc@btconnect.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Michael Wojcik <Michael.Wojcik@microfocus.com>, uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review]  Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 24 Nov 2010 09:19:13 -0000

Hello all,

I think we just need a formal specification
of tn3270 scheme. This will stop discussions
about moving or not moving it to 'Historic' as
it would be moved to 'Permanent'. We won't
have to specify the service - fust the URI
scheme. I think I'll make a corresponding
draft in a week to stop all these discussions
and put a point in this problem.

Mykyta Yevstifeyev

2010/11/23, t.petch <ietfc@btconnect.com>:
> ----- Original Message -----
> From: "Michael Wojcik" <Michael.Wojcik@microfocus.com>
> To: <uri-review@ietf.org>; <apps-discuss@ietf.org>
> Cc: "Alfred H=CEnes" <ah@TR-Sys.de>
> Sent: Tuesday, November 23, 2010 3:48 PM
>
>> From: uri-review-bounces@ietf.org [mailto:uri-review-bounces@ietf.org]
>> On Behalf Of Alfred H=CEnes
>> Sent: Monday, 22 November, 2010 15:35
>>
>> Graham Klyne wrote:
>>
>> > Having made a very quick review of that discussion (w.r.t. tn3270), I
>> > feel there is a consensus that the appropriate response to to say
>> > "that's fine, it has a definition, let's leave it there".
>>
>> Well, that's been one of the points where opinions seem to differ.
>> I could not find a definition, only RFC 1738 "reserving the name for
>> future definition".  The users of TN3270 service so far have claimed
>> there would be a definition, but nobody has shown it so far, and some
>> indications have been reported of different, non-interoperable
>> definitions as well.  I don't want to take a position on that now.
>
> As far as I can tell, the situation is this:
>
> - There is no definition of the tn3270 scheme.
>
> - There are applications which interpret tn3270 URIs, by starting a clien=
t
> that
> implements some flavor of TN3270.
>
> - There is no single definition of a TN3270 service, which is what the
> scheme
> presumably refers to. There are definitions of various pieces of Classic
> TN3270,
> definitions of "best practices" for Classic TN3270, and a definition of
> TN3270E.
>
> - There are various implementations of TN3270 service (client and server)=
,
> most
> or all of which are probably not fully compliant with the various
> definitions.
>
> <tp>
> Looking at recent IBM announcements, I found one from this year announcin=
g
> support for TN3270 over IPv6, which makes it more progressive, and likely=
 to
> be
> around longer, than some IETF protocols.
>
> Tom Petch
> </tp>
>
>
>
>
> - Those implementations are generally interoperable, but sometimes with
> caveats
> (eg reduced functionality).
>
> So I think it's fair to say that:
>
> 1) There is no definition of the tn3270 scheme.
>
> 2) While there's a working understanding of what specifications contribut=
e
> to a
> "standard" implementation of TN3270 service, there is no single definitio=
n
> of
> that service. That makes defining the scheme more difficult.
>
> I'd also suggest that while a single definition of the TN3270 service, an=
d a
> definition and proper registration of the tn3270 scheme, are desirable, i=
n
> practice I don't believe they'd have much effect. IBM hasn't shown any
> inclination to bring its client implementation into conformance with the
> extant
> TN3270E specification (RFC 2355), for example.
>
> I don't have strong feelings about whether the "tn3270" scheme is labelle=
d
> "provisional" or "historic". Again, I don't think it will make any
> difference to
> implementors, who will treat tn3270-scheme URIs however they like. (I'm a=
n
> implementor myself, but thus far I've only dealt with the server side, wh=
ich
> never sees such URIs, so it hasn't come up.)
>
> --
> Michael Wojcik
> Principal Software Systems Developer, Micro Focus
>
>
>
> This message has been scanned for viruses by MailController -
> www.MailController.altohiway.com
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review
>

From ietfc@btconnect.com  Wed Nov 24 01:43:01 2010
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6301F3A69B7; Wed, 24 Nov 2010 01:43:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Level: 
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfHbpXC2du3G; Wed, 24 Nov 2010 01:42:59 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by core3.amsl.com (Postfix) with ESMTP id 0A37C3A6817; Wed, 24 Nov 2010 01:42:58 -0800 (PST)
Received: from host81-156-71-67.range81-156.btcentralplus.com (HELO pc6) ([81.156.71.67]) by c2beaomr06.btconnect.com with SMTP id BAH72060; Wed, 24 Nov 2010 09:43:44 +0000 (GMT)
Message-ID: <002f01cb8bb3$6bc87fe0$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: "Graham Klyne" <GK-lists@ninebynine.org>, "Michael Wojcik" <Michael.Wojcik@microfocus.com>
References: <201011222034.VAA22485@TR-Sys.de><81F42F63D5BB344ABF294F8E80990C7902782A63@MTV-EXCHANGE.microfocus.com> <4CEBE19C.6020408@ninebynine.org>
Date: Wed, 24 Nov 2010 09:40:23 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CECDE39.00FA, actions=TAG
X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4CECDE56.0277,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Cc: uri-review@ietf.org, =?iso-8859-1?B?zm5lcw==?= <ah@TR-Sys.de>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review]  Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 24 Nov 2010 09:43:01 -0000

----- Original Message -----
From: "Graham Klyne" <GK-lists@ninebynine.org>
To: "Michael Wojcik" <Michael.Wojcik@microfocus.com>
Cc: <uri-review@ietf.org>; "Înes" <ah@TR-Sys.de>; <apps-discuss@ietf.org>;
<Alfred H@core3.amsl.com>
Sent: Tuesday, November 23, 2010 4:45 PM

Michael, thanks for the clarification.  I clearly skimmed the discussion too
quickly - I didn't pick up that the scheme was lacking a definition.  I think my
latest response to Alfred applies.

<tp>
Who needs a definition?  I did a quick 'literature search' and found plenty of
references to tn3270 as a URI but no definition; the examples were all of the
form
scheme :// host : port
No parameters, queries, fragments or anything fancy.  On reflection, this seems
right; tn3270 is more sophisticated than many IETF protocols and if it wants
something, it negotiates it, so no need for a complex URI to specify things in
advance.

One could write a universal URI definition for such schemes
scheme host port
means set up a connection of protocol 'scheme' to 'host', default port from
IANA, but, arguably, we already have all we need in RFC3986.

Tom Petch
</tp>


#g
--

Michael Wojcik wrote:
>> From: uri-review-bounces@ietf.org [mailto:uri-review-bounces@ietf.org]
>> On Behalf Of Alfred HÎnes
>> Sent: Monday, 22 November, 2010 15:35
>>
>> Graham Klyne wrote:
>>
>>> Having made a very quick review of that discussion (w.r.t. tn3270), I
>>> feel there is a consensus that the appropriate response to to say
>>> "that's fine, it has a definition, let's leave it there".
>> Well, that's been one of the points where opinions seem to differ.
>> I could not find a definition, only RFC 1738 "reserving the name for
>> future definition".  The users of TN3270 service so far have claimed
>> there would be a definition, but nobody has shown it so far, and some
>> indications have been reported of different, non-interoperable
>> definitions as well.  I don't want to take a position on that now.
>
> As far as I can tell, the situation is this:
>
> - There is no definition of the tn3270 scheme.
>
> - There are applications which interpret tn3270 URIs, by starting a client
that implements some flavor of TN3270.
>
> - There is no single definition of a TN3270 service, which is what the scheme
presumably refers to. There are definitions of various pieces of Classic TN3270,
definitions of "best practices" for Classic TN3270, and a definition of TN3270E.
>
> - There are various implementations of TN3270 service (client and server),
most or all of which are probably not fully compliant with the various
definitions.
>
> - Those implementations are generally interoperable, but sometimes with
caveats (eg reduced functionality).
>
> So I think it's fair to say that:
>
> 1) There is no definition of the tn3270 scheme.
>
> 2) While there's a working understanding of what specifications contribute to
a "standard" implementation of TN3270 service, there is no single definition of
that service. That makes defining the scheme more difficult.
>
> I'd also suggest that while a single definition of the TN3270 service, and a
definition and proper registration of the tn3270 scheme, are desirable, in
practice I don't believe they'd have much effect. IBM hasn't shown any
inclination to bring its client implementation into conformance with the extant
TN3270E specification (RFC 2355), for example.
>
> I don't have strong feelings about whether the "tn3270" scheme is labelled
"provisional" or "historic". Again, I don't think it will make any difference to
implementors, who will treat tn3270-scheme URIs however they like. (I'm an
implementor myself, but thus far I've only dealt with the server side, which
never sees such URIs, so it hasn't come up.)
>


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


From alexey.melnikov@isode.com  Wed Nov 24 04:12:55 2010
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B4B3A6A33 for <apps-discuss@core3.amsl.com>; Wed, 24 Nov 2010 04:12:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.528
X-Spam-Level: 
X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDKzG30OS-at for <apps-discuss@core3.amsl.com>; Wed, 24 Nov 2010 04:12:33 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5D2563A6918 for <discuss@apps.ietf.org>; Wed, 24 Nov 2010 04:12:30 -0800 (PST)
Received: from [192.168.1.124] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <TO0BZgAEea42@rufus.isode.com>; Wed, 24 Nov 2010 12:13:29 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4CED0159.7030701@isode.com>
Date: Wed, 24 Nov 2010 12:13:13 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Apps Discuss <discuss@apps.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] My Apps AD workload till March 2011
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 24 Nov 2010 12:12:56 -0000

Hi,

Yesterday I finished going over WGs that I am responsible for and 
individual submission documents I've agreed to sponsor earlier. The list 
of documents that I want to finish before my Apps term ends in March 
2011 is quite long, I even had to ask Peter to take over some of the 
documents (and his list is long too).
So, with the exception of WG documents I know are in the pipeline (e.g. 
some stuff from HTTPBIS, EAI, HYBI, APPSAWG), I am going to exercise my 
right to only sponsor documents I think are important. This basically 
translates into me saying No more frequently to sponsoring some 
individual submissions.

Best Regards,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address



From Michael.Wojcik@microfocus.com  Wed Nov 24 07:31:48 2010
Return-Path: <Michael.Wojcik@microfocus.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1083A6A62; Wed, 24 Nov 2010 07:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.746
X-Spam-Level: 
X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb78znFUrNiU; Wed, 24 Nov 2010 07:31:47 -0800 (PST)
Received: from cluster-a.mailcontroller.altohiway.com (clustera.mailcontroller.co.uk [213.83.66.193]) by core3.amsl.com (Postfix) with ESMTP id 98C0A3A690E; Wed, 24 Nov 2010 07:31:44 -0800 (PST)
Received: from rlya7a.mailcontroller.altohiway.com (localhost.localdomain [127.0.0.1]) by rlya7a.mailcontroller.altohiway.com (MailController) with ESMTP id oAOFWWw4032681; Wed, 24 Nov 2010 15:32:37 GMT
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rlya7a.mailcontroller.altohiway.com (MailControl) id oAOFVv2Y030795;  Wed, 24 Nov 2010 15:31:57 GMT
Received: from MTV-EXCHANGE.microfocus.com ([216.52.8.28]) by rlya7a-eth0.mailcontroller.altohiway.com (envelope-sender <Michael.Wojcik@microfocus.com>) (MIMEDefang) with ESMTP id oAOFVtds030551; Wed, 24 Nov 2010 15:31:57 +0000 (GMT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 24 Nov 2010 07:30:01 -0800
Message-ID: <81F42F63D5BB344ABF294F8E80990C7902782A73@MTV-EXCHANGE.microfocus.com>
In-Reply-To: <002f01cb8bb3$6bc87fe0$4001a8c0@gateway.2wire.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [apps-discuss] [Uri-review]  Provisional URI registrations
Thread-Index: AcuLvB79CrlaVBclRDeylb3qsAAgDwALheSw
References: <201011222034.VAA22485@TR-Sys.de><81F42F63D5BB344ABF294F8E80990C7902782A63@MTV-EXCHANGE.microfocus.com> <4CEBE19C.6020408@ninebynine.org> <002f01cb8bb3$6bc87fe0$4001a8c0@gateway.2wire.net>
From: "Michael Wojcik" <Michael.Wojcik@microfocus.com>
To: <uri-review@ietf.org>, <apps-discuss@ietf.org>
X-Scanned-By: MailControl A-09-22-20 (www.mailcontrol.com) on 10.60.1.117
Subject: Re: [apps-discuss] [Uri-review]  Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 24 Nov 2010 15:31:48 -0000

> From: t.petch [mailto:ietfc@btconnect.com]
> Sent: Wednesday, 24 November, 2010 03:40
>=20
> Who needs a definition?  I did a quick 'literature search' and found
> plenty of references to tn3270 as a URI but no definition; the
examples
> were all of the form scheme :// host : port No parameters, queries,
> fragments or anything fancy.  On reflection, this seems right; tn3270
> is more sophisticated than many IETF protocols and if it wants
> something, it negotiates it, so no need for a complex URI to specify
> things in advance.

There are many things in TN3270 that can't simply be negotiated, and
that could usefully be represented in a URI. LU name, terminal type and
model, and printer association, for example; those are all things that
TN3270 clients typically let the user configure.

The tn3270 URI syntax might also conceivably let the user override the
default capability negotiation, for example to force Classic TN3270
rather than TN3270E, or request a non-default subset of TN3270E
functions. That would be useful for testing, among other things.

And while there's no obvious use for path, fragment, and query URI
components in the tn3270 scheme, I can easily imagine an implementor
using them for TN3270 extensions, such as using the path to select an
initial transaction.

> One could write a universal URI definition for such schemes scheme
host
> port means set up a connection of protocol 'scheme' to 'host', default
> port from IANA, but, arguably, we already have all we need in RFC3986.

I think we still need at least a basic tn3270 definition, if we're going
to consider the scheme well-defined. (Whether its status should be
changed from "provisional" to "historic" in the absence of such a
definition is another question; I have no strong feelings about that.)
There's a lot of variation among TN3270 implementations and the relevant
RFCs don't provide enough direction.

--=20
Michael Wojcik
Principal Software Systems Developer, Micro Focus



This message has been scanned for viruses by MailController - www.MailContr=
oller.altohiway.com

From ietfc@btconnect.com  Wed Nov 24 10:31:02 2010
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80263A6994; Wed, 24 Nov 2010 10:31:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.209
X-Spam-Level: 
X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHHvoS785YzY; Wed, 24 Nov 2010 10:31:00 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id 228D93A6944; Wed, 24 Nov 2010 10:30:59 -0800 (PST)
Received: from host81-156-71-67.range81-156.btcentralplus.com (HELO pc6) ([81.156.71.67]) by c2beaomr10.btconnect.com with SMTP id ATT22469; Wed, 24 Nov 2010 18:31:52 +0000 (GMT)
Message-ID: <337601cb8bfd$32d815c0$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: "Michael Wojcik" <Michael.Wojcik@microfocus.com>, <uri-review@ietf.org>, <apps-discuss@ietf.org>
References: <201011222034.VAA22485@TR-Sys.de><81F42F63D5BB344ABF294F8E80990C7902782A63@MTV-EXCHANGE.microfocus.com> <4CEBE19C.6020408@ninebynine.org> <002f01cb8bb3$6bc87fe0$4001a8c0@gateway.2wire.net> <81F42F63D5BB344ABF294F8E80990C7902782A73@MTV-EXCHANGE.microfocus.com>
Date: Wed, 24 Nov 2010 18:29:45 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CED5A17.03A6, actions=tag
X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4CED5A18.0273,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Subject: Re: [apps-discuss] [Uri-review]  Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 24 Nov 2010 18:31:02 -0000

----- Original Message -----
From: "Michael Wojcik" <Michael.Wojcik@microfocus.com>
To: <uri-review@ietf.org>; <apps-discuss@ietf.org>
Cc: "t.petch" <ietfc@btconnect.com>
Sent: Wednesday, November 24, 2010 4:30 PM
> From: t.petch [mailto:ietfc@btconnect.com]
> Sent: Wednesday, 24 November, 2010 03:40
>
> Who needs a definition?  I did a quick 'literature search' and found
> plenty of references to tn3270 as a URI but no definition; the
examples
> were all of the form scheme :// host : port No parameters, queries,
> fragments or anything fancy.  On reflection, this seems right; tn3270
> is more sophisticated than many IETF protocols and if it wants
> something, it negotiates it, so no need for a complex URI to specify
> things in advance.

There are many things in TN3270 that can't simply be negotiated, and
that could usefully be represented in a URI. LU name, terminal type and
model, and printer association, for example; those are all things that
TN3270 clients typically let the user configure.

<tp>
Yes we could, but I would be averse to producing a specification to which
noone actually conforms.  That is, if TN3270 were new and we were embarking
on a URI, we would have a free choice, but instead, we have a decade of history,
and I do not know what that is; in a brief search.I could not find any
parameters
currently and would not want to create a specification that noone has
implemented or will implement.

I see the primary need at present to have an agreed basic definition so the
information stays available in a sensible category in our registries.

Tom Petch
</tp>


The tn3270 URI syntax might also conceivably let the user override the
default capability negotiation, for example to force Classic TN3270
rather than TN3270E, or request a non-default subset of TN3270E
functions. That would be useful for testing, among other things.

And while there's no obvious use for path, fragment, and query URI
components in the tn3270 scheme, I can easily imagine an implementor
using them for TN3270 extensions, such as using the path to select an
initial transaction.

> One could write a universal URI definition for such schemes scheme
host
> port means set up a connection of protocol 'scheme' to 'host', default
> port from IANA, but, arguably, we already have all we need in RFC3986.

I think we still need at least a basic tn3270 definition, if we're going
to consider the scheme well-defined. (Whether its status should be
changed from "provisional" to "historic" in the absence of such a
definition is another question; I have no strong feelings about that.)
There's a lot of variation among TN3270 implementations and the relevant
RFCs don't provide enough direction.

--
Michael Wojcik
Principal Software Systems Developer, Micro Focus



This message has been scanned for viruses by MailController -
www.MailController.altohiway.com


From lyndon@gandalf.orthanc.ca  Wed Nov 24 18:48:26 2010
Return-Path: <lyndon@gandalf.orthanc.ca>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3811F3A69DD; Wed, 24 Nov 2010 18:48:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Edv1JwCQjlVx; Wed, 24 Nov 2010 18:48:25 -0800 (PST)
Received: from orthanc.ca (ve6bbm-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:139::2]) by core3.amsl.com (Postfix) with ESMTP id 693503A6984; Wed, 24 Nov 2010 18:48:25 -0800 (PST)
Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (8.14.4/8.14.4) with ESMTP id oAP2nMaN064090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2010 18:49:22 -0800 (PST) (envelope-from lyndon@gandalf.orthanc.ca)
Received: (from uucp@localhost) by orthanc.ca (8.14.4/8.14.4/Submit) with UUCP id oAP2nMx0064089; Wed, 24 Nov 2010 18:49:22 -0800 (PST) (envelope-from lyndon@gandalf.orthanc.ca)
Received: from gandalf.orthanc.ca (frodo.orthanc.ca [172.16.0.3]) by legolas.orthanc.ca (8.14.4/8.14.4) with ESMTP id oAP2nJKr069701; Wed, 24 Nov 2010 18:49:19 -0800 (PST) (envelope-from lyndon@gandalf.orthanc.ca)
Message-ID: <2748668134b693184bc26f5331ea1284@gandalf.orthanc.ca>
To: ah@TR-Sys.de
From: "Lyndon Nerenberg (VE6BBM/VE7TFX)"  <lyndon@orthanc.ca>
Date: Wed, 24 Nov 2010 18:49:18 -0800
In-Reply-To: <201011222034.VAA22485@TR-Sys.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 25 Nov 2010 02:48:26 -0000

> I would not have challenged "tn3270" as a provisional URI scheme
> if there had been evidence that the procedures of RFC 4395 for such
> scheme had been followed.

'tn3270:' usage predates RFC 4395 by at least a decade.


From evnikita2@gmail.com  Thu Nov 25 07:35:20 2010
Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F55D28C149; Thu, 25 Nov 2010 07:35:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.023
X-Spam-Level: 
X-Spam-Status: No, score=-3.023 tagged_above=-999 required=5 tests=[AWL=-2.385, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vzda8lBQoZef; Thu, 25 Nov 2010 07:35:01 -0800 (PST)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 5143C28C146; Thu, 25 Nov 2010 07:35:00 -0800 (PST)
Received: by gwj17 with SMTP id 17so548361gwj.31 for <multiple recipients>; Thu, 25 Nov 2010 07:36:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type; bh=j88SIsBvYDxAhxE6MvNxx6exD0XGu/DL4AbukOwXZBw=; b=j6dfofiRaZaUhBzWZFZhi1QcavydCs0TqEzz/0QLFP59j5qyKs4DS7Y5AlPZnoSKUn NDJslD6l8yoI4anbNrGbx7j6SBeogYuoduVQck8E/c1zMQPWIHaq7v0tcBiqbevpn8vp K163LiUvAP2hWJSJzPdg5W6eq0r87m/EyXyRY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=S6/994EguBpjU+E/YPNS01+Xp/CyBix1NFkCCcMjMW4Pn2NK3Lu0hsvsEwHR3CC3Bz bPrVAHo+giNcklJB3Y0wR/2DpqCNx+xRMptgYNwq6vX0GbhrcvZXB8nE3qD4gIIMUTSr RLosZTHgDBonQUJMnTgj0bygRuQ5uFzOxWOrg=
Received: by 10.204.76.207 with SMTP id d15mr798841bkk.198.1290699359580; Thu, 25 Nov 2010 07:35:59 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id t10sm416415bkj.4.2010.11.25.07.35.57 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Nov 2010 07:35:58 -0800 (PST)
Message-ID: <4CEE8263.9030303@gmail.com>
Date: Thu, 25 Nov 2010 17:36:03 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: uri-review@ietf.org, apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary="------------050004060508020609030008"
Subject: [apps-discuss] tn3270 URI scheme formal specification
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 25 Nov 2010 15:35:21 -0000

This is a multi-part message in MIME format.
--------------050004060508020609030008
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello all,

There has been a discussion about tn3270 URI scheme
on the lists recently. The consensus was that we need
a formal specification of the scheme. I've made an I-D
on this topic - you are able to find it here:

https://datatracker.ietf.org/doc/draft-yevstifeyev-tn3270-uri/

Feedbacks and suggestions are welcome.

All the best,
Mykyta Yevstifeyev

--------------050004060508020609030008
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <font size="-1"><big>Hello all,<br>
        <br>
        There has been a discussion about </big></font><font size="-1"><big>tn3270
        URI scheme<br>
        on the lists recently. The consensus was that we need<br>
        a formal specification of the scheme. I've made an I-D<br>
        on this topic - you are able to find it here:<br>
        <br>
        <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-yevstifeyev-tn3270-uri/">https://datatracker.ietf.org/doc/draft-yevstifeyev-tn3270-uri/</a><br>
        <br>
        Feedbacks and suggestions are welcome.<br>
        <br>
        All the best,<br>
        Mykyta Yevstifeyev<br>
      </big></font>
  </body>
</html>

--------------050004060508020609030008--

From evnikita2@gmail.com  Thu Nov 25 07:42:03 2010
Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2325628C15C for <apps-discuss@core3.amsl.com>; Thu, 25 Nov 2010 07:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.806
X-Spam-Level: 
X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=-2.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOrddt0MrA+N for <apps-discuss@core3.amsl.com>; Thu, 25 Nov 2010 07:42:02 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id EE17F28C150 for <apps-discuss@ietf.org>; Thu, 25 Nov 2010 07:42:01 -0800 (PST)
Received: by bwz12 with SMTP id 12so1073442bwz.31 for <apps-discuss@ietf.org>; Thu, 25 Nov 2010 07:43:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type; bh=cZYza0Ut33sWckV9M20o0gwUTlf4R7eOCQODBGCu5DA=; b=Gs+4N5uk1khb+ZemwByZFR5VvAIv5+6PlzC9vdCfty8KtZnKWFLKAgmaCaA/vhi9on QJsa4rMz1rm2PEiIJj0JGO3/icXb1hUZX9eFHeoqjuXXpeEGgyHlxwcp2e7M+0yu1fq6 DjWFl+PoAesusAD1d1KZn6ifJFBvAv7vISLSg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=IseL82eWgzIQvkbox30JEsm8c9+utWXi67u38AMWFuaMZIip96uzAFAYqFuCkwvupH 0wZIZ6YSTBUxYEb9BFqUd7In0lA2/d52tIqAIjcLYzRKzpUunIBhwyimlxuH0ANR+fq3 AsWzngPTG1rlgEj6IdFDBOu8brRk0Al/nwHuw=
Received: by 10.204.116.199 with SMTP id n7mr791652bkq.188.1290699779500; Thu, 25 Nov 2010 07:42:59 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id p22sm420210bkp.9.2010.11.25.07.42.58 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Nov 2010 07:42:58 -0800 (PST)
Message-ID: <4CEE8408.9000205@gmail.com>
Date: Thu, 25 Nov 2010 17:43:04 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary="------------080909070309090100010804"
Subject: [apps-discuss] Draft review request - HTTP 'Headers Not Recognized'
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 25 Nov 2010 15:42:03 -0000

This is a multi-part message in MIME format.
--------------080909070309090100010804
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello all,

I have made an I-D, which, I think, will be interesting
for the Applications area.

You can find it here:

https://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/

The draft has already been discussed in the HTTPBIS WG,
and you are able to find some discussion history in the
WG mailing list archive in the messages entitled  'Please Review
  my Internet-Draft', 
'draft-yevstifeyev-http-headers-not-recognized-01.txt'
and Headers-Not-Recognized for HTTP'

Could you please review it?

Thank you in advance,
Mykyta Yevstifeyev

--------------080909070309090100010804
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <font size="-1">Hello all,<br>
      <br>
      I have made an I-D, which, I think, will be interesting<br>
      for the Applications area.<br>
      <br>
      You can find it here:<br>
      <br>
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/">https://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/</a><br>
      <br>
      The draft has already been discussed in the HTTPBIS WG,<br>
      and you are able to find some discussion history in the<br>
      WG mailing list archive in the messages entitled  'Please Review<br>
       my Internet-Draft',
      'draft-yevstifeyev-http-headers-not-recognized-01.txt' <br>
      and Headers-Not-Recognized for HTTP'<br>
      <br>
      Could you please review it?<br>
      <br>
      Thank you in advance,<br>
      Mykyta Yevstifeyev<br>
    </font>
  </body>
</html>

--------------080909070309090100010804--

From evnikita2@gmail.com  Thu Nov 25 23:40:46 2010
Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4041E3A6A5A; Thu, 25 Nov 2010 23:40:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.437
X-Spam-Level: 
X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJj2Os10+oMR; Thu, 25 Nov 2010 23:40:44 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id E89EA3A6A0B; Thu, 25 Nov 2010 23:40:27 -0800 (PST)
Received: by yxk30 with SMTP id 30so888067yxk.31 for <multiple recipients>; Thu, 25 Nov 2010 23:41:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2q9+EQAxPjoQoCOxee0l39Mt85mgUAGpmgSgAueRXvU=; b=fYhQNwWl7FtigZG4+AxzqURxD093twrQ2XenpnhFLnkRy6B8MIU/maUj0V+XWK+VG6 wIu71eE5TlJSQGbgfSk2P72tuAg0AtkvDVkMjIg/bLvHxT/jTZk6eGxjteUed8eQoym8 7NnL6xrwVj7FhepwUZBSxeYO8/3qA5tK1vr3E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Oiux/haWabOxDH2fJOtp+gw43L9nDmSvCyV6PcYJYfmxp/bTG8NzA/hD/dcgvxpNUc 1t7aC01o0HODXIJEGODQuorEtbTnPpAhY1dqbS6axyTrNbSLLEPyzkyzqk0GnxdDGm6Z YiJcBpQqnlypydZqHVXgXxq8keiWFasDL4RO8=
MIME-Version: 1.0
Received: by 10.150.95.3 with SMTP id s3mr4766120ybb.285.1290757271205; Thu, 25 Nov 2010 23:41:11 -0800 (PST)
Received: by 10.150.97.7 with HTTP; Thu, 25 Nov 2010 23:41:11 -0800 (PST)
In-Reply-To: <4CEEA4C0.50302@NineByNine.net>
References: <4CEE8263.9030303@gmail.com> <4CEEA4C0.50302@NineByNine.net>
Date: Fri, 26 Nov 2010 09:41:11 +0200
Message-ID: <AANLkTikAOkeNiDQV_N2XcDshVYJHpU2=W+rQ1GboYfEY@mail.gmail.com>
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
To: Graham Klyne <GK@ninebynine.net>
Content-Type: text/plain; charset=ISO-8859-1
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] tn3270 URI scheme formal specification
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 26 Nov 2010 07:40:46 -0000

Graham,

I have revised the draft. I think it wouldn't move
the 'tn3270' scheme to Permanent but remains it
Provisional with updated registration template.

As for Historic issues, there was a discussion on the list
about this topic and the consesus was that there is no
necessity to move it to Historic, but remain Prov. or Perm.

The references you proposed will be added.

Mykyta Yevstifeyev

2010/11/25, Graham Klyne <GK@ninebynine.net>:
> Mykyta Yevstifeyev wrote:
>>    Hello all,
>>
>> There has been a discussion about tn3270 URI scheme
>> on the lists recently. The consensus was that we need
>> a formal specification of the scheme. I've made an I-D
>> on this topic - you are able to find it here:
>>
>> https://datatracker.ietf.org/doc/draft-yevstifeyev-tn3270-uri/
>>
>> Feedbacks and suggestions are welcome.
>
> I think this is a most constructive move to resolve the running debate.
> Kudos:)
>
> My main motivation in reviewing this is to offer a view of how it might meet
> the
> registration criteria (but this is not a formal review for that purpose).  I
> know nothing about the tn3270 scheme, and do not comment on the technical
> content.
>
> I don't feel strongly about this, but the title might usefully be
>    "Reclassification of the tn3270 URI scheme as <foo>"
> (for some value of "<foo>" - see below).
>
> --------
> 1. Introduction
>
>     The tn3270 URI scheme was firstly mentioned in RFC 1738 [RFC1738] in
>     order to be registered as 'Provisional' URI scheme. However there are
>     no acceptable and clear specifications so far.
> ----
>
> I'd argue with "in order to be registered".  As someone noted, RFC1738
> rather
> pre-dates the URI registries :).  Suggest:
> [[
> The tn3270 URI scheme was first mentioned in RFC 1738 [RFC1738].  Following
> the
> creation of the URI scheme registries per RFC4395, it was added to the
> "provisional" registry. However there are no clear specifications so far for
> this scheme.
> ]]
> ----
>
> [...]
>
> --------
> 4. IANA Considerations
>
>     IANA is asked to move the tn3270 URI scheme registration from
>     'Provisional' to 'Permanent'.
> ----
>
> In my view, it would take a lot more than this document to justify moving
> the
> scheme to the 'permanent' registry - that would imply that there is
> widespread
> active and ongoing interest in actually using the scheme.  As reviewer, I'd
> be
> looking for some evidence of this.
>
> On the other hand, if the request were to reclassify the scheme as
> 'historic',
> I'd have fewer such concerns.
>
> --------
> 5. Normative References
>
>     [RFC1738]   Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
>                 Resource Locators (URL)", RFC 1738, December 1994.
> ----
>
> I think some more refs would be appropriate:
>
> RFC 5234 [RFC5234]
>
> Some documents (any documents) describing Telnet and the 3270 emulation
> framework.
>
> RFC3986, probably (the syntax needs to be consistent with the syntax given
> there)
>
> http://www.rfc-editor.org/rfc/rfc4395.txt, since this is based on the
> registries
> defined there.
>
> #g
> --
>
>

From ietfc@btconnect.com  Fri Nov 26 02:12:18 2010
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01FD3A6AC1; Fri, 26 Nov 2010 02:12:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.492
X-Spam-Level: 
X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmCHY3dut2XB; Fri, 26 Nov 2010 02:12:17 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by core3.amsl.com (Postfix) with ESMTP id 50C683A6AA6; Fri, 26 Nov 2010 02:12:16 -0800 (PST)
Received: from host81-156-71-67.range81-156.btcentralplus.com (HELO pc6) ([81.156.71.67]) by c2bthomr07.btconnect.com with SMTP id BBC78085; Fri, 26 Nov 2010 10:13:14 +0000 (GMT)
Message-ID: <009301cb8d49$dd773fe0$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: "Mykyta Yevstifeyev" <evnikita2@gmail.com>, "Graham Klyne" <GK@ninebynine.net>
References: <4CEE8263.9030303@gmail.com><4CEEA4C0.50302@NineByNine.net> <AANLkTikAOkeNiDQV_N2XcDshVYJHpU2=W+rQ1GboYfEY@mail.gmail.com>
Date: Fri, 26 Nov 2010 10:10:57 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CEF8835.0017, actions=TAG
X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4CEF883B.00E3,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] tn3270 URI scheme formalspecification
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 26 Nov 2010 10:12:19 -0000

There is a strong and recent parallel for this kind of action, namely RFC5781.
My idea would be to lift that RFC, lock, stock and barrel, make the very few
necessary changes and submit. In fact, I was .. ah well, never mind.

Tom Petch


----- Original Message -----
From: "Mykyta Yevstifeyev" <evnikita2@gmail.com>
To: "Graham Klyne" <GK@ninebynine.net>
Cc: <uri-review@ietf.org>; <apps-discuss@ietf.org>
Sent: Friday, November 26, 2010 8:41 AM
Subject: Re: [apps-discuss] [Uri-review] tn3270 URI scheme formalspecification


> Graham,
>
> I have revised the draft. I think it wouldn't move
> the 'tn3270' scheme to Permanent but remains it
> Provisional with updated registration template.
>
> As for Historic issues, there was a discussion on the list
> about this topic and the consesus was that there is no
> necessity to move it to Historic, but remain Prov. or Perm.
>
> The references you proposed will be added.
>
> Mykyta Yevstifeyev
>
> 2010/11/25, Graham Klyne <GK@ninebynine.net>:
> > Mykyta Yevstifeyev wrote:
> >>    Hello all,
> >>
> >> There has been a discussion about tn3270 URI scheme
> >> on the lists recently. The consensus was that we need
> >> a formal specification of the scheme. I've made an I-D
> >> on this topic - you are able to find it here:
> >>
> >> https://datatracker.ietf.org/doc/draft-yevstifeyev-tn3270-uri/
> >>
> >> Feedbacks and suggestions are welcome.
> >
> > I think this is a most constructive move to resolve the running debate.
> > Kudos:)
> >
> > My main motivation in reviewing this is to offer a view of how it might meet
> > the
> > registration criteria (but this is not a formal review for that purpose).  I
> > know nothing about the tn3270 scheme, and do not comment on the technical
> > content.
> >
> > I don't feel strongly about this, but the title might usefully be
> >    "Reclassification of the tn3270 URI scheme as <foo>"
> > (for some value of "<foo>" - see below).
> >
> > --------
> > 1. Introduction
> >
> >     The tn3270 URI scheme was firstly mentioned in RFC 1738 [RFC1738] in
> >     order to be registered as 'Provisional' URI scheme. However there are
> >     no acceptable and clear specifications so far.
> > ----
> >
> > I'd argue with "in order to be registered".  As someone noted, RFC1738
> > rather
> > pre-dates the URI registries :).  Suggest:
> > [[
> > The tn3270 URI scheme was first mentioned in RFC 1738 [RFC1738].  Following
> > the
> > creation of the URI scheme registries per RFC4395, it was added to the
> > "provisional" registry. However there are no clear specifications so far for
> > this scheme.
> > ]]
> > ----
> >
> > [...]
> >
> > --------
> > 4. IANA Considerations
> >
> >     IANA is asked to move the tn3270 URI scheme registration from
> >     'Provisional' to 'Permanent'.
> > ----
> >
> > In my view, it would take a lot more than this document to justify moving
> > the
> > scheme to the 'permanent' registry - that would imply that there is
> > widespread
> > active and ongoing interest in actually using the scheme.  As reviewer, I'd
> > be
> > looking for some evidence of this.
> >
> > On the other hand, if the request were to reclassify the scheme as
> > 'historic',
> > I'd have fewer such concerns.
> >
> > --------
> > 5. Normative References
> >
> >     [RFC1738]   Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
> >                 Resource Locators (URL)", RFC 1738, December 1994.
> > ----
> >
> > I think some more refs would be appropriate:
> >
> > RFC 5234 [RFC5234]
> >
> > Some documents (any documents) describing Telnet and the 3270 emulation
> > framework.
> >
> > RFC3986, probably (the syntax needs to be consistent with the syntax given
> > there)
> >
> > http://www.rfc-editor.org/rfc/rfc4395.txt, since this is based on the
> > registries
> > defined there.
> >
> > #g
> > --
> >
> >
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From evnikita2@gmail.com  Fri Nov 26 05:55:47 2010
Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6D428C0D9; Fri, 26 Nov 2010 05:55:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.473
X-Spam-Level: 
X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=-1.834, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oubNQxcALPe; Fri, 26 Nov 2010 05:55:47 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5544028B797; Fri, 26 Nov 2010 05:55:46 -0800 (PST)
Received: by bwz12 with SMTP id 12so2000617bwz.31 for <multiple recipients>; Fri, 26 Nov 2010 05:56:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=xdbUDCHzpReHx2HEJ+W7cULMVZ8nGNvFHi1leNBFgzw=; b=OSCgbO7v+vRjb6CDSqLc1OE9m9Fuocv4Ak/uAHDMyf12CcE+sEE8iB8PBfvuL/0xZb xPuVbQ8JZ6mZifWk6afdEGa4aJQAGcP/SYtPchxW3+chUG2LQW3hNeuDTh1IGkgIVFSW K6YFZayM1E5bjrRsSYyiIZqxfsH82W6DcRFEA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=aQz8tS3FHzBkwZyjdkp1zv8e/T5Xtf8SE0maK6bqe3nW+RgXG321Hk+6tsuEu/Tf7a d0zoJc2wZoJsTVGf6jx8/39LtzyvW7dXm2WTM1MubUvptITUttXZlLf2L1ijjn01FREF TZzp5xbDkXoigPhbpE7F/iOgm6aw5VGMCAB4Q=
Received: by 10.204.62.3 with SMTP id v3mr1940919bkh.99.1290779809280; Fri, 26 Nov 2010 05:56:49 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id 4sm470850bki.1.2010.11.26.05.56.46 (version=SSLv3 cipher=RC4-MD5); Fri, 26 Nov 2010 05:56:47 -0800 (PST)
Message-ID: <4CEFBCA4.6060805@gmail.com>
Date: Fri, 26 Nov 2010 15:56:52 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Graham Klyne <GK@NineByNine.net>, uri-review@ietf.org,  apps-discuss@ietf.org
References: <4CEE8263.9030303@gmail.com>	<4CEEA4C0.50302@NineByNine.net> <AANLkTikAOkeNiDQV_N2XcDshVYJHpU2=W+rQ1GboYfEY@mail.gmail.com> <4CEF98D0.1040106@NineByNine.net>
In-Reply-To: <4CEF98D0.1040106@NineByNine.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] [Uri-review] tn3270 URI scheme formal	specification
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 26 Nov 2010 13:55:47 -0000

26.11.2010 13:24, Graham Klyne wrote:
> Ack.  As someone pointed out, the rsync RFC is a good model.
>
> #g
> -- 
>
>
> Mykyta Yevstifeyev wrote:
>> Graham,
>>
>> I have revised the draft. I think it wouldn't move
>> the 'tn3270' scheme to Permanent but remains it
>> Provisional with updated registration template.
>>
>> As for Historic issues, there was a discussion on the list
>> about this topic and the consesus was that there is no
>> necessity to move it to Historic, but remain Prov. or Perm.
>>
>> The references you proposed will be added.
>>
>> Mykyta Yevstifeyev
>>
>> 2010/11/25, Graham Klyne <GK@ninebynine.net>:
>>> Mykyta Yevstifeyev wrote:
>>>>    Hello all,
>>>>
>>>> There has been a discussion about tn3270 URI scheme
>>>> on the lists recently. The consensus was that we need
>>>> a formal specification of the scheme. I've made an I-D
>>>> on this topic - you are able to find it here:
>>>>
>>>> https://datatracker.ietf.org/doc/draft-yevstifeyev-tn3270-uri/
>>>>
>>>> Feedbacks and suggestions are welcome.
>>> I think this is a most constructive move to resolve the running debate.
>>> Kudos:)
>>>
>>> My main motivation in reviewing this is to offer a view of how it 
>>> might meet
>>> the
>>> registration criteria (but this is not a formal review for that 
>>> purpose).  I
>>> know nothing about the tn3270 scheme, and do not comment on the 
>>> technical
>>> content.
>>>
>>> I don't feel strongly about this, but the title might usefully be
>>>    "Reclassification of the tn3270 URI scheme as <foo>"
>>> (for some value of "<foo>" - see below).
>>>
>>> --------
>>> 1. Introduction
>>>
>>>     The tn3270 URI scheme was firstly mentioned in RFC 1738 
>>> [RFC1738] in
>>>     order to be registered as 'Provisional' URI scheme. However 
>>> there are
>>>     no acceptable and clear specifications so far.
>>> ----
>>>
>>> I'd argue with "in order to be registered".  As someone noted, RFC1738
>>> rather
>>> pre-dates the URI registries :).  Suggest:
>>> [[
>>> The tn3270 URI scheme was first mentioned in RFC 1738 [RFC1738].  
>>> Following
>>> the
>>> creation of the URI scheme registries per RFC4395, it was added to the
>>> "provisional" registry. However there are no clear specifications so 
>>> far for
>>> this scheme.
>>> ]]
>>> ----
>>>
>>> [...]
>>>
>>> --------
>>> 4. IANA Considerations
>>>
>>>     IANA is asked to move the tn3270 URI scheme registration from
>>>     'Provisional' to 'Permanent'.
>>> ----
>>>
>>> In my view, it would take a lot more than this document to justify 
>>> moving
>>> the
>>> scheme to the 'permanent' registry - that would imply that there is
>>> widespread
>>> active and ongoing interest in actually using the scheme.  As 
>>> reviewer, I'd
>>> be
>>> looking for some evidence of this.
>>>
>>> On the other hand, if the request were to reclassify the scheme as
>>> 'historic',
>>> I'd have fewer such concerns.
>>>
>>> --------
>>> 5. Normative References
>>>
>>>     [RFC1738]   Berners-Lee, T., Masinter, L., and M. McCahill, 
>>> "Uniform
>>>                 Resource Locators (URL)", RFC 1738, December 1994.
>>> ----
>>>
>>> I think some more refs would be appropriate:
>>>
>>> RFC 5234 [RFC5234]
>>>
>>> Some documents (any documents) describing Telnet and the 3270 emulation
>>> framework.
>>>
>>> RFC3986, probably (the syntax needs to be consistent with the syntax 
>>> given
>>> there)
>>>
>>> http://www.rfc-editor.org/rfc/rfc4395.txt, since this is based on the
>>> registries
>>> defined there.
>>>
>>> #g
>>> -- 
>>>
>>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>
>
It is really a good idea. I'll try to remake the draft in a few days
so that all notes were taken into consideration.

Mykyta

From ietfc@btconnect.com  Fri Nov 26 08:07:24 2010
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77AE33A6B1F; Fri, 26 Nov 2010 08:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.205
X-Spam-Level: 
X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FutT4l5PDR3g; Fri, 26 Nov 2010 08:07:23 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by core3.amsl.com (Postfix) with ESMTP id 3535728C0DF; Fri, 26 Nov 2010 08:07:22 -0800 (PST)
Received: from host81-156-71-67.range81-156.btcentralplus.com (HELO pc6) ([81.156.71.67]) by c2bthomr14.btconnect.com with SMTP id AUQ01322; Fri, 26 Nov 2010 16:08:17 +0000 (GMT)
Message-ID: <003601cb8d7b$77481e60$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: "Michael Wojcik" <Michael.Wojcik@microfocus.com>, <uri-review@ietf.org>, <apps-discuss@ietf.org>
References: <201011222034.VAA22485@TR-Sys.de><81F42F63D5BB344ABF294F8E80990C7902782A63@MTV-EXCHANGE.microfocus.com><4CEBE19C.6020408@ninebynine.org><002f01cb8bb3$6bc87fe0$4001a8c0@gateway.2wire.net><81F42F63D5BB344ABF294F8E80990C7902782A73@MTV-EXCHANGE.microfocus.com> <337601cb8bfd$32d815c0$4001a8c0@gateway.2wire.net>
Date: Fri, 26 Nov 2010 16:04:27 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CEFDB62.0231, actions=tag
X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4CEFDB76.00CA,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Subject: Re: [apps-discuss] [Uri-review]  Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 26 Nov 2010 16:07:24 -0000

----- Original Message -----
From: "t.petch" <ietfc@btconnect.com>
To: "Michael Wojcik" <Michael.Wojcik@microfocus.com>; <uri-review@ietf.org>;
<apps-discuss@ietf.org>
Sent: Wednesday, November 24, 2010 6:29 PM
> ----- Original Message -----
> From: "Michael Wojcik" <Michael.Wojcik@microfocus.com>
> To: <uri-review@ietf.org>; <apps-discuss@ietf.org>
> Cc: "t.petch" <ietfc@btconnect.com>
> Sent: Wednesday, November 24, 2010 4:30 PM
> > From: t.petch [mailto:ietfc@btconnect.com]
> > Sent: Wednesday, 24 November, 2010 03:40
> >
> > Who needs a definition?  I did a quick 'literature search' and found
> > plenty of references to tn3270 as a URI but no definition; the
> examples
> > were all of the form scheme :// host : port No parameters, queries,
> > fragments or anything fancy.  On reflection, this seems right; tn3270
> > is more sophisticated than many IETF protocols and if it wants
> > something, it negotiates it, so no need for a complex URI to specify
> > things in advance.
>
> There are many things in TN3270 that can't simply be negotiated, and
> that could usefully be represented in a URI. LU name, terminal type and
> model, and printer association, for example; those are all things that
> TN3270 clients typically let the user configure.

Michael

Nice try, but most people would regard RFC1646 and RFC1647 as giving
you precisely that, even if, colloquially, they are not called TN3270 but
TN3270E.

I stand by my first statement, that you can negotiate anything you need with
TN3270  and a URI needs no options.

Tom Petch

<snip>


From Michael.Wojcik@microfocus.com  Sat Nov 27 07:29:48 2010
Return-Path: <Michael.Wojcik@microfocus.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF97E28C0E9; Sat, 27 Nov 2010 07:29:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level: 
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNALvF-3329o; Sat, 27 Nov 2010 07:29:47 -0800 (PST)
Received: from cluster-b.mailcontroller.altohiway.com (clusterb.mailcontroller.co.uk [213.83.66.209]) by core3.amsl.com (Postfix) with ESMTP id 4B96928C0E0; Sat, 27 Nov 2010 07:29:46 -0800 (PST)
Received: from rlya9b.mailcontroller.altohiway.com (localhost.localdomain [127.0.0.1]) by rlya9b.mailcontroller.altohiway.com (MailController) with ESMTP id oARFUmVu007139; Sat, 27 Nov 2010 15:30:49 GMT
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rlya9b.mailcontroller.altohiway.com (MailControl) id oARFURea004647;  Sat, 27 Nov 2010 15:30:27 GMT
Received: from MTV-EXCHANGE.microfocus.com ([216.52.8.28]) by rlya9b-eth0.mailcontroller.altohiway.com (envelope-sender <Michael.Wojcik@microfocus.com>) (MIMEDefang) with ESMTP id oARFUK7B004235; Sat, 27 Nov 2010 15:30:27 +0000 (GMT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 27 Nov 2010 07:30:10 -0800
Message-ID: <81F42F63D5BB344ABF294F8E80990C7902782A83@MTV-EXCHANGE.microfocus.com>
In-Reply-To: <003601cb8d7b$77481e60$4001a8c0@gateway.2wire.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [apps-discuss] [Uri-review]  Provisional URI registrations
Thread-Index: AcuNhClMXloRqhHtTvWgBETBs4aUfAAv3YAA
References: <201011222034.VAA22485@TR-Sys.de><81F42F63D5BB344ABF294F8E80990C7902782A63@MTV-EXCHANGE.microfocus.com><4CEBE19C.6020408@ninebynine.org><002f01cb8bb3$6bc87fe0$4001a8c0@gateway.2wire.net><81F42F63D5BB344ABF294F8E80990C7902782A73@MTV-EXCHANGE.microfocus.com> <337601cb8bfd$32d815c0$4001a8c0@gateway.2wire.net> <003601cb8d7b$77481e60$4001a8c0@gateway.2wire.net>
From: "Michael Wojcik" <Michael.Wojcik@microfocus.com>
To: "t.petch" <ietfc@btconnect.com>
X-Scanned-By: MailControl A-09-22-20 (www.mailcontrol.com) on 10.61.1.119
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review]  Provisional URI registrations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 27 Nov 2010 15:29:48 -0000

> From: t.petch [mailto:ietfc@btconnect.com]
> Sent: Friday, 26 November, 2010 10:04
> >
> > There are many things in TN3270 that can't simply be negotiated, and
> > that could usefully be represented in a URI. LU name, terminal type
> > and model, and printer association, for example; those are all
things
> > that TN3270 clients typically let the user configure.
>=20
> Nice try, but most people would regard RFC1646 and RFC1647 as giving
> you precisely that, even if, colloquially, they are not called TN3270
> but TN3270E.

I'm afraid not.

First, LU name and printer association are determined by the user, and
so they can't be negotiated. The user agent and service provider have no
way of knowing what LU or printer name the user wishes to use, unless
the user's specified it. A URI would be one way of specifying it.
Similarly, extant TN3270 clients let users configure model information
precisely because they don't always want what the client and server
would otherwise negotiate; a URI could also specify that.

Second, 1646 is not part of TN3270E, even though it was defined by
members of the TN3270E Working Group. It's an informational RFC that
defines a pair of possible extension mechanisms to Classic TN3270.
TN3270E didn't even exist when 1646 was published (since it was first
defined by 1647), and 1646 explicitly describes Classic TN3270
negotiation and flows.

Third, 1647 is obsolete. TN3270E is currently defined by RFC2355. And
it, too, cannot negotiate that which is not negotiable.
=20
> I stand by my first statement, that you can negotiate anything you
need
> with TN3270  and a URI needs no options.

And you're wrong. Have you implemented TN370? I have - client and
server, classic and enhanced. I also understand how LU names and printer
association work.


A trivial specification for the tn3270 URI scheme would be fine. It'd
provide a starting point for a real specification, if there is any
interest in creating one. But relegating it to a (hypothetical) new
category of "protocols with no possible URI parameters other than scheme
and authority" is inaccurate. There *are* other possible URI parameters
for a tn3270 URI scheme, and so it ought to have its own specification,
if it is to be specified at all.

--=20
Michael Wojcik
Principal Software Systems Developer, Micro Focus




This message has been scanned for viruses by MailController - www.MailContr=
oller.altohiway.com

From evnikita2@gmail.com  Sun Nov 28 02:05:17 2010
Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99E73A69E0; Sun, 28 Nov 2010 02:05:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.082
X-Spam-Level: 
X-Spam-Status: No, score=-3.082 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1g9q4NBbotdZ; Sun, 28 Nov 2010 02:05:17 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 831BB28C0CE; Sun, 28 Nov 2010 02:05:16 -0800 (PST)
Received: by bwz12 with SMTP id 12so3393311bwz.31 for <multiple recipients>; Sun, 28 Nov 2010 02:06:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Zgm+suhXLqw1snidN9BCZvzeExXCp8vHoE+7bW2UH40=; b=RoW7HB8G14rDIdWscPse/XqwXlHq+9W8ZcRLL5I1zsFgC1ihltx3VHzlJfn63faa6R zymD7X07INw77YTBAlhwzkWpyFtcIpYFDeUPU2RPtVyNDhklnGvW/w5P9ttD3KIPRChs 0ZxLJOjvuQLm8isJkD7QMTvxasBPm4ZZW/HEA=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=r2eQTxFhJboIZQZt0k2/u+BstX6I1KIwa3k05iaaIIvBPQlwrQtjr4APPd93KSV1pE zKiF/HGqLa1W2KDZJtuok/Re9pnuHWwtxT/89iCyhchC9JWFjR+I92uvtYnr7R1jxKyA yf0iFHl/1VmT9zusvQfbEfHTMndbsv6Quistk=
Received: by 10.204.103.133 with SMTP id k5mr3624415bko.68.1290938782891; Sun, 28 Nov 2010 02:06:22 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id v25sm1390082bkt.18.2010.11.28.02.06.21 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Nov 2010 02:06:22 -0800 (PST)
Message-ID: <4CF229A3.40808@gmail.com>
Date: Sun, 28 Nov 2010 12:06:27 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= <ah@TR-Sys.de>
References: <201011261556.QAA29714@TR-Sys.de>
In-Reply-To: <201011261556.QAA29714@TR-Sys.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: uri-review@ietf.org, GK@ninebynine.org, apps-discuss@ietf.org
Subject: [apps-discuss] New version of tn3270 draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 28 Nov 2010 10:05:17 -0000

Hello all,

A new version of tn3270 draft (-05) is now available on
the I-D repository. It includes the following changes:

-added the template for IANA to register the scheme as
  *Provisional*;
-added more detailed description of TN3270 service
  (with references to corresponding RFCs);
-added more references;
-added Acknowledgments section;
-another minor changes.

I am sending this message to Applications Area ADs -
Alexey Melnikov and Peter Saint-Andre in order they
can review this document.

Any suggestions for improvements are welcome.

Best regards,
Mykyta Yevstifeyev

From julian.reschke@gmx.de  Sun Nov 28 02:29:10 2010
Return-Path: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0023428C0EF for <apps-discuss@core3.amsl.com>; Sun, 28 Nov 2010 02:29:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.66
X-Spam-Level: 
X-Spam-Status: No, score=-104.66 tagged_above=-999 required=5 tests=[AWL=-2.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJxnhLiRX2nH for <apps-discuss@core3.amsl.com>; Sun, 28 Nov 2010 02:29:09 -0800 (PST)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id AED393A6BC9 for <apps-discuss@ietf.org>; Sun, 28 Nov 2010 02:28:59 -0800 (PST)
Received: (qmail invoked by alias); 28 Nov 2010 10:30:05 -0000
Received: from p508FBF0D.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.191.13] by mail.gmx.net (mp045) with SMTP; 28 Nov 2010 11:30:05 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/dMbB0sI7dcVS9MQ4rJk05b1KtRIQJtUYwQvI7/u /Hf3/tiytJX0rj
Message-ID: <4CF22F2B.9070906@gmx.de>
Date: Sun, 28 Nov 2010 11:30:03 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
References: <201011261556.QAA29714@TR-Sys.de> <4CF229A3.40808@gmail.com>
In-Reply-To: <4CF229A3.40808@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= <ah@TR-Sys.de>, GK@ninebynine.org, uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] New version of tn3270 draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 28 Nov 2010 10:29:10 -0000

On 28.11.2010 11:06, Mykyta Yevstifeyev wrote:
> Hello all,
>
> A new version of tn3270 draft (-05) is now available on
> the I-D repository. It includes the following changes:
>
> -added the template for IANA to register the scheme as
> *Provisional*;
> -added more detailed description of TN3270 service
> (with references to corresponding RFCs);
> -added more references;
> -added Acknowledgments section;
> -another minor changes.
>
> I am sending this message to Applications Area ADs -
> Alexey Melnikov and Peter Saint-Andre in order they
> can review this document.
>
> Any suggestions for improvements are welcome.
>
> Best regards,
> Mykyta Yevstifeyev

Sunday morning nitpicking:

1) It's really confusing when you submit 3 drafts on the same day, and 
some of them only fix minor typos, or punctuation. That makes it hard to 
find out what actually changed. Also, draft -04 seems to have the wrong 
submission date.

2) A URI scheme definition that cites RFC 3986 only for security 
considerations makes me nervous. For instance, it should be clear how 
the individual components would be recognized by a generic URI parser. 
It appears that all you're saying that the scheme-specific part maps to:

   "//" authority

3) ABNF comments

3a) What's the delimiter between password and host?

3b) What's the [/] at the end for? Did you mean [ "/" ]?

3c) Please avoid prose constructions; they are not sufficient to 
actually parse the URI. So which characters are allowed in "user", 
"password" and "host"?

4) You're not citing the URI scheme registration RFC (4395), nor have 
the information requested in 
<http://tools.ietf.org/html/rfc4395#section-5.4>.

Best regards, Julian

From evnikita2@gmail.com  Sun Nov 28 02:47:46 2010
Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D673A6A93; Sun, 28 Nov 2010 02:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.186
X-Spam-Level: 
X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LblSAJNHGmC2; Sun, 28 Nov 2010 02:47:45 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A30433A69E0; Sun, 28 Nov 2010 02:47:44 -0800 (PST)
Received: by bwz12 with SMTP id 12so3411554bwz.31 for <multiple recipients>; Sun, 28 Nov 2010 02:48:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=npf/dMeMiN+HaRfBhcfErgLEkwudrpagZgHcxzKapYM=; b=hC0CF5kzB7tvpBQV66me89496B80XaDGGwcpljdLRF5Nl6tXMwt3fJWs4RnCVsWPjU mYj78bQx/oxm7iYmJE/MSdJMPXBiCq7bO5/KRMMh3lU1NnuGO+1UcSR3Ri4SLQ8OF2wZ AsjZV3lsdobawfalsgOjEh8gguKKhNNKVtJ1U=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Gd0v9RIiTPNd+6DbegNpeWacMmlHus16aHFu0hng0E7wpmlcMnsYf65UJdlR35gIFW KmHwsp6ME70LE8iHNM2FqSceyBt/lzVw5tAveOSwax2p4Yg0yMpN2GujCQPWjHv4KflF LmwNdsEERg9hqk/b1J4KqIDbRWcJ1mCH8YDjk=
Received: by 10.204.63.193 with SMTP id c1mr3576868bki.110.1290941329173; Sun, 28 Nov 2010 02:48:49 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id b17sm1406566bku.20.2010.11.28.02.48.47 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Nov 2010 02:48:48 -0800 (PST)
Message-ID: <4CF23396.2040207@gmail.com>
Date: Sun, 28 Nov 2010 12:48:54 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
References: <201011261556.QAA29714@TR-Sys.de> <4CF229A3.40808@gmail.com> <4CF22F2B.9070906@gmx.de>
In-Reply-To: <4CF22F2B.9070906@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= <ah@TR-Sys.de>, GK@ninebynine.org, uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] New version of tn3270 draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 28 Nov 2010 10:47:46 -0000

Hello Julian,

Here are responses on your notes.

28.11.2010 12:30, Julian Reschke wrote:
> On 28.11.2010 11:06, Mykyta Yevstifeyev wrote:
>> Hello all,
>>
>> A new version of tn3270 draft (-05) is now available on
>> the I-D repository. It includes the following changes:
>>
>> -added the template for IANA to register the scheme as
>> *Provisional*;
>> -added more detailed description of TN3270 service
>> (with references to corresponding RFCs);
>> -added more references;
>> -added Acknowledgments section;
>> -another minor changes.
>>
>> I am sending this message to Applications Area ADs -
>> Alexey Melnikov and Peter Saint-Andre in order they
>> can review this document.
>>
>> Any suggestions for improvements are welcome.
>>
>> Best regards,
>> Mykyta Yevstifeyev
>
> Sunday morning nitpicking:
>
> 1) It's really confusing when you submit 3 drafts on the same day, and 
> some of them only fix minor typos, or punctuation. That makes it hard 
> to find out what actually changed. Also, draft -04 seems to have the 
> wrong submission date.
Now we are speaking about -05 draft.
>
> 2) A URI scheme definition that cites RFC 3986 only for security 
> considerations makes me nervous. 
See section 1 - Introduction. There is not only one Sec. Cons. citing.
> For instance, it should be clear how the individual components would 
> be recognized by a generic URI parser. It appears that all you're 
> saying that the scheme-specific part maps to:
>
>   "//" authority
The scheme syntax is similar to 'telnet:'. The same recognition is intended.
>
> 3) ABNF comments
>
> 3a) What's the delimiter between password and host?
I have mentioned that it is ":".
>
> 3b) What's the [/] at the end for? Did you mean [ "/" ]?
Yes, I meant ["/"]. Would be corrected.
>
> 3c) Please avoid prose constructions; they are not sufficient to 
> actually parse the URI. So which characters are allowed in "user", 
> "password" and "host"?
There is such information is Encoding considerations template section.
>
> 4) You're not citing the URI scheme registration RFC (4395), nor have 
> the information requested in 
> <http://tools.ietf.org/html/rfc4395#section-5.4>.
Why not mentioned? See section 4 of the draft - IANA Cons. The full 
template is given.
>
> Best regards, Julian
>
All notes seem to conform -04 draft. Maybe you are looking at html 
version, which
is not formed yet. Look at plain text version.

All the best,
Mykyta Yevstifeyev

From julian.reschke@gmx.de  Sun Nov 28 03:08:34 2010
Return-Path: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ABB63A6AAD for <apps-discuss@core3.amsl.com>; Sun, 28 Nov 2010 03:08:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.464
X-Spam-Level: 
X-Spam-Status: No, score=-104.464 tagged_above=-999 required=5 tests=[AWL=-1.865, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YG9WySbwfhy for <apps-discuss@core3.amsl.com>; Sun, 28 Nov 2010 03:08:33 -0800 (PST)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id ADF743A6AAB for <apps-discuss@ietf.org>; Sun, 28 Nov 2010 03:08:32 -0800 (PST)
Received: (qmail invoked by alias); 28 Nov 2010 11:09:38 -0000
Received: from p508FBF0D.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.191.13] by mail.gmx.net (mp004) with SMTP; 28 Nov 2010 12:09:38 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19jNwUoechjf6/lwynNF6m7ZbgOhvY47qjvPtloK2 nKol1ESHS8qlV0
Message-ID: <4CF2386A.3050701@gmx.de>
Date: Sun, 28 Nov 2010 12:09:30 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
References: <201011261556.QAA29714@TR-Sys.de> <4CF229A3.40808@gmail.com> <4CF22F2B.9070906@gmx.de> <4CF23396.2040207@gmail.com>
In-Reply-To: <4CF23396.2040207@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= <ah@TR-Sys.de>, GK@ninebynine.org, uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] New version of tn3270 draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 28 Nov 2010 11:08:34 -0000

Hi Mykyta,

so indeed I managed to look at -04, and didn't notice. Apologies.

More comments inline.

On 28.11.2010 11:48, Mykyta Yevstifeyev wrote:
>> 2) A URI scheme definition that cites RFC 3986 only for security
>> considerations makes me nervous.
> See section 1 - Introduction. There is not only one Sec. Cons. citing.

OK, but that doesn't really help. I think a URI scheme registration 
should define semantics and syntax in terms of the URI spec. (I realize 
that some people may disagree).

>> For instance, it should be clear how the individual components would
>> be recognized by a generic URI parser. It appears that all you're
>> saying that the scheme-specific part maps to:
>>
>> "//" authority
> The scheme syntax is similar to 'telnet:'. The same recognition is
> intended.

Please have a look at RFC 3986 and consider just re-using the syntax 
from over there, if it matches.

>> 3) ABNF comments
>>
>> 3a) What's the delimiter between password and host?
> I have mentioned that it is ":".

You mean, you will mention it?

>> 3b) What's the [/] at the end for? Did you mean [ "/" ]?
> Yes, I meant ["/"]. Would be corrected.
>>
>> 3c) Please avoid prose constructions; they are not sufficient to
>> actually parse the URI. So which characters are allowed in "user",
>> "password" and "host"?
> There is such information is Encoding considerations template section.

Actually, that is not the case. The ABNF needs to say what the character 
repertoire for these parts is, and the prose needs to state whether 
there's an escaping mechanism that can be used to map more characters 
into this syntax.

>> 4) You're not citing the URI scheme registration RFC (4395), nor have
>> the information requested in
>> <http://tools.ietf.org/html/rfc4395#section-5.4>.
> Why not mentioned? See section 4 of the draft - IANA Cons. The full
> template is given.
>>
>> Best regards, Julian
>>
> All notes seem to conform -04 draft. Maybe you are looking at html
> version, which
> is not formed yet. Look at plain text version.

As I said, I looked at the wrong version; but as you see above, part of 
my notes apply to the current version as well.

Furthermore:

    URI scheme encoding considerations: tn3270 scheme uses UTF-8 (see RFC
    3629 [RFC3629] for details) for encoding data. No internalization is
    intended

URIs do not contain non-ASCII characters. What you *could* say is that 
if the URI is built from components that *do* allow non-ASCII 
characters, such as the username, you need to map them to octets using 
UTF-8. But then you say "no internalization is intended"? What is it? 
How does IDNA work here?

Also, in the Normative References, you may want to check whether all of 
these are normative. For instance, the "telnet" scheme is only cited in 
the security considerations section, so I don't see why it would be 
normative.

Best regards, Julian

From evnikita2@gmail.com  Sun Nov 28 03:25:47 2010
Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413013A6AAD; Sun, 28 Nov 2010 03:25:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.098
X-Spam-Level: 
X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cc5djRjriX2Q; Sun, 28 Nov 2010 03:25:39 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 7F1123A6AAC; Sun, 28 Nov 2010 03:25:38 -0800 (PST)
Received: by bwz12 with SMTP id 12so3428989bwz.31 for <multiple recipients>; Sun, 28 Nov 2010 03:26:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=u/of3GjZ6A68NGxo1QuYITzTL17qTEDFJCwoNIBYd6c=; b=aArIu6rVTFpjgQH8VY38Qf+Xa8cjCxhCYC0gtU84TWdHfDqTk5IbBf3k4h0LC6tvxx 4AuOgUot6FaHAID3eBBChfiaT5ECIz67rCLnKHXWqPEJYA7WiOLhdfp2g+Mm0D0L86LE 3KqvuCJ/Jhb4ktossTGupE3xAv+ZC4ZSyzcPw=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=L26eNrybuJgJXA6kA0fZqO3BgRcMlpnlJi10/W73ZDNzl0P9iwRhnwjAmGblHxRpbL 7jBEmKkEp8PFjtc/tlUlf8gg5FIj7VrGw2YCb/AgvGTzhHb8CYJ6Cq0PANhM1CZZzBT/ mrkMRLnW0GGQumxo+BWvKkeuCXo3EhKS+Yg0k=
Received: by 10.204.112.78 with SMTP id v14mr3688980bkp.119.1290943603595; Sun, 28 Nov 2010 03:26:43 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id v20sm1420643bku.22.2010.11.28.03.26.42 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Nov 2010 03:26:42 -0800 (PST)
Message-ID: <4CF23C78.2010204@gmail.com>
Date: Sun, 28 Nov 2010 13:26:48 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
References: <201011261556.QAA29714@TR-Sys.de> <4CF229A3.40808@gmail.com> <4CF22F2B.9070906@gmx.de> <4CF23396.2040207@gmail.com> <4CF2386A.3050701@gmx.de>
In-Reply-To: <4CF2386A.3050701@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= <ah@TR-Sys.de>, GK@ninebynine.org, uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] New version of tn3270 draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 28 Nov 2010 11:25:47 -0000

Julian,

28.11.2010 13:09, Julian Reschke wrote:
> Hi Mykyta,
>
> so indeed I managed to look at -04, and didn't notice. Apologies.
>
> More comments inline.
>
> On 28.11.2010 11:48, Mykyta Yevstifeyev wrote:
>>> 2) A URI scheme definition that cites RFC 3986 only for security
>>> considerations makes me nervous.
>> See section 1 - Introduction. There is not only one Sec. Cons. citing.
>
> OK, but that doesn't really help. I think a URI scheme registration 
> should define semantics and syntax in terms of the URI spec. (I 
> realize that some people may disagree).
>
>>> For instance, it should be clear how the individual components would
>>> be recognized by a generic URI parser. It appears that all you're
>>> saying that the scheme-specific part maps to:
>>>
>>> "//" authority
>> The scheme syntax is similar to 'telnet:'. The same recognition is
>> intended.
>
> Please have a look at RFC 3986 and consider just re-using the syntax 
> from over there, if it matches.
Yes, it is just reusing. tn3270 is telnet3270 in fact. tn stands as 
acronym for telnet.
>
>>> 3) ABNF comments
>>>
>>> 3a) What's the delimiter between password and host?
>> I have mentioned that it is ":".
>
> You mean, you will mention it?
Yes, it will be mentioned.
>
>>> 3b) What's the [/] at the end for? Did you mean [ "/" ]?
>> Yes, I meant ["/"]. Would be corrected.
>>>
>>> 3c) Please avoid prose constructions; they are not sufficient to
>>> actually parse the URI. So which characters are allowed in "user",
>>> "password" and "host"?
>> There is such information is Encoding considerations template section.
>
> Actually, that is not the case. The ABNF needs to say what the 
> character repertoire for these parts is, and the prose needs to state 
> whether there's an escaping mechanism that can be used to map more 
> characters into this syntax.
I'll put smth. like 'user = *VCHAR' there.
>
>>> 4) You're not citing the URI scheme registration RFC (4395), nor have
>>> the information requested in
>>> <http://tools.ietf.org/html/rfc4395#section-5.4>.
>> Why not mentioned? See section 4 of the draft - IANA Cons. The full
>> template is given.
>>>
>>> Best regards, Julian
>>>
>> All notes seem to conform -04 draft. Maybe you are looking at html
>> version, which
>> is not formed yet. Look at plain text version.
>
> As I said, I looked at the wrong version; but as you see above, part 
> of my notes apply to the current version as well.
>
> Furthermore:
>
>    URI scheme encoding considerations: tn3270 scheme uses UTF-8 (see RFC
>    3629 [RFC3629] for details) for encoding data. No internalization is
>    intended
>
> URIs do not contain non-ASCII characters. What you *could* say is that 
> if the URI is built from components that *do* allow non-ASCII 
> characters, such as the username, you need to map them to octets using 
> UTF-8. But then you say "no internalization is intended"? What is it? 
> How does IDNA work here?
Generally HOST is an IP address and it is will be very few
cases when THIS scheme will be used with internationalized
DNS names.
>
> Also, in the Normative References, you may want to check whether all 
> of these are normative. For instance, the "telnet" scheme is only 
> cited in the security considerations section, so I don't see why it 
> would be normative.
We import a section (or a part of a section) of telnet scheme
spec. to this document. It is Normative only.
>
> Best regards, Julian
>
All the best, Mykyta

From julian.reschke@gmx.de  Sun Nov 28 03:37:21 2010
Return-Path: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2650C3A6BC3 for <apps-discuss@core3.amsl.com>; Sun, 28 Nov 2010 03:37:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.34
X-Spam-Level: 
X-Spam-Status: No, score=-104.34 tagged_above=-999 required=5 tests=[AWL=-1.741, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7mWsBDaegLI for <apps-discuss@core3.amsl.com>; Sun, 28 Nov 2010 03:37:19 -0800 (PST)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 0E6423A6AF1 for <apps-discuss@ietf.org>; Sun, 28 Nov 2010 03:37:18 -0800 (PST)
Received: (qmail invoked by alias); 28 Nov 2010 11:38:24 -0000
Received: from p508FBF0D.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.191.13] by mail.gmx.net (mp008) with SMTP; 28 Nov 2010 12:38:24 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18ia1YYzxQiz+qwDgZabI8mlXLtItSega2Ltd0FxI IKzEwWvTnPcKwq
Message-ID: <4CF23F2D.5090001@gmx.de>
Date: Sun, 28 Nov 2010 12:38:21 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
References: <201011261556.QAA29714@TR-Sys.de> <4CF229A3.40808@gmail.com> <4CF22F2B.9070906@gmx.de> <4CF23396.2040207@gmail.com> <4CF2386A.3050701@gmx.de> <4CF23C78.2010204@gmail.com>
In-Reply-To: <4CF23C78.2010204@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= <ah@TR-Sys.de>, GK@ninebynine.org, uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] New version of tn3270 draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 28 Nov 2010 11:37:21 -0000

On 28.11.2010 12:26, Mykyta Yevstifeyev wrote:
> ...
>> Please have a look at RFC 3986 and consider just re-using the syntax
>> from over there, if it matches.
> Yes, it is just reusing. tn3270 is telnet3270 in fact. tn stands as
> acronym for telnet.
> ...

That doesn't seem to be a reply to what I said.

> ...
>> Actually, that is not the case. The ABNF needs to say what the
>> character repertoire for these parts is, and the prose needs to state
>> whether there's an escaping mechanism that can be used to map more
>> characters into this syntax.
> I'll put smth. like 'user = *VCHAR' there.

That would make the ABNF ambiguous. You need to exclude certain 
characters so that the other components can be detected. Again, by any 
means, have a look at RFC 3986.

> ...
>> Furthermore:
>>
>> URI scheme encoding considerations: tn3270 scheme uses UTF-8 (see RFC
>> 3629 [RFC3629] for details) for encoding data. No internalization is
>> intended
>>
>> URIs do not contain non-ASCII characters. What you *could* say is that
>> if the URI is built from components that *do* allow non-ASCII
>> characters, such as the username, you need to map them to octets using
>> UTF-8. But then you say "no internalization is intended"? What is it?
>> How does IDNA work here?
> Generally HOST is an IP address and it is will be very few
> cases when THIS scheme will be used with internationalized
> DNS names.

OK, in that case you should say that non-ASCII characters in the host 
name component should be treated as per the IRI spec, Section xyz.

>> Also, in the Normative References, you may want to check whether all
>> of these are normative. For instance, the "telnet" scheme is only
>> cited in the security considerations section, so I don't see why it
>> would be normative.
> We import a section (or a part of a section) of telnet scheme
> spec. to this document. It is Normative only.

OK, let's agree to disagree on this one :-).

Best regards, Julian

From GK@NineByNine.net  Thu Nov 25 10:20:26 2010
Return-Path: <GK@NineByNine.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A8F3A6A4A; Thu, 25 Nov 2010 10:20:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPi3biYuNjiA; Thu, 25 Nov 2010 10:20:25 -0800 (PST)
Received: from relay1.mail.ox.ac.uk (relay1.mail.ox.ac.uk [129.67.1.165]) by core3.amsl.com (Postfix) with ESMTP id CB57A3A6A7B; Thu, 25 Nov 2010 10:20:24 -0800 (PST)
Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay1.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from <GK@NineByNine.net>) id 1PLgRh-0004WZ-5w; Thu, 25 Nov 2010 18:21:25 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK@NineByNine.net>) id 1PLgRh-0001EQ-20; Thu, 25 Nov 2010 18:21:25 +0000
Message-ID: <4CEEA4C0.50302@NineByNine.net>
Date: Thu, 25 Nov 2010 18:02:40 +0000
From: Graham Klyne <GK@NineByNine.net>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
References: <4CEE8263.9030303@gmail.com>
In-Reply-To: <4CEE8263.9030303@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
X-Mailman-Approved-At: Sun, 28 Nov 2010 10:29:08 -0800
Cc: uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] tn3270 URI scheme formal specification
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 26 Nov 2010 10:45:16 -0000

Mykyta Yevstifeyev wrote:
>    Hello all,
> 
> There has been a discussion about tn3270 URI scheme
> on the lists recently. The consensus was that we need
> a formal specification of the scheme. I've made an I-D
> on this topic - you are able to find it here:
> 
> https://datatracker.ietf.org/doc/draft-yevstifeyev-tn3270-uri/
> 
> Feedbacks and suggestions are welcome.

I think this is a most constructive move to resolve the running debate.  Kudos:)

My main motivation in reviewing this is to offer a view of how it might meet the 
registration criteria (but this is not a formal review for that purpose).  I 
know nothing about the tn3270 scheme, and do not comment on the technical content.

I don't feel strongly about this, but the title might usefully be
   "Reclassification of the tn3270 URI scheme as <foo>"
(for some value of "<foo>" - see below).

--------
1. Introduction

    The tn3270 URI scheme was firstly mentioned in RFC 1738 [RFC1738] in
    order to be registered as 'Provisional' URI scheme. However there are
    no acceptable and clear specifications so far.
----

I'd argue with "in order to be registered".  As someone noted, RFC1738 rather 
pre-dates the URI registries :).  Suggest:
[[
The tn3270 URI scheme was first mentioned in RFC 1738 [RFC1738].  Following the 
creation of the URI scheme registries per RFC4395, it was added to the 
"provisional" registry. However there are no clear specifications so far for 
this scheme.
]]
----

[...]

--------
4. IANA Considerations

    IANA is asked to move the tn3270 URI scheme registration from
    'Provisional' to 'Permanent'.
----

In my view, it would take a lot more than this document to justify moving the 
scheme to the 'permanent' registry - that would imply that there is widespread 
active and ongoing interest in actually using the scheme.  As reviewer, I'd be 
looking for some evidence of this.

On the other hand, if the request were to reclassify the scheme as 'historic', 
I'd have fewer such concerns.

--------
5. Normative References

    [RFC1738]   Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
                Resource Locators (URL)", RFC 1738, December 1994.
----

I think some more refs would be appropriate:

RFC 5234 [RFC5234]

Some documents (any documents) describing Telnet and the 3270 emulation framework.

RFC3986, probably (the syntax needs to be consistent with the syntax given there)

http://www.rfc-editor.org/rfc/rfc4395.txt, since this is based on the registries 
defined there.

#g
--


From evnikita2@gmail.com  Mon Nov 29 06:41:05 2010
Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F148A28C15B; Mon, 29 Nov 2010 06:41:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level: 
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=-1.455, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTSFFMk0Lzx1; Mon, 29 Nov 2010 06:40:58 -0800 (PST)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 558EE3A6BC1; Mon, 29 Nov 2010 06:40:56 -0800 (PST)
Received: by gwj17 with SMTP id 17so2330178gwj.31 for <multiple recipients>; Mon, 29 Nov 2010 06:42:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=kQw+bBDh8cCVhFFJOqZVszS/cChwUl5MOa5jE6voYZY=; b=CJo7YvUpnUJq3reayzdU2zezyscnX0nduCGrPdvzi3MHJHMXuZ354eUnPSC+v96PbR UroWA/y3gAae7v+6cJDjshlXINIyWhxVdFTny1J6k1ta3LDKMn28lcKUi1WNqYyyaCof bk4+tWAdtb39tJesILWoKCJ2+ojZPQGImN/vU=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=RW6p06flRQz0dxcBK5bvulEJVSR5g5nCNYm4Mj3tmw9YES6sqfWV+IfMugJZ/24BO0 BSb2TMlfypb+qf8OLXraoqfG+9mzEWGdTnrcTwioX7vB1EWmo96jH/3IgdrYFBE/h/pF wlhwW9Iv0TxL0Qn2BuT8U3sqGIERQ3L0k/Oxw=
Received: by 10.204.113.142 with SMTP id a14mr4847674bkq.206.1291041721472; Mon, 29 Nov 2010 06:42:01 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id v25sm2070921bkt.18.2010.11.29.06.41.59 (version=SSLv3 cipher=RC4-MD5); Mon, 29 Nov 2010 06:42:00 -0800 (PST)
Message-ID: <4CF3BBBE.9000209@gmail.com>
Date: Mon, 29 Nov 2010 16:42:06 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
References: <201011261556.QAA29714@TR-Sys.de> <4CF229A3.40808@gmail.com> <4CF22F2B.9070906@gmx.de> <4CF23396.2040207@gmail.com> <4CF2386A.3050701@gmx.de> <4CF23C78.2010204@gmail.com> <4CF23F2D.5090001@gmx.de>
In-Reply-To: <4CF23F2D.5090001@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Michael.Wojcik@microfocus.com, =?UTF-8?B?QWxmcmVkIO+/vQ==?= <ah@TR-Sys.de>, GK@ninebynine.org, uri-review@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [Uri-review] New version of tn3270 draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 29 Nov 2010 14:41:07 -0000

Hello all,

A new version of the tn3270 draft is available (-06). This
version took into account many Julian's proposals (see
below). Among other:

-ABNF for the scheme was updated,
-References were divided into Norm. and Inf.
-other minor changes.

The link:

http://www.ietf.org/id/draft-yevstifeyev-tn3270-uri-06.txt

Any suggestions and comments are welcome.

All the best,
Mykyta Yevstifeyev

28.11.2010 13:38, Julian Reschke wrote:
> On 28.11.2010 12:26, Mykyta Yevstifeyev wrote:
>> ...
>>> Please have a look at RFC 3986 and consider just re-using the syntax
>>> from over there, if it matches.
>> Yes, it is just reusing. tn3270 is telnet3270 in fact. tn stands as
>> acronym for telnet.
>> ...
>
> That doesn't seem to be a reply to what I said.
>
>> ...
>>> Actually, that is not the case. The ABNF needs to say what the
>>> character repertoire for these parts is, and the prose needs to state
>>> whether there's an escaping mechanism that can be used to map more
>>> characters into this syntax.
>> I'll put smth. like 'user = *VCHAR' there.
>
> That would make the ABNF ambiguous. You need to exclude certain 
> characters so that the other components can be detected. Again, by any 
> means, have a look at RFC 3986.
>
>> ...
>>> Furthermore:
>>>
>>> URI scheme encoding considerations: tn3270 scheme uses UTF-8 (see RFC
>>> 3629 [RFC3629] for details) for encoding data. No internalization is
>>> intended
>>>
>>> URIs do not contain non-ASCII characters. What you *could* say is that
>>> if the URI is built from components that *do* allow non-ASCII
>>> characters, such as the username, you need to map them to octets using
>>> UTF-8. But then you say "no internalization is intended"? What is it?
>>> How does IDNA work here?
>> Generally HOST is an IP address and it is will be very few
>> cases when THIS scheme will be used with internationalized
>> DNS names.
>
> OK, in that case you should say that non-ASCII characters in the host 
> name component should be treated as per the IRI spec, Section xyz.
>
>>> Also, in the Normative References, you may want to check whether all
>>> of these are normative. For instance, the "telnet" scheme is only
>>> cited in the security considerations section, so I don't see why it
>>> would be normative.
>> We import a section (or a part of a section) of telnet scheme
>> spec. to this document. It is Normative only.
>
> OK, let's agree to disagree on this one :-).
>
> Best regards, Julian
>


From ted.ietf@gmail.com  Tue Nov 30 14:10:14 2010
Return-Path: <ted.ietf@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67253A6C8E; Tue, 30 Nov 2010 14:10:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.142
X-Spam-Level: 
X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, J_CHICKENPOX_83=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fT29UaB27wv; Tue, 30 Nov 2010 14:10:13 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 64A843A6C43; Tue, 30 Nov 2010 14:10:13 -0800 (PST)
Received: by qwg5 with SMTP id 5so5187279qwg.31 for <multiple recipients>; Tue, 30 Nov 2010 14:11:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=7lzQ5XeeMoRAALJBRwoaLX3DYpQHzParIhus88oZHxY=; b=MzjTNh2nhqZACMB/eSdiHqS7XcVDACxPPR37ZB4lrvt+P1jYLYblSu9x6Glcbk5ytc of7S6J1BTe8XpIxroZOkgz44u8oYZO+pFCfTxTDxNR4JMvgMr0PN8WCinwIeEqBKweym eONp4KR9nUNeRXh8rgFYHhPLkNeqj/VK07FLk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=n0XtXGapeiJbABMdRa2oH5z+ONjPwuy3pksZUUFtjEaoM7lrS8s98tOk15CA+tafoy g7F4W1uyBLhhMaJ0e6dsXmcUXaavpVjoKDJa3DMgexup7vJnPuJwhv0PkRsG0Bxwqe9Q NB2PjiK3Unp0XSQ7Kw7AxIpee6YpCyhhbGVQI=
MIME-Version: 1.0
Received: by 10.229.214.73 with SMTP id gz9mr6585592qcb.226.1291155085168; Tue, 30 Nov 2010 14:11:25 -0800 (PST)
Received: by 10.229.222.80 with HTTP; Tue, 30 Nov 2010 14:11:25 -0800 (PST)
Date: Tue, 30 Nov 2010 14:11:25 -0800
Message-ID: <AANLkTi=pF9d0z3vQYAq+mPrpSiDK9OZzVPkE84W+-qGp@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Apps Discuss <discuss@ietf.org>, adam@nostrum.com,  Bernard Aboba <bernard_aboba@hotmail.com>, Spencer Dawkins <spencer@wonderhamster.org>, IESG <iesg@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] Apps Area Review team review: draft-ietf-martini-gin-10.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 30 Nov 2010 22:10:14 -0000

I have been selected as the Applications Area Review Team reviewer for
this draft
(for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).
Please resolve these comments along with any other Last Call comments
you may receive.
Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-ietf-martini-gin-10.txt
Title: Registration for Multiple Phone Numbers in the Session
Initiation Protocol (SIP)
Reviewer:Ted Hardie
Review Date: November 30, 2010

Summary: This draft is ready for publication as a proposed standard,
with a few editorial issues
which the author or working group may wish to consider.

Major Issues: None identified.

Minor Issues:

In the "Constraints" section, the document notes:

  The following paragraph is perhaps the most important in
   understanding the reasons for the design decisions made in this
   document.

   Within the problem space that has been established for this work,
   several constraints shape our solution.  These are defined in the
   MARTINI requirements document [18].  In terms of impact to the
   solution at hand, the following two constraints have the most
   profound effect: (1) The SIP-PBX cannot be assumed to be assigned a
   static IP address; and (2) No DNS entry can be relied upon to
   consistently resolve to the IP address of the SIP-PBX.

I suggest augmenting the pointer to the requirements document
here with a pointer to Appendix A, which helpfully lists how
the document meets the requirements (note however that the
Appendix apparently elides requirements 18, 19, and 20 without
comment).  Given the existence of appendix A, I am not personally
certain I see the need for the first of the two paragraphs.

In section 5.1, the document says:

  The "bnc" URI parameter indicates that special interpretation of the
   Contact URI is necessary: instead of representing a single, concrete
   Contact URI to be inserted into the location service, it represents
   multiple URIs (one for each associated AOR), semantically resulting
   in multiple AOR-to-Contact rows in the location service.

Saying that the URI parameter represents multiple URIs will bend
the brain of URI folks a bit, and the later text in 5.2 avoids this
same issue:

   After the SIP-PBX is authenticated, the registrar
   updates its location service with a unique AOR-to-Contact mapping for
   each of the AORs associated with the SIP-PBX.  Semantically, each of
   these mappings will be treated as a unique row in the location
   service.  The actual implementation may, of course, perform internal
   optimizations to reduce the amount of memory used to store such
   information.

I suggest using similar language for the 5.1 text, for example:

  The "bnc" URI parameter indicates that special interpretation of the
   Contact URI is necessary: instead of indicating the insertion of a single
   Contact URI into the location service, it indicates that
   multiple URIs (one for each associated AOR) should be inserted.

Section 7.4 contains two elements which it may be appropriate to consider
for inclusion in the Security Considerations.  The first of these is that
proxies will not be able to apply policy decisions on as granular a basis as
before:

   Proxies will be unable to make policy decisions on a
   contact-by-contact basis regarding whether to include themselves in
   the path.  Second, and similarly, all AORs on the SIP-PBX that are
   registered with a common REGISTER request will be forced to share a
   common Service-Route.

Would this extend to proxies including themselves for the purposes of
CALEA?  If so, this might be a privacy issue.  Similarly,  this text:

   This token or cookie may convey information
   to proxies about the identity, capabilities, and/or policies
   associated with the user.  Since this information will be shared
   among several AORs and several Contacts when multiple AOR
   registration is employed, care should be taken to ensure that doing
   so is acceptable for all AORs and all Contacts registered in a single
   REGISTER request.

might properly be considered in the privacy portion of a Security
Considerations section.  Back pointers to one or both sections may
be appropriate if the author or WG concur.

In the IANA registrations, IANA lists RFC 5727 as a governing
document along with the ones listed by this draft; including it
and a reference may be appropriate.

From duerst@it.aoyama.ac.jp  Tue Nov 30 17:50:04 2010
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157EC3A6CC5 for <apps-discuss@core3.amsl.com>; Tue, 30 Nov 2010 17:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.242
X-Spam-Level: 
X-Spam-Status: No, score=-100.242 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pywXdRheJ1Mn for <apps-discuss@core3.amsl.com>; Tue, 30 Nov 2010 17:50:03 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by core3.amsl.com (Postfix) with ESMTP id DCC703A6C97 for <apps-discuss@ietf.org>; Tue, 30 Nov 2010 17:50:02 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id oB11pAj8001454 for <apps-discuss@ietf.org>; Wed, 1 Dec 2010 10:51:10 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5b78_1d0e_78a9ef40_fced_11df_9e0b_001d096c5782; Wed, 01 Dec 2010 10:51:10 +0900
Received: from [IPv6:::1] ([133.2.210.1]:34817) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S1495549> for <apps-discuss@ietf.org> from <duerst@it.aoyama.ac.jp>; Wed, 1 Dec 2010 10:51:09 +0900
Message-ID: <4CF5AA06.3090405@it.aoyama.ac.jp>
Date: Wed, 01 Dec 2010 10:51:02 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: draft-ietf-geopriv-policy@tools.ietf.org, Internet Engineering Steering Group <iesg@ietf.org>
Subject: [apps-discuss] Resend: Apps-team review of draft-ietf-geopriv-policy-21
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 01 Dec 2010 01:50:04 -0000

My review of draft-ietf-geopriv-policy-21 (see below for pointer) at the 
end of September went out without problems, but I haven't heard back 
from the authors.

SM, who leads the Apps Review Team, has asked me to send a pointer, and 
to cc the IESG.

Regards,    Martin.

-------- Original Message --------
Subject: Apps-team review of	draft-ietf-geopriv-policy-21
Date: Wed, 29 Sep 2010 18:53:20 +0900
From: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
To: draft-ietf-geopriv-policy@tools.ietf.org
CC: apps-discuss@ietf.org <apps-discuss@ietf.org>

Rest at:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01813.html

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp