From laurentwalter.goix@telecomitalia.it Fri Jun 1 02:39:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A581C21F8534 for ; Fri, 1 Jun 2012 02:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.229 X-Spam-Level: X-Spam-Status: No, score=-0.229 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMPr3vCJDohg for ; Fri, 1 Jun 2012 02:39:41 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id BFAA521F8667 for ; Fri, 1 Jun 2012 02:39:39 -0700 (PDT) Content-Type: multipart/mixed; boundary="_dae2108b-ce87-400e-883d-af3c25b1ad62_" Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Fri, 1 Jun 2012 11:39:38 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Fri, 1 Jun 2012 11:39:37 +0200 From: Goix Laurent Walter To: "apps-discuss@ietf.org" Date: Fri, 1 Jun 2012 11:39:36 +0200 Thread-Topic: [WF/SWD] about variable names in templates Thread-Index: Ac0/2nUx7FONk2rQSq2Bmg0Mwj7Y6A== Message-ID: Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Subject: [apps-discuss] [WF/SWD] about variable names in templates X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 09:39:43 -0000 --_dae2108b-ce87-400e-883d-af3c25b1ad62_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE530CE26BB5GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE530CE26BB5GRFMBX704BA02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I'd like to discuss the introduction of a new variable name to be defined i= n WF/SWD beyond the {uri} variable defined in RFC6415, in relation to the u= se of templates in xrd/jrd descriptors. This variable name should capture t= he username part only for more flexibility. This is based on implementation experience for social network federation (i= e server to server discovery) where large provider islands need perform dis= covery on many users of remote islands to discover some endpoints. Currently in various implementations a first host-meta call is issued to di= scover the lrdd template, followed by the actual lrdd query for a specific = resource. The host-meta of that domain is typically cached to save a call f= or the next user discovery, but a lrdd query is sent each time for a new us= er (the response for the specific resource can be cached to limit queries). On the other hand most of the endpoints discovered through lrdd queries for= different resources on the same domain share the same pattern. The host-meta can typically already contain a number of templates (right no= w lrdd is clearly the most popular), but lrdd typically contains actual uri= s. It would be useful (up to the service provider policy of course) to info= rm the "client" (in this case the querying server) that a specific endpoint= uri actually follows a pattern that can be used for any user of that domai= n (whenever applicable of course). This could be already achieved for example by exposing such endpoints alrea= dy in the host-meta using templates. However currently the only template variable name defined is "{uri}", which= gives very little flexibility to servers to create patterns. I'd like to g= et your feedback on the introduction in the WF draft of a new variable name= related to the userpart only (eg. for "acct:joe@example.com", the userpart= is "joe"). This could be "{uri.userpart}" or "{username}" etc and would e= nable to express templates like: The client would thus know that this template is generalizable for other us= ers. In case the single href is provided, the client would not know (and ma= y not assume) that the actual url is built according to a specific pattern. Walter Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non ? necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE530CE26BB5GRFMBX704BA02_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I’d like to discuss the i= ntroduction of a new variable name to be defined in WF/SWD beyond the {uri}= variable defined in RFC6415, in relation to the use of templates in xrd/jr= d descriptors. This variable name should capture the username part only for more flexibility.

 

This is based on implementation= experience for social network federation (ie server to server discovery) w= here large provider islands need perform discovery on many users of remote = islands to discover some endpoints.

 

Currently in various implementa= tions a first host-meta call is issued to discover the lrdd template, follo= wed by the actual lrdd query for a specific resource. The host-meta of that= domain is typically cached to save a call for the next user discovery, but a lrdd query is sent each time for= a new user (the response for the specific resource can be cached to limit = queries).

On the other hand most of the e= ndpoints discovered through lrdd queries for different resources on the sam= e domain share the same pattern.

 

The host-meta can typically alr= eady contain a number of templates (right now lrdd is clearly the most popu= lar), but lrdd typically contains actual uris. It would be useful (up to th= e service provider policy of course) to inform the “client” (in this case the querying server) that= a specific endpoint uri actually follows a pattern that can be used for an= y user of that domain (whenever applicable of course).

This could be already achieved = for example by exposing such endpoints already in the host-meta using templ= ates.

 

However currently the only temp= late variable name defined is “{uri}”, which gives very little = flexibility to servers to create patterns. I’d like to get your feedb= ack on the introduction in the WF draft of a new variable name related to the userpart only (eg. for “acct:joe@example.comR= 21;, the userpart is “joe”). This could be “{uri.userpart= }” or “{username}” etc  and would enable to express = templates like:

 

<Link rel=3D'http://schemas.= google.com/g/2010#updates-from'

     &= nbsp;    template=3D'http://example.com/activities/{uri.user= part}'

     &= nbsp;    type=3D'application/atom+xml'/>

<Link rel=3D'http://portable= contacts.net/spec/1.0#me'

     &= nbsp;    template=3D 'http://example.com/api/people/{uri.use= rpart}'/>

 

The client would thus know that= this template is generalizable for other users. In case the single href is= provided, the client would not know (and may not assume) that the actual u= rl is built according to a specific pattern.

 

Walter

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

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

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

--_000_A09A9E0A4B9C654E8672D1DC003633AE530CE26BB5GRFMBX704BA02_-- --_dae2108b-ce87-400e-883d-af3c25b1ad62_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_dae2108b-ce87-400e-883d-af3c25b1ad62_-- From alexey.melnikov@isode.com Fri Jun 1 06:23:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2BC11E8106; Fri, 1 Jun 2012 06:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.914 X-Spam-Level: X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iE5m5Hkq0pz9; Fri, 1 Jun 2012 06:23:28 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 64E3611E8089; Fri, 1 Jun 2012 06:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338557006; d=isode.com; s=selector; i=@isode.com; bh=vkPlyMXzLw7INl3frsCgq7Br3GPg7TwWqXST2FrLFrM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=cu8/o9ICH80O8XfISOdofoG2l07qMqETXALW5GExmPfxfv6aBDRRNxEJUYwphn5jET2JfZ 9zagv6Zzj1lrsA9BOh0kaD+zFt1gpBqe5L+oYMKeSQmPDgFZmXRV7sr2F423NBl92cnVYI AtCOZj+0l+c8xS0Ga+qn8cNKjz4gA2w=; Received: from [192.168.1.144] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 1 Jun 2012 14:23:25 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING Message-ID: <4FC89931.5060201@isode.com> Date: Fri, 01 Jun 2012 11:28:01 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: dcrocker@bbiw.net References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> In-Reply-To: <4FC722A2.2050905@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 13:23:30 -0000 On 31/05/2012 08:49, Dave Crocker wrote: > This review is at my own initiative. Dave, Thank you for the review. I've applied most of your editorial changes (and spelling fixes) as is. I've deleted them from my reply. I will reply to different parts of your review in separate messages. >> 2. Conventions Used in This Document >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in [RFC2119] when they >> appear in ALL CAPS. These words also appear in this document in >> lower case as plain English words, absent their normative meanings. > > "when they appear in ALL CAPS". sigh. In other words, this document > is modifying RFC2119. > > Does anyone seriously expect this new nuance of usage to be read and > remembered by average readers of this document? > FWIW, it took me about 3 minutes to make the relevant changes, below. > Case-sensitivity in semantics invites comprehension problems here. > Worse, there is absolutely no need or benefit in creating the problem > for this document. At a minimum, please do not try to modify IETF > document writing policy on the fly. I will let IESG weight in on this. I've implemented what I was told earlier. I don't have a strong opinion on this. >> 4.1. Handling of the MT-PRIORITY parameter by the receiving SMTP server >> >> The following rules apply to SMTP transactions in a server that >> supports the MT-PRIORITY parameter: >> >> 1. A conforming SMTP server MUST NOT refuse a MAIL FROM command >> based on the absence of the MT-PRIORITY parameter. > > > hmmm. For some operational environments, it will be essential to > have /all/ handling conform to the priority policy model in force for > the environment. In those cases, the absence of the parameter would > be a violation of the spec. Good point. Deleted. >> >> 5. If no priority has been determined by the above, the server may >> use its normal policies to set the message's priority. By >> default, each message has priority 0. > > ouch. This chooses a particular model for meaning of the numbers, and > without having defined the model beforehand. > > That is, I think the problem with this default is that it really is > assuming a particular policy for meaning of the values, namely that > average mail is mid-priority, assuming the numbers have linear semantics. Why is this a problem (commenting on the last sentence quoted above)? >> however, allow an untrusted source to lower its own message's >> priorities -- consider, for example, an email marketer that >> voluntarily sends its marketing messages at low priority. > > To beat the point a bit deader: this assumes a particular policy for > the meaning of the priority values. Worse, it also appears to > contradict the earlier default of 0, but perhaps I've misunderstood that. Yes, you misunderstood. The example talking about marketing messages is an example of a sender that explicitly requests priority below 0. >> 450 or 550 reply code. The corresponding enhanced status code MUST >> be X.7.TBD1 [RFC2034] if the determined priority level is below the >> lowest priority currently acceptable for the receiving SMTP server. >> Note that this condition might be temporary, in cases where the >> server is temporarily operating in a mode where only high priority >> messages are accepted for transfer and delivery. > > Given a range of 0-9, what qualifies as high priority and what > qualifies as low? > > Perhaps: > > Note that this condition might be temporary. In some environments, > operational policies might permit periods of operation that relay only > higher priority messages and defer lower priority ones. Such handling > choices need to be specified for that operational environment.. Ok. I used a slightly modified version of your suggested text. >> 4.4. Mailing lists and Aliases >> >> Several options exist to translate the address of an email recipient > > "options"? Perhaps you mean mechanisms or services? Yes. > And they really aren't translating an address but are doing a form of > message transmission (relaying, or the like). Suggested replacement? >> into one or more other addresses. Examples for this are aliases and >> mailing lists [RFC5321]. >> >> If a recipient address is to be translated and/or expanded when >> delivered to an alias or a mailing list, the translating or expanding >> entity (MTA, etc.) SHOULD retain the MT-PRIORITY parameter value for >> all expanded and/or translated addresses. > > This appears to expect the extension's semantics to survive delivery > and re-posting via a mailing list. Remember that a mailing list posts > a /new/ message. Offhand, this requirement seems to go considerably > beyond normal SMTP options and beyond most Internet Mail standards > services... This is the same as for the DSN SMTP extension. So no, this is not the first time. > > At the least, this needs considerably more extensive and careful > documentation that it is given here. > > >> 4.5. Gatewaying a message into a foreign environment >> >> The following rules govern the behavior of a conforming MTA, when >> gatewaying a message that was received via the SMTP protocol, into a >> foreign (non-SMTP) environment: >> >> 1. If the destination environment is unable to provide an equivalent >> of the MT-PRIORITY parameter, the conforming MTA SHOULD behave as >> if it is relaying to a non-conformant SMTP server (Section 4.3). > > Given the variable semantics that apply here -- per the different > policy possibilities -- what does it mean to be an equivalent of the > MT-PRIORITY parameter, in specific technical terms? The point is that if I am trying to gateway to the Royal Pigeon Mail Service and it doesn't support anything similar to priorities at the protocol level, then this is treated as relaying to a non-conformant SMTP server. >> 2. If the destination environment is capable of providing an >> equivalent of the MT-PRIORITY parameter, the conforming MTA >> SHOULD behave as if it is relaying to a conformant SMTP server >> (Section 4.2), converting the MT-PRIORITY value to the equivalent >> in the destination environment. > > Is this really enough technical and operational detail to cover > gatewaying? Perhaps it is, but it feels to me as if it isn't. Then > again, I don't know what more/else to suggest. I don't know either :-). >> 4.6. Interaction with DSN SMTP Extension >> >> An MTA which also conforms to [RFC3461] SHOULD apply the same >> priority value to delivery reports (whether for successful delivery >> or failed delivery) it generates for a message. > > In many operational environments, control messages get higher priority > (or lower priority) than payload messages. What is a control message? Any suggested text? >> Note that rejections based on priority (see Section 4.1) or priority+ >> message size combination SHOULD only be done by an MSA (i.e. they >> SHOULD NOT be done by MTAs/MDAs), because the MSA has a link to the > > This presumes that an MSA knows the priority-related policies of > downstream MTAs and MDAs. I don't think so. Why do you say that? >> Mail User Agents (MUAs) which generated the message and is in a >> position to perform a corrective action, such as resubmission of the > > resubmission with lower priority is a big deal but seems to get a > rather casual reference here. > > >> message with lower priority, converting or truncating the message to >> make it smaller, etc. Such actions usually require user interaction. >> For this reason it is also important for MUAs to support enhanced >> >> > >> with a lower one. Additionally, the retry interval and/or default >> timeout before non-delivery report is generated can be lower (more >> aggressive) for messages of higher priority. > > oh? "can be"? Should have been "MAY be". > This sort of language looks like it is specifying something but it > isn't. And the reference to what "can be" carries no cautions or > directions meaningful to implementers. > > >> Note that as this SMTP extension requires some sort of trust >> relationship between a sender and a receiver and thus some for of > > for -> form (?) Yes. > This is treated as a side comment (by introducing it with "Note") but > I believe it is in fact a core predicate for the extension. > > >> authentication (whether using SMTP AUTH, TLS, IP address whitelist, >> etc.), so senders using this SMTP extension will not be subject to >> greylisting [GREYLISTING], unless they are unauthorized to use this >> SMTP extension, due to an explicit policy decision or a >> misconfiguration error. >> >> In order to make implementations of this extension easier, this SMTP >> extension only allows a single priority for all recipients of the >> same message. > > This is quite a good and clear simplification point. However note > that a model which permits selective support of priority values winds > up going counter to that goal of simplification. Well, simplification doesn't apply to everything in this extension. Some tradeoffs were made.... >> >> 5.2. Timely Delivery >> >> An important constraint (usually associated with higher priority >> levels) is that messages with high priority have some delivery time >> constraints. In some cases, higher priorities mean a shorter maximum >> time allowed for delivery. >> >> Unextended SMTP does not offer a service for timely delivery. The >> "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in >> [RFC2852] is an example of an SMTP extension providing a service that >> can be used to implement such constraints. But note that use of the >> DELIVERBY extension alone does not guarantee any priority processing. > > It seems as if this section introduces an issue but does not actually > deal with it. Perhaps there should be some discussion of the possible > (or required?) interaction between the two extensions it discusses? There is no issue and no real interaction in this specific case. A client that wants to use both against a server that supports both should consider this issue. >> 8. Deployment Considerations >> >> If multiple DNS MX records are used to specify multiple servers for a >> domain in section 5 of [RFC5321], it is strongly advised that all of > > "strongly advised"? > > This seems the sort of thing that needs normative language yet it is > carefully avoided. That is, by saying 'strongly' the issue is moved > towards the asking why it is not stated normatively. I'd guess this > needs a SHOULD, possibly with discussion of permissible exceptions > (such as the open Internet...?) This section applies to system administrators. It is quite different from the rest of the document which contains mostly protocol level requirements. So yes, I avoided usage of RFC 2119 keywords here on purpose. Suggestions for alternatives are welcomed. > However note that the 'strongly advised' presumes instantaneous > implementation on all hosts within the trust environment. > Since that isn't possible, it's not clear how the advice of this > section is practical. Nothing is instantaneous, so I am not very concerned ;-). Once some servers start supporting this extension a sysadmin can remove MXes for servers which don't support it. Upgrading all servers nearly simultaneously is another option. >> 10. Security Considerations >> >> Message Submission Agents MUST implement a policy that only allows >> authenticated users (or only certain groups of authenticated users) >> to specify message transfer priorities, and MAY restrict maximum >> priority values different groups of users can request, or MAY >> override the priority values specified by MUAs. > > Presumably the normative MSA language is meant "for those MSAs > supporting this extension"? Of course. I don't think this needs saying. From fanf2@hermes.cam.ac.uk Fri Jun 1 09:47:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EC511E80E0; Fri, 1 Jun 2012 09:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZdd8bcbgFVL; Fri, 1 Jun 2012 09:47:52 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 03C1911E80D2; Fri, 1 Jun 2012 09:47:52 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:58622) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SaV0w-0006oO-T0 (Exim 4.72) (return-path ); Fri, 01 Jun 2012 17:47:51 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SaV0w-00087s-VP (Exim 4.67) (return-path ); Fri, 01 Jun 2012 17:47:50 +0100 Date: Fri, 1 Jun 2012 17:47:50 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: apps-discuss@ietf.org, dane@ietf.org Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [apps-discuss] DANE for MUAs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 16:47:53 -0000 I've started a draft for using DANE with IMAP, POP3, and message submission, but I've got a bit stuck deciding how to fit in with RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). RFC 6125 has the following example: A mail user agent that is connecting via IMAPS to the email service at "example.net" (resolved as "mail.example.net") might have five reference identifiers: an SRV-ID of "_imaps.example.net" (see [EMAIL-SRV]), DNS-IDs of "example.net" and "mail.example.net", and, as a fallback, CN-IDs of "example.net" and "mail.example.net". (A legacy email user agent would not support [EMAIL-SRV] and therefore would probably be explicitly configured to connect to "mail.example.net", whereas an SRV-aware user agent would derive "example.net" from an email address of the form "user@example.net" but might also accept "mail.example.net" as the DNS domain name portion of reference identifiers for the service.) I presume that the client would not actually use mail.example.net as a reference identifier unless DNSSEC is in use, otherwise that would not be secure and is therefore forbidden according to the rules a few paragraphs earlier in RFC 6125. There's also a question about how SNI fits in. RFC 6066 says that it only supports DNS host names, which I take to mean SRV targets not SRV names. RFC 6186 encourages the use of SNI but says nothing about which identity should be used. So I'm inclined to state that the server should have a certificate containing both the SRV name and target as DNS-IDs and offer that certificate if it is given either identity in an SNI. This is so that the server can support new-style clients (supporing DANE and SRV and using the SRV name as the identity) as well as old-style clients (using address records directly and the server host name for the TLS identity). I'll mention the SRV-ID for form's sake but as far as I can tell it's a fantasy that doesn't exist in the real world. Tony. -- f.anthony.n.finch http://dotat.at/ Dogger: Northwesterly 4 or 5, occasionally 6 in east. Moderate. Showers later. Good. From cyrus@daboo.name Fri Jun 1 09:55:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F7421F889A; Fri, 1 Jun 2012 09:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLeBZmxzicmn; Fri, 1 Jun 2012 09:55:27 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id C862721F8899; Fri, 1 Jun 2012 09:55:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 2E8952855C34; Fri, 1 Jun 2012 12:55:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOh1lwOdnNQd; Fri, 1 Jun 2012 12:55:26 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id AE30D2855C29; Fri, 1 Jun 2012 12:55:24 -0400 (EDT) Date: Fri, 01 Jun 2012 12:55:21 -0400 From: Cyrus Daboo To: Tony Finch , apps-discuss@ietf.org, dane@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=489 Subject: Re: [apps-discuss] DANE for MUAs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 16:55:28 -0000 Hi Tony, --On June 1, 2012 5:47:50 PM +0100 Tony Finch wrote: > I've started a draft for using DANE with IMAP, POP3, and message > submission, but I've got a bit stuck deciding how to fit in with > RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). Shouldn't 6125 be updated to account for DANE, rather than doing this per protocol (or set of protocols)? That way anything that references 6125bis would inherit the correct DANE behavior. -- Cyrus Daboo From shuque@upenn.edu Fri Jun 1 10:03:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CF621F88F7; Fri, 1 Jun 2012 10:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3VjwgmjSGyP; Fri, 1 Jun 2012 10:03:13 -0700 (PDT) Received: from mopeypopo.net.isc.upenn.edu (www.huque.com [IPv6:2607:f470:2:1::a:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA2621F88F3; Fri, 1 Jun 2012 10:03:13 -0700 (PDT) Received: by mopeypopo.net.isc.upenn.edu (Postfix, from userid 500) id E1F27A0A44; Fri, 1 Jun 2012 13:03:06 -0400 (EDT) Date: Fri, 1 Jun 2012 13:03:06 -0400 From: Shumon Huque To: Tony Finch Message-ID: <20120601170306.GA32180@isc.upenn.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: University of Pennsylvania User-Agent: Mutt/1.5.21 (2010-09-15) Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [apps-discuss] [dane] DANE for MUAs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 17:03:14 -0000 On Fri, Jun 01, 2012 at 05:47:50PM +0100, Tony Finch wrote: > I've started a draft for using DANE with IMAP, POP3, and message > submission, but I've got a bit stuck deciding how to fit in with > RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). > > RFC 6125 has the following example: > > A mail user agent that is connecting via IMAPS to the email service > at "example.net" (resolved as "mail.example.net") might have five > reference identifiers: an SRV-ID of "_imaps.example.net" (see > [EMAIL-SRV]), DNS-IDs of "example.net" and "mail.example.net", and, > as a fallback, CN-IDs of "example.net" and "mail.example.net". (A > legacy email user agent would not support [EMAIL-SRV] and therefore > would probably be explicitly configured to connect to > "mail.example.net", whereas an SRV-aware user agent would derive > "example.net" from an email address of the form "user@example.net" > but might also accept "mail.example.net" as the DNS domain name > portion of reference identifiers for the service.) > > I presume that the client would not actually use mail.example.net as a > reference identifier unless DNSSEC is in use, otherwise that would not be > secure and is therefore forbidden according to the rules a few paragraphs > earlier in RFC 6125. That sounds correct to me. > There's also a question about how SNI fits in. RFC 6066 says that it only > supports DNS host names, which I take to mean SRV targets not SRV names. > RFC 6186 encourages the use of SNI but says nothing about which identity > should be used. SNI really needs to be extended to support other name types (especially SRVName and URI). > So I'm inclined to state that the server should have a certificate > containing both the SRV name and target as DNS-IDs and offer that > certificate if it is given either identity in an SNI. This is so that the > server can support new-style clients (supporing DANE and SRV and using the > SRV name as the identity) as well as old-style clients (using address > records directly and the server host name for the TLS identity). I'll > mention the SRV-ID for form's sake but as far as I can tell it's a fantasy > that doesn't exist in the real world. This doesn't achieve compartmentalization of security against other services sharing the domain name at the DNS-ID. It might however be necessary until software evolves. I agree that SRV-ID is for the time being a fantasy. Although if DANE usage types 2 and 3 take off, it might not be in the future. -- Shumon Huque University of Pennsylvania. From Jeff.Hodges@KingsMountain.com Fri Jun 1 10:36:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5588421F8A25 for ; Fri, 1 Jun 2012 10:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jNllBN7UdfD for ; Fri, 1 Jun 2012 10:36:00 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 6A16C21F8A23 for ; Fri, 1 Jun 2012 10:36:00 -0700 (PDT) Received: (qmail 21929 invoked by uid 0); 1 Jun 2012 17:35:59 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 1 Jun 2012 17:35:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=gSlQTVnh8NRk33qgWY9i8ii8hirfpA7QfnxCpTLIWFk=; b=JfITYWNBrwgXSCwgvgryqF2yaW76DBVioQMgSV+GuitK6YWI2HT4RaM0Ls8ehdh1s1vKA/mJSHYVSCh5XbKpbuMs3I8Vca4P0qKa4+Y6/U6xOax4muOIRo6TW2SZUpcJ; Received: from [216.113.168.128] (port=10492 helo=[10.244.136.116]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SaVlX-0006qt-Ce; Fri, 01 Jun 2012 11:35:59 -0600 Message-ID: <4FC8FD7F.3020200@KingsMountain.com> Date: Fri, 01 Jun 2012 10:35:59 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Apps Discuss , IETF WebSec WG , draft-ietf-websec-strict-transport-sec@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [apps-discuss] AppsDir review of draft-ietf-websec-strict-transport-sec X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 17:36:01 -0000 Hi, thanks for your review Murray, apologies for latency. Nice to see you didn't find any major issues. The most major obvious item in this review, concerning ABNF in section 6, was discussed on the list -- and then I neglected to submit a bug for the overall review feedback (sorry). that's now done: HSTS: AppsDir Editorial comments http://trac.tools.ietf.org/wg/websec/trac/ticket/46 ..and I'm working on -09 to incorporate your feedback and will reply to your msg on-list. =JeffH From ned.freed@mrochek.com Fri Jun 1 12:13:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B516311E80B4; Fri, 1 Jun 2012 12:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUT9G0JtiPAe; Fri, 1 Jun 2012 12:13:44 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFB311E80A3; Fri, 1 Jun 2012 12:13:44 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG663YE9AO002X1O@mauve.mrochek.com>; Fri, 1 Jun 2012 12:13:41 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG54121Q0W0006TF@mauve.mrochek.com>; Fri, 1 Jun 2012 12:13:39 -0700 (PDT) Message-id: <01OG663WXFQA0006TF@mauve.mrochek.com> Date: Fri, 01 Jun 2012 09:18:43 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 31 May 2012 09:39:55 +0200" <4FC7204B.8020403@dcrocker.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC7204B.8020403@dcrocker.net> To: Dave Crocker Cc: draft-melnikov-smtp-priority-13.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 19:13:45 -0000 A few comments are in order here. > > particularly important during emergencies for first responders and > > for environments such as military messaging, where messages have high > > operational significance, and the consequences of extraneous delay > > can be significant. > > > > In order for an SMTP receiver to be able to send higher priority > send -> relay Given the imprecise nature of this document overall, it's a stretch to believe that being precise here is really necessary, but if it is, this fixes only part of the problem. The message may have been received via SMTP, SUBMIT, or something else. And the higher *or* *lower* priority may apply to whatever the next step is: SMTP, LMTP, or something else. If you want to be precise here, it needs to say something like: In order for an MSA, MTA, or MDA to be able to relay, deliver, or otherwise process higher priority messages first, ... > > messages first, there needs to be a mechanism to communicate (during > > both Message Submission [RFC6409] and Message Transfer [RFC5321]) the > > priority of each message. This specification defines this mechanism > > by specification of an SMTP [RFC5321] extension. > > > > Implementors of this document might also consider implementing > > [PRIORITY-TUNNELING] which talks about tunneling of Message Transfer > > Priority information through Message Transfer Agents (MTAs) that do > > not support this extension, using a new message header field > > [RFC5322]. > Consider replacing above paragraph with: > In order to permit end-to-end use of this extension across email > infrastructure that does not support it, a companion tunneling mechanism > is defined in [PRIORITY-TUNNELING] through use of a new message header > field [RFC5322]. This is better. These specifications are not just for implementors. > > 2. Conventions Used in This Document > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in [RFC2119] when they > > appear in ALL CAPS. These words also appear in this document in > > lower case as plain English words, absent their normative meanings. > "when they appear in ALL CAPS". sigh. In other words, this document is > modifying RFC2119. On the contrary, all this is doing is being specific about the way RFC 2119 has actually been used ever since it was created. I can easily produce a long list of RFCs containing instances of these words in lower case where, even though it wasn't stated, the intent *clearly* was for lower case versions of these words to have their regular meanings. And even if I were to accept the notion that this document specifies a novel derivation of RFC 2119 (the notion that it *modifies* it being patently absurd), that ship has also sailed. I can also easily point to RFCs that do things like specify ALLS CAPS versions of these words have one meaning, Mixed Case another, and lower case yet another. > Does anyone seriously expect this new nuance of usage to be read and > remembered by average readers of this document? The better question is does anyone seriously expect anyone to assume, given abundant evidence to the contrary, that the lower case versions of these words will be taken to have RFC 2119 meaning? > FWIW, it took me about 3 minutes to make the relevant changes, below. > Case-sensitivity in semantics invites comprehension problems here. > Worse, there is absolutely no need or benefit in creating the problem > for this document. At a minimum, please do not try to modify IETF > document writing policy on the fly. You're the one who is arguing for a modification to the *actual* IETF document writing policy here. > > The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] > > notation including the core rules defined in Appendix B of RFC 5234 > > [RFC5234]. > > > > In examples, "C:" and "S:" indicate lines sent by the client and > > server respectively. Line breaks that do not start with a new "C:" > > or "S:" exist for editorial reasons and are not a part of the > > protocol. > > > > This document uses the term "priority" specifically in relation to > > the internal treatment of a message by the server: messages with > > higher priorities may be given expedited handling, and those with > may -> can > > lower priorities may be handled only as resources become available. > may -> can Again, given the loosey-goosey nature of this document overall, I don't think precision is really required, but if it is, both of these changes are somewhat objectionable. Like it or not, "may" and "can" are *not* synonyms. "Can" is more assertive, and carries with it a flavor that's closer to "should", whereas "may" is expresses a possibilit with no preference. We're talking about prioritization methodology here, specifically expedited handling and deferred processing. There can be overhead associated with both of these, and we should not be encourage the use of these techniques when it isn't absolutely necessary. And yes, I'm being very pedantic here. That's what you're going to get when you elect to go down this path. > > > > 3. Definition of the Priority SMTP Extension > > > > The Priority SMTP service extension is defined as follows: > > > > > > > > > > Melnikov & Carlberg Expires November 25, 2012 [Page 3] > > > > Internet-Draft Message Transfer Priority SMTP Extension May 2012 > > > > > > 1. The textual name of this extension is "Priority Message > > Handling". > > > > 2. The EHLO keyword value associated with this extension is "MT- > > PRIORITY". > > > > 3. The EHLO keyword has no parameters. Parameters are reserved for > > possible future extensions and MUST be ignored by clients that > > don't understand them. > > > > 4. No additional SMTP verbs are defined by this extension. > > > > 5. One optional parameter ("MT-PRIORITY") is added to the MAIL FROM > > command. The value associated with this parameter is a decimal > > integer number from -9 to 9 (inclusive) indicating the priority > > of the email message. The syntax of the MT-PRIORITY parameter is > > described by the ABNF non-terminal defined in > > Section 6. Higher numbers mean higher priority. > As a minor point, the form of -9 to 9 seems more complicated than > useful. Is there a need for 19 values? I'd think that 0 to 9 would be > sufficient. Well, to be fair, the specification only requires support for six distinct values: A message priority is a decimal integer in the range from -9 to 9 (inclusive). SMTP servers compliant with this specification are not required to support all 19 distinct priority levels (i.e. to treat each priority value as a separate priority), but they MUST implement at least the following 6 distinct priority levels: -4, -2, 0, 2, 4, 9. I.e. an implementation that only supports the 6 priority levels will internally round up a syntactically valid level that isn't supported to the next higher supported number. For example, such an implementation will treat priority values below and including -4 as priority -4, priority -3 as priority -2, and all priorities starting from 5 are treated as priority 9. An SMTP server MAY support more than 6 different priority levels. Decision about which levels to support in addition to the 6 mentioned above is a local matter. Now, I have no idea what it actually means to "support" six values, but I assume it means that if you only make a processing distinction between five or fewer values total, if you support only one "lower than normal" priority, or you support fewer than three "higher than normal" priorities, you cannot implement this specification. (Note I'm assuming 0 is "normal" here - see below.) Of course there's a trivial way around this: You simply state that, as a matter of implementation policy, you only support X number and here's the mapping. This would allow, say, a system that only does the old X.400 non-urgent, normal, urgent thing to claim support. > For that matter, why are many values needed? What is the basis for > choosing to have a range of more than a few values? IMO this is one of the rare cases where X.400 was spot-on correct. > This appears to be the only place the provides semantics to the priority > number. As such, it should be more thorough. The critical issue in > assigning the number, I think, is trying to get independent originators > to assign numbers according roughly the same criteria. For example, if > I label "average" messages I send as as 0 and you label them as 1, then > your messages get preferential treatment over mine, although that was > not your intent. (Assuming you're not trying to game the service...) > This issue goes to the core of the usage model for the feature: It > really needs an environment tailored to its use, with all participants > not only within the same trust system, but sharing the same priority > assignment model/policy. It's probably good for this document to permit > a range of assignment models, but should note that an operational > requirement for use of the extension is that an assignment policy be > defined for all participants. > This document might, then, offer a candidate model, to be use by default > and absent one specific to an environment. Well, this goes to the problem I have with the entire document - I have no real idea what the policy associated with these priorities is supposed to be. We have a prioritization capability in our product and I can tell you what it does, but s to whether or not it satisfies the intended target of this specification, I realy couldn't say. More generally, in a modern, high performance MTA that's capable of processing large numbers of messages simultaneously, there's a significant problem actually implementing mechanisms that are guaranteed to preferentially process certain messages. For example, suppose I have several dozen threads/processes/whatever connected up to a given system, all busy transferring large messages. A higher priority message comes in. If I shove this message on the thread that is the closest to being done, there may still be a significant delay. OTOH, if I start a new connection to handle it, what if I hit the limit on the number of connections the remote MTA will accept from me? Put another way, if you assume a fairly strict policy is needed, your point about this only being applicable in an environment that's specifically tailored for it is, if anything, an massive understatement. For this to provide a real priority boost with high reliability it's actually necessary to closely coordinate operational policies across all involved ADMDs. And not to put too fine a point on it, the level of technical acumen needed to actually do this sort of thing is something I've observed to be the exception and not the rule. All that said, I think this actually argues for putting in some statements as to what this document does *not* do. It calls for best effort to provide preferential processing, nothing more. It does *not* provide any sort of guarantees. And if that's not the case, then this needs to be experimental. > > 6. The maximum length of a MAIL FROM command line is increased by 15 > > octets by the possible addition of a space, the MT-PRIORITY > > keyword and value. > > > > 7. The MT-PRIORITY extension is valid for the submission service > > [RFC6409] and LMTP [RFC2033]. > > > > 4. Handling of messages received via SMTP > > > > This section describes how a conforming SMTP server should handle any > > messages received via SMTP. > > > > 4.1. Handling of the MT-PRIORITY parameter by the receiving SMTP server > > > > The following rules apply to SMTP transactions in a server that > > supports the MT-PRIORITY parameter: > > > > 1. A conforming SMTP server MUST NOT refuse a MAIL FROM command > > based on the absence of the MT-PRIORITY parameter. > hmmm. For some operational environments, it will be essential to have > /all/ handling conform to the priority policy model in force for the > environment. In those cases, the absence of the parameter would be a > violation of the spec. Interesting point. I'm not sure what, if anything, to do about it. > > 2. If any of the associated s (as defined in Section > > 4.1.2 of [RFC5321]) are not syntactically valid, or if there is > > more than one MT-PRIORITY parameter in a particular MAIL FROM > > command, the server MUST return an error, for example "501 syntax > > error in parameter" (with 5.5.2 Enhanced Status Code [RFC2034]). > > > > 3. When inserting a Received header field as specified in Section > > 4.4 of [RFC5321], the compliant MTA/MSA SHOULD include the > > "PRIORITY" clause whose syntax is specified in Section 6. > > > > > > > > Melnikov & Carlberg Expires November 25, 2012 [Page 4] > > > > Internet-Draft Message Transfer Priority SMTP Extension May 2012 > > > > > > 4. If the sending SMTP client specified the MT-PRIORITY parameter to > > the MAIL FROM command, then the value of this parameter is the > > message priority. > > > > 5. If no priority has been determined by the above, the server may > may -> can > > use its normal policies to set the message's priority. By > > default, each message has priority 0. > ouch. This chooses a particular model for meaning of the numbers, and > without having defined the model beforehand. I for one was assuming 0 was the normal, default priority. But now that you mention it, at least this needs to be made explicit. > That is, I think the problem with this default is that it really is > assuming a particular policy for meaning of the values, namely that > average mail is mid-priority, assuming the numbers have linear semantics. That sure was what I was assuming. > > The SMTP server MUST NOT allow upgraded priorities from untrusted > > (e.g. unauthenticated) or insufficiently trusted sources. (One > > example of an "insufficiently trusted source" might be an SMTP sender > > which authenticated using SMTP AUTH, but which is not explicitly > > whitelisted to use the SMTP MT-PRIORITY service.) The server MAY, > It is good that this issue is raised, but it really requires an earlier, > separate and careful discussion of the need for this extension to be > used within an administered trust environment. Given such an > introductory section, the above text would be sufficient. Agreed. > In its absence, the reference to a whitelist is based on the very large > assumption that participants in the extension are whitelisted. This is > not document elsewhere. True. > > however, allow an untrusted source to lower its own message's > > priorities -- consider, for example, an email marketer that > > voluntarily sends its marketing messages at low priority. > To beat the point a bit deader: this assumes a particular policy for > the meaning of the priority values. Worse, it also appears to > contradict the earlier default of 0, but perhaps I've misunderstood that. I think that's a misunderstanding. I generally agree with the remainder of your comments, although I think some of them become less important as long as it's clear this doesn't provide guaranteees, but they still should be addressed. Ned From dhc@dcrocker.net Fri Jun 1 12:15:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB4A11E80EE; Fri, 1 Jun 2012 12:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkpGNB23JnpD; Fri, 1 Jun 2012 12:15:46 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E34C511E810C; Fri, 1 Jun 2012 12:15:45 -0700 (PDT) Received: from [192.168.2.101] (g225186221.adsl.alicedsl.de [92.225.186.221]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q51JFfAr030056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jun 2012 12:15:43 -0700 Message-ID: <4FC914DB.4000806@dcrocker.net> Date: Fri, 01 Jun 2012 21:15:39 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> In-Reply-To: <4FC89931.5060201@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]); Fri, 01 Jun 2012 12:15:45 -0700 (PDT) Cc: draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 19:15:47 -0000 On 6/1/2012 12:28 PM, Alexey Melnikov wrote: > On 31/05/2012 08:49, Dave Crocker wrote: >> FWIW, it took me about 3 minutes to make the relevant changes, below. >> Case-sensitivity in semantics invites comprehension problems here. >> Worse, there is absolutely no need or benefit in creating the problem >> for this document. At a minimum, please do not try to modify IETF >> document writing policy on the fly. > > I will let IESG weight in on this. I've implemented what I was told > earlier. I don't have a strong opinion on this. So we don't follow IETF consensus documents anymore for process and documentation conventions? The IESG establishes those details at its whim? >>> 5. If no priority has been determined by the above, the server may >>> use its normal policies to set the message's priority. By >>> default, each message has priority 0. >> >> ouch. This chooses a particular model for meaning of the numbers, and >> without having defined the model beforehand. >> >> That is, I think the problem with this default is that it really is >> assuming a particular policy for meaning of the values, namely that >> average mail is mid-priority, assuming the numbers have linear semantics. > > Why is this a problem (commenting on the last sentence quoted above)? It's quite basic. The document specifies a standard but does not specify it completely. First, it periodically relies on undocumented policy assumptions. Second, policies will vary from one environment to the next. As I note in the review, proper operation of a QOS mechanism requires all participants to operate according to the same policies. I gave the example of two posters meaning 'average priority' but happening to choose different values for that semantic. To get proper system operation, you and I and the other guy all need to choose the same value for the same semantic. That requires a definition of the semantic; in this case that means rules for when to assign specific values. In effect, the current document is a syntax mechanism for expressing priority, but it doesn't really specify actual priority semantics for making assignments, although it does hint at a particular set of semantics/policies. So the document is both incomplete and overly rigid, IMO. That's why I suggested providing an explicit and complete policy section as a default, but designed to allow alternative policy sections for other environments. >>> however, allow an untrusted source to lower its own message's >>> priorities -- consider, for example, an email marketer that >>> voluntarily sends its marketing messages at low priority. >> >> To beat the point a bit deader: this assumes a particular policy for >> the meaning of the priority values. Worse, it also appears to >> contradict the earlier default of 0, but perhaps I've misunderstood that. > > Yes, you misunderstood. The example talking about marketing messages is > an example of a sender that explicitly requests priority below 0. But there is no inherent meaning to "low priority", absent a policy statement that defines the meaning of values. Low is relative to other values, but which ones? In some environments -5 is low and in others 0 is low and I'll bet some others will treat 5 as low. >>> 4.4. Mailing lists and Aliases >>> >>> Several options exist to translate the address of an email recipient >> >> "options"? Perhaps you mean mechanisms or services? > > Yes. > >> And they really aren't translating an address but are doing a form of >> message transmission (relaying, or the like). > > Suggested replacement? Several types of mechanisms exist to redirect or forward messages to alternative or multiple addresses.[RFC5598] Examples for this are aliases and mailing lists [RFC5321]. If a message is subject to such processing, the Mediator node [rfc5598, Sec 2.1] SHOULD retain the MT-PRIORITY parameter value for all expanded and/or translated addresses. >>> 4.6. Interaction with DSN SMTP Extension >>> >>> An MTA which also conforms to [RFC3461] SHOULD apply the same >>> priority value to delivery reports (whether for successful delivery >>> or failed delivery) it generates for a message. >> >> In many operational environments, control messages get higher priority >> (or lower priority) than payload messages. > > What is a control message? Chatter about handling activity is distinct from traffic comprising user payload (messages) even if a user is the recipient. The chatter consists of control messages. A delivery report is a control message. > Any suggested text? Messages concerning email handling, such as delivery reports, constitute control information rather than direct message payload. In some environments, control traffic is subject to higher priority handling and in others it receives the same priority as the message that caused the report to be generated. Determining the priority to assign is a matter for the policy statements applying to the environment in which [RFC3461] is supported. >>> Note that rejections based on priority (see Section 4.1) or priority+ >>> message size combination SHOULD only be done by an MSA (i.e. they >>> SHOULD NOT be done by MTAs/MDAs), because the MSA has a link to the >> >> This presumes that an MSA knows the priority-related policies of >> downstream MTAs and MDAs. > > I don't think so. Why do you say that? A rejection means that the message is outside an acceptable range. That's a policy for the environment and it does not make sense for an MSA to have one set of policies and MTAs to have another. >>> 5.2. Timely Delivery >>> >>> An important constraint (usually associated with higher priority >>> levels) is that messages with high priority have some delivery time >>> constraints. In some cases, higher priorities mean a shorter maximum >>> time allowed for delivery. >>> >>> Unextended SMTP does not offer a service for timely delivery. The >>> "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in >>> [RFC2852] is an example of an SMTP extension providing a service that >>> can be used to implement such constraints. But note that use of the >>> DELIVERBY extension alone does not guarantee any priority processing. >> >> It seems as if this section introduces an issue but does not actually >> deal with it. Perhaps there should be some discussion of the possible >> (or required?) interaction between the two extensions it discusses? > > There is no issue and no real interaction in this specific case. A > client that wants to use both against a server that supports both should > consider this issue. Specifications that say an implementer should consider something but which gives no guidance about the consideration aren't doing much useful, in my view. As this set of text was proceeding, I thought it was going to provide some useful guidance about possible uses of the combined options, since it seemed like the combination could be, well, useful. >>> 8. Deployment Considerations >>> >>> If multiple DNS MX records are used to specify multiple servers for a >>> domain in section 5 of [RFC5321], it is strongly advised that all of >> >> "strongly advised"? >> >> This seems the sort of thing that needs normative language yet it is >> carefully avoided. That is, by saying 'strongly' the issue is moved >> towards the asking why it is not stated normatively. I'd guess this >> needs a SHOULD, possibly with discussion of permissible exceptions >> (such as the open Internet...?) > > This section applies to system administrators. It is quite different > from the rest of the document which contains mostly protocol level > requirements. So yes, I avoided usage of RFC 2119 keywords here on purpose. I think that is merely confusing. Normative direction to operators is an entirely reasonable part of a specification. Since that's really what you are doing, go ahead and use officially normative language. > Suggestions for alternatives are welcomed. Just convert to the normative terms that are appropriate. >> However note that the 'strongly advised' presumes instantaneous >> implementation on all hosts within the trust environment. >> Since that isn't possible, it's not clear how the advice of this >> section is practical. > > Nothing is instantaneous, so I am not very concerned ;-). So the document is strongly advising something that is impossible to achieve, during a transition period. It's worth considering how to handle that. > Once some servers start supporting this extension a sysadmin can remove > MXes for servers which don't support it. Upgrading all servers nearly > simultaneously is another option. Is it practical? >>> 10. Security Considerations >>> >>> Message Submission Agents MUST implement a policy that only allows >>> authenticated users (or only certain groups of authenticated users) >>> to specify message transfer priorities, and MAY restrict maximum >>> priority values different groups of users can request, or MAY >>> override the priority values specified by MUAs. >> >> Presumably the normative MSA language is meant "for those MSAs >> supporting this extension"? > > Of course. I don't think this needs saying. And yet the document says exactly that sort of qualifier earlier: "An MTA which also conforms to [RFC3461]..." d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From alexey.melnikov@isode.com Fri Jun 1 12:59:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91A611E80CC; Fri, 1 Jun 2012 12:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.893 X-Spam-Level: X-Spam-Status: No, score=-102.893 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uVSED1ZPB+5; Fri, 1 Jun 2012 12:59:07 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE5611E80A0; Fri, 1 Jun 2012 12:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338580745; d=isode.com; s=selector; i=@isode.com; bh=ulLGL7Jt5UaIcnHerVyNu62UkX28P9GeRH+QegregtQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=L+y9W70Lgu4oWR8CnVihOzDW/jrcC7aNMWhWYCa+uG5DQ6LnMsjlMk+cSpYhGBOfSHOCtA zlhKwOF8vLLtvRhelIJqBR/TR9c8SbnLgLoPZXwWgLiMbMZNQoMWK76VtMYSLRedyxfaCd LP/lj/9EzdnJlf/J6FlysJMQSAvqgtA=; Received: from [192.168.1.144] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 1 Jun 2012 20:59:05 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING Message-ID: <4FC91F09.7070701@isode.com> Date: Fri, 01 Jun 2012 20:59:05 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Ned Freed References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC7204B.8020403@dcrocker.net> <01OG663WXFQA0006TF@mauve.mrochek.com> In-Reply-To: <01OG663WXFQA0006TF@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-melnikov-smtp-priority-13.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 19:59:08 -0000 Hi Ned, On 01/06/2012 17:18, Ned Freed wrote: > A few comments are in order here. > >> > particularly important during emergencies for first responders and >> > for environments such as military messaging, where messages have >> high >> > operational significance, and the consequences of extraneous delay >> > can be significant. >> > >> > In order for an SMTP receiver to be able to send higher priority > >> send -> relay > > Given the imprecise nature of this document overall, it's a stretch to > believe > that being precise here is really necessary, but if it is, this fixes > only part > of the problem. The message may have been received via SMTP, SUBMIT, or > something else. And the higher *or* *lower* priority may apply to > whatever the > next step is: SMTP, LMTP, or something else. > > If you want to be precise here, it needs to say something like: > > In order for an MSA, MTA, or MDA to be able to relay, deliver, or > otherwise process higher priority messages first, ... Yeah, I think this is less readable than what I have. I am sure readers understand the meaning of what is being said. > >> > messages first, there needs to be a mechanism to communicate >> (during >> > both Message Submission [RFC6409] and Message Transfer >> [RFC5321]) the >> > priority of each message. This specification defines this >> mechanism >> > by specification of an SMTP [RFC5321] extension. >> > >> > Implementors of this document might also consider implementing >> > [PRIORITY-TUNNELING] which talks about tunneling of Message >> Transfer >> > Priority information through Message Transfer Agents (MTAs) that do >> > not support this extension, using a new message header field >> > [RFC5322]. > >> Consider replacing above paragraph with: > >> In order to permit end-to-end use of this extension across email >> infrastructure that does not support it, a companion tunneling mechanism >> is defined in [PRIORITY-TUNNELING] through use of a new message header >> field [RFC5322]. > > This is better. These specifications are not just for implementors. Yes, already used in -15. >> > 2. Conventions Used in This Document >> > >> > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in >> this >> > document are to be interpreted as described in [RFC2119] when they >> > appear in ALL CAPS. These words also appear in this document in >> > lower case as plain English words, absent their normative meanings. > >> "when they appear in ALL CAPS". sigh. In other words, this document is >> modifying RFC2119. > > On the contrary, all this is doing is being specific about the way RFC > 2119 has > actually been used ever since it was created. I can easily produce a > long list > of RFCs containing instances of these words in lower case where, even > though it > wasn't stated, the intent *clearly* was for lower case versions of > these words > to have their regular meanings. > > And even if I were to accept the notion that this document specifies a > novel > derivation of RFC 2119 (the notion that it *modifies* it being patently > absurd), that ship has also sailed. I can also easily point to RFCs > that do > things like specify ALLS CAPS versions of these words have one > meaning, Mixed > Case another, and lower case yet another. > >> Does anyone seriously expect this new nuance of usage to be read and >> remembered by average readers of this document? > > The better question is does anyone seriously expect anyone to assume, > given > abundant evidence to the contrary, that the lower case versions of > these words > will be taken to have RFC 2119 meaning? > >> FWIW, it took me about 3 minutes to make the relevant changes, below. >> Case-sensitivity in semantics invites comprehension problems here. >> Worse, there is absolutely no need or benefit in creating the problem >> for this document. At a minimum, please do not try to modify IETF >> document writing policy on the fly. > > You're the one who is arguing for a modification to the *actual* IETF > document > writing policy here. Agreeing with that. >> > The formal syntax use the Augmented Backus-Naur Form (ABNF) >> [RFC5234] >> > notation including the core rules defined in Appendix B of RFC 5234 >> > [RFC5234]. >> > >> > In examples, "C:" and "S:" indicate lines sent by the client and >> > server respectively. Line breaks that do not start with a new "C:" >> > or "S:" exist for editorial reasons and are not a part of the >> > protocol. >> > >> > This document uses the term "priority" specifically in relation to >> > the internal treatment of a message by the server: messages with >> > higher priorities may be given expedited handling, and those with > >> may -> can > > >> > lower priorities may be handled only as resources become available. > >> may -> can > > Again, given the loosey-goosey nature of this document overall, I > don't think > precision is really required, but if it is, both of these changes are > somewhat > objectionable. > > Like it or not, "may" and "can" are *not* synonyms. "Can" is more > assertive, > and carries with it a flavor that's closer to "should", whereas "may" is > expresses a possibilit with no preference. > > We're talking about prioritization methodology here, specifically > expedited > handling and deferred processing. There can be overhead associated > with both of > these, and we should not be encourage the use of these techniques when > it isn't > absolutely necessary. > And yes, I'm being very pedantic here. That's what you're going to get > when > you elect to go down this path. :-) > >> > >> > 3. Definition of the Priority SMTP Extension >> > >> > The Priority SMTP service extension is defined as follows: >> > >> > >> > >> > >> > Melnikov & Carlberg Expires November 25, 2012 >> [Page 3] >> > >> > Internet-Draft Message Transfer Priority SMTP Extension May >> 2012 >> > >> > >> > 1. The textual name of this extension is "Priority Message >> > Handling". >> > >> > 2. The EHLO keyword value associated with this extension is "MT- >> > PRIORITY". >> > >> > 3. The EHLO keyword has no parameters. Parameters are reserved >> for >> > possible future extensions and MUST be ignored by clients that >> > don't understand them. >> > >> > 4. No additional SMTP verbs are defined by this extension. >> > >> > 5. One optional parameter ("MT-PRIORITY") is added to the MAIL >> FROM >> > command. The value associated with this parameter is a decimal >> > integer number from -9 to 9 (inclusive) indicating the priority >> > of the email message. The syntax of the MT-PRIORITY >> parameter is >> > described by the ABNF non-terminal defined in >> > Section 6. Higher numbers mean higher priority. > >> As a minor point, the form of -9 to 9 seems more complicated than >> useful. Is there a need for 19 values? I'd think that 0 to 9 would be >> sufficient. > > Well, to be fair, the specification only requires support for six > distinct > values: > > A message priority is a decimal integer in the range from -9 to 9 > (inclusive). SMTP servers compliant with this specification are not > required to support all 19 distinct priority levels (i.e. to treat > each priority value as a separate priority), but they MUST implement > at least the following 6 distinct priority levels: -4, -2, 0, 2, 4, > 9. I.e. an implementation that only supports the 6 priority levels > will internally round up a syntactically valid level that isn't > supported to the next higher supported number. For example, such an > implementation will treat priority values below and including -4 as > priority -4, priority -3 as priority -2, and all priorities starting > from 5 are treated as priority 9. An SMTP server MAY support more > than 6 different priority levels. Decision about which levels to > support in addition to the 6 mentioned above is a local matter. > > Now, I have no idea what it actually means to "support" six values, but I > assume it means that if you only make a processing distinction between > five or > fewer values total, if you support only one "lower than normal" > priority, or > you support fewer than three "higher than normal" priorities, you cannot > implement this specification. (Note I'm assuming 0 is "normal" here - see > below.) More or less, yes. > > Of course there's a trivial way around this: You simply state that, as > a matter > of implementation policy, you only support X number and here's the > mapping. > This would allow, say, a system that only does the old X.400 non-urgent, > normal, urgent thing to claim support. Right. And there is already such a mapping in Appendix B. >> For that matter, why are many values needed? What is the basis for >> choosing to have a range of more than a few values? > > IMO this is one of the rare cases where X.400 was spot-on correct. > >> This appears to be the only place the provides semantics to the priority >> number. As such, it should be more thorough. The critical issue in >> assigning the number, I think, is trying to get independent originators >> to assign numbers according roughly the same criteria. For example, if >> I label "average" messages I send as as 0 and you label them as 1, then >> your messages get preferential treatment over mine, although that was >> not your intent. (Assuming you're not trying to game the service...) > >> This issue goes to the core of the usage model for the feature: It >> really needs an environment tailored to its use, with all participants >> not only within the same trust system, but sharing the same priority >> assignment model/policy. It's probably good for this document to permit >> a range of assignment models, but should note that an operational >> requirement for use of the extension is that an assignment policy be >> defined for all participants. > >> This document might, then, offer a candidate model, to be use by default >> and absent one specific to an environment. > > Well, this goes to the problem I have with the entire document - I > have no real > idea what the policy associated with these priorities is supposed to > be. We > have a prioritization capability in our product and I can tell you > what it > does, but s to whether or not it satisfies the intended target of this > specification, I realy couldn't say. I hope I clarified this in -16. Also look at Appendix A and Appendix B. > More generally, in a modern, high performance MTA that's capable of > processing > large numbers of messages simultaneously, there's a significant problem > actually implementing mechanisms that are guaranteed to preferentially > process > certain messages. > > For example, suppose I have several dozen threads/processes/whatever > connected > up to a given system, all busy transferring large messages. A higher > priority > message comes in. If I shove this message on the thread that is the > closest to > being done, there may still be a significant delay. OTOH, if I start a > new > connection to handle it, what if I hit the limit on the number of > connections > the remote MTA will accept from me? > > Put another way, if you assume a fairly strict policy is needed, your > point > about this only being applicable in an environment that's specifically > tailored > for it is, if anything, an massive understatement. For this to provide > a real > priority boost with high reliability it's actually necessary to closely > coordinate operational policies across all involved ADMDs. And not to > put too > fine a point on it, the level of technical acumen needed to actually > do this > sort of thing is something I've observed to be the exception and not > the rule. > > All that said, I think this actually argues for putting in some > statements > as to what this document does *not* do. It calls for best effort to > provide preferential processing, nothing more. It does *not* provide > any sort of guarantees. Fair enough, I will add some text about that. Best effort was certainly the intent. > And if that's not the case, then this needs to be experimental. > >> > 6. The maximum length of a MAIL FROM command line is increased >> by 15 >> > octets by the possible addition of a space, the MT-PRIORITY >> > keyword and value. >> > >> > 7. The MT-PRIORITY extension is valid for the submission service >> > [RFC6409] and LMTP [RFC2033]. >> > >> > 4. Handling of messages received via SMTP >> > >> > This section describes how a conforming SMTP server should >> handle any >> > messages received via SMTP. >> > >> > 4.1. Handling of the MT-PRIORITY parameter by the receiving SMTP >> server >> > >> > The following rules apply to SMTP transactions in a server that >> > supports the MT-PRIORITY parameter: >> > >> > 1. A conforming SMTP server MUST NOT refuse a MAIL FROM command >> > based on the absence of the MT-PRIORITY parameter. > >> hmmm. For some operational environments, it will be essential to have >> /all/ handling conform to the priority policy model in force for the >> environment. In those cases, the absence of the parameter would be a >> violation of the spec. > > Interesting point. I'm not sure what, if anything, to do about it. > >> > 2. If any of the associated s (as defined in Section >> > 4.1.2 of [RFC5321]) are not syntactically valid, or if there is >> > more than one MT-PRIORITY parameter in a particular MAIL FROM >> > command, the server MUST return an error, for example "501 >> syntax >> > error in parameter" (with 5.5.2 Enhanced Status Code >> [RFC2034]). >> > >> > 3. When inserting a Received header field as specified in Section >> > 4.4 of [RFC5321], the compliant MTA/MSA SHOULD include the >> > "PRIORITY" clause whose syntax is specified in Section 6. >> > >> > >> > >> > Melnikov & Carlberg Expires November 25, 2012 >> [Page 4] >> > >> > Internet-Draft Message Transfer Priority SMTP Extension May >> 2012 >> > >> > >> > 4. If the sending SMTP client specified the MT-PRIORITY >> parameter to >> > the MAIL FROM command, then the value of this parameter is the >> > message priority. >> > >> > 5. If no priority has been determined by the above, the server may > >> may -> can > > >> > use its normal policies to set the message's priority. By >> > default, each message has priority 0. > >> ouch. This chooses a particular model for meaning of the numbers, and >> without having defined the model beforehand. > > I for one was assuming 0 was the normal, default priority. But now > that you > mention it, at least this needs to be made explicit. I believe the document already says that, but I will double check. >> That is, I think the problem with this default is that it really is >> assuming a particular policy for meaning of the values, namely that >> average mail is mid-priority, assuming the numbers have linear >> semantics. > > That sure was what I was assuming. Yes. >> > The SMTP server MUST NOT allow upgraded priorities from untrusted >> > (e.g. unauthenticated) or insufficiently trusted sources. (One >> > example of an "insufficiently trusted source" might be an SMTP >> sender >> > which authenticated using SMTP AUTH, but which is not explicitly >> > whitelisted to use the SMTP MT-PRIORITY service.) The server MAY, > >> It is good that this issue is raised, but it really requires an earlier, >> separate and careful discussion of the need for this extension to be >> used within an administered trust environment. Given such an >> introductory section, the above text would be sufficient. > > Agreed. Ok. >> In its absence, the reference to a whitelist is based on the very large >> assumption that participants in the extension are whitelisted. This is >> not document elsewhere. > > True. Hmm, Ok. >> > however, allow an untrusted source to lower its own message's >> > priorities -- consider, for example, an email marketer that >> > voluntarily sends its marketing messages at low priority. > >> To beat the point a bit deader: this assumes a particular policy for >> the meaning of the priority values. Worse, it also appears to >> contradict the earlier default of 0, but perhaps I've misunderstood >> that. > > I think that's a misunderstanding. I already replied in another message that it is. > I generally agree with the remainder of your comments, although I > think some > of them become less important as long as it's clear this doesn't provide > guaranteees, but they still should be addressed. I believe I addressed most of them in -15 and -16. I might need to add a couple of clarifying sentences as per above. From ned.freed@mrochek.com Fri Jun 1 13:34:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9E811E80C7; Fri, 1 Jun 2012 13:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioWb7-8MeF0m; Fri, 1 Jun 2012 13:34:04 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id BC8E311E80B0; Fri, 1 Jun 2012 13:34:04 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG68WL990W002Z6R@mauve.mrochek.com>; Fri, 1 Jun 2012 13:34:02 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG54121Q0W0006TF@mauve.mrochek.com>; Fri, 1 Jun 2012 13:34:00 -0700 (PDT) Message-id: <01OG68WJL5MG0006TF@mauve.mrochek.com> Date: Fri, 01 Jun 2012 12:15:15 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 01 Jun 2012 12:55:21 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: To: Cyrus Daboo Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [apps-discuss] DANE for MUAs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 20:34:05 -0000 > Hi Tony, > --On June 1, 2012 5:47:50 PM +0100 Tony Finch wrote: > > I've started a draft for using DANE with IMAP, POP3, and message > > submission, but I've got a bit stuck deciding how to fit in with > > RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). > Shouldn't 6125 be updated to account for DANE, rather than doing this per > protocol (or set of protocols)? That way anything that references 6125bis > would inherit the correct DANE behavior. I've been thinking about this as well, and due to the different ways the DNS is used in these cases, I think it it at least makes sense to do them separately. But we should do all the email SRV ones at once. I'm willing to help on a DANE spec built on top of RFC 6186. (Since Tony has apparently taken some of my prose, I feel no qualms about swiping a bunch of his ;-) Ned From ned.freed@mrochek.com Fri Jun 1 13:35:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3367E21F882D; Fri, 1 Jun 2012 13:35:43 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwdlMIGXUiO6; Fri, 1 Jun 2012 13:35:42 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B931621F882C; Fri, 1 Jun 2012 13:35:42 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG68YLKYDC002Z6R@mauve.mrochek.com>; Fri, 1 Jun 2012 13:35:40 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG54121Q0W0006TF@mauve.mrochek.com>; Fri, 1 Jun 2012 13:35:37 -0700 (PDT) Message-id: <01OG68YK6UR00006TF@mauve.mrochek.com> Date: Fri, 01 Jun 2012 13:34:56 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 01 Jun 2012 12:15:15 -0700 (PDT)" <01OG68WJL5MG0006TF@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <01OG68WJL5MG0006TF@mauve.mrochek.com> To: Ned Freed Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [apps-discuss] DANE for MUAs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 20:35:43 -0000 Sorry, didn't notice that Tony has already started. Anyway, I'm willing to help. Ned > > Hi Tony, > > --On June 1, 2012 5:47:50 PM +0100 Tony Finch wrote: > > > I've started a draft for using DANE with IMAP, POP3, and message > > > submission, but I've got a bit stuck deciding how to fit in with > > > RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). > > Shouldn't 6125 be updated to account for DANE, rather than doing this per > > protocol (or set of protocols)? That way anything that references 6125bis > > would inherit the correct DANE behavior. > I've been thinking about this as well, and due to the different ways the DNS is > used in these cases, I think it it at least makes sense to do them separately. > But we should do all the email SRV ones at once. > I'm willing to help on a DANE spec built on top of RFC 6186. (Since Tony has > apparently taken some of my prose, I feel no qualms about swiping a bunch of > his ;-) > Ned > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From stpeter@stpeter.im Fri Jun 1 13:36:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF8311E8097; Fri, 1 Jun 2012 13:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InRJqu23uQbo; Fri, 1 Jun 2012 13:36:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9E711E808A; Fri, 1 Jun 2012 13:36:35 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0C1E540075; Fri, 1 Jun 2012 14:53:09 -0600 (MDT) Message-ID: <4FC927D2.9080903@stpeter.im> Date: Fri, 01 Jun 2012 14:36:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ned Freed References: <01OG68WJL5MG0006TF@mauve.mrochek.com> In-Reply-To: <01OG68WJL5MG0006TF@mauve.mrochek.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [apps-discuss] [dane] DANE for MUAs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 20:36:36 -0000 On 6/1/12 1:15 PM, Ned Freed wrote: >> Hi Tony, > >> --On June 1, 2012 5:47:50 PM +0100 Tony Finch wrote: > >> > I've started a draft for using DANE with IMAP, POP3, and message >> > submission, but I've got a bit stuck deciding how to fit in with >> > RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). > >> Shouldn't 6125 be updated to account for DANE, rather than doing this per >> protocol (or set of protocols)? That way anything that references 6125bis >> would inherit the correct DANE behavior. > > I've been thinking about this as well, and due to the different ways the > DNS is > used in these cases, I think it it at least makes sense to do them > separately. > But we should do all the email SRV ones at once. Ned, I tend to agree. Let's define them separately for now (Matt Miller and I are working on an XMPP+DANE spec) and then see what the commonalities are before we try to define a more generic approach. Now, it's *also* possible that we might want to update RFC 6125 to address the existence of DANE, and I'm happy to work on that as well, but I see it as a parallel work item. Peter -- Peter Saint-Andre https://stpeter.im/ From ned.freed@mrochek.com Fri Jun 1 13:37:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1246111E80B4; Fri, 1 Jun 2012 13:37:50 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUaSXqjTDHlE; Fri, 1 Jun 2012 13:37:48 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5768111E80B0; Fri, 1 Jun 2012 13:37:48 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG6915ZXFK002Z6R@mauve.mrochek.com>; Fri, 1 Jun 2012 13:37:44 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG54121Q0W0006TF@mauve.mrochek.com>; Fri, 1 Jun 2012 13:37:41 -0700 (PDT) Message-id: <01OG6914E4MS0006TF@mauve.mrochek.com> Date: Fri, 01 Jun 2012 13:36:45 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 01 Jun 2012 20:59:05 +0100" <4FC91F09.7070701@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC7204B.8020403@dcrocker.net> <01OG663WXFQA0006TF@mauve.mrochek.com> <4FC91F09.7070701@isode.com> To: Alexey Melnikov Cc: draft-melnikov-smtp-priority-13.all@tools.ietf.org, Ned Freed , iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 20:37:50 -0000 OK, let me take a look at -16 and I'll see what else, if anything, needs to be said. (I was looking at -15.) Ned > Hi Ned, > On 01/06/2012 17:18, Ned Freed wrote: > > A few comments are in order here. > > > >> > particularly important during emergencies for first responders and > >> > for environments such as military messaging, where messages have > >> high > >> > operational significance, and the consequences of extraneous delay > >> > can be significant. > >> > > >> > In order for an SMTP receiver to be able to send higher priority > > > >> send -> relay > > > > Given the imprecise nature of this document overall, it's a stretch to > > believe > > that being precise here is really necessary, but if it is, this fixes > > only part > > of the problem. The message may have been received via SMTP, SUBMIT, or > > something else. And the higher *or* *lower* priority may apply to > > whatever the > > next step is: SMTP, LMTP, or something else. > > > > If you want to be precise here, it needs to say something like: > > > > In order for an MSA, MTA, or MDA to be able to relay, deliver, or > > otherwise process higher priority messages first, ... > Yeah, I think this is less readable than what I have. I am sure readers > understand the meaning of what is being said. > > > >> > messages first, there needs to be a mechanism to communicate > >> (during > >> > both Message Submission [RFC6409] and Message Transfer > >> [RFC5321]) the > >> > priority of each message. This specification defines this > >> mechanism > >> > by specification of an SMTP [RFC5321] extension. > >> > > >> > Implementors of this document might also consider implementing > >> > [PRIORITY-TUNNELING] which talks about tunneling of Message > >> Transfer > >> > Priority information through Message Transfer Agents (MTAs) that do > >> > not support this extension, using a new message header field > >> > [RFC5322]. > > > >> Consider replacing above paragraph with: > > > >> In order to permit end-to-end use of this extension across email > >> infrastructure that does not support it, a companion tunneling mechanism > >> is defined in [PRIORITY-TUNNELING] through use of a new message header > >> field [RFC5322]. > > > > This is better. These specifications are not just for implementors. > Yes, already used in -15. > >> > 2. Conventions Used in This Document > >> > > >> > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > >> > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > >> this > >> > document are to be interpreted as described in [RFC2119] when they > >> > appear in ALL CAPS. These words also appear in this document in > >> > lower case as plain English words, absent their normative meanings. > > > >> "when they appear in ALL CAPS". sigh. In other words, this document is > >> modifying RFC2119. > > > > On the contrary, all this is doing is being specific about the way RFC > > 2119 has > > actually been used ever since it was created. I can easily produce a > > long list > > of RFCs containing instances of these words in lower case where, even > > though it > > wasn't stated, the intent *clearly* was for lower case versions of > > these words > > to have their regular meanings. > > > > And even if I were to accept the notion that this document specifies a > > novel > > derivation of RFC 2119 (the notion that it *modifies* it being patently > > absurd), that ship has also sailed. I can also easily point to RFCs > > that do > > things like specify ALLS CAPS versions of these words have one > > meaning, Mixed > > Case another, and lower case yet another. > > > >> Does anyone seriously expect this new nuance of usage to be read and > >> remembered by average readers of this document? > > > > The better question is does anyone seriously expect anyone to assume, > > given > > abundant evidence to the contrary, that the lower case versions of > > these words > > will be taken to have RFC 2119 meaning? > > > >> FWIW, it took me about 3 minutes to make the relevant changes, below. > >> Case-sensitivity in semantics invites comprehension problems here. > >> Worse, there is absolutely no need or benefit in creating the problem > >> for this document. At a minimum, please do not try to modify IETF > >> document writing policy on the fly. > > > > You're the one who is arguing for a modification to the *actual* IETF > > document > > writing policy here. > Agreeing with that. > >> > The formal syntax use the Augmented Backus-Naur Form (ABNF) > >> [RFC5234] > >> > notation including the core rules defined in Appendix B of RFC 5234 > >> > [RFC5234]. > >> > > >> > In examples, "C:" and "S:" indicate lines sent by the client and > >> > server respectively. Line breaks that do not start with a new "C:" > >> > or "S:" exist for editorial reasons and are not a part of the > >> > protocol. > >> > > >> > This document uses the term "priority" specifically in relation to > >> > the internal treatment of a message by the server: messages with > >> > higher priorities may be given expedited handling, and those with > > > >> may -> can > > > > > >> > lower priorities may be handled only as resources become available. > > > >> may -> can > > > > Again, given the loosey-goosey nature of this document overall, I > > don't think > > precision is really required, but if it is, both of these changes are > > somewhat > > objectionable. > > > > Like it or not, "may" and "can" are *not* synonyms. "Can" is more > > assertive, > > and carries with it a flavor that's closer to "should", whereas "may" is > > expresses a possibilit with no preference. > > > > We're talking about prioritization methodology here, specifically > > expedited > > handling and deferred processing. There can be overhead associated > > with both of > > these, and we should not be encourage the use of these techniques when > > it isn't > > absolutely necessary. > > And yes, I'm being very pedantic here. That's what you're going to get > > when > > you elect to go down this path. > :-) > > > >> > > >> > 3. Definition of the Priority SMTP Extension > >> > > >> > The Priority SMTP service extension is defined as follows: > >> > > >> > > >> > > >> > > >> > Melnikov & Carlberg Expires November 25, 2012 > >> [Page 3] > >> > > >> > Internet-Draft Message Transfer Priority SMTP Extension May > >> 2012 > >> > > >> > > >> > 1. The textual name of this extension is "Priority Message > >> > Handling". > >> > > >> > 2. The EHLO keyword value associated with this extension is "MT- > >> > PRIORITY". > >> > > >> > 3. The EHLO keyword has no parameters. Parameters are reserved > >> for > >> > possible future extensions and MUST be ignored by clients that > >> > don't understand them. > >> > > >> > 4. No additional SMTP verbs are defined by this extension. > >> > > >> > 5. One optional parameter ("MT-PRIORITY") is added to the MAIL > >> FROM > >> > command. The value associated with this parameter is a decimal > >> > integer number from -9 to 9 (inclusive) indicating the priority > >> > of the email message. The syntax of the MT-PRIORITY > >> parameter is > >> > described by the ABNF non-terminal defined in > >> > Section 6. Higher numbers mean higher priority. > > > >> As a minor point, the form of -9 to 9 seems more complicated than > >> useful. Is there a need for 19 values? I'd think that 0 to 9 would be > >> sufficient. > > > > Well, to be fair, the specification only requires support for six > > distinct > > values: > > > > A message priority is a decimal integer in the range from -9 to 9 > > (inclusive). SMTP servers compliant with this specification are not > > required to support all 19 distinct priority levels (i.e. to treat > > each priority value as a separate priority), but they MUST implement > > at least the following 6 distinct priority levels: -4, -2, 0, 2, 4, > > 9. I.e. an implementation that only supports the 6 priority levels > > will internally round up a syntactically valid level that isn't > > supported to the next higher supported number. For example, such an > > implementation will treat priority values below and including -4 as > > priority -4, priority -3 as priority -2, and all priorities starting > > from 5 are treated as priority 9. An SMTP server MAY support more > > than 6 different priority levels. Decision about which levels to > > support in addition to the 6 mentioned above is a local matter. > > > > Now, I have no idea what it actually means to "support" six values, but I > > assume it means that if you only make a processing distinction between > > five or > > fewer values total, if you support only one "lower than normal" > > priority, or > > you support fewer than three "higher than normal" priorities, you cannot > > implement this specification. (Note I'm assuming 0 is "normal" here - see > > below.) > More or less, yes. > > > > Of course there's a trivial way around this: You simply state that, as > > a matter > > of implementation policy, you only support X number and here's the > > mapping. > > This would allow, say, a system that only does the old X.400 non-urgent, > > normal, urgent thing to claim support. > Right. And there is already such a mapping in Appendix B. > >> For that matter, why are many values needed? What is the basis for > >> choosing to have a range of more than a few values? > > > > IMO this is one of the rare cases where X.400 was spot-on correct. > > > >> This appears to be the only place the provides semantics to the priority > >> number. As such, it should be more thorough. The critical issue in > >> assigning the number, I think, is trying to get independent originators > >> to assign numbers according roughly the same criteria. For example, if > >> I label "average" messages I send as as 0 and you label them as 1, then > >> your messages get preferential treatment over mine, although that was > >> not your intent. (Assuming you're not trying to game the service...) > > > >> This issue goes to the core of the usage model for the feature: It > >> really needs an environment tailored to its use, with all participants > >> not only within the same trust system, but sharing the same priority > >> assignment model/policy. It's probably good for this document to permit > >> a range of assignment models, but should note that an operational > >> requirement for use of the extension is that an assignment policy be > >> defined for all participants. > > > >> This document might, then, offer a candidate model, to be use by default > >> and absent one specific to an environment. > > > > Well, this goes to the problem I have with the entire document - I > > have no real > > idea what the policy associated with these priorities is supposed to > > be. We > > have a prioritization capability in our product and I can tell you > > what it > > does, but s to whether or not it satisfies the intended target of this > > specification, I realy couldn't say. > I hope I clarified this in -16. Also look at Appendix A and Appendix B. > > More generally, in a modern, high performance MTA that's capable of > > processing > > large numbers of messages simultaneously, there's a significant problem > > actually implementing mechanisms that are guaranteed to preferentially > > process > > certain messages. > > > > For example, suppose I have several dozen threads/processes/whatever > > connected > > up to a given system, all busy transferring large messages. A higher > > priority > > message comes in. If I shove this message on the thread that is the > > closest to > > being done, there may still be a significant delay. OTOH, if I start a > > new > > connection to handle it, what if I hit the limit on the number of > > connections > > the remote MTA will accept from me? > > > > Put another way, if you assume a fairly strict policy is needed, your > > point > > about this only being applicable in an environment that's specifically > > tailored > > for it is, if anything, an massive understatement. For this to provide > > a real > > priority boost with high reliability it's actually necessary to closely > > coordinate operational policies across all involved ADMDs. And not to > > put too > > fine a point on it, the level of technical acumen needed to actually > > do this > > sort of thing is something I've observed to be the exception and not > > the rule. > > > > All that said, I think this actually argues for putting in some > > statements > > as to what this document does *not* do. It calls for best effort to > > provide preferential processing, nothing more. It does *not* provide > > any sort of guarantees. > Fair enough, I will add some text about that. Best effort was certainly > the intent. > > And if that's not the case, then this needs to be experimental. > > > >> > 6. The maximum length of a MAIL FROM command line is increased > >> by 15 > >> > octets by the possible addition of a space, the MT-PRIORITY > >> > keyword and value. > >> > > >> > 7. The MT-PRIORITY extension is valid for the submission service > >> > [RFC6409] and LMTP [RFC2033]. > >> > > >> > 4. Handling of messages received via SMTP > >> > > >> > This section describes how a conforming SMTP server should > >> handle any > >> > messages received via SMTP. > >> > > >> > 4.1. Handling of the MT-PRIORITY parameter by the receiving SMTP > >> server > >> > > >> > The following rules apply to SMTP transactions in a server that > >> > supports the MT-PRIORITY parameter: > >> > > >> > 1. A conforming SMTP server MUST NOT refuse a MAIL FROM command > >> > based on the absence of the MT-PRIORITY parameter. > > > >> hmmm. For some operational environments, it will be essential to have > >> /all/ handling conform to the priority policy model in force for the > >> environment. In those cases, the absence of the parameter would be a > >> violation of the spec. > > > > Interesting point. I'm not sure what, if anything, to do about it. > > > >> > 2. If any of the associated s (as defined in Section > >> > 4.1.2 of [RFC5321]) are not syntactically valid, or if there is > >> > more than one MT-PRIORITY parameter in a particular MAIL FROM > >> > command, the server MUST return an error, for example "501 > >> syntax > >> > error in parameter" (with 5.5.2 Enhanced Status Code > >> [RFC2034]). > >> > > >> > 3. When inserting a Received header field as specified in Section > >> > 4.4 of [RFC5321], the compliant MTA/MSA SHOULD include the > >> > "PRIORITY" clause whose syntax is specified in Section 6. > >> > > >> > > >> > > >> > Melnikov & Carlberg Expires November 25, 2012 > >> [Page 4] > >> > > >> > Internet-Draft Message Transfer Priority SMTP Extension May > >> 2012 > >> > > >> > > >> > 4. If the sending SMTP client specified the MT-PRIORITY > >> parameter to > >> > the MAIL FROM command, then the value of this parameter is the > >> > message priority. > >> > > >> > 5. If no priority has been determined by the above, the server may > > > >> may -> can > > > > > >> > use its normal policies to set the message's priority. By > >> > default, each message has priority 0. > > > >> ouch. This chooses a particular model for meaning of the numbers, and > >> without having defined the model beforehand. > > > > I for one was assuming 0 was the normal, default priority. But now > > that you > > mention it, at least this needs to be made explicit. > I believe the document already says that, but I will double check. > >> That is, I think the problem with this default is that it really is > >> assuming a particular policy for meaning of the values, namely that > >> average mail is mid-priority, assuming the numbers have linear > >> semantics. > > > > That sure was what I was assuming. > Yes. > >> > The SMTP server MUST NOT allow upgraded priorities from untrusted > >> > (e.g. unauthenticated) or insufficiently trusted sources. (One > >> > example of an "insufficiently trusted source" might be an SMTP > >> sender > >> > which authenticated using SMTP AUTH, but which is not explicitly > >> > whitelisted to use the SMTP MT-PRIORITY service.) The server MAY, > > > >> It is good that this issue is raised, but it really requires an earlier, > >> separate and careful discussion of the need for this extension to be > >> used within an administered trust environment. Given such an > >> introductory section, the above text would be sufficient. > > > > Agreed. > Ok. > >> In its absence, the reference to a whitelist is based on the very large > >> assumption that participants in the extension are whitelisted. This is > >> not document elsewhere. > > > > True. > Hmm, Ok. > >> > however, allow an untrusted source to lower its own message's > >> > priorities -- consider, for example, an email marketer that > >> > voluntarily sends its marketing messages at low priority. > > > >> To beat the point a bit deader: this assumes a particular policy for > >> the meaning of the priority values. Worse, it also appears to > >> contradict the earlier default of 0, but perhaps I've misunderstood > >> that. > > > > I think that's a misunderstanding. > I already replied in another message that it is. > > I generally agree with the remainder of your comments, although I > > think some > > of them become less important as long as it's clear this doesn't provide > > guaranteees, but they still should be addressed. > I believe I addressed most of them in -15 and -16. I might need to add a > couple of clarifying sentences as per above. From stpeter@stpeter.im Fri Jun 1 13:42:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2188F11E80CE; Fri, 1 Jun 2012 13:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvduUC9wdaZN; Fri, 1 Jun 2012 13:42:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3C911E80C7; Fri, 1 Jun 2012 13:42:13 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9330140075; Fri, 1 Jun 2012 14:58:47 -0600 (MDT) Message-ID: <4FC928DE.6070503@stpeter.im> Date: Fri, 01 Jun 2012 14:41:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Shumon Huque References: <20120601170306.GA32180@isc.upenn.edu> In-Reply-To: <20120601170306.GA32180@isc.upenn.edu> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [apps-discuss] [dane] DANE for MUAs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 20:42:14 -0000 On 6/1/12 11:03 AM, Shumon Huque wrote: > On Fri, Jun 01, 2012 at 05:47:50PM +0100, Tony Finch wrote: >> I've started a draft for using DANE with IMAP, POP3, and message >> submission, but I've got a bit stuck deciding how to fit in with >> RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). >> >> RFC 6125 has the following example: >> >> A mail user agent that is connecting via IMAPS to the email service >> at "example.net" (resolved as "mail.example.net") might have five >> reference identifiers: an SRV-ID of "_imaps.example.net" (see >> [EMAIL-SRV]), DNS-IDs of "example.net" and "mail.example.net", and, >> as a fallback, CN-IDs of "example.net" and "mail.example.net". (A >> legacy email user agent would not support [EMAIL-SRV] and therefore >> would probably be explicitly configured to connect to >> "mail.example.net", whereas an SRV-aware user agent would derive >> "example.net" from an email address of the form "user@example.net" >> but might also accept "mail.example.net" as the DNS domain name >> portion of reference identifiers for the service.) >> >> I presume that the client would not actually use mail.example.net as a >> reference identifier unless DNSSEC is in use, otherwise that would not be >> secure and is therefore forbidden according to the rules a few paragraphs >> earlier in RFC 6125. > > That sounds correct to me. Agreed. That's the approach Matt Miller and I are taking for secure delegation in XMPP (we'll submit an I-D soonish). Peter -- Peter Saint-Andre https://stpeter.im/ From sm@elandsys.com Fri Jun 1 15:29:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6714C21F84DF for ; Fri, 1 Jun 2012 15:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0LVbi1E4A+V for ; Fri, 1 Jun 2012 15:29:45 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5567411E8116 for ; Fri, 1 Jun 2012 15:29:45 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.21]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q51MTRxp005349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2012 15:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1338589780; i=@elandsys.com; bh=LZnU+J2HqgYkS2sZNEfi8xwCtKuVEGyKCV25pSRWoec=; h=Date:To:From:Subject:Cc; b=rsQ4GKzmds/SNmpGp2lDbYNTyeMnQm4yWlf0OtGP7m1e+TrjOUxkyU/M0hJFmT7mv E8SRfGB99HJcac7ahetAJ3tt2T7/obxWrKlWVQPiq0IzgtfYTH8VAvssqKNKaDAR4B fnQC6Vsxv0GYIT96+8MzfAxKHD2u2N7w5s6fBxuQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1338589780; i=@elandsys.com; bh=LZnU+J2HqgYkS2sZNEfi8xwCtKuVEGyKCV25pSRWoec=; h=Date:To:From:Subject:Cc; b=q5TIIPGdSctAv9epmdYZltw6n4E8CtMzZjh19LID/EXWvHD+yLAkGgAUkjcomOQid CrNzXrFpkDqvEfeH7J5jBje1YuYZYghZcWXMHn+Y/Da021CuCCBrFrgYEYHguHii9l b/rT6tnKBGg13y4rUVbwcKdDXa68RFsbqgDne/yM= Message-Id: <6.2.5.6.2.20120601150427.0b1e51d8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Jun 2012 15:27:15 -0700 To: "Murray S. Kucherawy" , Alexey Melnikov From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-appsawg-about-uri-scheme.all@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Changes to draft-ietf-appsawg-about-uri-scheme-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 22:29:47 -0000 Hi Alexey, Murray, I have not seen any objections about the changes in draft-ietf-appsawg-about-uri-scheme-05. I propose the following changes for the last revision: Section 2.1 (proposed): 2.1. URI Scheme Syntax The "about" URI syntactically conforms to the rule below, expressed using Augmented Backus-Naur Form (ABNF) [RFC5234]: about-uri = "about:" about-token [ about-query ] [ about-fragment ] about-token = *pchar about-query = "?" query about-fragment = "#" fragment pchar = query = fragment = In terms of RFC 3986, part corresponds to , to the query component and to the fragment component of the URI. The second sentence about the IRI prohibition in the "Encoding Considerations" paragraph and the reference to RFC 3987 should be removed. Occurrences of "Special-purpose" in Section 5.2 will be replaced with "Well-known". Regards, S. Moonesamy From ned.freed@mrochek.com Fri Jun 1 18:00:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6C911E808C; Fri, 1 Jun 2012 18:00:04 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9kwSxvY+3j3; Fri, 1 Jun 2012 18:00:03 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id AB77A11E8087; Fri, 1 Jun 2012 18:00:03 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG6I7B20GW002W9B@mauve.mrochek.com>; Fri, 1 Jun 2012 17:59:59 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG54121Q0W0006TF@mauve.mrochek.com>; Fri, 1 Jun 2012 17:59:56 -0700 (PDT) Message-id: <01OG6I78VF6I0006TF@mauve.mrochek.com> Date: Fri, 01 Jun 2012 16:56:51 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 01 Jun 2012 13:36:45 -0700 (PDT)" <01OG6914E4MS0006TF@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC7204B.8020403@dcrocker.net> <01OG663WXFQA0006TF@mauve.mrochek.com> <4FC91F09.7070701@isode.com> <01OG6914E4MS0006TF@mauve.mrochek.com> To: Ned Freed Cc: draft-melnikov-smtp-priority-13.all@tools.ietf.org, Ned Freed , iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 01:00:04 -0000 > OK, let me take a look at -16 and I'll see what else, if anything, needs to be > said. (I was looking at -15.) Well, I looked, and now I'm even more confused. The statements about implementations having to support at least six levels (with no indication of what support means) are still there, but so are the Appendices about mappings with far fewer levels. So let me put this in a form of a question. Suppose I have an implementation that is capable of storing and transferring all of the MT-PRIORITY levels, but internally is only capable of doing the three X.400 levels. Would such an implementation be able to offer this extension? Ned P.S. The text about defaults and what is the normal level is now fine. From yaojk@cnnic.cn Fri Jun 1 18:47:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8726621F8771 for ; Fri, 1 Jun 2012 18:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.662 X-Spam-Level: X-Spam-Status: No, score=-100.662 tagged_above=-999 required=5 tests=[AWL=1.936, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y+h8lRs9yAt for ; Fri, 1 Jun 2012 18:47:20 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id C11AE21F876C for ; Fri, 1 Jun 2012 18:47:17 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO yaoguanchengpc) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 02 Jun 2012 09:47:12 +0800 From: "Jiankang Yao" To: Date: Sat, 2 Jun 2012 09:47:11 +0800 Message-ID: <000301cd4061$a194a090$e4bde1b0$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CD40A4.AFB7E090" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1AYZpFcTk3B+LVT7WscSksv+Nu6Q== Content-Language: zh-cn Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-6lowpan-btle-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 01:47:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01CD40A4.AFB7E090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Directorate reviewer for = this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ). =20 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.=20 =20 Document: draft-ietf-6lowpan-btle-07 Title: Transmission of IPv6 Packets over Bluetooth Low Energy Reviewer: Jiankang Yao=20 Review Date: 1 June 2012 =20 Summary: This draft is well-written and ready for publication as an Standards Track document. =20 Major Issues: none Minor Issues: none Nits:=20 In section 2: In the rest of the draft---> In the rest of this document =20 =20 In section 3.2 :=20 This draft assumes ---=E0 This document assumes =20 Comments: This draft will be a RFC. So =93this document=94 will be better than = =93the draft=94 =20 ------=_NextPart_000_0004_01CD40A4.AFB7E090 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have been selected as the Applications Area = Directorate reviewer for this draft (for background on appsdir, please = see http://trac= .tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ).

 

Please resolve these comments along with any = other Last Call comments you may receive. Please wait for direction from = your document shepherd or AD before posting a new version of the draft. =

 
Document: =
draft-ietf-6lowpan-btle-07

Title: = Transmission of IPv6 Packets over Bluetooth Low = Energy

Reviewer: Jiankang =
Yao 
Review Date: 1 June =
2012
 
Summary:=A0 This draft is well-written and ready for =
publication as an Standards Track document.
 
Major =
Issues: none
Minor =
Issues: none
Nits: =
In section =
2:
In the rest of the draft---> In =
the rest of this document

 

 

In section 3.2 :

=A0This draft assumes ---=E0 This document = assumes

 

Comments:

This draft will be a = RFC. So “this document” will be better than “the = draft”

 

------=_NextPart_000_0004_01CD40A4.AFB7E090-- From superuser@gmail.com Fri Jun 1 20:48:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCD211E80C6 for ; Fri, 1 Jun 2012 20:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ha7Qaz58jtpf for ; Fri, 1 Jun 2012 20:48:36 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 21AE611E808C for ; Fri, 1 Jun 2012 20:48:35 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2270171lbb.31 for ; Fri, 01 Jun 2012 20:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=joXV9uegR3/TiyEGnNy2C1FPRtbtHi1pSLfvhylY25I=; b=AXwpK7D5ILMYDPwaD0mUtw1O6XQKdKSKrH6YzH3efwRuLxnUZxVoRMrt3rNHgvE9b2 uGYlUFM6m41lyVRrgELkBT67zS1/A7A1bYSBPV7M4R+Un2n+wwFRPA3JT4Qsxn/X+fIx 6Y8HYrNkebwU9QnMLKVCezY01geawCpixcxlsZVZ/ycERg3Y2mR/nqyldlEO363OgcVl hDCX7Yic18oXwrTZ+rlLSY5+N1jRwYAGrelZZpfsUzTjxtj8fsyIHOKN0+4CYH0Lo3TK ktWpZfTSaUDfQGmzSu2IHJyeQWAa2nyLz7b/mMOskxNVf3BXPN/7mkqmX1OWpMQ/Gm2r zvyA== MIME-Version: 1.0 Received: by 10.152.104.171 with SMTP id gf11mr5387112lab.5.1338608914982; Fri, 01 Jun 2012 20:48:34 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Fri, 1 Jun 2012 20:48:34 -0700 (PDT) Date: Fri, 1 Jun 2012 20:48:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=f46d04083de7dee4f004c1752ce8 Subject: [apps-discuss] Change of address X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 03:48:37 -0000 --f46d04083de7dee4f004c1752ce8 Content-Type: text/plain; charset=ISO-8859-1 Hi all, quick administrative note: With a change in employers comes a change in address. My IETF activity now lives at this one. All of the datatracker and tools aliases have been updated, so replies to those will now come to me here with no action needed by you. Direct replies to my old address will bounce after Sunday, and I may not notice them before then. Please update your address books accordingly. Have a good weekend, -MSK, APPSAWG and WEIRDS co-chair --f46d04083de7dee4f004c1752ce8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, quick administrative note:

With a change in employers comes = a change in address.=A0 My IETF activity now lives at this one.

All = of the datatracker and tools aliases have been updated, so replies to those= will now come to me here with no action needed by you.=A0 Direct replies t= o my old address will bounce after Sunday, and I may not notice them before= then.=A0 Please update your address books accordingly.

Have a good weekend,

-MSK, APPSAWG and WEIRDS co-chair

--f46d04083de7dee4f004c1752ce8-- From Jeff.Hodges@KingsMountain.com Fri Jun 1 21:38:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026DF21F898C for ; Fri, 1 Jun 2012 21:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.195 X-Spam-Level: X-Spam-Status: No, score=-98.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MANGLED_EMAIL=2.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aRVd5VO+3jb for ; Fri, 1 Jun 2012 21:38:40 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id CF3E921F8986 for ; Fri, 1 Jun 2012 21:38:39 -0700 (PDT) Received: (qmail 7989 invoked by uid 0); 2 Jun 2012 04:38:39 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 2 Jun 2012 04:38:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=qz2va2nZK+4Ejho4U4isWBK6c5q06J623q2fS8RhVRg=; b=ox5ZZ5WTjDBUJ5EsEkBbZKujo0rXgnT6X0L3IjTVYski5812C6yMh1+u6hGHN53Dh0U02ijoa2EG4OSgy8+2vcxtYzE+YCYjK9YaHi5gPr1h8Elwx3eAIAjGmm5khS3y; Received: from [24.4.122.173] (port=36095 helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Sag6o-0002Gb-PU; Fri, 01 Jun 2012 22:38:38 -0600 Message-ID: <4FC998CD.4040407@KingsMountain.com> Date: Fri, 01 Jun 2012 21:38:37 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Apps Discuss , IETF WebSec WG , draft-ietf-websec-strict-transport-sec@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [apps-discuss] AppsDir review of draft-ietf-websec-strict-transport-sec X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 04:38:42 -0000 Hi, thanks again for your review of draft-ietf-websec-strict-transport-sec-06, Murray. I've interpreted and applied your comments [1] to -08, yielding an -09 working copy. In the below, "done in -09" means done in my working copy of -09 -- which I haven't published quite yet. I'm trying to resolve the unrecognized directives language thing being discussed on websec@ before doing so. thanks again, =JeffH [1] HSTS: AppsDir Editorial comments http://trac.tools.ietf.org/wg/websec/trac/ticket/46 > MINOR ISSUES: > > Section 2.3.2: Your Security Considerations section should probably include > a pointer to this section. very good point. done in -09. > Section 3: Are the latter two paragraphs really necessary? I only find such > statements useful when minimum conformance is not the same thing as full > conformance. It's apparently helpful for readers with a strong W3C-style spec background. I'll leave them in. > Section 4, HTTP Strict Transport Security Host: Should this say "for all > web pages it serves" or similar? That sort of detailed requirements are given in Section 7 Server Processing Model. I'd rather keep the term definition to be high-level. Plus, the statement isn't strictly true -- an HSTS Host doesn't have to return the STS header field for all resources on all requests. (again see S7) > Section 4: Expand ABNF on first use, and include a reference to RFC5234. > (The reference could instead go in Section 6.) > > Section 6.1: The ABNF you have there requires a leading semi-colon. Based > on your examples, I think instead you want: > > Strict-Transport-Security = "Strict-Transport-Security" ":" > directive *( ";" [directive] ) > > Note that this also allows: > > Strict-Transport-Security: foobar;;;;;;;;;;;; > > Is that okay? > > Section 6.1: What's "the STS directive extension point"? > > Section 6.1.1: I think the "delta-seconds" should be: > > delta-seconds = 1*DIGIT > ; defined in Section 3.3.2 of [RFC2616] > > The angle-bracket notation you have there doesn't seem to be normal. > > Section 6.2: The second example isn't strictly correct because no space is > allowed around the semi-colon in the ABNF in Section 6.1. It looks like you'll > need to add optional whitespace at various points in the ABNF, or correct the > example. the above issues were discussed on list, the spec is based on RFC2616 ABNF (not RFC5234), as well as there having been changes to aspects of the above quoted text from -06 to -08. please refer to at least -08. thx. > Section 8.1: The "Note:" includes stuff that should be normative, and thus > is not appropriate for a side discussion note. It doesn't quite jive with > how you've defined use of "Note:" as a document convention. "Note:" removed. done in -09. > Section 8.2: The "Note that..." at the end threw me for a loop. How does > what's said in 8.2 imply what's stated here? For example, what does it say > about SMTP or FTP? sec 8.2 (now 8.3) was heavily re-written in rev -07 -- I believe this comment no longer applies. > Section 10.1: This discussion got me wondering why an absolute time for > HSTS Policy expiration isn't used instead of a delta. Perhaps that could be > explained somewhere like Appendix A. (Yes, I know about time synchronization, > but this text gave me pause.) as I recall (this was early in the HSTS work), there were the time sync issues plus the whole mess with cookies having both "expires" and "max-age" and other non-trivial stuff such as needing to parse various date formats because server implementors got it wrong but its incumbent on UA implementors to try to be a lenient as possible, etc. Without rummaging back through all those discussions, I've added this note to Appendix A "Design Decision Notes" in -09, and hope it's sufficient... The max-age approch of having the HSTS Host provide a simple integer number of seconds for a cached HSTS Policy time-to-live value, as opposed to an approach of stating an expiration time in the future was chosen for various reasons. Amongst the reasons are no need for clock syncronization, no need to define date and time value syntaxes (specification simplicity), and implementation simplicity. > Section 10.3: "example-ca.com" is not a reserved domain name for use in > examples. Suggest "ca.example.com" or "ca.example". Same issue with > "example-ca-services.net". done in -09. > Section 14.2: The "but the attacker has established somewhere" clause > doesn't parse for me. What's it trying to say? clarified in -09: "...but that the attacker has managed to register in the DNS and point at an HTTP server under the attacker's control.." ##### Ok, so amongst the below "NITS" comments was the "a HSTS" vs "an HSTS", as well as "a STS" vs "an STS". I did some research (e.g. Chicago Manual of Style) and will change 'em all to the "an" form. Those various comments are elided from the below in a perhaps vain attempt at shortening the below. > NITS (mostly trying to save the RFC Editor some work here): > > There are so many important references to [ForceHTTPS] that I think it > might be helpful to include page or section numbers for those. I added section #s to a couple more [ForceHTTPS] citation occurrences. > Section 1: The Abstract uses "Web" as a proper noun, but this section > includes uses of it that are all lowercase. I believe it should be used > one way or the other throughout the document. I fixed the occurrences in the abstract. done in -09. > Section 1: "Section", when referring to a section of a document, should be > capitalized. (Also occurs in a few other places.) not sure what's being referred to here. "Section" is capitalized when it is used to denote an explicit section in a cited doc. Am declining to capitalize "section" in phrases such as "This section..." > Section 2.2, bullet 1: s/to be/such that they are replaced by/ > > Section 2.2, bullet 3: s/to a HSTS Host/to an HSTS Host/ sec 2.2 re-written in -07/-08, decline. > Section 2.3.1.1: Define or provide a reference for what Firefox is, in case > it's somehow not in common use at the time some future reader gets this. s/Firefox/web browser extension/ done in -09. > Section 2.3.1.2: Define or expand "CA" on first use. done in -09. > For that matter, would > it be possible to reference something that talks about the difference between > self-signed and CA-signed certificates, and why they get different treatment? suggestions welcome. > Section 2.3.1.3: Define or expand "SWF" on first use. > > Section 2.3.1.3: s/by injecting script/by injecting a script/ done in -09. > > Section 2.4.1.1, bullet 1: s/interacted with/accessed/ > > Section 2.4.1.1, bullet 3: s/to persistently remember/to retain persistent > data about/ > > Section 2.4.1.1, ending Note: The last "," should be a ";", or a period > followed by a new sentence. done in -09. > > Section 4: Suggest ending terms with ":" so that you don't get things like > how "domain name label" looks in this version of the draft. > > Section 4, "HTTP Strict Transport Security Host": s/policy/Policy/, so it's > clear we're using your definition. done in -09. > > Section 4, "HTTP Strict Transport Security Policy": Is "Policy" right here? > Isn't it really a "Protocol"? perhaps. text ? > Section 4, "HTTP Strict Transport Security Policy": s/specified/defined/ > (so as to avoid "specified in this specification") done in -09. > Section 4, "Local policy": Why is "configuration settings" quoted? quoted no longer. done in -09. > Section 5 and beyond: You define "HSTS Policy" and "HSTS Host" (note > capitalization), but use "HSTS policy" and "HSTS host" in numerous places. > Best to be consistent agreed. thought I'd caught them all. done in -09. > Section 5, second paragraph: All-lowercase "may" should probably be "MAY". It's on "overview" -- those are not normative MAYs, lowercase usage is on purpose. declined. > Section 6.1.2: s/which/that/ I prefer which. declined. > Section 7: s/facets:/facets,/; s/the second/and the second/ stylistic preference, declined. > Section 7.1: s/difficult to uniformly emit STS header fields/difficult to > emit STS header fields uniformly/ stylistic preference, declined. > Section 7.2, second bullet: Add a matching "--" after "components". some modest fixups made to that bulleted list. done in -09. > Section 8.1.1: s/that the host responded to/to which the host responded/ done in -09. > Section 8.1.1: That last paragraph is one big long sentence. Suggest > breaking it up. text? > Section 8.5: The "For example, ..." is a sentence fragment. done in -09. > Section 9, bullet 2: Remove the "," after "label". addressed in -07. > Section 9, bullet 2: s/latter,/latter;/ addressed in -07. > Section 9, bullet 3: The (".") should come after the hex. done in -09. > Section 10: "This section is non-normative." (cringe; I'm still of the > opinion that a section is implicitly non-normative if it has no normative > text in it, and these notations are extraneous) am being purposefully painfully explicit with their usage in the two sections where they occur. Keeping them. > Section 10.1, fourth paragraph: This is another sentence fragment. addressed in -07. > Section 10.2: s/their own/its own/ (the noun is singular, the verb has to > agree) done in -09. > Section 10.2, second paragraph: s/certificates, and their own/certificates > and its own/; various other "their/they" to "its/it", because "organization" > isn't plural done in -09. > Section 10.2, note: s/attack, see/attack. See/ > > Section 10.3: s/implications -- for/implications. For/ done in -09. > Section 10.3, second paragraph: s/which/that/ stylistic. declined. > Section 10.3: s/HSTS, and that have/HSTS that have/; s/application, > would/application would/ done in -09. > Section 11: (cringe) > > Section 11: You variably spell it "implementors" and "implementers". I'm > pretty sure the latter is correct, but either way, some of them are not. :-) done in -09. > Section 11.1: s/Establishment"),/Establishment")/ > > > Section 11.2, Note: s/basis -- see/basis. See/ > > Section 11.2, Note: s/is independent of/is independent of,/ done in -09. > Section 11.2: Opens with a non-sentence. > > Section 11.3: Opens with a non-sentence. > > Section 11.4: Opens with a non-sentence. fixed in -07. > Section 11.4, Note: s/to more clearly define the term(s)/to define the > term(s) more clearly/ done in -09. > Section 11.5: Opens with a non-sentence. fixed in -07. > Section 12: All lowercase MUST here. eh? I believe the "MUST NOT" at the end of S12.2 should remain. that's the only one. > Section 12.2: Seriously nitty here: The "host, and the port (if present)" > doesn't make it clear if the separating colon is included. those are production names from the ABNF in S12.1, so I don't think it needs addressing. If this is a problem, then you need to comment on the appropriate draft of the httpbis suite-o-drafts (draft -p1 me thinks), too. > Section 14.1, first bullet: Missing close parenthesis. doh. done in -09. > Section 14.1, second bullet: s/to no longer be regarded/to cease being > regarded/ done in -09. > Section 14.1: s/And even if the risk/Even if the risk/ > > Section 14.1: s/as a HSTS Host. Thus as/as an HSTS Host. Thus, as/ > > Section 14.1: s/But once/Once/ done in -09. > Section 14.2: s/to adequately protect/to provide adequate protection for/ stylisticly declined. > Section 14.3: s/to manually configure HSTS Policy/to configure HSTS Policy > manually/ stylisticly declined. > Section 14.3, third "*" bullet: Contains two sentence fragments. done in -09. > Section 14.3, final paragraph: s/to automatically regard/to regard > automatically/ stylisticly declined. > Section 14.5: Expand NTP on first use, and provide a reference. done in -09. > Section 14.6: Opens with a sentence fragment. rewrote this section in -09. please review. --- end From sm@elandsys.com Sat Jun 2 00:56:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B2121F898A for ; Sat, 2 Jun 2012 00:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH-UOl3e8hMf for ; Sat, 2 Jun 2012 00:56:29 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A906D21F8986 for ; Sat, 2 Jun 2012 00:56:29 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.21]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q527uHWV020989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 2 Jun 2012 00:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1338623788; i=@elandsys.com; bh=bByzgh/AO2TbChwGWatBriQb295QPXAves8txZ9bFMw=; h=Date:To:From:Subject:Cc; b=aPN5RQ0v3AZbS51kqAUJYgZ2qAA9oIHYonKb2+RRTm7eL1qHCUzHrBXSE8HMzOZhj u03ruPj+fzOdEKlQzcxlh7SOJQWzDOwrCxEGmTXXvfEfycAwl9+Jpl3KoVxNT6e4mP jg0J36ZGpGue6tTV9hMdYULfcyXt+uqi0wtiY0vs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1338623788; i=@elandsys.com; bh=bByzgh/AO2TbChwGWatBriQb295QPXAves8txZ9bFMw=; h=Date:To:From:Subject:Cc; b=MjIDIQoBMSgGqwCn/41JA6hQHUCIEcRYDptcYa86aKCPR9SUsbzXPfrnvcxoS8v9e 0lllfN75u6+S6VzCgvaFeMOTSJAZtSCRDjzE9qQ+qV5HtNeGWGgr7VMfMpSoN5hoNR irHpbOV+TOxX81HqWuwIxHzv1bVT5CM7wIXSrY1M= Message-Id: <6.2.5.6.2.20120601222358.09e42fa8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 02 Jun 2012 00:10:17 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Apps Area Directorate Report for May 2012 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 07:56:30 -0000 The Applications Area Directorate provides semi-formal reviews of Internet-Drafts as a way to improve the quality of IETF specifications. The directorate consists of the Working Group Chairs of the Applications Area and recognized experts in the Applications Area. The following reviews were performed in May 2012: Reviewer I-D Julian Reschke draft-levine-application-gzip-02 Glenn Parsons draft-ietf-eai-rfc5721bis-04 Glenn Parsons draft-ietf-eai-5738bis-03 Larry Masinter draft-ietf-appsawg-mime-default-charset-03 Carsten Bormann draft-ietf-mboned-64-multicast-address-format-01 Enrico Marocco draft-ietf-mboned-mcaddrdoc-03 Yoshiro Yoneya draft-ietf-netext-access-network-option-10 Alexey Melnikov draft-ietf-spfbis-experiment-09 Aaron Stone draft-ietf-eai-5738bis-03 Aaron Stone draft-ietf-eai-popimap-downgrade-05 Salvatore Loreto draft-ietf-appsawg-http-forwarded-02 Eran Hammer draft-ietf-mile-template-04 D. Crocker draft-ietf-bmwg-2544-as-03 Mark Nottingham draft-ietf-appsawg-media-type-regs-07 S. Moonesamy draft-melnikov-smtp-priority-13 S. Moonesamy draft-ietf-dnsext-dnssec-bis-updates-18 Murray Kucherawy draft-polk-ipr-disclosure-03 Murray Kucherawy draft-farrresnickel-ipr-sanctions-05 Vijay Gurbani draft-ietf-ledbat-congestion-09 William Mills draft-ietf-abfab-gss-eap-06 Carsten Bormann draft-ietf-dccp-udpencap-10 Salvatore Loreto draft-ietf-avtcore-monarch Henry S. Thompson draft-camarillo-rai-media-policy-dataset-01 Pending reviews are listed at http://trac.tools.ietf.org/area/app/trac/report/1 There were 23 reviews last month compared to 3 reviews in May 2011. The Security Area Directorate performed 11 reviews last month. Aaron Stone and Eran Hammer-Lahav stepped down from the Applications Area Directorate. I would like to thank them for sharing their expertise through the reviews they performed. Regards, S. Moonesamy On behalf of the Applications Area Directorate http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From julian.reschke@gmx.de Sat Jun 2 03:59:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BEF21F8A55 for ; Sat, 2 Jun 2012 03:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.199 X-Spam-Level: X-Spam-Status: No, score=-105.199 tagged_above=-999 required=5 tests=[AWL=-2.600, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9PH1DGC4WPt for ; Sat, 2 Jun 2012 03:59:31 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B025721F8A42 for ; Sat, 2 Jun 2012 03:59:30 -0700 (PDT) Received: (qmail invoked by alias); 02 Jun 2012 10:59:29 -0000 Received: from p54BB353B.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.53.59] by mail.gmx.net (mp030) with SMTP; 02 Jun 2012 12:59:29 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/dQDgu5MndEGq48nXW4PSND0FpzQF35CBnRPn29/ IRDsDnpQhUyg1f Message-ID: <4FC9F20F.6060205@gmx.de> Date: Sat, 02 Jun 2012 12:59:27 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: HTTP Working Group References: <7B9B7D15-9510-4C90-9B77-EEC55262758C@mnot.net> In-Reply-To: <7B9B7D15-9510-4C90-9B77-EEC55262758C@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps Discuss , Mark Nottingham , Mike Kelly Subject: Re: [apps-discuss] FYI: LCI -02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 10:59:31 -0000 On 2012-06-01 03:08, Mark Nottingham wrote: > We've published an -02 draft of LCI: > > > and intend to request publication as an Individual Submission Informational RFC soon (the link relations have just been submitted for review). Feedback still welcome (http list is best, I think). > ... HTTPbis introduces a registry for cache directives (see ). Would it make sense to change the dependency from RFC 2616 to HTTPbis, and to register as defined in Part 6? Best regards, Julian From lear@cisco.com Sat Jun 2 06:00:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E65821F8665; Sat, 2 Jun 2012 06:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL8b4D4QqjZ5; Sat, 2 Jun 2012 06:00:50 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id E16E221F865A; Sat, 2 Jun 2012 06:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=4616; q=dns/txt; s=iport; t=1338642050; x=1339851650; h=message-id:date:from:mime-version:to:cc:subject; bh=pOhlmC+eumfcB67KHpASchgU1L+bBCW8LzySfz2x8hQ=; b=MssU/AE/GnLbWt1c2cvdQ7+AoI8GMfJgEVV5jgYKO5bq6HyQSIvb21wQ ZliqoiIRbPPa5ukZCrC1/3wx4i0/8OSwy2SjU4sXdxCvFB+I26T+sLBGx /mIbJJvUInGwCjcSvDfSmg+8CugrGxL2zKcO6RPIIJsY7g1AzM6JeZx10 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIcNyk+Q/khL/2dsb2JhbABFhU6uT4EHghgBAQEDEwEQVQEFGhANFgsCCwMCAQIBSwEMAQcBAR6HZAWXUY0Wkg2LEYR+gRIDlRuOEIFmgmI X-IronPort-AV: E=Sophos;i="4.75,701,1330905600"; d="scan'208,217";a="5291680" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 02 Jun 2012 13:00:48 +0000 Received: from dhcp-10-61-99-222.cisco.com (dhcp-10-61-99-222.cisco.com [10.61.99.222]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q52D0lu1024078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jun 2012 13:00:48 GMT Message-ID: <4FCA0E7F.7020109@cisco.com> Date: Sat, 02 Jun 2012 15:00:47 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: draft-ietf-intarea-ipv4-update.all@tools.ietf.org, "apps-discuss@ietf.org" X-Enigmail-Version: 1.4.1 Content-Type: multipart/alternative; boundary="------------060505010801040403010400" Cc: Internet Area , IETF Discussion Subject: [apps-discuss] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 13:00:51 -0000 This is a multi-part message in MIME format. --------------060505010801040403010400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Document: draft-ietf-intarea-ipv4-id-update-05 Title: Updated Specification of the IPv4 ID Field Reviewer: Eliot Lear Review Date: 2 June 2012 IETF Last Call Date: 31 May 2012 Summary: This draft is quite well written, and is *very* nearly ready for publication. This draft is well written, and from the applications perspective represents an important step to improving performance and error reduction. It uses a new requirements call-out style that I would class as experimental, but not bad. It is worth people reading this draft and deciding if they agree with Joe's approach. Major issues: None (Yay!). Minor issues: Section 4 needs to be reconciled a bit with Section 6.1. Specifically: > The IPv4 ID field can be useful for other purposes. And >> IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly. My suggestion is to drop the above sentence from Section 4. In Section 6.1: > Datagram de-duplication can be accomplished using hash-based > duplicate detection for cases where the ID field is absent. Under what circumstances would the ID field be absent? > >> Sources of non-atomic IPv4 datagrams using strong integrity checks > MAY reuse the ID within MSL values smaller than is typical. Is the issue really the source using strong integrity checks or the destination in this context? What is typical? Nit: Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3? Eliot --------------060505010801040403010400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Document: draft-ietf-intarea-ipv4-id-update-05
Title: Updated Specification of the IPv4 ID Field
Reviewer: Eliot Lear
Review Date: 2 June 2012
IETF Last Call Date: 31 May  2012


Summary: This draft is quite well written, and is very nearly ready for publication.

This draft is well written, and from the applications perspective represents an important step to improving performance and error reduction.  It uses a new requirements call-out style that I would class as experimental, but not bad.  It is worth people reading this draft and deciding if they agree with Joe's approach.

Major issues:

None (Yay!).

Minor issues:

Section 4 needs to be reconciled a bit with Section 6.1.  Specifically:

 The IPv4 ID field can be useful for other purposes. 


And

  >> IPv4 ID field MUST NOT be used for purposes other than
   fragmentation and reassembly.

My suggestion is to drop the above sentence from Section 4.

In Section 6.1:


   Datagram de-duplication can be accomplished using hash-based
   duplicate detection for cases where the ID field is absent.

Under what circumstances would the ID field be absent?

   >> Sources of non-atomic IPv4 datagrams using strong integrity checks
   MAY reuse the ID within MSL values smaller than is typical.

Is the issue really the source using strong integrity checks or the destination in this context?  What is typical?

Nit:

Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3?


Eliot


--------------060505010801040403010400-- From barryleiba.mailing.lists@gmail.com Sat Jun 2 06:03:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16D321F8672; Sat, 2 Jun 2012 06:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.003 X-Spam-Level: X-Spam-Status: No, score=-103.003 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srIeHHNbQP9q; Sat, 2 Jun 2012 06:03:44 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B987121F8671; Sat, 2 Jun 2012 06:03:40 -0700 (PDT) Received: by lagv3 with SMTP id v3so2289707lag.31 for ; Sat, 02 Jun 2012 06:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OeKTWuKZ6GEQd9u+PN8pg+gFYXXlsvZd0bZTYzmzcrg=; b=ohCXoFXVaBsbFb6GIJUMvnDKi5WdN/PNry/H+L6SuF/Sl//3vRjDva7973taWVDmdf QAtamPoJVlEzdZjTux3e6jHfrlTBwqCTGHXRQcF+wTAz2hulTIbHTkm1uqmLjiix/NYt gx1crcVjI7LxTXwkv9pYmsLRWR77a4yAtS1eFMnZYfmlk8OpVfXYzMM3Wl+Wchx07/H6 dSfrv7T337cs4ph/o2g9zk1NV7bmF3L1DhfMJRdedQK8CjIUlSt/qjA01wt2hxPS6HQU h88GNU/psGf2caOZ1CQyuSTNlBz7eeSIjDnDnszXR7/S0EEF6tPjzwOWPmTpnSbWYL9f 4KyQ== MIME-Version: 1.0 Received: by 10.152.108.144 with SMTP id hk16mr6547257lab.2.1338642219659; Sat, 02 Jun 2012 06:03:39 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Sat, 2 Jun 2012 06:03:39 -0700 (PDT) In-Reply-To: <4FC998CD.4040407@KingsMountain.com> References: <4FC998CD.4040407@KingsMountain.com> Date: Sat, 2 Jun 2012 09:03:39 -0400 X-Google-Sender-Auth: W9f2FDEkeoDex3LC11GsoasJmOs Message-ID: From: Barry Leiba To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-websec-strict-transport-sec@tools.ietf.org, IETF WebSec WG , Apps Discuss Subject: Re: [apps-discuss] AppsDir review of draft-ietf-websec-strict-transport-sec X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 13:03:46 -0000 [Changed Murray's address to his new one.] >> Section 3: Are the latter two paragraphs really necessary? I only find >> such >> statements useful when minimum conformance is not the same thing as full >> conformance. > > It's apparently helpful for readers with a strong W3C-style spec background. > I'll leave them in. It might be a good idea, then, to put something like the following in at the beginning of the section: [[IESG Note: This section is for readers with a background in W3C specification style, of which we expect many. RFC Editor, please remove this note before publication.]] This will avoid the same question/complaint from ADs during IESG evaluation. I also suggest that you move the 2119 paragraph to the end of the section, to keep all three compliance-related paragraphs together. Barry From touch@isi.edu Sat Jun 2 07:50:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C95321F8535; Sat, 2 Jun 2012 07:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdACuNWqRnzV; Sat, 2 Jun 2012 07:50:29 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDFA21F8531; Sat, 2 Jun 2012 07:50:29 -0700 (PDT) Received: from [192.168.1.95] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q52Eo1WA022182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 2 Jun 2012 07:50:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <4FCA0E7F.7020109@cisco.com> Date: Sat, 2 Jun 2012 07:50:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FCA0E7F.7020109@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1278) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Internet Area , draft-ietf-intarea-ipv4-update.all@tools.ietf.org, IETF Discussion , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 14:50:30 -0000 Hi, Eliot, On Jun 2, 2012, at 6:00 AM, Eliot Lear wrote: >=20 > Document: draft-ietf-intarea-ipv4-id-update-05 > Title: Updated Specification of the IPv4 ID Field > Reviewer: Eliot Lear > Review Date: 2 June 2012 > IETF Last Call Date: 31 May 2012 >=20 >=20 > Summary: This draft is quite well written, and is very nearly ready = for publication. >=20 > This draft is well written, and from the applications perspective = represents an important step to improving performance and error = reduction. It uses a new requirements call-out style that I would class = as experimental, but not bad. It is worth people reading this draft and = deciding if they agree with Joe's approach. >=20 > Major issues: >=20 > None (Yay!). >=20 > Minor issues: >=20 > Section 4 needs to be reconciled a bit with Section 6.1. = Specifically: >=20 >> The IPv4 ID field can be useful for other purposes.=20 >=20 >=20 > And >=20 > >> IPv4 ID field MUST NOT be used for purposes other than > fragmentation and reassembly. >=20 >=20 > My suggestion is to drop the above sentence from Section 4. The two are not contradictory - the ID can be useful, but generating it = correctly is prohibitive and typically not done. > In Section 6.1: >=20 >=20 >> Datagram de-duplication can be accomplished using hash-based >> duplicate detection for cases where the ID field is absent. >>=20 >=20 > Under what circumstances would the ID field be absent? Replace "absent" with "known not unique". >> >> Sources of non-atomic IPv4 datagrams using strong integrity = checks >> MAY reuse the ID within MSL values smaller than is typical. >>=20 >=20 > Is the issue really the source using strong integrity checks or the = destination in this context? What is typical? The onus is on the source (of non-atomic datagrams) - if it includes = strong integrity checks (that are presumably validated by the receiver), = it then has more flexibility in its generation of the iD values. > Nit: >=20 > Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3? Not subsections of 2, but perhaps "3, 3.1, 3.2"?=20 Joe= From Claudio.Allocchio@garr.it Sat Jun 2 10:25:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCA521F8467; Sat, 2 Jun 2012 10:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFNZwFf1kl4v; Sat, 2 Jun 2012 10:25:09 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id DD5B521F8463; Sat, 2 Jun 2012 10:25:08 -0700 (PDT) Received: from mac-allocchio3.garrtest.units.it (mac-allocchio3.garrtest.units.it [140.105.201.3]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q52HP4H2099610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jun 2012 19:25:05 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q52HP4H2099610 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=Ts8TwpXFRMIdsfEIg0rLfgxx0goyVezmU424CWMSvDD+RxSnx7GO9NHkLUV6Kie/v iSPU+g+1iZHNNiKm4Z8v4Yz1FHQzOMfHOiyRzt9aLXOHWDRgtlX9DZB6K/m3QT9PYR3 rjvmRXZic7dbzz+O1A+WYtulx5a9CgfTCF/cHcc= Date: Sat, 2 Jun 2012 19:25:02 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: apps-discuss@ietf.org, draft-ietf-codec-opus.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-codec-opus-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 17:25:10 -0000 Hello all, I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-codec-opus-14 Title: Definition of the Opus Audio Codec Reviewer: Claudio Allocchio Review Date: 02.Jun.2012 IETF Last Call Date: 26.04.2012 IESG Telechat Date: 07.Jun.2012 Summary: This draft follows a quite unusual specification method: I see the real specification as is "a piece of software code", and the text specification is intented as an extended "comment" to the software code itself. I personally do not have a strong opinion if this method is an acceptable IETF practice; for sure it is the opposite of what's normally done, where the normative text gives instruction and suggestions on how to write the indipendent implementations (mostly software code) later on. If this is already common practice, just ignore my comment. If it is not, the IESG should consider adding a consideration about this pracice in the published document preface. Apart this general consideation, my guess is that the draft is well written and there are no major issues to prevent its publication. As I am not an audio engineer, I might, however, have missed some detailes in the coding/decoding mathematics, thus a furhter review by an audio engineer expert could help. Major Issues: The full draft has one only other IETF normative reference... the one which all RFCs have: RFC2119. I call this a major issue because I wonder how this specification relates to other activities in IETF. It can also be a non issue at all, of course. But I'm puzzled... this specification can happily live without the internet existance, because the data can be sent from the encode to the decoder with any other mean, including a storage device. Ok, this is philosophy, but I'm nevertheless puzzled. Minor Issues: In general, all over the specification, there is very little reference or considerations on what the network trasmission of audio data encoded using the Opus codec might be affected by various network conditions. The only case which is considered a number of times is the event of a packet (to be more exact of "data") loss. What about some considerations about how bandwidth, jitter, latency might affect ? Of course this is a generic consideration which has to do with buffering the data, but I guess at least some comments should be added. In the introduction the document say that the codec can be used also for real time music interactions (I guess over the network). Given the way the coded behaves, allowing switching between various modes on the fly, and providing support for acoustic echo cancellations (AEC) my guess is that this real time music interaction cannot be done using this codec. There are other existing applications which allows real time music interaction of the network (like the one described at http://www.conts.it/artistica/lola-project for example) which rely on abolishing all codecs, sending raw audio/video data and using fast reliable error free networks to do this. Thus I suggest removing that sentence about "real time music interaction" from the introduction of the draft. 2. Opus Codec Overview. FB (fullband). The draft declares that the codec can be used also for music performances. But here it declares that it just "ingnores" anthing above 20 Khz because we cannot hear it. This is a well known nonsense in music wordld, where all higher frequencies are preserved because they anyhow make wave interferences with the others, and create ambience etc. I suggest removing that explanation and add another one, for example "even if we know this will limit the full quality of the encoded sound, this will anyhow result in minor problems, and it is common practice". 2.1.4 Frame duration. "20ms are a good choice for most applications" should be supplemented by adding "however, this already enters the latency range where real time interaction experinces difficutlies, in particuar for music". It is experimentally know that above 20ms musicians can already detect latency and delays. 6. Conformance the whole section describes a testing and benchmarking procedure which in general is not specified by the specification itself. This makes quite complex to apply the paradigm of the two indipendent interworking implementations, when at lease the "exceptions" makes conpulsory to use at least some very same piece of code. 7 Security Considerations. the text of the first section neutrally applies to any piece of software which handles data received by an extenal source, not only this specific case. As I pointed out in the beginning, given than this draft is "a piece of software with comments" I can understand this part of the security consideration which could be named "secure programming considerations". However... it this relevant? Ok, it does not harm... but I'd point out that this apply to any case in programming. A. appendix A as said, it is quite unusual that a piece of code is the specificaton itself. As a general IETF practice, is this the correct way to go? Should exixt a "reference implementation" of a specification? Nits: none ------------------------------------------------------------------------------ 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 sm@elandsys.com Sat Jun 2 12:38:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9D321F8644 for ; Sat, 2 Jun 2012 12:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQqE-XQRdg1C for ; Sat, 2 Jun 2012 12:38:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBB821F8643 for ; Sat, 2 Jun 2012 12:38:02 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.102]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q52JbPS6009079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jun 2012 12:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1338665861; i=@elandsys.com; bh=o0sLtV4Ra1+ryhE86AFKNv5Ztt+YUE04eQraS5neHTs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GH5B3KItEAiQ5jyDVLXiX7ls8kfZihKcf8prOoVolF27J+MsZ0dYeXyNgDGRobXJI Ydl1flyk93rISZ6o4qaiyni9QCXZBR/z9NB6xlqevYYpMZyD8q4IYN4yQWuEL8g4E3 54kWLrpil4Dl6VRr+GOgxzThCkdpOvvb9ZNf8i9E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1338665861; i=@elandsys.com; bh=o0sLtV4Ra1+ryhE86AFKNv5Ztt+YUE04eQraS5neHTs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=svauHlW/wqcHU9tmYovZA9iUVBy/pZUMuQfqb89AHiZ4bnOYlT9n0Rv+HRsJz73Jn pbesyEP4xjm+rqHF8njAbc8CESRnG1+nBmEuv8sqZuhccvkx5EGQSlTAR1mHtxmQuN W1OM/N4qGLj36c6Z8QdvrOdQVaiEBoYFztcV88fk= Message-Id: <6.2.5.6.2.20120602120750.08e1c528@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 02 Jun 2012 12:17:59 -0700 To: Claudio Allocchio From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-codec-opus-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 19:38:04 -0000 Hi Claudio, At 10:25 02-06-2012, Claudio Allocchio wrote: >Document: draft-ietf-codec-opus-14 >Title: Definition of the Opus Audio Codec >Reviewer: Claudio Allocchio Thanks for performing this review. It is the most complex draft I have come across. Regards, S. Moonesamy From jyee@afilias.info Sat Jun 2 15:53:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861CF21F84D9 for ; Sat, 2 Jun 2012 15:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9w6QXIIT3P8 for ; Sat, 2 Jun 2012 15:53:43 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id A4F3B21F84D8 for ; Sat, 2 Jun 2012 15:53:40 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1SaxCV-00070Q-4v for Apps-Discuss@ietf.org; Sat, 02 Jun 2012 22:53:39 +0000 Received: from mail-ob0-f178.google.com ([209.85.214.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-MD5:128) (Exim 4.72) (envelope-from ) id 1SaxCV-0004jn-7c for Apps-Discuss@ietf.org; Sat, 02 Jun 2012 22:53:39 +0000 Received: by obceq6 with SMTP id eq6so5325193obc.9 for ; Sat, 02 Jun 2012 15:53:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer:x-gm-message-state; bh=RbwiW9bfYGWkV3bsBbriCmuoBtsTrx+tHEvnPXVNbdU=; b=AMZ2W8j0Kr6bLp/rfJzYao2GZ3u0pa2gh5uwc2GO9LQ8BnflV4AKvjb6u7/wDyNGPb eclU7DPoTknkT/Yu6GSYZqi9b+FFikm5yzV6MUZu1G6Pv9GAAQhPT0AtSBq3cUFWYvgG ED5XlDcBnlMEsM7aCRy2re0jXouP6RsYczV9v4P1u8EFGPyYFJuPrU9GmBuNoIH3V17k DNFFu2PXMSeQgWl6xU6LsIypyWs39is5qzbAQznPrb5XWMwFBkvip0gGXWGE0fKPASo3 ZpMPva+obfzaDSK8bTrwd/NSoXRpjfmISN/PqNUD5jtY5VfPD1XVcZ+mIDQMjjFYJ405 fEqw== Received: by 10.50.237.9 with SMTP id uy9mr4955165igc.40.1338677618677; Sat, 02 Jun 2012 15:53:38 -0700 (PDT) Received: from [192.168.0.108] (206-248-161-72.dsl.teksavvy.com. [206.248.161.72]) by mx.google.com with ESMTPS id if4sm2586321igc.10.2012.06.02.15.53.36 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Jun 2012 15:53:37 -0700 (PDT) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 2 Jun 2012 18:53:35 -0400 To: Apps-Discuss@ietf.org, draft-ietf-6man-lineid.all@tools.ietf.org Message-Id: <4D0553BA-8A40-4DF0-83D4-26F7E0E77430@afilias.info> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmOeiraD6BztpNMgyTibchjn8GGAF07bJTyNFSgI03a9YALdWQMKkCrtVl1Pzk6L5bHqYd/ Subject: [apps-discuss] APPSDIR review of draft-ietf-6man-lineid-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 22:53:44 -0000 All, I have been selected as the Applications Area Directorate reviewer for = this draft (for background on appsdir, please see = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate = ). Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. Document: draft-ietf-6man-lineid-04 Title: The Line Identification Destination Option Reviewer: Joseph Yee Review Date: June 2, 2012 Summary: "This draft is almost ready for publication as an Experimental = RFC but has a few issues that should be fixed before publication", Major Issues:=20 none Minor Issues:=20 section 6.2, 8th line "advertisement(es. The Edge Router then forms...." There is no matching close bracket thru the rest of paragraph & = section. This may be a typo (nits), but I am not entirely sure, so I = put it as minor. section 6.2, line 15 "All BBF Access Nodes multicast address [to be allocated]..." Shouldn't this document define the address for IANA = consideration? If it's to be determined by WG before Last Call or to be = documented (or already documented) by another RFC, please ignore. Nits:=20 none Note and Question This is just my personal thought and question, it may be just my lack of = knowledge in the subject matter. If I am right, this drafts is to help making distinction at Edge Router = if multiple end point or AN do not use vLAN (hence N:1). In section 2, it says that it's experimental and not recommend for = general deployment. If it's not recommended, what's missing to make it = "safe" or "good enough" for general deployment? Is it something to do = with 1:1 or vLAN environment to know how to handle ILO data first? = Would it better to document the issues in security consideration? or = expand section 2 a bit more? Regards Joseph= From ned.freed@mrochek.com Sat Jun 2 17:00:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087D921F8525 for ; Sat, 2 Jun 2012 17:00:50 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twfelsQu0xZk for ; Sat, 2 Jun 2012 17:00:49 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 52A7721F8512 for ; Sat, 2 Jun 2012 17:00:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG7UF8LBY8002Q8U@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 2 Jun 2012 17:00:46 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG54121Q0W0006TF@mauve.mrochek.com>; Sat, 2 Jun 2012 17:00:43 -0700 (PDT) Message-id: <01OG7UF6SMR60006TF@mauve.mrochek.com> Date: Sat, 02 Jun 2012 16:43:46 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 31 May 2012 11:50:05 +1000" <50A05D98-4F29-41A9-8886-C0CA60F1A4F5@mnot.net> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <39405CB0-D62D-419F-83C6-DB3CFA7CD9B7@mnot.net> <01OFJW6FHKJ60006TF@mauve.mrochek.com> <50A05D98-4F29-41A9-8886-C0CA60F1A4F5@mnot.net> To: Mark Nottingham Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] RFC2045 terminology [was: APPSDIR review of draft-ietf-appsawg-media-type-regs-07] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 00:00:50 -0000 > On 17/05/2012, at 2:24 AM, Ned Freed wrote: > >> * Throughout, "media type" is used somewhat freely to mean all of: a complete > >> media type label, the format that it identifies, and a top-level type. This is > >> needlessly confusing. It would be extremely helpful to explicitly define terms > >> and use them consistently throughout. In particular, "top-level type" is used > >> sometimes, whereas the plain "media type" is used elsewhere. "content type" > >> sneaks in sometimes too (again, inconsistently). > > > > Some of this is intentional. In particular, the term "media type" is used > > interchangeably (or, if you prefer, sloppily) to refer to media types in the > > abstract and to the label for a media type. I've tried writing it the other > > way, and the resulting prose is stilted and confusing. > Just to put a pin in this, I was e-mailed this morning about what a "media > type" is on the type parameter in RFC5988, and went to 2048 as a reference, > where I came across: > > 5. Content-Type Header Field > > > > The purpose of the Content-Type field is to describe the data > > contained in the body fully enough that the receiving user agent can > > pick an appropriate agent or mechanism to present the data to the > > user, or otherwise deal with the data in an appropriate manner. The > > value in this field is called a media type. > > > [...] > > > > The Content-Type header field specifies the nature of the data in the > > body of an entity by giving media type and subtype identifiers, and > > by providing auxiliary information that may be required for certain > > media types. After the media type and subtype names, the remainder > > of the header field is simply a set of parameters, specified in an > > attribute=value notation. The ordering of parameters is not > > significant. > [...] > > In general, the top-level media type is used to declare the general > > type of data, while the subtype specifies a specific format for that > > type of data. Thus, a media type of "image/xyz" is enough to tell a > > user agent that the data is an image, even if the user agent has no > > knowledge of the specific image format "xyz". > This demonstrates at least three different meanings of "media type." Note > that the first paragraph explicitly defines a media type as "anything in the > Content-Type header field value", including parameters. This is what I tried to explain to you in my original response. > Now, while a very careful reading of this in isolation makes it clear what's > going on, what is a third party who wants to reference what a "media type" is > for use in another field supposed to do? That can be a very difficult question to answer, but in practice the difficulty has *nothing* to do with the multiple meaning of the term "media type". Rather, the difficulties in practice lie in the interaction between type and parameter syntax, field syntax, and the underlying protocol. For example, there are cases where a type/subtype name can be supplied but not any parameters. (This one is a real problem, BTW.) There are cases where there are hard length limits. There are cases where only a subset of the top-level types can be used. There are cases where the transport imposes restrictions on the type content (and encoding cannot always be used to address the issues). There are cases where the list of allowed types must be explicitly enumerated. As for issues of understanding, there are many. People often don't understand what parameters are really for. (And it seems that absolutely nobody has even heard of media features.) People put stuff under the wrong top-level type. People try and register standards-tree types directly with IANA. The issues list goes on and on and on. I've encountered all of these in practice, quite a few of them multiple or even many times. But the one thing I have yet to encounter - and I've been doing this for over 15 years - is any real confusion caused by the *definition* of the term "media type". To be sure, people have shown up who are confused what a media type is. But in these cases it's quite clear they haven't read *any* of the relevant specifications. And it's quite difficult to write a specification that canveys knowledge without someone actually reading it. Ned From internet-drafts@ietf.org Sun Jun 3 03:25:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C618E21F8659; Sun, 3 Jun 2012 03:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twV2jv0hE89b; Sun, 3 Jun 2012 03:25:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AE321F8608; Sun, 3 Jun 2012 03:25:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120603102520.7197.18999.idtracker@ietfa.amsl.com> Date: Sun, 03 Jun 2012 03:25:20 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-about-uri-scheme-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 10:25:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : The "about" URI Scheme Author(s) : S. Moonesamy Filename : draft-ietf-appsawg-about-uri-scheme-06.txt Pages : 6 Date : 2012-06-03 This document describes the "about" URI scheme, which is widely used by web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-about-uri-scheme-06.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-about-uri-scheme-06.t= xt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-about-uri-scheme/ From sm@elandsys.com Sun Jun 3 03:36:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CB621F864E; Sun, 3 Jun 2012 03:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq7Woxy0P-zn; Sun, 3 Jun 2012 03:36:26 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8760021F864C; Sun, 3 Jun 2012 03:36:26 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.102]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q53AaABq014765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Jun 2012 03:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1338719782; i=@elandsys.com; bh=y9PVa/WtjvsS3hSnTEaXN+g8/pjUlEFRkSATR57t5T4=; h=Date:To:From:Subject:Cc; b=l0AV58x7rFeX5jP+R4hr8C5DJXK8iV7Ji7jwop+OTvONezJB0fzEr30NvBtV6wlge TOPWo01aqsf20xPmscuwNMfARchmdlpAmQGvLd617ZX3OWCzsKRSjyD5Q+3NWGAbh1 pXtnqn8Dkp8iwiwegYK0NzW2h/P8SdVxowElMxdE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1338719782; i=@elandsys.com; bh=y9PVa/WtjvsS3hSnTEaXN+g8/pjUlEFRkSATR57t5T4=; h=Date:To:From:Subject:Cc; b=V5Y2kbRlB3w1jrLWmFAJ7sWm6S7aHeemcjqcd5uz0pfGB8cbkmvKoSX8+bVWVFEau Zi1bhBcFiYdUFIIvjXpxbiM6+jSg23F5gsaydbpKtVUmyfHIGey9TBjvfptIiN3ABO vsm8d9wfGPF7isQJ1CvpeVj1iZc7jatF1DMaTPQ0= Message-Id: <6.2.5.6.2.20120603010308.0be0d8e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 03 Jun 2012 03:18:10 -0700 To: apps-discuss@ietf.org, draft-vegoda-cotton-rfc5735bis.all@tools.ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf@ietf.org Subject: [apps-discuss] APPSDIR review of draft-vegoda-cotton-rfc5735bis-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 10:36:28 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. The review is not copied to the IESG as the Last Call has not been announced yet. Document: draft-vegoda-cotton-rfc5735bis-02 Title: Special Use IPv4 Addresses Reviewer: S. Moonesamy Review Date: June 3, 2012 Summary: This document is almost ready for publication as a BCP. The draft describes the global and other specialized IPv4 address blocks that have been assigned by IANA. It is an update of RFC 5735 to include the Shared IPv4 address space which was assigned about the publication of RFC 5735. The proposal does not have any impact on Application-related protocols. Major issues: None Minor issues: In Section 1: "Section 4 of this document describes that assignment process." Section 4 contains a summary table without any assignment process description. Where is the assignment process described? In Section 5: "The domain name and IP address spaces involve policy issues (in addition to technical issues) so that the requirements of [RFC2860] do not apply generally to those spaces." The wording is different from what is in RFC 2860. "Immediately before the RFC is published, the IANA will, in consultation with the Regional Internet Registries, make the necessary assignment and notify the RFC Editor of the particulars for inclusion in the RFC as published." There is no mention of "Regional Internet Registries" in RFC 2860. I suggest dropping Section 5 as according to Abstract this draft is about documenting Special Use IPv4 addresses. In Section 7: "Security policy SHOULD NOT blindly filter all of these address spaces without due consideration, and network operators are encouraged to review this document, and references contained therein, and determine what security policies should be associated with each of these address blocks within their specific operating environments." The recommendation is not clear. The recommendation seems more appropriate for network operators instead of "Security policy" as they have the awareness to make such decisions. Given the recommendation about due consideration and reviewing all the references, these references would have to be normative. It is easier to remove the RFC 2119 boilerplate and use a "should not" to reduce the amount of required reading. Nits: Why does this draft update RFC 6441? Regards, S. Moonesamy From glenzorn@gmail.com Sat Jun 2 21:54:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C24C21F848A; Sat, 2 Jun 2012 21:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc0xjAjGOSAI; Sat, 2 Jun 2012 21:54:01 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 944BE21F8466; Sat, 2 Jun 2012 21:54:01 -0700 (PDT) Received: by dacx6 with SMTP id x6so4350273dac.31 for ; Sat, 02 Jun 2012 21:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :organization:content-type:x-mailer:content-transfer-encoding :mime-version; bh=SW8hKCbAQgq3FmuGaCh+kPbttGlsBCtrkCRMo3sbY+Q=; b=rfh+j1fhkn/UQjPKIUGY4adFK/7MyusW7H68QgCgrqR7q+mc1hhhy8DBYHs68vm15E 1riNaXtM3F4DzWshYzO5oUCBdlN6MOlAFnPzho6QhLJ3S4Vzn2aSbfBJkc9HXE0dECUP /CDc2Bbg71aBfT/yn4sdiKg4DkO6wevXuepTFgiQRAgjz3dNFoAzEqX0AlO3tVVdrWSr FlcNdMUQyiktlDJdvkamyvqxxq5KBkVsbfvVdzzbcmnEBN/v94TNOXtmFSnpZXkGK+FH UOIZ5J6raVNcvqf98+KHvXp+Az0bN3QgiCqUkNFoyI+UwvI2FzoARxwFRZLOym+lBTYO u/cQ== Received: by 10.68.219.162 with SMTP id pp2mr25898071pbc.85.1338699241397; Sat, 02 Jun 2012 21:54:01 -0700 (PDT) Received: from [192.168.1.99] (ppp-58-11-241-69.revip2.asianet.co.th. [58.11.241.69]) by mx.google.com with ESMTPS id iv8sm326444pbc.53.2012.06.02.21.53.59 (version=SSLv3 cipher=OTHER); Sat, 02 Jun 2012 21:54:00 -0700 (PDT) Message-ID: <1338699237.5620.3.camel@gwz-laptop> From: Glen Zorn To: "C. M. Heard" Date: Sun, 03 Jun 2012 11:53:57 +0700 In-Reply-To: References: <4FCA0E7F.7020109@cisco.com> Organization: Network Zen Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.2- Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailman-Approved-At: Sun, 03 Jun 2012 08:06:51 -0700 Cc: glenzorn@gmail.com, Internet Area , IETF Discussion , Apps Discussion Subject: Re: [apps-discuss] [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 04:54:02 -0000 On Sat, 2012-06-02 at 21:21 -0700, C. M. Heard wrote: ... > > > In Section 6.1: > > > > > > > > >> Datagram de-duplication can be accomplished using hash-based > > >> duplicate detection for cases where the ID field is absent. > > >> > > > > > > Under what circumstances would the ID field be absent? > > > > Replace "absent" with "known not unique". > > Better, I think, would be "not known to be unique". Except that the two are not semantically equivalent. ... From heard@pobox.com Sat Jun 2 21:28:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995D911E8094 for ; Sat, 2 Jun 2012 21:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAYRgcMsgCyK for ; Sat, 2 Jun 2012 21:28:21 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A20311E8089 for ; Sat, 2 Jun 2012 21:28:21 -0700 (PDT) Received: (qmail 19638 invoked from network); 2 Jun 2012 21:21:39 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Jun 2012 21:21:39 -0700 Date: Sat, 2 Jun 2012 21:21:38 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IETF Discussion In-Reply-To: Message-ID: References: <4FCA0E7F.7020109@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sun, 03 Jun 2012 08:07:02 -0700 Cc: Internet Area , Apps Discussion , Joe Touch Subject: Re: [apps-discuss] [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 04:28:21 -0000 On Sat, 2 Jun 2012, Joe Touch wrote: > Hi, Eliot, > > On Jun 2, 2012, at 6:00 AM, Eliot Lear wrote: > > > > > Document: draft-ietf-intarea-ipv4-id-update-05 > > Title: Updated Specification of the IPv4 ID Field > > Reviewer: Eliot Lear > > Review Date: 2 June 2012 > > IETF Last Call Date: 31 May 2012 > > > > > > Summary: This draft is quite well written, and is very nearly ready for publication. > > > > This draft is well written, and from the applications > > perspective represents an important step to improving > > performance and error reduction. It uses a new requirements > > call-out style that I would class as experimental, but not bad. > > It is worth people reading this draft and deciding if they agree > > with Joe's approach. FWIW, I thought it was helpful. > > Major issues: > > > > None (Yay!). > > > > Minor issues: > > > > Section 4 needs to be reconciled a bit with Section 6.1. Specifically: > > > >> The IPv4 ID field can be useful for other purposes. > > > > > > And > > > > >> IPv4 ID field MUST NOT be used for purposes other than > > fragmentation and reassembly. > > > > > > My suggestion is to drop the above sentence from Section 4. > > The two are not contradictory - the ID can be useful, but > generating it correctly is prohibitive and typically not done. After re-reading the text I agree with Eliot that it is confusing. Dropping the sentence in Section 4 would be fine. Another possibility would be to reword it along the following lines: Other uses have been envisioned for the IPv4 ID field. > > In Section 6.1: > > > > > >> Datagram de-duplication can be accomplished using hash-based > >> duplicate detection for cases where the ID field is absent. > >> > > > > Under what circumstances would the ID field be absent? > > Replace "absent" with "known not unique". Better, I think, would be "not known to be unique". > >> >> Sources of non-atomic IPv4 datagrams using strong integrity checks > >> MAY reuse the ID within MSL values smaller than is typical. > >> > > > > Is the issue really the source using strong integrity checks or > > the destination in this context? What is typical? > > The onus is on the source (of non-atomic datagrams) - if it > includes strong integrity checks (that are presumably validated by > the receiver), it then has more flexibility in its generation of > the iD values. > > > Nit: > > > > Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3? > > Not subsections of 2, but perhaps "3, 3.1, 3.2"? That would be fine but I'm also OK with leaving the document the way it is (especially if it would get it into the publication queue faster). //cmh From heard@pobox.com Sat Jun 2 22:06:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B806821F8525 for ; Sat, 2 Jun 2012 22:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpcXikPD+a7h for ; Sat, 2 Jun 2012 22:06:45 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id F410021F851E for ; Sat, 2 Jun 2012 22:06:44 -0700 (PDT) Received: (qmail 31369 invoked from network); 2 Jun 2012 22:00:02 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Jun 2012 22:00:02 -0700 Date: Sat, 2 Jun 2012 22:00:01 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IETF Discussion In-Reply-To: <1338699237.5620.3.camel@gwz-laptop> Message-ID: References: <4FCA0E7F.7020109@cisco.com> <1338699237.5620.3.camel@gwz-laptop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sun, 03 Jun 2012 08:07:10 -0700 Cc: Glen Zorn , Internet Area , Apps Discussion Subject: Re: [apps-discuss] [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 05:06:46 -0000 On Sun, 3 Jun 2012, Glen Zorn wrote: > On Sat, 2012-06-02 at 21:21 -0700, C. M. Heard wrote: > > ... > > > > > In Section 6.1: > > > > > > > > > > > >> Datagram de-duplication can be accomplished using hash-based > > > >> duplicate detection for cases where the ID field is absent. > > > >> > > > > > > > > Under what circumstances would the ID field be absent? > > > > > > Replace "absent" with "known not unique". > > > > Better, I think, would be "not known to be unique". > > Except that the two are not semantically equivalent. Indeed. That was why I suggested the change. //cmh From mnot@mnot.net Sun Jun 3 18:26:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D146121F87E6 for ; Sun, 3 Jun 2012 18:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.856 X-Spam-Level: X-Spam-Status: No, score=-103.856 tagged_above=-999 required=5 tests=[AWL=-1.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeZZ+G43Zn-h for ; Sun, 3 Jun 2012 18:26:32 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 159C121F87E5 for ; Sun, 3 Jun 2012 18:26:32 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.203.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 83BE422E25B; Sun, 3 Jun 2012 21:26:23 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <01OG7UF6SMR60006TF@mauve.mrochek.com> Date: Mon, 4 Jun 2012 11:26:20 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <9F06DA93-0B06-411A-AFDF-85099860E449@mnot.net> References: <39405CB0-D62D-419F-83C6-DB3CFA7CD9B7@mnot.net> <01OFJW6FHKJ60006TF@mauve.mrochek.com> <50A05D98-4F29-41A9-8886-C0CA60F1A4F5@mnot.net> <01OG7UF6SMR60006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] RFC2045 terminology [was: APPSDIR review of draft-ietf-appsawg-media-type-regs-07] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 01:26:33 -0000 On 03/06/2012, at 9:43 AM, Ned Freed wrote: > That can be a very difficult question to answer, but in practice the = difficulty > has *nothing* to do with the multiple meaning of the term "media = type". >=20 > Rather, the difficulties in practice lie in the interaction between = type and > parameter syntax, field syntax, and the underlying protocol. For = example, there > are cases where a type/subtype name can be supplied but not any = parameters. > (This one is a real problem, BTW.) There are cases where there are = hard length > limits. There are cases where only a subset of the top-level types can = be used. > There are cases where the transport imposes restrictions on the type = content > (and encoding cannot always be used to address the issues). There are = cases > where the list of allowed types must be explicitly enumerated. >=20 > As for issues of understanding, there are many. People often don't = understand > what parameters are really for. (And it seems that absolutely nobody = has even > heard of media features.) People put stuff under the wrong top-level = type. > People try and register standards-tree types directly with IANA. >=20 > The issues list goes on and on and on. I've encountered all of these = in > practice, quite a few of them multiple or even many times. But the one = thing I > have yet to encounter - and I've been doing this for over 15 years - = is any > real confusion caused by the *definition* of the term "media type". >=20 > To be sure, people have shown up who are confused what a media type = is. But in > these cases it's quite clear they haven't read *any* of the relevant > specifications. And it's quite difficult to write a specification that = canveys > knowledge without someone actually reading it. Well, it's pretty clear we feel differently here; it's all moot until a = 2045bis starts, if it does. Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Sun Jun 3 18:38:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB2721F87ED for ; Sun, 3 Jun 2012 18:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.821 X-Spam-Level: X-Spam-Status: No, score=-103.821 tagged_above=-999 required=5 tests=[AWL=-1.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYsyoz+UaImL for ; Sun, 3 Jun 2012 18:38:32 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9AC21F87F3 for ; Sun, 3 Jun 2012 18:38:32 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.203.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3E19122E259; Sun, 3 Jun 2012 21:38:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: <4FC9F20F.6060205@gmx.de> Date: Mon, 4 Jun 2012 11:38:20 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B9B7D15-9510-4C90-9B77-EEC55262758C@mnot.net> <4FC9F20F.6060205@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss , HTTP Working Group , Mike Kelly Subject: Re: [apps-discuss] FYI: LCI -02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 01:38:33 -0000 On 02/06/2012, at 8:59 PM, Julian Reschke wrote: > On 2012-06-01 03:08, Mark Nottingham wrote: >> We've published an -02 draft of LCI: >> >>=20 >> and intend to request publication as an Individual Submission = Informational RFC soon (the link relations have just been submitted for = review). Feedback still welcome (http list is best, I think). >> ... >=20 > HTTPbis introduces a registry for cache directives (see = ). >=20 > Would it make sense to change the dependency from RFC 2616 to HTTPbis, = and to register as defined in Part 6? I'm not against it, although it'd require reworking the BNF. I'll look = into it. Cheers, -- Mark Nottingham http://www.mnot.net/ From internet-drafts@ietf.org Mon Jun 4 01:02:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0182F21F8621; Mon, 4 Jun 2012 01:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iaL4hbuBcIC; Mon, 4 Jun 2012 01:02:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5422821F855F; Mon, 4 Jun 2012 01:02:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120604080244.20562.3923.idtracker@ietfa.amsl.com> Date: Mon, 04 Jun 2012 01:02:44 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 08:02:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Media Type Specifications and Registration Procedures Author(s) : Ned Freed John C. Klensin Tony Hansen Filename : draft-ietf-appsawg-media-type-regs-11.txt Pages : 32 Date : 2012-06-04 This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-11.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/ From julian.reschke@gmx.de Mon Jun 4 01:09:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC16421F877E for ; Mon, 4 Jun 2012 01:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEFSqA7GShPf for ; Mon, 4 Jun 2012 01:09:01 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A462921F8575 for ; Mon, 4 Jun 2012 01:09:00 -0700 (PDT) Received: (qmail invoked by alias); 04 Jun 2012 08:08:59 -0000 Received: from p5DD95FED.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.95.237] by mail.gmx.net (mp040) with SMTP; 04 Jun 2012 10:08:59 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/ctKUS9h/c+D4qo8bQmJVG8w47Iw/GjZG0gKwONq HPsDenwzc5WxyF Message-ID: <4FCC6D13.9020106@gmx.de> Date: Mon, 04 Jun 2012 10:08:51 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: HTTP Working Group References: <7B9B7D15-9510-4C90-9B77-EEC55262758C@mnot.net> In-Reply-To: <7B9B7D15-9510-4C90-9B77-EEC55262758C@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps Discuss , Mark Nottingham , Mike Kelly Subject: Re: [apps-discuss] FYI: LCI -02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 08:09:01 -0000 On 2012-06-01 03:08, Mark Nottingham wrote: > We've published an -02 draft of LCI: > > > and intend to request publication as an Individual Submission Informational RFC soon (the link relations have just been submitted for review). Feedback still welcome (http list is best, I think). Here's another question: the proposal defines both a cache directive and link relations. Have you considered putting all the link-related information into a cache directive as well? (Not saying it should be the case but wondering whether that would keep things together that belong together). Best regards, Julian From mnot@mnot.net Mon Jun 4 03:34:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB8721F865F for ; Mon, 4 Jun 2012 03:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.83 X-Spam-Level: X-Spam-Status: No, score=-103.83 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d08Dlk0oWhpM for ; Mon, 4 Jun 2012 03:34:00 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA1E21F8799 for ; Mon, 4 Jun 2012 03:34:00 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.203.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6893D22E1EB; Mon, 4 Jun 2012 06:33:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: <4FCC6D13.9020106@gmx.de> Date: Mon, 4 Jun 2012 20:33:47 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B9B7D15-9510-4C90-9B77-EEC55262758C@mnot.net> <4FCC6D13.9020106@gmx.de> To: "Julian F. Reschke" X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss , HTTP Working Group , Mike Kelly Subject: Re: [apps-discuss] FYI: LCI -02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 10:34:01 -0000 On 04/06/2012, at 6:08 PM, Julian Reschke wrote: > On 2012-06-01 03:08, Mark Nottingham wrote: >> We've published an -02 draft of LCI: >> >>=20 >> and intend to request publication as an Individual Submission = Informational RFC soon (the link relations have just been submitted for = review). Feedback still welcome (http list is best, I think). >=20 > Here's another question: the proposal defines both a cache directive = and link relations. Have you considered putting all the link-related = information into a cache directive as well? (Not saying it should be the = case but wondering whether that would keep things together that belong = together). Yes. However, some use cases are to strip the link on the way out, and = it's easier to strip all Link headers than to parse and selectively = change Cache-Control headers. I know that theoretically other Link = headers could be emitted, but with current software, this is the easier = path. Additionally, I didn't want to rely on the quality of Cache-Control = parsers already out there. Also, we didn't want to re-invent the Link header and all of its = associated machinery (e.g., relative vs. absolute, scoping, etc.). Finally, it's conceivable that some folks might want to use the = relations for other purposes. After all, they may be separate headers, but they'll be in the same = message.=20 Cheers, -- Mark Nottingham http://www.mnot.net/ From alexey.melnikov@isode.com Mon Jun 4 07:22:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1F021F8864; Mon, 4 Jun 2012 07:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.38 X-Spam-Level: X-Spam-Status: No, score=-101.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i066Dod5eHYh; Mon, 4 Jun 2012 07:22:14 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id ECE7421F88C5; Mon, 4 Jun 2012 07:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338819731; d=isode.com; s=selector; i=@isode.com; bh=jrf30EViLjABRxmxJutRdjmuw8iJLMkGka/T51UuumE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=tbTDHKOpy+YJUEH2SdPY7FXryeGr1EYhkTTEuYXe2LT8fQcbOU/8QJk+EgMeMAn7OsTC1j VhTTy2fhm0P7xfHsSLKvxjYU8zXg99qCOqqqxeiBmr0R22agthWkcFRObRh79+MrEI3TXa PaLEvzQcX20pnbQPOOoVL2LOvBNqVgM=; Received: from [172.20.10.2] ((unknown) [212.183.128.146]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 4 Jun 2012 15:22:06 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FCA6BFE.3050609@isode.com> Date: Sat, 02 Jun 2012 20:39:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: dcrocker@bbiw.net References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> In-Reply-To: <4FC914DB.4000806@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:22:16 -0000 Hi Dave, On 01/06/2012 20:15, Dave Crocker wrote: > On 6/1/2012 12:28 PM, Alexey Melnikov wrote: >> On 31/05/2012 08:49, Dave Crocker wrote: [...] >>>> however, allow an untrusted source to lower its own message's >>>> priorities -- consider, for example, an email marketer that >>>> voluntarily sends its marketing messages at low priority. >>> >>> To beat the point a bit deader: this assumes a particular policy for >>> the meaning of the priority values. Worse, it also appears to >>> contradict the earlier default of 0, but perhaps I've misunderstood >>> that. >> >> Yes, you misunderstood. The example talking about marketing messages is >> an example of a sender that explicitly requests priority below 0. > > But there is no inherent meaning to "low priority", absent a policy > statement that defines the meaning of values. Low is relative to > other values, but which ones? In some environments -5 is low and in > others 0 is low and I'll bet some others will treat 5 as low. To clarify I've changed that to "a negative priority". This is good enough for this example. >>>> 4.4. Mailing lists and Aliases >>>> >>>> Several options exist to translate the address of an email recipient >>> >>> "options"? Perhaps you mean mechanisms or services? >> >> Yes. >> >>> And they really aren't translating an address but are doing a form of >>> message transmission (relaying, or the like). >> >> Suggested replacement? > > Several types of mechanisms exist to redirect or forward messages > to alternative or multiple addresses.[RFC5598] Examples for this are > aliases and mailing lists [RFC5321]. > > If a message is subject to such processing, the Mediator node > [rfc5598, Sec 2.1] SHOULD retain the MT-PRIORITY parameter value for > all expanded and/or translated addresses. Ok, I've used your text. [...] >>>> 5.2. Timely Delivery >>>> >>>> An important constraint (usually associated with higher priority >>>> levels) is that messages with high priority have some delivery time >>>> constraints. In some cases, higher priorities mean a shorter maximum >>>> time allowed for delivery. >>>> >>>> Unextended SMTP does not offer a service for timely delivery. The >>>> "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in >>>> [RFC2852] is an example of an SMTP extension providing a service that >>>> can be used to implement such constraints. But note that use of the >>>> DELIVERBY extension alone does not guarantee any priority processing. >>> >>> It seems as if this section introduces an issue but does not actually >>> deal with it. Perhaps there should be some discussion of the possible >>> (or required?) interaction between the two extensions it discusses? >> >> There is no issue and no real interaction in this specific case. A >> client that wants to use both against a server that supports both should >> consider this issue. > > Specifications that say an implementer should consider something but > which gives no guidance about the consideration aren't doing much > useful, in my view. > > As this set of text was proceeding, I thought it was going to provide > some useful guidance about possible uses of the combined options, > since it seemed like the combination could be, well, useful. The client can decide to use smaller values. In this case it is up to the client to pick them, this is not controlled by the site policy. [...] >>>> 10. Security Considerations >>>> >>>> Message Submission Agents MUST implement a policy that only allows >>>> authenticated users (or only certain groups of authenticated users) >>>> to specify message transfer priorities, and MAY restrict maximum >>>> priority values different groups of users can request, or MAY >>>> override the priority values specified by MUAs. >>> >>> Presumably the normative MSA language is meant "for those MSAs >>> supporting this extension"? >> >> Of course. I don't think this needs saying. > > And yet the document says exactly that sort of qualifier earlier: "An > MTA which also conforms to [RFC3461]..." RFC 3461 is a separate specification, so mentioning it explicitly is, IMHO, quite appropriate. From tobias.gondrom@gondrom.org Mon Jun 4 07:42:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6887F21F87E3 for ; Mon, 4 Jun 2012 07:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.778 X-Spam-Level: X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqFpKP1OWfOl for ; Mon, 4 Jun 2012 07:42:08 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC5E21F87D3 for ; Mon, 4 Jun 2012 07:42:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=ZzNvD+xQZjV6CLx4ySHu8i+lDajy9VTYsQ0QpgPFinTZmfM5EM7ulAoF6laW/fe0LwOPPfoRwGzCRKEtnfPEFDgkFItB17x2/A/edavPSejP9Hlrhtz26bkqkoYYXF5P; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; Received: (qmail 6119 invoked from network); 4 Jun 2012 16:41:59 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.69?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Jun 2012 16:41:59 +0200 Message-ID: <4FCCC936.3030600@gondrom.org> Date: Mon, 04 Jun 2012 15:41:58 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org, iesg@ietf.org, draft-ietf-krb-wg-kdc-model.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] AppsDir review of draft-ietf-krb-wg-kdc-model X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:42:09 -0000 Hello all, I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-krb-wg-kdc-model-12 Title: An information model for Kerberos version 5 Reviewer: Tobias Gondrom Review Date: June-4 2012 Summary: This draft is almost ready for publication. One basic question: This draft aims for Standards Track, yet as far as I understood, it is not required that the used field names are in fact the same across different implementations but only that name-mappings exist. The ID also uses a modified RFC2119 language definition to allow that. I would like to ask, whether possibly Informational Status would be more appropriate for this draft? Minor issues: - RFC2119 language in 4.1.1.2 and 4.1.1.3 s/MUST not/MUST NOT - 4.4.2 sub-sections for policy: in several sub-sections: IANA: still need to set the values and spaces for the OIDs is marked for IANA in IANA considerations section 7, but why have the specific values not been put in the ID? - section 5.1 and 5.2 and section 6 reference to expired ID: draft-ietf-krb-wg-kerberos-set-passwd Am not so happy that the draft refers to drafts (which is expired in 2009) for set/change password protocol. I lack the knowledge of the context of why the WG chose to expire this ID at the time and why it is now used as a reference here. Is there another resource you could refer to instead? Do you want to revive the set-passwd ID? Especially as the reference is part of a mandatory part ("SHALL only") of the security considerations 6, I am having a hard time to see this as only "informational" and how to refer here to an expired draft.... Best regards, Tobias From hartmans@mit.edu Mon Jun 4 09:02:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E54721F88B9; Mon, 4 Jun 2012 09:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.343 X-Spam-Level: X-Spam-Status: No, score=-103.343 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AydxQ2ikFAxW; Mon, 4 Jun 2012 09:02:41 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6C23721F8896; Mon, 4 Jun 2012 09:02:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A139120341; Mon, 4 Jun 2012 12:02:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C736A4151; Mon, 4 Jun 2012 12:02:29 -0400 (EDT) From: Sam Hartman To: Tobias Gondrom References: <4FCCC936.3030600@gondrom.org> Date: Mon, 04 Jun 2012 12:02:29 -0400 In-Reply-To: <4FCCC936.3030600@gondrom.org> (Tobias Gondrom's message of "Mon, 04 Jun 2012 15:41:58 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-krb-wg-kdc-model.all@tools.ietf.org, ietf-krb-wg@anl.gov, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-ietf-krb-wg-kdc-model X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 16:02:42 -0000 >>>>> "Tobias" == Tobias Gondrom writes: Tobias> One basic question: Tobias> This draft aims for Standards Track, yet as far as I understood, it is Tobias> not required that the used field names are in fact the same across Tobias> different implementations but only that name-mappings exist. The ID Tobias> also uses a modified RFC2119 language definition to allow that. Tobias> I would like to ask, whether possibly Informational Status would be Tobias> more appropriate for this draft? My concern is that this does specify mandatory behavior of implementations and that it's likely that a schema would want to normatively refer to this document for semantics of attributes. Tobias> reference to expired ID: draft-ietf-krb-wg-kerberos-set-passwd Tobias> Am not so happy that the draft refers to drafts (which is expired in Tobias> 2009) for set/change password protocol. I lack the knowledge of the Tobias> context of why the WG chose to expire this ID at the time and why it Tobias> is now used as a reference here. Is there another resource you could Tobias> refer to instead? Do you want to revive the set-passwd ID? Tobias> Especially as the reference is part of a mandatory part ("SHALL only") Tobias> of the security considerations 6, I am having a hard time to see this Tobias> as only "informational" and how to refer here to an expired draft.... Leif, I think it would be desirable to clean up section 6 to imply that we expect there to be protocols to use to write keys such as the set/change password protocol. Possibly adding a note that a schema that implements keys at all is expected to choose a normative protocol for writing key objects. Do people think that would be a good approach for this? From leifj@sunet.se Mon Jun 4 09:33:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B4911E8079; Mon, 4 Jun 2012 09:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpiYD8uLzeYL; Mon, 4 Jun 2012 09:33:23 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5FD11E8074; Mon, 4 Jun 2012 09:33:23 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q54GXA5J004372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jun 2012 18:33:14 +0200 (CEST) Message-ID: <4FCCE346.3020907@sunet.se> Date: Mon, 04 Jun 2012 18:33:10 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sam Hartman References: <4FCCC936.3030600@gondrom.org> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-krb-wg-kdc-model.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [apps-discuss] AppsDir review of draft-ietf-krb-wg-kdc-model X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 16:33:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/04/2012 06:02 PM, Sam Hartman wrote: >>>>>> "Tobias" == Tobias Gondrom >>>>>> writes: > > > Tobias> One basic question: Tobias> This draft aims for Standards > Track, yet as far as I understood, it is Tobias> not required that > the used field names are in fact the same across Tobias> different > implementations but only that name-mappings exist. The ID Tobias> > also uses a modified RFC2119 language definition to allow that. > Tobias> I would like to ask, whether possibly Informational Status > would be Tobias> more appropriate for this draft? > > My concern is that this does specify mandatory behavior of > implementations and that it's likely that a schema would want to > normatively refer to this document for semantics of attributes. > Yes. > > Tobias> reference to expired ID: > draft-ietf-krb-wg-kerberos-set-passwd Tobias> Am not so happy that > the draft refers to drafts (which is expired in Tobias> 2009) for > set/change password protocol. I lack the knowledge of the Tobias> > context of why the WG chose to expire this ID at the time and why > it Tobias> is now used as a reference here. Is there another > resource you could Tobias> refer to instead? Do you want to revive > the set-passwd ID? Tobias> Especially as the reference is part of a > mandatory part ("SHALL only") Tobias> of the security > considerations 6, I am having a hard time to see this Tobias> as > only "informational" and how to refer here to an expired draft.... > > Leif, I think it would be desirable to clean up section 6 to imply > that we expect there to be protocols to use to write keys such as > the set/change password protocol. Possibly adding a note that a > schema that implements keys at all is expected to choose a > normative protocol for writing key objects. > > Do people think that would be a good approach for this? Yeah that is totally doable. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/M40YACgkQ8Jx8FtbMZndWJgCcCeB99vxQfWC0w/3yAmqK+olj s2QAoI/c/ZgwPekoLTqbhN99su5QXz5L =aFiE -----END PGP SIGNATURE----- From tobias.gondrom@gondrom.org Mon Jun 4 09:38:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF07111E808F for ; Mon, 4 Jun 2012 09:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.778 X-Spam-Level: X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d+NIKEpozys for ; Mon, 4 Jun 2012 09:38:57 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC8211E808D for ; Mon, 4 Jun 2012 09:38:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=Gi7Q2y+VOIiliF0ZQ+PHQ++5lH3cw1H8C9cAtVAQFAU6YQx3ldGcj5AX6Gm0zNP7C2QSM4tjrptwJXsxT0KiauZlNIq8vF1/21MqxmO9zhWDAoLP0hLaGo1nKcZrMco5; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 7623 invoked from network); 4 Jun 2012 18:38:46 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.69?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Jun 2012 18:38:46 +0200 Message-ID: <4FCCE496.1030800@gondrom.org> Date: Mon, 04 Jun 2012 17:38:46 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: hartmans-ietf@mit.edu References: <4FCCC936.3030600@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-krb-wg-kdc-model.all@tools.ietf.org, ietf-krb-wg@anl.gov, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-ietf-krb-wg-kdc-model X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 16:38:57 -0000 On 04/06/12 17:02, Sam Hartman wrote: >>>>>> "Tobias" == Tobias Gondrom writes: > > Tobias> One basic question: > Tobias> This draft aims for Standards Track, yet as far as I understood, it is > Tobias> not required that the used field names are in fact the same across > Tobias> different implementations but only that name-mappings exist. The ID > Tobias> also uses a modified RFC2119 language definition to allow that. > Tobias> I would like to ask, whether possibly Informational Status would be > Tobias> more appropriate for this draft? > > My concern is that this does specify mandatory behavior of > implementations and that it's likely that a schema would want to > normatively refer to this document for semantics of attributes. Does it have to be Standards Track for that purpose? (note: I don't have a strong opinion on this, just feel uneasy with using the watered down 2119 definitions in the draft and the name-mapping, and then to go for Standards Track....) > > > Tobias> reference to expired ID: draft-ietf-krb-wg-kerberos-set-passwd > Tobias> Am not so happy that the draft refers to drafts (which is expired in > Tobias> 2009) for set/change password protocol. I lack the knowledge of the > Tobias> context of why the WG chose to expire this ID at the time and why it > Tobias> is now used as a reference here. Is there another resource you could > Tobias> refer to instead? Do you want to revive the set-passwd ID? > Tobias> Especially as the reference is part of a mandatory part ("SHALL only") > Tobias> of the security considerations 6, I am having a hard time to see this > Tobias> as only "informational" and how to refer here to an expired draft.... > > Leif, I think it would be desirable to clean up section 6 to imply that > we expect there to be protocols to use to write keys such as the > set/change password protocol. Possibly adding a note that a schema that > implements keys at all is expected to choose a normative protocol for > writing key objects. > > Do people think that would be a good approach for this? Would work for me. On a personal note: Would still be curious about the intentions for draft-ietf-krb-wg-kerberos-set-passwd? Best regards, Tobias From phk@phk.freebsd.dk Mon Jun 4 01:11:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6580321F8777 for ; Mon, 4 Jun 2012 01:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.795 X-Spam-Level: X-Spam-Status: No, score=-5.795 tagged_above=-999 required=5 tests=[AWL=-4.205, BAYES_00=-2.599, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y230TZmzmNbC for ; Mon, 4 Jun 2012 01:11:42 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by ietfa.amsl.com (Postfix) with ESMTP id D549D21F8764 for ; Mon, 4 Jun 2012 01:11:39 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7C4CF1407D; Mon, 4 Jun 2012 08:11:36 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q548BYfO020394; Mon, 4 Jun 2012 08:11:34 GMT (envelope-from phk@phk.freebsd.dk) To: Julian Reschke From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 04 Jun 2012 10:08:51 +0200." <4FCC6D13.9020106@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 04 Jun 2012 08:11:34 +0000 Message-ID: <20393.1338797494@critter.freebsd.dk> X-Mailman-Approved-At: Mon, 04 Jun 2012 10:02:24 -0700 Cc: Apps Discuss , Mark Nottingham , HTTP Working Group , Mike Kelly Subject: Re: [apps-discuss] FYI: LCI -02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 08:11:43 -0000 In message <4FCC6D13.9020106@gmx.de>, Julian Reschke writes: >Here's another question: the proposal defines both a cache directive and >link relations. Have you considered putting all the link-related >information into a cache directive as well? (Not saying it should be the >case but wondering whether that would keep things together that belong >together). I think that will wastly increase the chances that people understand how to use it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From sm@elandsys.com Mon Jun 4 10:22:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E519C11E8088; Mon, 4 Jun 2012 10:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Pi4OkpL9Fpn; Mon, 4 Jun 2012 10:22:05 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C1121F845F; Mon, 4 Jun 2012 10:22:05 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.236.146]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q54HLkDh027717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jun 2012 10:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1338830521; i=@elandsys.com; bh=ZICT4SsNKoebjID3Jr4J6G6YKzLiu7w9knpVKol53QA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GftnKy+PrvXqCGP4WfDH5JM8fuYuDIXOehj3FyhecmcoqZf19MNvmb7t8GQYntb02 tPw3WrNsf/M1DlzmNhQ76ydkZ+cPOJ/QLn7IOyzfkwWQWKVa7tinvX2BMXtOhr0I/Z onhp34NwPij92ni3xE5CXsWmtKwFhapWmHxllP4A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1338830521; i=@elandsys.com; bh=ZICT4SsNKoebjID3Jr4J6G6YKzLiu7w9knpVKol53QA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1NySZBjGptjCil2uTxP6wdxAF/Uz5oJysiyReUANhxGAGVUbiscpraV77SycgwYjQ lEl+hzRcw7HwonMsLsdwWUFLvGpjgjGxCwSOIXFkmczL+xSRHK54HLORx0ExDdvlTq g7Ai5Wz2KjPlpoa9SEvjD2mV4EgaRJR5Mddr9viw= Message-Id: <6.2.5.6.2.20120604072443.098cdc28@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 04 Jun 2012 10:00:38 -0700 To: "Richard L. Barnes" , IESG From: S Moonesamy In-Reply-To: <196B9066-2934-443D-B642-997BDF57948E@bbn.com> References: <196B9066-2934-443D-B642-997BDF57948E@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: gen-art@ietf.org, ietf@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Gen-ART Telechat review of draft-ietf-appsawg-about-uri-scheme-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 17:22:08 -0000 Hi Richard, Thanks for the review. This is an individual comment. At 05:33 04-06-2012, Richard L. Barnes wrote: >I wonder how useful this document is, given that the use of "about:" >URIs is currently very inconsistent across browsers. (See, for >example, ) Some >browsers also use alternative URI schemes for essentially the same >function ("opera:", "chrome:"). Has there been input from the >browser vendor community on this document? One of the editors of draft-ietf-appsawg-about-uri-scheme-04 affiliated with Opera Software ASA provided input about the draft. The Wikipedia article mentions that it needs additional citations for verification. Although the "about" URI scheme is well-known, it has never been registered. The document describes the URI scheme and registers it in the "URI Schemes". The document does not seek to impose any requirement. It leaves it to browser vendors to decide what to do. >4. >The document correctly notes that "about:" URIs sometimes point to >sensitive data, and that browsers need to protect them. However, >the document fails to specify what the threats are and how to >mitigate them. It seems to me that the major risk is cross-site >scripting, in the sense that a remote web page might include an >"about:" URI (e.g., via an XMLHttpRequest) in order to access >sensitive data. At a high level, then, the mitigation would be to >ensure that such URIs are accessible only as a result of direct user >action (e.g., typing in a URI) or trusted browser code (e.g., extensions). Section 4 of draft-ietf-appsawg-about-uri-scheme-06 mentions that "about" URIs may be used to reference, for example, user passwords stored in a cache. The document does not register such a token though. It leaves it to person with expertise to write the specification about that token to consider the security implications. Adding text to discuss about cross-site scripting might be misconstrued as a recommendation. Regards, S. Moonesamy From jhutz@cmu.edu Mon Jun 4 10:51:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611A811E808C; Mon, 4 Jun 2012 10:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R32fuY1P6X-F; Mon, 4 Jun 2012 10:51:39 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBF911E8079; Mon, 4 Jun 2012 10:51:38 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q54HpXx4006445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jun 2012 13:51:34 -0400 (EDT) From: Jeffrey Hutzelman To: Tobias Gondrom In-Reply-To: <4FCCE496.1030800@gondrom.org> References: <4FCCC936.3030600@gondrom.org> <4FCCE496.1030800@gondrom.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 04 Jun 2012 13:51:33 -0400 Message-ID: <1338832293.7221.60.camel@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: ietf-krb-wg@anl.gov, apps-discuss@ietf.org, iesg@ietf.org, draft-ietf-krb-wg-kdc-model.all@tools.ietf.org, hartmans-ietf@mit.edu, jhutz@cmu.edu Subject: Re: [apps-discuss] AppsDir review of draft-ietf-krb-wg-kdc-model X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 17:51:40 -0000 On Mon, 2012-06-04 at 17:38 +0100, Tobias Gondrom wrote: > On 04/06/12 17:02, Sam Hartman wrote: > >>>>>> "Tobias" == Tobias Gondrom writes: > > > > Tobias> One basic question: > > Tobias> This draft aims for Standards Track, yet as far as I understood, it is > > Tobias> not required that the used field names are in fact the same across > > Tobias> different implementations but only that name-mappings exist. The ID > > Tobias> also uses a modified RFC2119 language definition to allow that. > > Tobias> I would like to ask, whether possibly Informational Status would be > > Tobias> more appropriate for this draft? > > > > My concern is that this does specify mandatory behavior of > > implementations and that it's likely that a schema would want to > > normatively refer to this document for semantics of attributes. > Does it have to be Standards Track for that purpose? > (note: I don't have a strong opinion on this, just feel uneasy with > using the watered down 2119 definitions in the draft and the > name-mapping, and then to go for Standards Track....) The present document is a data model. Its "implementations" are schemas or the like; that is, other documents. The RFC2119 language is in fact not "watered down"; rather, it is the case that, for example, we may REQUIRE a schema to include a particular field without requiring that every implementation of that schema support that field. The particular point you raised about names is not, in fact a problem. Read with the understanding that an implementation of this document is a schema or the like and _not_ a piece of software, the language in the third paragraph of section 1 means that an LDAP schema or XML DTD based on this document would not be required to use the same field names as are used in the model, provided the document defining such a schema or DTD makes clear which of its fields correspond to which fields in the data model. Yes, this document wants to be standards track. It is intended to define the semantics of data items used by the KDC and made visible in one or more standards track management protocols. > On a personal note: Would still be curious about the intentions for > draft-ietf-krb-wg-kerberos-set-passwd? It is an item on our current charter, to which we intend eventually to return. Both the author and the working group have been concentrating on other work for some time. -- Jeff From leifj@sunet.se Mon Jun 4 11:58:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8514C11E80C4; Mon, 4 Jun 2012 11:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uPN+ehu6eRy; Mon, 4 Jun 2012 11:58:56 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id BA76311E80C2; Mon, 4 Jun 2012 11:58:55 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q54Iwg02003300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jun 2012 20:58:47 +0200 (CEST) Message-ID: <4FCD0562.10300@sunet.se> Date: Mon, 04 Jun 2012 20:58:42 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tobias Gondrom References: <4FCCC936.3030600@gondrom.org> <4FCCE496.1030800@gondrom.org> In-Reply-To: <4FCCE496.1030800@gondrom.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-krb-wg-kdc-model.all@tools.ietf.org, ietf-krb-wg@anl.gov, hartmans-ietf@mit.edu, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-ietf-krb-wg-kdc-model X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 18:58:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/04/2012 06:38 PM, Tobias Gondrom wrote: > On 04/06/12 17:02, Sam Hartman wrote: >>>>>>> "Tobias" == Tobias Gondrom >>>>>>> writes: >> >> Tobias> One basic question: Tobias> This draft aims for >> Standards Track, yet as far as I understood, it is Tobias> not >> required that the used field names are in fact the same across >> Tobias> different implementations but only that name-mappings >> exist. The ID Tobias> also uses a modified RFC2119 language >> definition to allow that. Tobias> I would like to ask, whether >> possibly Informational Status would be Tobias> more appropriate >> for this draft? >> >> My concern is that this does specify mandatory behavior of >> implementations and that it's likely that a schema would want to >> normatively refer to this document for semantics of attributes. > Does it have to be Standards Track for that purpose? (note: I don't > have a strong opinion on this, just feel uneasy with using the > watered down 2119 definitions in the draft and the name-mapping, > and then to go for Standards Track....) It isn't watered-down at all! The reason we have that section is to clarify what an implementation of the information-model actually is (a schema) and what it means to be compliant with the information model. The RFC2919 terms mean what they always mean - just in a non-typical context (i.e not just viz an bits-on-the-wire implementation) Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/NBV0ACgkQ8Jx8FtbMZnf+BwCfbkN1S6Em41wIwmyh0cR8FIFE ssQAnR3s0TtpUcpih689UPwb8Mc50GoA =X0lz -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Mon Jun 4 12:01:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D0221F84A7; Mon, 4 Jun 2012 12:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlaSY1KxXsgv; Mon, 4 Jun 2012 12:01:48 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC8111E80BC; Mon, 4 Jun 2012 12:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338836507; d=isode.com; s=selector; i=@isode.com; bh=vxo9UNRHNXKosweE/7BBzhB8IVZ0Ll8Zii4qOOSGJOI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=DXUlY8hlueWQ6af40iOP9KQgx8xRYhMglblOtCsSfTEVgIH/5XQ9vNCIi+Q3t0jST+zzz1 IZRrs48uXe9Saf2mZOTMIJMu4nBhjJ4iOWoknM8eyz7fJjbc8qfXd4DGj+KUW12F2N9478 U4LUNjEBo0gs6MJIx8BuWWC0PjxDN6Y=; Received: from [172.20.10.2] ((unknown) [212.183.128.204]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 4 Jun 2012 20:01:44 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FCD0614.5050902@isode.com> Date: Mon, 04 Jun 2012 20:01:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: apps-discuss@ietf.org, draft-ietf-nea-pt-tls.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-nea-pt-tls-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 19:01:49 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. The review is not copied to the IESG as the Last Call has not been announced yet. Document: draft-ietf-nea-pt-tls-04 Title: PT-TLS: A TCP-based Posture Transport (PT) Protocol Reviewer: Alexey Melnikov Review Date: June 4, 2012 Summary: This document is almost ready for publication as a Proposed Standard, although some [mostly] SASL related issues remain. This document specifies PT-TLS, a TCP-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel. (Note, I've reviewed -04, but I think all of this still applies to -05.) Major: In 3.4.2.1: RFC 6125 use details are missing. You need to describe whether CN-IDs and SRV-IDs are allowed, whether wildcards are allowed, etc. I can suggest some details. Minor: In Section 3.2: This document is not yet Internet Standard, it will be Proposed Standard. Suggest saying "Publication on Standards Track" instead instead of "Internet Standard". The same issue in the IANA consideration section. In 3.8.1: I think one instance of "SASL authentication messages" --> "SASL authentication mechanisms". Otherwise this sentence is out of place, as you are not talking about SASL messages. In 3.8.4: in SASL the server doesn't return abort as an error code, it just fails the authentication exchange. I suggest removing it as a choice. In 3.8.7: you define the Reserved field which I assume is used for padding? If yes, then you will not get proper alignment for the next field, as SASL mechanism names are variable length. (If you intended that they are always sent as 20 bytes, then this is missing from the document.) In 3.8.10: The Abort choice is really not needed (as per above). Also, can you give me an example of when the Mechanism Failure will be returned instead of just Failure? In 3.9: Failed Authentication error code - how does this differ from SASL Authentication result with Failure code? In 4.1.2, second block, the first bullet: I think you meant "client" instead of the "server". Question (might not be an issue): In 6.2: is it possible to register a vendor specific value without a specification? The same question for 6.3. Nits: None From dhc@dcrocker.net Mon Jun 4 13:15:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E4211E80EC; Mon, 4 Jun 2012 13:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuxPqvlbYGjV; Mon, 4 Jun 2012 13:15:37 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CAE2911E80E8; Mon, 4 Jun 2012 13:15:36 -0700 (PDT) Received: from [192.168.2.101] (g225186006.adsl.alicedsl.de [92.225.186.6]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q54KFTTh025262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Jun 2012 13:15:31 -0700 Message-ID: <4FCD175D.30307@dcrocker.net> Date: Mon, 04 Jun 2012 22:15:25 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> In-Reply-To: <4FCA6BFE.3050609@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]); Mon, 04 Jun 2012 13:15:36 -0700 (PDT) Cc: draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:15:38 -0000 Alexey, On 6/2/2012 9:39 PM, Alexey Melnikov wrote: >>>>> 5.2. Timely Delivery >>>>> >>>>> An important constraint (usually associated with higher priority >>>>> levels) is that messages with high priority have some delivery time >>>>> constraints. In some cases, higher priorities mean a shorter maximum >>>>> time allowed for delivery. >>>>> >>>>> Unextended SMTP does not offer a service for timely delivery. The >>>>> "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in >>>>> [RFC2852] is an example of an SMTP extension providing a service that >>>>> can be used to implement such constraints. But note that use of the >>>>> DELIVERBY extension alone does not guarantee any priority processing. >>>> >>>> It seems as if this section introduces an issue but does not actually >>>> deal with it. Perhaps there should be some discussion of the possible >>>> (or required?) interaction between the two extensions it discusses? >>> >>> There is no issue and no real interaction in this specific case. A >>> client that wants to use both against a server that supports both should >>> consider this issue. >> >> Specifications that say an implementer should consider something but >> which gives no guidance about the consideration aren't doing much >> useful, in my view. >> >> As this set of text was proceeding, I thought it was going to provide >> some useful guidance about possible uses of the combined options, >> since it seemed like the combination could be, well, useful. > > The client can decide to use smaller values. In this case it is up to > the client to pick them, this is not controlled by the site policy. Once again: it is not reasonable to have different clients apply different semantics (policies) for choosing values. The values need to have consistent meaning across the entire the trust environment that is supporting this mechanism. Otherwise, it won't work properly. The environment will be left with individual clients taking more than their fair share. Or trying to. Absent very specific rules to be applied consistently across the trust environment, what is most likely is that every client will always claim top priority and no one will actually get it. (This is a well-known phenomenon for this sort of game-theoretic condition.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From adrian@olddog.co.uk Mon Jun 4 13:59:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4A711E8106; Mon, 4 Jun 2012 13:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CRN33ReseWb; Mon, 4 Jun 2012 13:59:23 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 0196F11E807F; Mon, 4 Jun 2012 13:59:22 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q54KxGAg024610; Mon, 4 Jun 2012 21:59:16 +0100 Received: from 950129200 (ns-visitor-nsrp.juniper.net [208.223.208.242]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q54KxD57024588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2012 21:59:14 +0100 From: "Adrian Farrel" To: "'Murray S. Kucherawy'" , , , References: <9452079D1A51524AA5749AD23E00392812C442@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392812C442@exch-mbx901.corp.cloudmark.com> Date: Mon, 4 Jun 2012 21:59:12 +0100 Message-ID: <014901cd4294$e6ba1440$b42e3cc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL7zXuqY6u57WJZ2IF/5Dzq5Xpj1ZSNik9Q Content-Language: en-gb Cc: 'The IESG' Subject: Re: [apps-discuss] AppsDir review of draft-farrresnickel-ipr-sanctions X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:59:27 -0000 Hi Murray, Sorry for a delayed reply... > Summary: This document is ready for publication as an Informational > document, modulo my two issues for discussion below. > > Major Issues: > > 1. Should this not be a BCP?=A0 The polk draft describes ways to = encourage > compliance, while this one talks about penalties for = non-compliance.=A0 That > seems too severe for Informational status, while the polk draft can=20 > probably get away with it. My thinking was that this does not define any new process and doesn't = even recommend their use. It just makes sure people remember the options = exist. Barry seems to think "not a BCP" as well. Maybe we leave this to the IESG? > Minor Issues: > > 1. Are all the URL references in here permanent?=A0 I=92m not sure = about things > like [URLIESGIPR], for example, since it points to a wiki. I am not sure the URLs must be permanent. Sure we would like them to be = "stable" but the RFC Editor seems to say that a URL is acceptable where no better reference can be found. Additionally, this is "only" an Informative = reference. Can we leave this, and fix it if the RFC Editor complains? > Nits: Useful and accepted, except... > 3. Section 2.4: s/to be clearly understood/to be understood clearly/ This is largely stylistic and a lot of stuff is said about split = infinitives. Here I intended to stress clarity not understanding. I am sure the RFC Editor will apply house style. Thanks, Adrian From stpeter@stpeter.im Mon Jun 4 14:04:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F9D21F8522; Mon, 4 Jun 2012 14:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.851 X-Spam-Level: X-Spam-Status: No, score=-102.851 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MGx0AX6T-3n; Mon, 4 Jun 2012 14:04:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0F41111E807F; Mon, 4 Jun 2012 14:04:47 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E647F400A4; Mon, 4 Jun 2012 15:21:30 -0600 (MDT) Message-ID: <4FCD22ED.1030804@stpeter.im> Date: Mon, 04 Jun 2012 15:04:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <9452079D1A51524AA5749AD23E00392812C442@exch-mbx901.corp.cloudmark.com> <014901cd4294$e6ba1440$b42e3cc0$@olddog.co.uk> In-Reply-To: <014901cd4294$e6ba1440$b42e3cc0$@olddog.co.uk> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-farrresnickel-ipr-sanctions.all@tools.ietf.org, 'The IESG' , apps-discuss@ietf.org, "'Murray S. Kucherawy'" Subject: Re: [apps-discuss] AppsDir review of draft-farrresnickel-ipr-sanctions X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 21:04:48 -0000 On 6/4/12 2:59 PM, Adrian Farrel wrote: > Hi Murray, > > Sorry for a delayed reply... > >> Summary: This document is ready for publication as an Informational >> document, modulo my two issues for discussion below. >> >> Major Issues: >> >> 1. Should this not be a BCP? The polk draft describes ways to encourage >> compliance, while this one talks about penalties for non-compliance. That >> seems too severe for Informational status, while the polk draft can >> probably get away with it. > > My thinking was that this does not define any new process and doesn't even > recommend their use. It just makes sure people remember the options exist. > > Barry seems to think "not a BCP" as well. > > Maybe we leave this to the IESG? Hi Adrian, In draft-polk-ipr-disclosure we added the following paragraph: By intent, this document does not claim to define best current practices; instead, it suggests strategies that ADs, WG chairs, and WG secretaries might find useful. With sufficient use and appropriate modification to incorporate the lessons of experience, these strategies might someday form the basis for documentation of best current practices. Something similar might be appropriate for your I-D as well. Peter -- Peter Saint-Andre https://stpeter.im/ From ned.freed@mrochek.com Mon Jun 4 15:13:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E09521F86DB; Mon, 4 Jun 2012 15:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUO3ufZx6qNI; Mon, 4 Jun 2012 15:13:10 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A04F721F8589; Mon, 4 Jun 2012 15:13:10 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGAJ8HI9U8002QM5@mauve.mrochek.com>; Mon, 4 Jun 2012 15:13:08 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG54121Q0W0006TF@mauve.mrochek.com>; Mon, 4 Jun 2012 15:13:06 -0700 (PDT) Message-id: <01OGAJ8GBR2Q0006TF@mauve.mrochek.com> Date: Mon, 04 Jun 2012 14:47:39 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 04 Jun 2012 22:15:25 +0200" <4FCD175D.30307@dcrocker.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> To: Dave Crocker Cc: draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 22:13:12 -0000 > Once again: it is not reasonable to have different clients apply > different semantics (policies) for choosing values. The values need to > have consistent meaning across the entire the trust environment that is > supporting this mechanism. > Otherwise, it won't work properly. More precisely, it may "work" in some sense, but it may not deliver the results you expect, which given what I understand the intended uses to be may be problematic. OTOH, it may actually work very well, if for no other reason than most modern mail systems are able to deliver messages in a matter of seconds most of the time, which will make it difficult for a human user to observe any tangible difference for different priorities. And in practice since prioritization is very complex - to the point where, as I've pointed out previously, the most obvious strategies may actually result in increased latency, especially under high load conditions - so aligning behavior across multiple implementations may prove to be a practical impossibility. All that said, I am completly at a loss as to what, if anything, to do about all of this. To nail down what prioritization means in an operational sense requires a far more detailed model of how MSA/MTA/MDAs work than we currently have. And I given what I know about the internals of various MTAs, I despair of finding any sort of model that is simultaneously sufficiently general and sufficiently accurate that we could even talk about this stuff sensibly. There's a reason why every specification I've seen that mentions email prioritization, going back as far as FIPS PUB 98 (RFC 841) and including X.400, GOSIP, various LAN email systems, either omits entirely any description of what priorization actually means or contains nothing but a bunch of handwaving. > The environment will be left with individual clients taking more than > their fair share. Or trying to. > Absent very specific rules to be applied consistently across the trust > environment, what is most likely is that every client will always claim > top priority and no one will actually get it. (This is a well-known > phenomenon for this sort of game-theoretic condition.) I have no good explanation for it, but the evidence I've seen says otherwise: Quite a few existing systems support message prioritization, but I've yet to encounter a case where everybody claims the top priority. (Users mostly seem to ignore it, even when the controls for setting it are in plain view.) I rather suspect it's a combination of factors: (1) As noted above, it has no observable effect a lot of the time, (2) Interfaces rarely let average users bump the default priority, meaning you have to do it every time, and (3) It can have unwanted side effects, e.g., shortening timeouts, using up quotas, or enabling generation of delivery receipts. Ned From Jeff.Hodges@KingsMountain.com Mon Jun 4 15:57:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4B921F8655 for ; Mon, 4 Jun 2012 15:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.3 X-Spam-Level: X-Spam-Status: No, score=-99.3 tagged_above=-999 required=5 tests=[AWL=1.105, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmGpCe9pZAZ9 for ; Mon, 4 Jun 2012 15:57:57 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id C4DD021F8631 for ; Mon, 4 Jun 2012 15:57:56 -0700 (PDT) Received: (qmail 1169 invoked by uid 0); 4 Jun 2012 22:57:56 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 4 Jun 2012 22:57:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=vhkvePCjnsLg0H6lk5OUUQ+K0jSuzNKSWHFDbz+2zPI=; b=NlGxGk3afFXuIClWfdj+H9qu7ei97VVDQvJ/QqKAMmCbcHx7Q9MVXWCtZAfgyQnQ+bzu6tSfCtb2JISv8uhP8kPh9HkwJ8UV62FwU4vTTWouyYrCcc3VUtA4JbyyLIKg; Received: from [24.4.122.173] (port=34158 helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SbgDk-0000Es-6y; Mon, 04 Jun 2012 16:57:56 -0600 Message-ID: <4FCD3D73.6000509@KingsMountain.com> Date: Mon, 04 Jun 2012 15:57:55 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: draft-ietf-websec-strict-transport-sec@tools.ietf.org, IETF WebSec WG , Apps Discuss Subject: Re: [apps-discuss] AppsDir review of draft-ietf-websec-strict-transport-sec X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 22:57:58 -0000 >>> Section 3: Are the latter two paragraphs really necessary? I only find >>> such >>> statements useful when minimum conformance is not the same thing as full >>> conformance. >> >> It's apparently helpful for readers with a strong W3C-style spec background. >> I'll leave them in. > > It might be a good idea, then, to put something like the following in > at the beginning of the section: > > [[IESG Note: This section is for readers with a background in W3C > specification style, of which we expect many. RFC Editor, please > remove this note before publication.]] > > This will avoid the same question/complaint from ADs during IESG evaluation. > > I also suggest that you move the 2119 paragraph to the end of the > section, to keep all three compliance-related paragraphs together. thx, the above is done in the -09 working copy. =JeffH From john@jck.com Mon Jun 4 16:14:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B05321F85A8; Mon, 4 Jun 2012 16:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5-tS+AStbVy; Mon, 4 Jun 2012 16:14:47 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEE511E80EC; Mon, 4 Jun 2012 16:14:47 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SbgNy-0001QX-6g; Mon, 04 Jun 2012 19:08:30 -0400 Date: Mon, 04 Jun 2012 19:14:34 -0400 From: John C Klensin To: Ned Freed , Dave Crocker Message-ID: In-Reply-To: <01OGAJ8GBR2Q0006TF@mauve.mrochek.com> References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> <01OGAJ8GBR2Q0006TF@mauve.mrochek.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: draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 23:14:48 -0000 --On Monday, June 04, 2012 14:47 -0700 Ned Freed wrote: >... > More precisely, it may "work" in some sense, but it may not > deliver the results > you expect, which given what I understand the intended uses to > be may be problematic. I mostly agree, but see below. > OTOH, it may actually work very well, if for no other reason > than most modern > mail systems are able to deliver messages in a matter of > seconds most of the > time, which will make it difficult for a human user to observe > any tangible > difference for different priorities. > > And in practice since prioritization is very complex - to the > point where, as > I've pointed out previously, the most obvious strategies may > actually result in > increased latency, especially under high load conditions - so > aligning behavior > across multiple implementations may prove to be a practical > impossibility. Yes in principle. In practice, I've seen one set of communities that have repeatedly expressed high levels of demand for prioritization. Those communities are military or ones with aspirations to behave like military ones. For those communities, "messages from the General get more delivery priority than those from the Lieutenant" have obvious meaning and obvious intent. Moreover, the obvious response, especially if someone is a communications officer in that chain of command, is to salute and say, "yessir, we will transmit the General's message with instructions to process it at higher priority". If what happens after that is that this information is passed along but no MTA does a thing about it, your observation about a second or two takes over, there is a report back to the General of complete conformance to his wishes and recognition of his exalted status, and everyone is happy. And, if that trick doesn't work, it is always possible to artificially delay the Lieutenant's mail for a while, even if the General has no mail in the queue, just to help prove that the General is important. Simply dumping the Lieutenant's mail into the queue when it arrives while trying to immediately process the General's mail for delivery or forwarding would probably be a sufficient implementation. I don't have enough data to claim that scenario occurs many times around the world every day, but it has got to be close. That view leads to an unattractive variation on Ned's question... > All that said, I am completly at a loss as to what, if > anything, to do about > all of this. To nail down what prioritization means in an > operational sense > requires a far more detailed model of how MSA/MTA/MDAs work > than we currently > have. And I given what I know about the internals of various > MTAs, I despair > of finding any sort of model that is simultaneously > sufficiently general > and sufficiently accurate that we could even talk about this > stuff sensibly. >... I agree about the model issues (and have said so). But suppose the above scenario, for which the model is good enough within a chain of command and irrelevant outside it, _is_ the use case. The question is then whether it is appropriate for the IETF to support this type of essentially "do little but get folks to feel good" option. I'd normally say "no". But, if the reality is that people will demand mail prioritization --I suggest that they will as long as there are Generals and they outrank Lieutenants and maybe as long as there are mail service providers who can figure out how to charge one class of customers more for exactly the same service because that groups is willing to pay to be important-- and, that by standardizing something we can at least do a security analysis and contain interoperability issues, then maybe we should just hold our noses (or Alexey's) and do it. john From presnick@qualcomm.com Mon Jun 4 16:35:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B049811E80FC; Mon, 4 Jun 2012 16:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.863 X-Spam-Level: X-Spam-Status: No, score=-105.863 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kAyTNgFCtof; Mon, 4 Jun 2012 16:35:52 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 70A7E11E80BA; Mon, 4 Jun 2012 16:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1338852952; x=1370388952; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; bh=cfgmiQwcTSP/JqUsfKjh1SwdQeRWc1xglOUTgZDhZ+E=; b=tp677cG1BB4HFVfTvwEABDyoRBBlejRxmjWnl+1F2aIuYqnzqcazjlHy dZOQrnXVd7a2ms4p5QRB5GebKKxQrNVgKUBq9/VSK18BDO1WT2PPrh7SY 9VB4sGBGKgRjk80RySCSAxEpUNPVT9tAoAi/Q5VIZSyICremI5l+CN6HN s=; X-IronPort-AV: E=McAfee;i="5400,1158,6732"; a="195339506" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 04 Jun 2012 16:35:51 -0700 X-IronPort-AV: E=Sophos;i="4.75,714,1330934400"; d="scan'208";a="159502179" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Jun 2012 16:35:51 -0700 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 4 Jun 2012 16:35:51 -0700 Message-ID: <4FCD4653.6080105@qualcomm.com> Date: Mon, 4 Jun 2012 18:35:47 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> <01OGAJ8GBR2Q0006TF@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: Ned Freed , apps-discuss@ietf.org, draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 23:35:55 -0000 On 6/4/12 6:14 PM, John C Klensin wrote: > ...if the reality > is that people will demand mail prioritization --I suggest that > they will as long as there are Generals and they outrank > Lieutenants and maybe as long as there are mail service > providers who can figure out how to charge one class of > customers more for exactly the same service because that groups > is willing to pay to be important-- and, that by standardizing > something we can at least do a security analysis and contain > interoperability issues, then maybe we should just hold our > noses (or Alexey's) and do it. > Speaking as the sponsoring AD, this is where I ended up. I find much of this exercise silly; I find more than 5 "priorities" complete overkill, and I think the likelihood that in a modern SMTP system any of these priorities will cause a significant change in delivery time (or order, for that matter) to be exceedingly low. That said, there is a community that insists on attempting this, and it is not a completely insular community; they will insist on implementations not of their own making to do "the right thing" about this. Given that, I'd prefer we document it and see if it gets deployment in any kind of interoperable way. If it doesn't, we move it to Historic and move on with our lives. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From presnick@qualcomm.com Mon Jun 4 16:57:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D3311E812D; Mon, 4 Jun 2012 16:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.912 X-Spam-Level: X-Spam-Status: No, score=-105.912 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wucnKoxN4O91; Mon, 4 Jun 2012 16:57:28 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5867111E8125; Mon, 4 Jun 2012 16:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1338854248; x=1370390248; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; bh=knefK+wKdNGH/5OHwH6+5fO/kVtDnh7rNMYGo71cilU=; b=ae0PePN3YC7rgvKRGk9FotdBGok9zzLKU8I2eYezLq04ROCNCCFNvhlq X9A9OObUJl+kV3yw15iB7mvcceYiEc8mVJp39DpBAjbf5PfK0FEjzBzC5 LiLaqDgydXBlKDuBzN9E8d227Erw9PxFDrj8boO7Jai8MIsjMbQpATfc4 A=; X-IronPort-AV: E=McAfee;i="5400,1158,6732"; a="195344953" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 04 Jun 2012 16:57:28 -0700 X-IronPort-AV: E=Sophos;i="4.75,716,1330934400"; d="scan'208";a="260654153" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Jun 2012 16:57:24 -0700 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 4 Jun 2012 16:57:24 -0700 Message-ID: <4FCD4B62.204@qualcomm.com> Date: Mon, 4 Jun 2012 18:57:22 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> <01OGAJ8GBR2Q0006TF@mauve.mrochek.com> <4FCD4653.6080105@qualcomm.com> In-Reply-To: <4FCD4653.6080105@qualcomm.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: Ned Freed , apps-discuss@ietf.org, draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 23:57:29 -0000 On 6/4/12 6:35 PM, Pete Resnick wrote: > On 6/4/12 6:14 PM, John C Klensin wrote: > >> ...if the reality >> is that people will demand mail prioritization --I suggest that >> they will as long as there are Generals and they outrank >> Lieutenants and maybe as long as there are mail service >> providers who can figure out how to charge one class of >> customers more for exactly the same service because that groups >> is willing to pay to be important-- and, that by standardizing >> something we can at least do a security analysis and contain >> interoperability issues, then maybe we should just hold our >> noses (or Alexey's) and do it. > > Speaking as the sponsoring AD, this is where I ended up. I find much > of this exercise silly; I find more than 5 "priorities" complete > overkill, and I think the likelihood that in a modern SMTP system any > of these priorities will cause a significant change in delivery time > (or order, for that matter) to be exceedingly low. That said, there is > a community that insists on attempting this, and it is not a > completely insular community; they will insist on implementations not > of their own making to do "the right thing" about this. Given that, > I'd prefer we document it and see if it gets deployment in any kind of > interoperable way. If it doesn't, we move it to Historic and move on > with our lives. Sorry, should have ended with the appropriate question: Does anybody feel that we should *not* be moving forward and documenting this? pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From superuser@gmail.com Mon Jun 4 22:23:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C06121F8731; Mon, 4 Jun 2012 22:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSMjSfh97S8F; Mon, 4 Jun 2012 22:23:43 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2310621F8726; Mon, 4 Jun 2012 22:23:42 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3940698lbb.31 for ; Mon, 04 Jun 2012 22:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pVr4SzkPJgPZuAkTVXxEfIv4+e4RGpDEwFbFVnIUcF0=; b=n8ZMfOJEdhq87Zj/C5OT+PpsqrrWelgjOc2v7vWccyJ+vZ19waaSxoSCP/G+PPQ9mO AdjpTpgQXT+awFXk0o+Bln+1P1Ov/M5mnFubbZbFcunicSLBSFvv20GLIZuWKTXMpocb AzAhpD94BRkZ+1dX0SkwDIGnRwzzaMsudhMOd+l2pmXj8s7TSxBiuZU99ZUxUKuhJyPx NCW6y3FEzgoJxNC7pyAk/cc45ah1UeHm9BWCdKjNfW/Gxixa+7lCw0JGT7LeyldQo020 5yUjxPsfYqn/GeiqESijLRRGp5FYoDVORmbAO/P3hTpd0+DNtOeyq7XmcahMnhjKkhit uBzg== MIME-Version: 1.0 Received: by 10.112.49.100 with SMTP id t4mr7331511lbn.10.1338873821906; Mon, 04 Jun 2012 22:23:41 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 4 Jun 2012 22:23:41 -0700 (PDT) In-Reply-To: <014901cd4294$e6ba1440$b42e3cc0$@olddog.co.uk> References: <9452079D1A51524AA5749AD23E00392812C442@exch-mbx901.corp.cloudmark.com> <014901cd4294$e6ba1440$b42e3cc0$@olddog.co.uk> Date: Mon, 4 Jun 2012 22:23:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=bcaec554d63c8dc77404c1b2da9a Cc: draft-farrresnickel-ipr-sanctions.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-farrresnickel-ipr-sanctions X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 05:23:44 -0000 --bcaec554d63c8dc77404c1b2da9a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jun 4, 2012 at 1:59 PM, Adrian Farrel wrote: > > 1. Should this not be a BCP? The polk draft describes ways to encourag= e > > compliance, while this one talks about penalties for non-compliance. > That > > seems too severe for Informational status, while the polk draft can > > probably get away with it. > > My thinking was that this does not define any new process and doesn't eve= n > recommend their use. It just makes sure people remember the options exist= . > > Barry seems to think "not a BCP" as well. > > Maybe we leave this to the IESG? > Sure. PSA's suggestion is also reasonable to me. > > > Minor Issues: > > > > 1. Are all the URL references in here permanent? I=92m not sure about > things > > like [URLIESGIPR], for example, since it points to a wiki. > > I am not sure the URLs must be permanent. Sure we would like them to be > "stable" > but the RFC Editor seems to say that a URL is acceptable where no better > reference can be found. Additionally, this is "only" an Informative > reference. > > Can we leave this, and fix it if the RFC Editor complains? > Yep. I was just trying to anticipate what the Editor might want. Whatever satisfies their requirements works for me. > > > Nits: > > Useful and accepted, except... > > > 3. Section 2.4: s/to be clearly understood/to be understood clearly/ > > This is largely stylistic and a lot of stuff is said about split > infinitives. > Here I intended to stress clarity not understanding. > I am sure the RFC Editor will apply house style. > Same here. Cheers, -MSK --bcaec554d63c8dc77404c1b2da9a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 4, 2012 at 1:59 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> 1. Should this not be a BCP?=A0 The polk draft describes ways to encou= rage
> compliance, while this one talks about penalties for non-compliance.= =A0 That
> seems too severe for Informational status, while the polk draft can > probably get away with it.

My thinking was that this does not define any new process and doesn't e= ven
recommend their use. It just makes sure people remember the options exist.<= br>
Barry seems to think "not a BCP" as well.

Maybe we leave this to the IESG?

Sure.=A0 PSA'= s suggestion is also reasonable to me.
=A0

> Minor Issues:
>
> 1. Are all the URL references in here permanent?=A0 I=92m not sure abo= ut things
> like [URLIESGIPR], for example, since it points to a wiki.

I am not sure the URLs must be permanent. Sure we would like them to be &qu= ot;stable"
but the RFC Editor seems to say that a URL is acceptable where no better reference can be found. Additionally, this is "only" an Informati= ve reference.

Can we leave this, and fix it if the RFC Editor complains?
=

Yep.=A0 I was just trying to anticipate what the Editor might want= .=A0 Whatever satisfies their requirements works for me.
=A0

> Nits:

Useful and accepted, except...

> 3. Section 2.4: s/to be clearly understood/to be understood clearly/
This is largely stylistic and a lot of stuff is said about split infinitive= s.
Here I intended to stress clarity not understanding.
I am sure the RFC Editor will apply house style.

S= ame here.

Cheers,
-MSK

--bcaec554d63c8dc77404c1b2da9a-- From Claudio.Allocchio@garr.it Mon Jun 4 23:35:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF7A21F865F; Mon, 4 Jun 2012 23:35:16 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIXTuyz3M2Dq; Mon, 4 Jun 2012 23:35:15 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 92C0C21F855A; Mon, 4 Jun 2012 23:35:15 -0700 (PDT) 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.5/8.14.5) with ESMTP id q556Z9n3070112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2012 08:35:11 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q556Z9n3070112 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=oRZmS6/oos6iIAGk04lmq0GDEjyLn/KBmYh1A6oY+wkL/lrWgzd3z3m5gnWS3guqA xWzzrWCEOjrRdwlkrC2JKdkC00pELm9jdVTcY/jzjOKeJ7ygkoVDjZTA43P90d7pap+ DFhUb4tucHN/iyFaPDg5Gn4SOZBzuZSTDpc+/d4= Date: Tue, 5 Jun 2012 08:35:09 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@webcam1-all.garrtest.units.it To: Pete Resnick In-Reply-To: <4FCD4653.6080105@qualcomm.com> Message-ID: References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> <01OGAJ8GBR2Q0006TF@mauve.mrochek.com> <4FCD4653.6080105@qualcomm.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: John C Klensin , Ned Freed , draft-melnikov-smtp-priority.all@tools.ietf.org, apps-discuss@ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 06:35:16 -0000 On Mon, 4 Jun 2012, Pete Resnick wrote: > On 6/4/12 6:14 PM, John C Klensin wrote: > >> ...if the reality >> is that people will demand mail prioritization --I suggest that >> they will as long as there are Generals and they outrank >> Lieutenants and maybe as long as there are mail service >> providers who can figure out how to charge one class of >> customers more for exactly the same service because that groups >> is willing to pay to be important-- and, that by standardizing >> something we can at least do a security analysis and contain >> interoperability issues, then maybe we should just hold our >> noses (or Alexey's) and do it. >> > > Speaking as the sponsoring AD, this is where I ended up. I find much of this > exercise silly; I find more than 5 "priorities" complete overkill, and I > think the likelihood that in a modern SMTP system any of these priorities > will cause a significant change in delivery time (or order, for that matter) > to be exceedingly low. That said, there is a community that insists on > attempting this, and it is not a completely insular community; they will > insist on implementations not of their own making to do "the right thing" > about this. Given that, I'd prefer we document it and see if it gets > deployment in any kind of interoperable way. If it doesn't, we move it to > Historic and move on with our lives. +1 +1 +1 Also given the combination of other "actions" which happens to an e-mail message when traversing current MTAs and MUAs: Highest Priority which meets a graylisting in the middle... need other examples? Let's see... and we check later on. > > pr > > -- > Pete Resnick > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > > _______________________________________________ > 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 duerst@it.aoyama.ac.jp Tue Jun 5 02:43:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D545F21F86B3 for ; Tue, 5 Jun 2012 02:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.852 X-Spam-Level: X-Spam-Status: No, score=-98.852 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_50=0.001, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_35=0.6, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTQyhzI7ei+L for ; Tue, 5 Jun 2012 02:43:06 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 417A321F86C5 for ; Tue, 5 Jun 2012 02:43:05 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q559gqEY014598 for ; Tue, 5 Jun 2012 18:42:52 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 4a8b_f5b5_d18e615a_aef2_11e1_a54d_001d096c5782; Tue, 05 Jun 2012 18:42:51 +0900 Received: from [IPv6:::1] ([133.2.210.1]:52147) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 5 Jun 2012 18:42:56 +0900 Message-ID: <4FCDD499.7060206@it.aoyama.ac.jp> Date: Tue, 05 Jun 2012 18:42:49 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: draft-farrell-decade-ni.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF discussion list , "apps-discuss@ietf.org" Subject: [apps-discuss] APPSDIR review of draft-farrell-decade-ni-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 09:43:09 -0000 Hello everybody, [For replies, please trim the cc list, thanks!] I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-farrell-decade-ni-07 Title: Naming Things with Hashes Reviewer: Martin Dürst Review Date: 2012-06-03, 2012 (written up 2012-06-04/05) IETF Last Call Date: started 2012-06-04, ends 2012-07-02 Summary: This draft addresses a real generic need, but the current form of the draft is the result of adding more and more special cases without a clear overall view and a firm hand to separate the wheat from the chaff. This shows both in the technical issues as well as in many of the editorial issues below. This draft is not ready for publication without some serious additional work, but that work is mostly straightforward and should be easy to complete quickly. Major design issue: The draft defines two schemes, which differ only slightly, and mostly just gratuitously (see also editorial issues). These are the ni: and the nih: scheme. As far as I understand, they differ as follows: ni: nih: authority: optional disallowed ascii-compatible encoding: base64url base16 check digit: disallowed optional query part: optional disallowed decimal presentation of algorithm: disallowed possible The usability of URIs is strongly influenced by the number of different schemes, with the smaller a number, the better. As a somewhat made-up example, if the original URIs had been separated into httph: for HTML pages and httpi: for images, or any other arbitrary subdivision that one can envision, that would have hurt the growth and extensibility of the Web. Creating new URI schemes is occasionally necessary, and the ideas that lead to this draft definitely seem to warrant a new scheme (*), but there's no reason for two schemes. [(*) I know people who would claim the the .well-formed http/https thing is completely sufficient, no new scheme needed at all.] More specifically, if the original URIs had been separated into httpm: (for machines) and httph: (for humans), the Web for sure wouldn't have grown at the speed it did (and does) grow. In practice, there are huge differences in human 'speakability' for URIs (and IRIs, for that matter); compare e.g. http://google.com with http://www.google.co.jp/#sclient=psy-ab&hl=en&site=&source=hp&q=hash&oq=hash&aq=f&aqi=g4&aql= (which I have significantly shortened to hopefully eliminate potential privacy issues), or compare the average mailto: URI with the average data: URI. However, what's important is that there never has been a strong dividing line between machine-only and human-only URIs or schemes, the division has always been very gradual. Short and mainly human-oriented URIs have of course been handled by machines, and on the other hand, very long URIs have been spoken when really necessary. "Speakability" has been maintained to some extent by scheme designers, and to some extent by "survival of the fittest" (URIs that weren't very speakable (or spellable/memorizable/guessable/...), and their Web sites, might just die out slowly). It should also be noted that the resistance against multiple URI schemes may have been low because there are so many different ways to express hashes in the draft anyway, and one more (the nih: section is the last one before the examples section) didn't seem like much of a deal anymore. But when it comes to URIs, one less is a lot better than one more. In the above ni:/nih: distinction, nih: seems to have been added as an afterthought after realizing that reading an ni: URI aloud over the phone may be somewhat suboptimal because there is a need for repeated "upper case" - "lower case" (sure very quickly shortened to "upper" - "lower" and then to "up" - "low" or something similar). It is not a bad idea to try to make sure that IETF technology, and URIs in particular, are accessible to people with certain kinds of dislexya. (There are indeed people who have tremendous difficulties with distinguishing upper- and lower-case letters, and this may or may not be connected with other aspects of dislexya.) It is however totally unclear to this reviewer why this has to lead to two different URI schemes with other gratuitous differences. Finding a solution is rather easy (of course, other solutions may also be possible): Merge the schemes, so that authority, check digit, and query part are all optional (an authority part and/or a query part may very well be very useful in human communication, and a check digit won't hurt when transmitted electronically) and the decimal presentation of the algorithm is always allowed, and use base32 (http://tools.ietf.org/html/rfc4648) as the encoding. This leads to a 16.6% less efficient encoding of the value part of the ni: URI, but given that other URI-related encodings, e.g. the %-encoding resulting when converting an IRI to an URI, are much less efficient, and that URI infrastructure these days can handle URIs with more than 1000 bytes, this should not be a serious problem. Also, there's a separate binary format (section 6) that is more compact already. (relatively) Minor technical issues: Section 2, "When the input to the hash algorithm is a public key value": Is it absolutely clear that this will work for any and all public key values, existing and future, and not only for what's currently around? After all, as far as I understand, the concept of a public key is a fairly general one. "Other than in the above special case where public keys are used, we do not specify the hash function input here. Other specifications are expected to define this.": Do you really expect that to happen? Wouldn't it be better limit variability here as much as possible, and to use media types to identify different kinds of data? This would also work for public keys: If there's a MIME media type for a SubjectPublicKeyInfo, then the fact that this media type is the preferred way to transfer a public key becomes an application convention rather than a special case in the spec. If a better way (or just another way) to encode/transfer public keys became popular at a later date, there would be no need to change the spec. Related, in Section 3: The "val" field MUST contain the output of base64url encoding the result of applying the hash function ("alg") to its defined input, which defaults to the object bytes that are expected to be returned when the URI is dereferenced. How do I know whether the default applies or not? The URI doesn't tell you. Deducing from context is a bad idea. Section 3: "Thus to ensure interoperability, implementations SHOULD NOT generate URIs that employ URI character escaping": This is wrong and needs to be fixed. Characters such as "&", "=", "#", and "%", as well as ASCII characters not allowed in URIs and non-ASCII characters MUST be %-encoded if they appear in query parameter values in URIs (or in query parameter tags, which is however less likely). It would be better if the spec here deferred to the URI spec rather than trying to come up with its own rules. Section 3: "The Named Information URI adapts the URI definition from the URI Generic Syntax [RFC3986].": This sounds as if this were a voluntary decision (and the text should be changed to avoid such an impression), but if you don't conform to RFC 3986 syntax, you're not an URI. This is the first time I have seen an URI scheme definition starting explicitly with the top ABNF rule from RFC 3986 (http://tools.ietf.org/html/rfc3986#appendix-A). This is completely unnecessary. Just make sure your production conforms to the generic URI syntax, and mention all the ABNF rules from RFC3986 that you use. Also, using the "URI" production from RFC 3986, and then silently dropping the #fragment part, is technically wrong. Scheme definitions have nothing to do with the fragment (including the question of whether there's a fragment or not; the semantics of fragments are defined by the MIME media type that you get when you resolve). This may not be completely clear in RFC 4395, but the IRI WG is working on an update of RFC 4395 where this will be made clearer (see also http://trac.tools.ietf.org/wg/iri/trac/ticket/126; thanks for giving me a chance to remember that I had to create a new issue in the tracker for this :-). Section 3, ABNF: ni-hier-part = "//" authority path-algval / path-algval This gives you ni://example.com/sha-256;f4OxZX_x_FO5... (//authority/) and ni:/sha-256;f4OxZX_x_FO5... (one slash only), but the examples show ni:///sha-256;f4OxZX_x_FO5... (three slashes). It looks like the ABNF you want is: ni-hier-part = "//" authority path-algval / "//" path-algval (aligning "=" and "/" helps!) or more simply: ni-hier-part = "//" [authority] path-algval or even more simply: ni-hier-part = "//" authority path-algval because authority can be empty; let's show this: authority = [ userinfo "@" ] host [ ":" port ] If we can show that host can be empty, we're done: host = IP-literal / IPv4address / reg-name If we can show that any one of these can be empty, we're done, let's pick reg-name: reg-name = *( unreserved / pct-encoded / sub-delims ) * means "zero or more", thus reg-name can be empty. QED. Section 4: The HTTP(S) mapping MAY be used in any context where clients without support for ni URIs are needed without loss of interoperability or functionality. What is meant by "support for ni"? There's nowhere in the spec where this is explained clearly. If I were a browser maker, or writing an URI library,..., what would I do to support the ni scheme? The only thing I have come up with is to covert ni to the .well-known format, then use HTTP(S). In that case, the above text seems wrong, as it says that .well-known is used when there's no support for ni, not in order to support ni. Section 5: This defines an "URL segment format". It seems to be limited to path componest in HTTP URIs. What if I want to use this in a query part, or maybe even as a fragment identifier? What if I want to use this as a path component in an FTP URI? Or in some other schem? It would be better to define the alg-val (see next point) part as such (before the other things), with an explanation along the following lines: "This is defined here both for use in other sections of this document as well as for use in other places where it may be helpful, such as HTTP URI path segments,..." Section 5 (and Section 3): "To do this one simply uses the "alg;val" production": There is no "alg;val" production. Please change to "To do this one simply uses the production" and fix the ABNF in section 3 to path-algval = "/" alg-val alg-val = alg ";" val It's probably even better to fold this in with the changes to ni-hier-part, resulting e.g. in: ni-hier-part = "//" authority "/" alg-val alg-val = alg ";" val Section 9.4: Status can be 'empty' or 'deprecated'. I suggest to replace 'empty' with something positive, such as 'valid' or 'active'. This will help people who go to the IANA page and start to ask "well, it doesn't have a status, what does that mean". Also, I strongly suggest to add an additional status 'reserved', and remove the current "Reserved" hash name string from the entries with IDs 0 and 32. Section 9.4: "The Suite ID value 32 is reserved for compatibility with ORCHIDs [RFC4843].": How will compatibility be kept for future changes/additions in ORCHID? Major editorial issues: Title and abstract (and the spec itself) use the wording "Naming Things". While in a security context, it may be that there is an implicitly assumption that there are only digital things, in a wider context, this is of course not true. Research on the Internet of Things and efforts such as the Semantic Web/Linked Data try to deal with things in the real world. People in these areas it will be confused by title, abstract, and text, unless you can show (me and) them an ni: hash for a person, an apple, a building, or an elephant. Therefore, while it may be possible to keep the catchy title, the abstract has to be fixed to avoid such misunderstandings, e.g. by changing "to identify a thing" to "to identify a digital object" or some such in the abstract, and likewise in the main text of the spec. "Human-speakable" (e.g. ), "human-readable" (e.g. section title of section 7), and "for humans" (e.g. section title of section 9.2): These terms are used throughout the spec, but are imprecise and confusing. First, there's the problem of interpreting "for humans" in the sense of the previous paragraph, which of course has to be fixed. But the main problem is that none of the "ni:" URIs are "non-human-readable" or "non-human-speakable". Reading them aloud is only somewhat more tedious, but not at all impossible. And because the value part of the nih: form is 50% longer, and people quickly develop conventions for shortening things such as "upper case" and "lower case", it's not even clear that reading aloud the nih: form will necessarily take that much time. Therefore, I strongly recommend to change all occurrences of "Human-speakable", "human-readable", "for humans", and the like, to the more precise "more easily read out aloud by humans" or something equivalent. Abstract and further on: "specifying URI, URL": By all URx theories (see e.g. http://www.w3.org/TR/uri-clarification/), URLs are a subset of URIs, and therefore saying that the spec specifies an URI and an URL is somewhat confusing. I'd propose using wording along the following lines: "specifying an URI scheme and a way to map these URIs to http". Section 2, "When the input to the hash algorithm is a public key value", and example section: It took me a while to understand that the "public key" stuff was not yet another way to present a hash, and also not a way to mix in a public key to the hash in order to obtain some specific security property (I wasn't able to figure out how that would work, but draft-hallambaker-decade-ni-params contains something similar involving digital signatures and a public key). The document would be much easier to understand if there was a section e.g. entitled "Forms of input to hash", with subsections e.g. "general data", "public keys", "other stuff (not defined in this document)". As it is written, the relevant paragraphs in section 2 look like an afterthought, and it's not clear to what. Also, the example section should be fixed as follows: 1) say upfront that there will be two examples, one for a short string and another for a public key. 2) Make sure both examples exercise all forms (the public key example seems to be pretty complete, but the "Hello World!" example seems to be incomplete). 3) Use the same form of presentation (either a table in both cases or short paragaphs in both cases. The caption on Figure 7 is also way too unspecific. Section 9.4: "Hash Name Algorithm Registry", and later "a new registry for hash algorithms as used in the name formats specified here": IANA will be helped tremendously if your draft comes with an easy-to-understand and unambiguous name for the new registry. "Hash Name Algorithm Registry" may be okay, but is probably not specific enough. The circumscription at the start of the section is definitely not good enough because you're not registering hash algorithms, but names of hash algorithms and their truncations. Minor editorial issues: Introduction: It would be good to have a general reference to hashing (for security purposes) for people not utterly familiar with the subject. Intro: After reading the whole document, the structure of the Intro seems to make some sense, but it didn't on first reading (where it's actually more important). The main problem I was able to identify was that after a general outlook in paragraph 1, the Intro drops into a list of examples without saying what they are good for. I suggest to, after the sentence "This document specifies standard ways to do that to aid interoperability.", add a sentence along the lines: "The next few paragraphs give usage examples for the various ways to include a hash in a name or identifier as they are defined later in this document.". It may also make sense to further streamline the following paragraphs, so that it is clearer which pieces of text refer each to one of the "standard ways". There are two instances of the term "binary presentation". Looking around, it seems that they are supposed to mean the same as "binary format". Please replace all instances of "binary presentation" with "binary format" to avoid misunderstandings and useless seach time. Section 3: "A Named Information (ni) URI consists of the following components:": It would be good to know exactly where the list ended. One way to do this would be to say "consists of the following nine components". Section 3: "Note that while the ni names with and without an authority differ syntactically, both names refer to the same object if the digest algorithm and value are the same.": What about cases with different authority? The text seems to apply by transitivity, but this may be easy to miss for an implementer. I suggest changing to: "Note that while ni names with and without an authority, and ni names with different authorities, differ syntactically, they all refer to the same object if the digest algorithm and value are the same.". Section 3: "Consequently no special escaping mechanism is required for the query parameter portion of ni URIs.": Does this mean "no escaping mechanism at all"? Or "nothing besides %-encoding"? Or something else? Please clarify. Figure 3: the "=" characters of the various rules should be aligned as much as possible to make it easier to scan the productions (see http://tools.ietf.org/html/rfc3986#appendix-A for an example). Section 3: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" ; directly from RFC 3986, section 2.3 ; "authority" and "pct-encoded" are also from RFC 3986 Please don't copy productions. Please don't copy half (or one-third, actually) of the productions you use, and reference the rest. Please don't say what productions you copy from where in a comment, and even less in a comment for an unrelated production. Please before the ABNF, say which productions are used from another spec. Section 4: The HTTP(S) mapping MAY be used in any context where clients without support for ni URIs are needed without loss of interoperability or functionality. This is difficult to understand. If some new functionality is proposed, it's usually a client *with* the new functionality that's needed, not one without. Also, the "without loss of interoperability or functionality" is unclear: Sure if ni isn't supported, there's a loss in interoperability. So I suggest to rewrite this as: The HTTP(S) mapping MAY be used in any context where clients with support for ni URIs are not available. (but see also the comment in minor technical issues) Section 6: "binary format name": Why 'name'? Why not just "binary format"? The later is completely clear in the context of the document or together with an indication of the document; for something that can be used independently, even "binary format name" isn't enough. Section 6: "suite ID": The word "suite" seems out of place here. In the general use of the term, it refers to "a group of things forming a unit or constituting a collection" (see http://www.merriam-webster.com/dictionary/suite). A good definition that works for the uses I'm familiar with in digital security would be "An algorithm suite is a coherent collection of cryptographic algorithms for performing operations such as signing, encryption, generating message digests, and so on." (http://fusesource.com/docs/framework/2.4/security/MsgProtect-SOAP-SpecifyAlgorithmSuite.html; disclaimer: I'm in no way a SOAP fan). The use here is not for a collection, but for a single truncated-length variant of a single hash algorithm. I seriously hope you can find a better name. Section 6: "Note that a hash value that is truncated to 120 bits will result in the overall name being a 128-bit value which may be useful with certain use-cases.": This left me really wondering: Is there something magic to 128 bits in computer/internet security? What are the "certain use cases"? Or is this just an example to make sure the reader got the relationships, and it could have been as well "Note that a hash value that is truncated to 64 bits will result in the overall name being a 72-bit value which may be useful with certain use-cases." (or whatever other value that's registered in section 9)? Section 7: Just for the highly unfortunate case that this doesn't disappear, it would be very helpful if the presentation of this section paralleled section 3. Section 7: "contain the ID value as a UTF-8 encoded decimal number": I'm an internationalization expert with a strong affection for UTF-8, but even for me, this should be "contain the ID value as an ASCII encoded decimal number". Section 9: The registration templates refer to sections. This is fine for readers of the draft, but not if the template is standalone. I suggest using a format such as that at http://tools.ietf.org/html/rfc6068#section-8.1, which in draft stage may look e.g. like http://tools.ietf.org/html/draft-duerst-eai-mailto-03#section-8.1. Section 9.3: "Assignment of Well Known URI prefix ni" and later (and elsewhere in the draft) "URI suffix": Are we dealing with a prefix or a suffix here? Section 9.4: "This registry has five fields, the binary suite ID,...": Better to remove the word "binary", because the actual number is decimal. Section 9.4: "The expert SHOULD seek IETF review before approving a request to mark an entry as "deprecated." Such requests may simply take the form of a mail to the designated expert (an RFC is not required). IETF review can be achieved if the designated expert sends a mail to the IETF discussion list. At least two weeks for comments MUST be allowed thereafter before the request is approved and actioned.": I'm at a loss to see why asking the IETF at large is a SHOULD, but if it's done, then the two weeks period is a MUST. Section 9.4: The registry initialization in Fig. 8 refers to RFC4055 many times. But RFC 4055 does in no way define SHA-256. It looks like the actual spec is http://tools.ietf.org/html/rfc4055#ref-SHA2 (National Institute of Standards and Technology (NIST), FIPS 180-2: Secure Hash Standard, 1 August 2002.) I think this should be cited, in particular because there is a "Specification Required" requirement, and this sure should mean that there is a Specification for the actual algorithm, and not just a specification that mentions some labels. So using RFC4055 as a reference could be taken as creating bad precedent. Section 9.4: "The designated expert is responsible for ensuring that the document referenced for the hash algorithm is such that it would be acceptable were the "specification required" rule applied.": Why all this circumscription? Why not just say something like: "The designated expert is responsible for ensuring that the document referenced for the hash algorithm meets the "specification required" rule." Nits: Author's list: Last time I heard about this, there was a general limit of 5 authors per RFC. I'm not sure whether this still exists, and what'd be needed to get around it, but I just wanted to point out that this may be a potential problem or additional work (hoops to get through). Intro: "Since, there is no standard" -> "Since there is no standard" Intro: "for these various purposes" -> "for these purposes" or "for various purposes" (the indefinite 'various' is incompatible with the definite 'these'). "2. Hashes are what Count" -> "2. Hashes are what Counts" (the former may look logically correct, but 'what' requires a singular verb form. Section 2: "the left-most or most significant in network byte order N bits from the binary representation of the hash value" -> "the left-most (or most significant in network byte order) N bits from the binary representation of the hash value" or "the left-most N bits, or the N most significant bits in network byte order, from the binary representation of the hash value" (the current text is virtually unparsable). Figure 1: The 0x notation is never explained. A short clause or pharse is all that would be needed, but it would be better if this were spelled out. Section 3, Query Parameter separator: "The query parameter separator acts a separator between" -> "The query parameter separator acts *as* a separator between". Section 3, Query Parameters: "A tag=value list of optional query parameters as are used with HTTP URLs" -> "A tag=value list of optional query parameters as used with HTTP URLs" (or "A tag=value list of optional query parameters as they are used with HTTP URLs"). Section 4: "the object named by the ni URI will be available at the corresponding HTTP(S) URL" -> "the object named by the ni URI will be available via the corresponding HTTP(S) URL" (via stresses the point that this should be done via (sic) redirection) Section 4: "so there may still be reasons to use" -> "so there can still be reasons to use" (better to use can because non-normative; the document otherwise does a good job on this) Section 10: "Note that fact that" -> "Note the fact that", or much better: "Note that". Regards, Martin. From john-ietf@jck.com Tue Jun 5 03:07:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248F221F868A; Tue, 5 Jun 2012 03:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbp8EAgHvxik; Tue, 5 Jun 2012 03:07:37 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 133DB21F867E; Tue, 5 Jun 2012 03:07:37 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SbqZa-0002Ou-HI; Tue, 05 Jun 2012 06:01:10 -0400 Date: Tue, 05 Jun 2012 06:07:15 -0400 From: John C Klensin To: ken carlberg Message-ID: <1E3DCEC5990AF898F1E3582D@PST.JCK.COM> In-Reply-To: References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> <01OGAJ8GBR2Q0006TF@mauve.mrochek.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: Ned Freed , apps-discuss@ietf.org, draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 10:07:38 -0000 --On Monday, June 04, 2012 20:18 -0400 ken carlberg wrote: > > On Jun 4, 2012, at 7:14 PM, John C Klensin wrote: > >> Yes in principle. In practice, I've seen one set of >> communities that have repeatedly expressed high levels of >> demand for prioritization. Those communities are military or >> ones with aspirations to behave like military ones. For those >> communities, "messages from the General get more delivery >> priority than those from the Lieutenant" have obvious meaning >... > so what you describe above is what I've called role-based > prioritization. its the easiest form of prioritization to > implement and deploy because its typically associated with a > role (sargent, general, etc.) and its generally stagnant and > stays associated with a user or device. several systems for > both voice and messaging have been built over the past 50 > years or so using this form of prioritization. Yes, but it is a little more than that. Referring back to a recent conversation about authentication, I note that most military organizations have a very negative view about corporals impersonating generals... and the means to deliver unambiguous negative reinforcement to support that view. Impersonating your boss in a civilian company might get you fired, but would be unlikely to get you shot (I can think of an exception or two, but let's not go there). While that isn't authentication in the sense that we normally use the term, it can be a reasonable surrogate for many purposes. If this were just "role-based", one would need to reopen the authentication and authorization issues and to do so for inter-organizational mail. I won't say "impossible", but one could spend a rather long time exploring that family of rat holes. > another type of system (that I worked on about 25 years ago) > is what I refer to as content-based prioritization, where the > prioritization is attributed to the content of the message. > So in this case, one could have a case where the user (or a > proxy) decides and associates a priority based on the > information in the message to be sent. So in this case, you > could have a case where the lowly Sargent trumps the General > (kind a cool :-). And by far, this is the hardest system to > build/deploy because one needs to avoid the trap that Dave > brought up earlier in that given the freedom, everyone wants > to have the highest priority. Sorry, the Sargent never trumps the General. He may be sending a message on behalf of a body that can, with that body's authorization, or may, more generally, have authorizations the General does not, but... See Ned's comment, with which my experience agrees. Also think about whether you can make an anecdotal inference about message and topic priority from this thread of messages. It shows that neither of us want to, and are assigning, "highest priority" to handling this thread, sitting anxiously in front of our screens waiting for the next message to arrive so it can be answered instantly. Now that it prioritization in the human part of the process --message reading priority, message answering priority, and message dispatching priority-- not in the transport part. But the recipient generally doesn't care about the human-versus-transport distinction. The distinction clearly makes no difference to the total or delivery times of a communications round trip, etc. I suggest that is a practical counterexample to assertions that everyone always wants highest priority. Indeed, while (as far as I know) it has never been proposed as an Internet mail extension, partially because it is best implemented in the sending MUA or between it and the sending Submission Server, experiments run many years ago made a convincing case for a "sit on this message for an hour or two before sending it out just in case I change my mind" service. That, again, would be just the opposite from "I want highest priority and for my message to be delivered immediately or sooner". > In the past few years, some communities have had to rely on > the prioritization made available in X.400. However, these > and other communities wish to migrate to SMTP, hence the > interest in produce the draft-melnikov-smtp-priority draft. > So what i wanted to point out is that people have indeed > worked on these systems and gained experience in the subject > area, and we'd like to migrate this to SMTP, as opposed to > just relying on proprietary hacks. I'm tempted to say that, if you want the X.400 service model, you should be looking to improve on MIXER, not SMTP. I might also note that that the round trip (message out, reply, message back) time of many X.400 transactions in progress was such that prioritization. In practice, X.400 also needed it -- what was it that Einar Steffrud used to say about X.400 delivery in a millisecond world? Days? But, more important, there is an authentication and authorization infrastructure built into the X.400 model with bilateral trust agreements between management (and hence transmission-authorizing) entities and each such entity required to take responsibility for authentication and authorization of anyone initiating mail. Whether one trusts the results of that model or not is another issue but the structure is there. Attempts to retrofit that structure onto Internet mail without extensive hand waving have been rather unsuccessful. And that is ultimately one of the key problems with trying to use this particular proposal between unrelated administrative domains. john From tobias.gondrom@gondrom.org Tue Jun 5 04:07:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7323421F869D for ; Tue, 5 Jun 2012 04:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.778 X-Spam-Level: X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZDV+iFXlxih for ; Tue, 5 Jun 2012 04:07:51 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5505921F867E for ; Tue, 5 Jun 2012 04:07:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=O7XLvNz8vM+eusk2o3MiH07lvzbDvOpJVftdqGm6Q3wdgBpIWEt/vVgSP+Fj/tiZKeelE95sKGpXih0bOOD7XWISRdeEIN4FkhpwoikwiRXWqjoB7/G9g+3HTBS25GEW; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 18193 invoked from network); 5 Jun 2012 13:07:44 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.69?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Jun 2012 13:07:44 +0200 Message-ID: <4FCDE87F.3030405@gondrom.org> Date: Tue, 05 Jun 2012 12:07:43 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: jhutz@cmu.edu References: <4FCCC936.3030600@gondrom.org> <4FCCE496.1030800@gondrom.org> <1338832293.7221.60.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1338832293.7221.60.camel@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-krb-wg-kdc-model.all@tools.ietf.org, ietf-krb-wg@anl.gov, hartmans-ietf@mit.edu, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-ietf-krb-wg-kdc-model X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 11:07:56 -0000 On 04/06/12 18:51, Jeffrey Hutzelman wrote: > On Mon, 2012-06-04 at 17:38 +0100, Tobias Gondrom wrote: >> On 04/06/12 17:02, Sam Hartman wrote: >>>>>>>> "Tobias" == Tobias Gondrom writes: >>> Tobias> One basic question: >>> Tobias> This draft aims for Standards Track, yet as far as I understood, it is >>> Tobias> not required that the used field names are in fact the same across >>> Tobias> different implementations but only that name-mappings exist. The ID >>> Tobias> also uses a modified RFC2119 language definition to allow that. >>> Tobias> I would like to ask, whether possibly Informational Status would be >>> Tobias> more appropriate for this draft? >>> >>> My concern is that this does specify mandatory behavior of >>> implementations and that it's likely that a schema would want to >>> normatively refer to this document for semantics of attributes. >> Does it have to be Standards Track for that purpose? >> (note: I don't have a strong opinion on this, just feel uneasy with >> using the watered down 2119 definitions in the draft and the >> name-mapping, and then to go for Standards Track....) > The present document is a data model. Its "implementations" are schemas > or the like; that is, other documents. The RFC2119 language is in fact > not "watered down"; rather, it is the case that, for example, we may > REQUIRE a schema to include a particular field without requiring that > every implementation of that schema support that field. > > The particular point you raised about names is not, in fact a problem. > Read with the understanding that an implementation of this document is a > schema or the like and _not_ a piece of software, the language in the > third paragraph of section 1 means that an LDAP schema or XML DTD based > on this document would not be required to use the same field names as > are used in the model, provided the document defining such a schema or > DTD makes clear which of its fields correspond to which fields in the > data model. > > Yes, this document wants to be standards track. It is intended to > define the semantics of data items used by the KDC and made visible in > one or more standards track management protocols. Will try to answer to that together with Sam's and Leif's email. > >> On a personal note: Would still be curious about the intentions for >> draft-ietf-krb-wg-kerberos-set-passwd? > It is an item on our current charter, to which we intend eventually to > return. Both the author and the working group have been concentrating > on other work for some time. It expired in 2009. That is even by IETF standards a long time to eventually return to the draft. Best regards, Tobias > > -- Jeff > From stephen.farrell@cs.tcd.ie Tue Jun 5 04:11:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6397221F868A; Tue, 5 Jun 2012 04:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_35=0.6, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqt8Pg-a9tKJ; Tue, 5 Jun 2012 04:11:49 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id D490521F8685; Tue, 5 Jun 2012 04:11:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1F2F01714E8; Tue, 5 Jun 2012 12:11:48 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338894705; bh=iH5g6Si9BZVv7M /ksHWD/H6cxopNpufd7jbeTUh5nUA=; b=Km9QiHWzH78ziZNpOvQtJNchRdz87D c3a/U8PbTbPiBowYGOQQy/SJk6zdqDis5v1GZeBSNsgVHl1Bl8xj8F0ZWeko1gJw gDXNpGR1dP+onxOKiCIQI+fXVjXXnVtK03dpmHGPd5mBkkdAN0WBpvl0Ql3SMGoT DbfrU0UqjhfQ8HalteXEeVyMV5YhI4R5l8SPzPL4rjMKNECgPHBOiZiCyUSuumj3 0AxjvqvAw1QRboKFx+EfSkiNSUHgWvMH3rpOKb2k4VifFrSoYmW4pWkRHPj86CGw 4tsiVjvTGkPOGscDFqZjDQiZQ/v7B+iXr9/QCHmesKNs0/oAGhg3pLXA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 21CULiXHWsKW; Tue, 5 Jun 2012 12:11:45 +0100 (IST) Received: from [IPv6:2001:770:10:203:cc4b:866f:6fec:abaf] (unknown [IPv6:2001:770:10:203:cc4b:866f:6fec:abaf]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 568451718D8; Tue, 5 Jun 2012 12:11:42 +0100 (IST) Message-ID: <4FCDE96E.5000109@cs.tcd.ie> Date: Tue, 05 Jun 2012 12:11:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <4FCDD499.7060206@it.aoyama.ac.jp> In-Reply-To: <4FCDD499.7060206@it.aoyama.ac.jp> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Apps Discuss , "draft-farrell-decade-ni@tools.ietf.org" , IETF discussion list Subject: Re: [apps-discuss] APPSDIR review of draft-farrell-decade-ni-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 11:11:52 -0000 Hi Martin, First, thanks for the speedy and thorough review. Some good points made, some with which I strongly disagree, but thrashing stuff like that out is part of the point of the reviews. On 06/05/2012 10:42 AM, "Martin J. Drst" wrote: > Hello everybody, > > [For replies, please trim the cc list, thanks!] Not sure what trimming you mean. I've reduced it to ietf-discuss and apps-discuss and authors. > > > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). > > > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > > Document: draft-farrell-decade-ni-07 > Title: Naming Things with Hashes > Reviewer: Martin Drst > Review Date: 2012-06-03, 2012 (written up 2012-06-04/05) > IETF Last Call Date: started 2012-06-04, ends 2012-07-02 > > > Summary: This draft addresses a real generic need, but the current form > of the draft is the result of adding more and more special cases without > a clear overall view and a firm hand to separate the wheat from the > chaff. This shows both in the technical issues as well as in many of the > editorial issues below. This draft is not ready for publication without > some serious additional work, but that work is mostly straightforward > and should be easy to complete quickly. Wheat? Chaff? Firm hand? Hmm. Are those useful phrases here? I disagree about 'em in any case, and you're wrong as to how we got here and IMO quite wrong in your main technical comment. See below for that. > > Major design issue: > > The draft defines two schemes, which differ only slightly, and mostly > just gratuitously (see also editorial issues). > These are the ni: and the nih: scheme. As far as I understand, they > differ as follows: > ni: nih: > authority: optional disallowed > ascii-compatible encoding: base64url base16 > check digit: disallowed optional > query part: optional disallowed > decimal presentation of algorithm: disallowed possible > > The usability of URIs is strongly influenced by the number of different > schemes, with the smaller a number, the better. As a somewhat made-up > example, if the original URIs had been separated into httph: for HTML > pages and httpi: for images, or any other arbitrary subdivision that one > can envision, that would have hurt the growth and extensibility of the > Web. Creating new URI schemes is occasionally necessary, and the ideas > that lead to this draft definitely seem to warrant a new scheme (*), but > there's no reason for two schemes. > [(*) I know people who would claim the the .well-formed http/https thing > is completely sufficient, no new scheme needed at all.] > > More specifically, if the original URIs had been separated into httpm: > (for machines) and httph: (for humans), the Web for sure wouldn't have > grown at the speed it did (and does) grow. In practice, there are huge > differences in human 'speakability' for URIs (and IRIs, for that > matter); compare e.g. http://google.com with > http://www.google.co.jp/#sclient=psy-ab&hl=en&site=&source=hp&q=hash&oq=hash&aq=f&aqi=g4&aql= > > (which I have significantly shortened to hopefully eliminate potential > privacy issues), or compare the average mailto: URI with the average > data: URI. However, what's important is that there never has been a > strong dividing line between machine-only and human-only URIs or > schemes, the division has always been very gradual. Short and mainly > human-oriented URIs have of course been handled by machines, and on the > other hand, very long URIs have been spoken when really necessary. > "Speakability" has been maintained to some extent by scheme designers, > and to some extent by "survival of the fittest" (URIs that weren't very > speakable (or spellable/memorizable/guessable/...), and their Web sites, > might just die out slowly). > > It should also be noted that the resistance against multiple URI schemes > may have been low because there are so many different ways to express > hashes in the draft anyway, and one more (the nih: section is the last > one before the examples section) didn't seem like much of a deal > anymore. But when it comes to URIs, one less is a lot better than one more. > > In the above ni:/nih: distinction, nih: seems to have been added as an > afterthought after realizing that reading an ni: URI aloud over the > phone may be somewhat suboptimal because there is a need for repeated > "upper case" - "lower case" (sure very quickly shortened to "upper" - > "lower" and then to "up" - "low" or something similar). It is not a bad > idea to try to make sure that IETF technology, and URIs in particular, > are accessible to people with certain kinds of dislexya. (There are > indeed people who have tremendous difficulties with distinguishing > upper- and lower-case letters, and this may or may not be connected with > other aspects of dislexya.) It is however totally unclear to this > reviewer why this has to lead to two different URI schemes with other > gratuitous differences. > > Finding a solution is rather easy (of course, other solutions may also > be possible): Merge the schemes, so that authority, check digit, and > query part are all optional (an authority part and/or a query part may > very well be very useful in human communication, and a check digit won't > hurt when transmitted electronically) and the decimal presentation of > the algorithm is always allowed, and use base32 > (http://tools.ietf.org/html/rfc4648) as the encoding. This leads to a > 16.6% less efficient encoding of the value part of the ni: URI, but > given that other URI-related encodings, e.g. the %-encoding resulting > when converting an IRI to an URI, are much less efficient, and that URI > infrastructure these days can handle URIs with more than 1000 bytes, > this should not be a serious problem. Also, there's a separate binary > format (section 6) that is more compact already. I strongly disagree with merging ni & nih. Though that clearly could be done, it would be an error. There was no such comment on the uri-review list and the designated expert was happy. That review was IMO the time for such comments and second-guessing the designated expert at this stage seems contrary to the registration requirements. So process-wise I think your main comment is late. But in any case, I also think you're wrong technically in this case. nih *is* intended for a corner case, where humans need to speak these URIs and was added as a direct result of requirements from the core WG and not as an afterthought. ni URIs are not intended for that and so there really are IMO different requirements, (esp. e.g. checkdigit) that are best met with different schemes. Merging ni/nih would also add more complexity for no benefit, which would be a bad idea. Your analogy about httpm/h may appear reasonable, but it is always unreasonable to draw conclusions from analogies. It is also unwise to reason from counterfactuals, which we'd also be doing if we accepted your argument. So I find that speculation utterly useless to be honest. In this case, we are dealing with different requirements so this should stay as-is. Finally, we have (some, early,) running code that matches the current draft and that ought also count for something when compared to a change that would be a gratuitous dis-improvement based it seems upon dubious argument that is also offered at the wrong point in the process. (I'd say that gets over the level of my disagreement here with a firm hand:-) > (relatively) Minor technical issues: > > Section 2, "When the input to the hash algorithm is a public key value": > Is it absolutely clear that this will work for any and all public key > values, existing and future, and not only for what's currently around? > After all, as far as I understand, the concept of a public key is a > fairly general one. Yes. SPKI is good for this and is what's used elsewhere, e.g. in dane and websec. Its the right choice and will be so long as folks still need to map public key formats to X.509 which I expect will be the case for many years to come. (Not that we get new public key formats very often in any case.) > "Other than in the above special case where public keys are used, we do > not specify the hash function input here. Other specifications are > expected to define this.": Do you really expect that to happen? I do, yes, assuming that ni URIs get adopted. If they don't, then its not a problem:-) > Wouldn't > it be better limit variability here as much as possible, and to use > media types to identify different kinds of data? To be honest, I think that's another day's work. I don't know that there's a generic solution that'd work for enough protocols. If there were, then that could, and I think, should, be done in another RFC. > This would also work > for public keys: If there's a MIME media type for a > SubjectPublicKeyInfo, then the fact that this media type is the > preferred way to transfer a public key becomes an application convention > rather than a special case in the spec. If a better way (or just another > way) to encode/transfer public keys became popular at a later date, > there would be no need to change the spec. See above. > > Related, in Section 3: > The "val" field MUST contain the output of base64url encoding the > result of applying the hash function ("alg") to its defined input, > which defaults to the object bytes that are expected to be returned > when the URI is dereferenced. > How do I know whether the default applies or not? The URI doesn't tell > you. Deducing from context is a bad idea. I agree that deducing the input from context alone could be difficult, though you would know when you got the right answer. I think the way to handle this is for other specifications that use ni URIs to specify the inputs. > > Section 3: "Thus to ensure interoperability, implementations SHOULD NOT > generate URIs that employ URI character escaping": This is wrong and > needs to be fixed. Characters such as "&", "=", "#", and "%", as well as > ASCII characters not allowed in URIs and non-ASCII characters MUST be > %-encoded if they appear in query parameter values in URIs (or in query > parameter tags, which is however less likely). It would be better if the > spec here deferred to the URI spec rather than trying to come up with > its own rules. Can you suggest text to include? I'm always uncertain about this kind of thing and would be very happy to take your suggestion. > > Section 3: "The Named Information URI adapts the URI definition from the > URI Generic Syntax [RFC3986].": This sounds as if this were a voluntary > decision (and the text should be changed to avoid such an impression), Huh? I don't get what change you'd like. > but if you don't conform to RFC 3986 syntax, you're not an URI. This is > the first time I have seen an URI scheme definition starting explicitly > with the top ABNF rule from RFC 3986 > (http://tools.ietf.org/html/rfc3986#appendix-A). This is completely > unnecessary. Just make sure your production conforms to the generic URI > syntax, and mention all the ABNF rules from RFC3986 that you use. > > Also, using the "URI" production from RFC 3986, and then silently > dropping the #fragment part, is technically wrong. Scheme definitions > have nothing to do with the fragment (including the question of whether > there's a fragment or not; the semantics of fragments are defined by the > MIME media type that you get when you resolve). This may not be > completely clear in RFC 4395, but the IRI WG is working on an update of > RFC 4395 where this will be made clearer (see also > http://trac.tools.ietf.org/wg/iri/trac/ticket/126; thanks for giving me > a chance to remember that I had to create a new issue in the tracker for > this :-). Again, I'm not clear what change is suggested. > > Section 3, ABNF: > ni-hier-part = "//" authority path-algval > / path-algval > This gives you ni://example.com/sha-256;f4OxZX_x_FO5... (//authority/) > and ni:/sha-256;f4OxZX_x_FO5... (one slash only), but the examples show > ni:///sha-256;f4OxZX_x_FO5... (three slashes). It looks like the ABNF > you want is: > ni-hier-part = "//" authority path-algval > / "//" path-algval > (aligning "=" and "/" helps!) > or more simply: > ni-hier-part = "//" [authority] path-algval > or even more simply: > ni-hier-part = "//" authority path-algval > because authority can be empty; let's show this: > authority = [ userinfo "@" ] host [ ":" port ] > If we can show that host can be empty, we're done: > host = IP-literal / IPv4address / reg-name > If we can show that any one of these can be empty, we're done, let's > pick reg-name: > reg-name = *( unreserved / pct-encoded / sub-delims ) > * means "zero or more", thus reg-name can be empty. QED. Good catch. Will craft a fix that disallows "ni:/sha-s56;..." and forces "ni:///sha-256;..." when the authority is empty. > > Section 4: > The HTTP(S) mapping MAY be used in any context where clients without > support for ni URIs are needed without loss of interoperability or > functionality. > What is meant by "support for ni"? There's nowhere in the spec where > this is explained clearly. If I were a browser maker, or writing an URI > library,..., what would I do to support the ni scheme? The only thing I > have come up with is to covert ni to the .well-known format, then use > HTTP(S). In that case, the above text seems wrong, as it says that > .well-known is used when there's no support for ni, not in order to > support ni. We can re-word, but personally I think its clear now. A suggestion would be welcome. > > Section 5: This defines an "URL segment format". It seems to be limited > to path componest in HTTP URIs. What if I want to use this in a query > part, or maybe even as a fragment identifier? What if I want to use this > as a path component in an FTP URI? Or in some other schem? It would be > better to define the alg-val (see next point) part as such (before the > other things), with an explanation along the following lines: "This is > defined here both for use in other sections of this document as well as > for use in other places where it may be helpful, such as HTTP URI path > segments,..." Can do that. Good suggestion. > > Section 5 (and Section 3): "To do this one simply uses the "alg;val" > production": There is no "alg;val" production. Please change to "To do > this one simply uses the production" and fix the ABNF in > section 3 to > path-algval = "/" alg-val > alg-val = alg ";" val > It's probably even better to fold this in with the changes to > ni-hier-part, resulting e.g. in: > ni-hier-part = "//" authority "/" alg-val > alg-val = alg ";" val Ok. > > Section 9.4: Status can be 'empty' or 'deprecated'. I suggest to replace > 'empty' with something positive, such as 'valid' or 'active'. This will > help people who go to the IANA page and start to ask "well, it doesn't > have a status, what does that mean". Can do. > Also, I strongly suggest to add an > additional status 'reserved', and remove the current "Reserved" hash > name string from the entries with IDs 0 and 32. Huh? Wouldn't that confuse things more? IANA handles Reserved values all the time. > Section 9.4: "The Suite ID value 32 is reserved for compatibility with > ORCHIDs [RFC4843].": How will compatibility be kept for future > changes/additions in ORCHID? Dunno actually:-) Ari might. But we can change it to just say "reserved for compatibility with 4843" > > Major editorial issues: > > Title and abstract (and the spec itself) use the wording "Naming > Things". While in a security context, it may be that there is an > implicitly assumption that there are only digital things, in a wider > context, this is of course not true. Research on the Internet of Things > and efforts such as the Semantic Web/Linked Data try to deal with things > in the real world. People in these areas it will be confused by title, > abstract, and text, unless you can show (me and) them an ni: hash for a > person, an apple, a building, or an elephant. Therefore, while it may be > possible to keep the catchy title, the abstract has to be fixed to avoid > such misunderstandings, e.g. by changing "to identify a thing" to "to > identify a digital object" or some such in the abstract, and likewise in > the main text of the spec. First, I disagree that people will really be confused. I think this is both a nit and a gratuitous one. However, I've no problem with making that (tiny, inconsequential and by no means major:-) change to the abstract. > > "Human-speakable" (e.g. ), "human-readable" (e.g. section title of > section 7), and "for humans" (e.g. section title of section 9.2): These > terms are used throughout the spec, but are imprecise and confusing. Imprecise: sure. Confusing: really? Were you really confused? > First, there's the problem of interpreting "for humans" in the sense of > the previous paragraph, which of course has to be fixed. But the main > problem is that none of the "ni:" URIs are "non-human-readable" or > "non-human-speakable". Reading them aloud is only somewhat more tedious, > but not at all impossible. And because the value part of the nih: form > is 50% longer, and people quickly develop conventions for shortening > things such as "upper case" and "lower case", it's not even clear that > reading aloud the nih: form will necessarily take that much time. > Therefore, I strongly recommend to change all occurrences of > "Human-speakable", "human-readable", "for humans", and the like, to the > more precise "more easily read out aloud by humans" or something > equivalent. Happy to take a look. But I suspect we'll still disagree on whether or not there's real confusion here. > > Abstract and further on: "specifying URI, URL": By all URx theories (see > e.g. http://www.w3.org/TR/uri-clarification/), URLs are a subset of > URIs, and therefore saying that the spec specifies an URI and an URL is > somewhat confusing. I'd propose using wording along the following lines: > "specifying an URI scheme and a way to map these URIs to http". Sure. Happy to make this *minor* change:-) > > Section 2, "When the input to the hash algorithm is a public key value", > and example section: It took me a while to understand that the "public > key" stuff was not yet another way to present a hash, and also not a way > to mix in a public key to the hash in order to obtain some specific > security property (I wasn't able to figure out how that would work, but > draft-hallambaker-decade-ni-params contains something similar involving > digital signatures and a public key). The document would be much easier > to understand if there was a section e.g. entitled "Forms of input to > hash", with subsections e.g. "general data", "public keys", "other stuff > (not defined in this document)". As it is written, the relevant > paragraphs in section 2 look like an afterthought, and it's not clear to > what. I really don't get what's not clear there and I suspect I don't like the suggested re-structuring but I'll take a look. Be good if you can make a suggestion for text to add to the current structure that would have avoided your confusion. > Also, the example section should be fixed as follows: 1) say upfront > that there will be two examples, one for a short string and another for > a public key. 2) Make sure both examples exercise all forms (the public > key example seems to be pretty complete, but the "Hello World!" example > seems to be incomplete). 3) Use the same form of presentation (either a > table in both cases or short paragaphs in both cases. > The caption on Figure 7 is also way too unspecific. I'll take a look. I entirely disagree that these are *major* editorial changes. > > Section 9.4: "Hash Name Algorithm Registry", and later "a new registry > for hash algorithms as used in the name formats specified here": IANA > will be helped tremendously if your draft comes with an > easy-to-understand and unambiguous name for the new registry. "Hash Name > Algorithm Registry" may be okay, but is probably not specific enough. > The circumscription at the start of the section is definitely not good > enough because you're not registering hash algorithms, but names of hash > algorithms and their truncations. I'll take a look. > Minor editorial issues: > > Introduction: It would be good to have a general reference to hashing > (for security purposes) for people not utterly familiar with the subject. Disagree. If I added that I could reasonably be asked to introduce URIs for the security folks. Serious and pointless ratholes would ensue. > Intro: After reading the whole document, the structure of the Intro > seems to make some sense, but it didn't on first reading (where it's > actually more important). The main problem I was able to identify was > that after a general outlook in paragraph 1, the Intro drops into a list > of examples without saying what they are good for. I suggest to, after > the sentence "This document specifies standard ways to do that to aid > interoperability.", add a sentence along the lines: "The next few > paragraphs give usage examples for the various ways to include a hash in > a name or identifier as they are defined later in this document.". It > may also make sense to further streamline the following paragraphs, so > that it is clearer which pieces of text refer each to one of the > "standard ways". > > There are two instances of the term "binary presentation". Looking > around, it seems that they are supposed to mean the same as "binary > format". Please replace all instances of "binary presentation" with > "binary format" to avoid misunderstandings and useless seach time. > > Section 3: "A Named Information (ni) URI consists of the following > components:": It would be good to know exactly where the list ended. One > way to do this would be to say "consists of the following nine components". Those look reasonable. Will see if the changes work out. > Section 3: "Note that while the ni names with and without an authority > differ syntactically, both names refer to the same object if the digest > algorithm and value are the same.": What about cases with different > authority? The text seems to apply by transitivity, but this may be easy > to miss for an implementer. I suggest changing to: "Note that while ni > names with and without an authority, and ni names with different > authorities, differ syntactically, they all refer to the same object if > the digest algorithm and value are the same.". Sure. > Section 3: "Consequently no special escaping mechanism is required for > the query parameter portion of ni URIs.": Does this mean "no escaping > mechanism at all"? Or "nothing besides %-encoding"? Or something else? > Please clarify. I wish I knew:-) What do you think is right here? (Honestly, input on this would be appreciated.) > > Figure 3: the "=" characters of the various rules should be aligned as > much as possible to make it easier to scan the productions (see > http://tools.ietf.org/html/rfc3986#appendix-A for an example). Ack. > > Section 3: > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" > ; directly from RFC 3986, section 2.3 > ; "authority" and "pct-encoded" are also from RFC 3986 > Please don't copy productions. Please don't copy half (or one-third, > actually) of the productions you use, and reference the rest. Please > don't say what productions you copy from where in a comment, and even > less in a comment for an unrelated production. Please before the ABNF, > say which productions are used from another spec. We got contrary advice from elsewhere (can't recall where right now;-). I'll let Barry (as sponsoring AD) just tell us his preference and go with that if that's ok. > Section 4: > The HTTP(S) mapping MAY be used in any context where clients without > support for ni URIs are needed without loss of interoperability or > functionality. > This is difficult to understand. If some new functionality is proposed, > it's usually a client *with* the new functionality that's needed, not > one without. Also, the "without loss of interoperability or > functionality" is unclear: Sure if ni isn't supported, there's a loss in > interoperability. So I suggest to rewrite this as: > The HTTP(S) mapping MAY be used in any context where clients with > support for ni URIs are not available. Sure. > (but see also the comment in minor technical issues) > > Section 6: "binary format name": Why 'name'? Why not just "binary > format"? The later is completely clear in the context of the document or > together with an indication of the document; for something that can be > used independently, even "binary format name" isn't enough. I don't get the problem with that. > Section 6: "suite ID": The word "suite" seems out of place here. In the > general use of the term, it refers to "a group of things forming a unit > or constituting a collection" (see > http://www.merriam-webster.com/dictionary/suite). A good definition that > works for the uses I'm familiar with in digital security would be "An > algorithm suite is a coherent collection of cryptographic algorithms for > performing operations such as signing, encryption, generating message > digests, and so on." > (http://fusesource.com/docs/framework/2.4/security/MsgProtect-SOAP-SpecifyAlgorithmSuite.html; > disclaimer: I'm in no way a SOAP fan). The use here is not for a > collection, but for a single truncated-length variant of a single hash > algorithm. I seriously hope you can find a better name. That's a don't-care for me. I think suite is fine, but could take other terms (so long as its not "algorithm"). Suite could be justified since we have alg+truncation here, but like I said I'd be fine to change, if a good suggestion is made. > > Section 6: "Note that a hash value that is truncated to 120 bits will > result in the overall name being a 128-bit value which may be useful > with certain use-cases.": This left me really wondering: Is there > something magic to 128 bits in computer/internet security? What are the > "certain use cases"? Or is this just an example to make sure the reader > got the relationships, and it could have been as well "Note that a hash > value that is truncated to 64 bits will result in the overall name being > a 72-bit value which may be useful with certain use-cases." (or whatever > other value that's registered in section 9)? Bit of both. I believe the core WG are keen to end up with a 128 bit binary value as their preferred option. > > Section 7: Just for the highly unfortunate case that this doesn't > disappear, it would be very helpful if the presentation of this section > paralleled section 3. Disagree. Different requirements, different URIs, different presentation. I don't think there's a real problem here. > > Section 7: "contain the ID value as a UTF-8 encoded decimal number": I'm > an internationalization expert with a strong affection for UTF-8, but > even for me, this should be "contain the ID value as an ASCII encoded > decimal number". Fine. > > Section 9: The registration templates refer to sections. This is fine > for readers of the draft, but not if the template is standalone. I > suggest using a format such as that at > http://tools.ietf.org/html/rfc6068#section-8.1, which in draft stage may > look e.g. like > http://tools.ietf.org/html/draft-duerst-eai-mailto-03#section-8.1. Will take a peek. Not sure I agree. (Nor disagree:-) > Section 9.3: "Assignment of Well Known URI prefix ni" and later (and > elsewhere in the draft) "URI suffix": Are we dealing with a prefix or a > suffix here? Will take a peek. > Section 9.4: "This registry has five fields, the binary suite ID,...": > Better to remove the word "binary", because the actual number is decimal. Ack. > > Section 9.4: "The expert SHOULD seek IETF review before approving a > request to mark an entry as "deprecated." Such requests may simply take > the form of a mail to the designated expert (an RFC is not required). > IETF review can be achieved if the designated expert sends a mail to the > IETF discussion list. At least two weeks for comments MUST be allowed > thereafter before the request is approved and actioned.": I'm at a loss > to see why asking the IETF at large is a SHOULD, but if it's done, then > the two weeks period is a MUST. I don't get your comment. The two weeks is a MUST already. > > Section 9.4: The registry initialization in Fig. 8 refers to RFC4055 > many times. But RFC 4055 does in no way define SHA-256. It looks like > the actual spec is http://tools.ietf.org/html/rfc4055#ref-SHA2 (National > Institute of Standards and Technology (NIST), FIPS 180-2: Secure Hash > Standard, 1 August 2002.) I think this should be cited, in particular > because there is a "Specification Required" requirement, and this sure > should mean that there is a Specification for the actual algorithm, and > not just a specification that mentions some labels. So using RFC4055 as > a reference could be taken as creating bad precedent. I guess so. Good catch. > Section 9.4: "The designated expert is responsible for ensuring that the > document referenced for the hash algorithm is such that it would be > acceptable were the "specification required" rule applied.": Why all > this circumscription? Why not just say something like: "The designated > expert is responsible for ensuring that the document referenced for the > hash algorithm meets the "specification required" rule." Honestly? I can't recall:-) Will change unless I do remember. > Nits: > > Author's list: Last time I heard about this, there was a general limit > of 5 authors per RFC. I'm not sure whether this still exists, and what'd > be needed to get around it, but I just wanted to point out that this may > be a potential problem or additional work (hoops to get through). > > Intro: "Since, there is no standard" -> "Since there is no standard" > > Intro: "for these various purposes" -> "for these purposes" or "for > various purposes" (the indefinite 'various' is incompatible with the > definite 'these'). > > "2. Hashes are what Count" -> "2. Hashes are what Counts" (the former > may look logically correct, but 'what' requires a singular verb form. > > Section 2: "the left-most or most significant in network byte order N > bits from the binary representation of the hash value" -> "the left-most > (or most significant in network byte order) N bits from the binary > representation of the hash value" or "the left-most N bits, or the N > most significant bits in network byte order, from the binary > representation of the hash value" (the current text is virtually > unparsable). > > Figure 1: The 0x notation is never explained. A short clause or pharse > is all that would be needed, but it would be better if this were spelled > out. > > Section 3, Query Parameter separator: "The query parameter separator > acts a separator between" -> "The query parameter separator acts *as* a > separator between". > > Section 3, Query Parameters: "A tag=value list of optional query > parameters as are used with HTTP URLs" -> "A tag=value list of optional > query parameters as used with HTTP URLs" (or "A tag=value list of > optional query parameters as they are used with HTTP URLs"). > > Section 4: "the object named by the ni URI will be available at the > corresponding HTTP(S) URL" -> "the object named by the ni URI will be > available via the corresponding HTTP(S) URL" (via stresses the point > that this should be done via (sic) redirection) > > Section 4: "so there may still be reasons to use" -> "so there can still > be reasons to use" (better to use can because non-normative; the > document otherwise does a good job on this) > > Section 10: "Note that fact that" -> "Note the fact that", or much > better: "Note that". Those look ok or are nits in any case. Thanks again for the thorough review even though we disagree as to the main point. Cheers, Stephen. > > > Regards, Martin. > > > From tobias.gondrom@gondrom.org Tue Jun 5 04:27:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFA721F8663 for ; Tue, 5 Jun 2012 04:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.778 X-Spam-Level: X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUHLMtJ585az for ; Tue, 5 Jun 2012 04:27:58 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA6621F8665 for ; Tue, 5 Jun 2012 04:27:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=FYYlH/7E7He/5BlytZuV8+FdtzyX3u1nATWOlA9/1ODM7AsfMgtrhAqD9p68hxBCEoYcBPeqhdrg47VnQULk2cTFOaJleczYnGlQz80CVCpmFQY7ieRg1AGd1GefA7G+; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 18332 invoked from network); 5 Jun 2012 13:27:56 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.69?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Jun 2012 13:27:56 +0200 Message-ID: <4FCDED3C.80300@gondrom.org> Date: Tue, 05 Jun 2012 12:27:56 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: leifj@sunet.se, hartmans-ietf@mit.edu, jhutz@cmu.edu References: <4FCCC936.3030600@gondrom.org> <4FCCE496.1030800@gondrom.org> <4FCD0562.10300@sunet.se> In-Reply-To: <4FCD0562.10300@sunet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-krb-wg-kdc-model.all@tools.ietf.org, ietf-krb-wg@anl.gov, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-ietf-krb-wg-kdc-model X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 11:27:59 -0000 On 04/06/12 19:58, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/04/2012 06:38 PM, Tobias Gondrom wrote: >> On 04/06/12 17:02, Sam Hartman wrote: >>>>>>>> "Tobias" == Tobias Gondrom >>>>>>>> writes: >>> Tobias> One basic question: Tobias> This draft aims for >>> Standards Track, yet as far as I understood, it is Tobias> not >>> required that the used field names are in fact the same across >>> Tobias> different implementations but only that name-mappings >>> exist. The ID Tobias> also uses a modified RFC2119 language >>> definition to allow that. Tobias> I would like to ask, whether >>> possibly Informational Status would be Tobias> more appropriate >>> for this draft? >>> >>> My concern is that this does specify mandatory behavior of >>> implementations and that it's likely that a schema would want to >>> normatively refer to this document for semantics of attributes. >> Does it have to be Standards Track for that purpose? (note: I don't >> have a strong opinion on this, just feel uneasy with using the >> watered down 2119 definitions in the draft and the name-mapping, >> and then to go for Standards Track....) > It isn't watered-down at all! The reason we have that section is to > clarify what an implementation of the information-model actually is (a > schema) and what it means to be compliant with the information model. > > The RFC2919 terms mean what they always mean - just in a non-typical > context (i.e not just viz an bits-on-the-wire implementation) > > Cheers Leif Leif, Sam and Jeff, thank you for your answers. As I said I have no strong opinion on the Intended Status, but at the moment my concerns remain. Please let me explain why I perceived 2119 to be watered down in this case. Maybe to provide the context, let me copy the relevant sections from the draft once more here: section 1 states: " Implementations of this document MAY decide to change the names used (e.g. principalName). If so an implementation MUST provide a name to name mapping to this document. In particular schema languages may have different conventions for caseing, eg camelCase vs use of '_' and '-' to separate 'words' in a name. Implementations MUST call out such conventions explicitly." Plus section 2: " This document describes an information model for kerberos 5 but does not directly describe any mapping onto a particular schema- or modelling language. Hence an implementation of this model consists of a mapping to such a language - e.g. an LDAP or SQL schema. The precise interpretation of terms from [RFC2119] therefore require some extra explanation. The terms MUST or REQUIRED means that schema implementing this model must have a way to represent the feature (i.e that it is mandatory to implement) but that unless otherwise specified the feature may represent an optional element in the chosen schema definition language. However MUST also means that a KDC or administrative interface implementing this information model MUST provide the feature and associated behavior consistent with schema." To me this reads that, first the schemas will not have direct interoperability, because they can use different names, etc. (Yes, I read that there must be a mapping, still direct interoperability remains a question.) And second the MUST requirement feels for me vague ("must have a way to represent the feature"). All this reads to me more like an Informational RFC rather than a Proposed Std. Of course it is open whether you want/need interoperability between different kdc models at the schema level. Probably you don't really. In which case again the question pops up why Std Track and not Informational? But as I said, this is only my humble opinion. Maybe the best way would be for the AD to simply give this a quick look in the IESG during LC. And if the WG has discussed that aspect already before and came to the consensus that Std Track is the right way to go, I would not see a need to re-open that discussion. Best regards, Tobias From dhc@dcrocker.net Tue Jun 5 04:45:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4917421F867A; Tue, 5 Jun 2012 04:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWNcSOtuIvKB; Tue, 5 Jun 2012 04:45:34 -0700 (PDT) Received: from sbh11.songbird.com (sbh11.songbird.com [72.52.113.11]) by ietfa.amsl.com (Postfix) with ESMTP id 525D021F862A; Tue, 5 Jun 2012 04:45:34 -0700 (PDT) Received: from [10.102.2.236] ([212.184.65.20]) (authenticated bits=0) by sbh11.songbird.com (8.13.8/8.13.8) with ESMTP id q55BjQm9029430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2012 04:45:31 -0700 Message-ID: <4FCDF13F.3000106@dcrocker.net> Date: Tue, 05 Jun 2012 13:45:03 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ned Freed References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> <01OGAJ8GBR2Q0006TF@mauve.mrochek.com> In-Reply-To: <01OGAJ8GBR2Q0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh11.songbird.com [72.52.113.11]); Tue, 05 Jun 2012 04:45:34 -0700 (PDT) Cc: draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 11:45:35 -0000 My hope is that I can respond to Ned without contradicting him. I'm prefacing with that statement because this is proving a challenging topic having -- as he notes -- some unexpected characteristics... On 6/4/2012 11:47 PM, Ned Freed wrote: > OTOH, it may actually work very well, if for no other reason than > most modern mail systems are able to deliver messages in a matter of > seconds most of the time, which will make it difficult for a human > user to observe any tangible difference for different priorities. Priority is a mechanism intended to deal with situations of limited resources. In other guises, that's an aspect of queuing. An observation made by Kleinrock and others about such queuing is that it only works well in periods of transient congestion. In protracted periods the only thing that suffices is more capacity and in periods of no queuing, there's no need for the mechanism. Perceiving no difference equates to "we don't need the mechanism". The modification for some prioritization -- the role-based usage that's been cited -- is protracted declining of service to lower rank originators. That's no longer 'queuing' in an operational sense, it's a termination of service for some. Besides the military example, that's what happens for telephone emergency mode, as I understand it. So as soon as we say that user's perceive no difference, we are saying that this mechanism isn't needed. Therefore we need to define use cases that /do/ need to show a difference. I believe the military case and the emergency service case have plenty of experience in that regard, establishing the value of traffic segmentation. > All that said, I am completly at a loss as to what, if anything, to > do about all of this. To nail down what prioritization means in an > operational sense requires a far more detailed model of how > MSA/MTA/MDAs work than we currently have. I think the basic syntax of prioritization is simple: differential labeling of the object with a rank-ordering value. Handling of labeled objects will, at a minimum, simply mean taking higher-labeled stuff before lower-labeled stuff. In more sophisticated queue-management situations, handling could be more complex. (I've just heard of recent work by van Jacobsen, for IP routers, that provides an example, but the details don't matter here.) > There's a reason why every specification I've seen that mentions > email prioritization, going back as far as FIPS PUB 98 (RFC 841) and > including X.400, GOSIP, various LAN email systems, either omits > entirely any description of what priorization actually means or > contains nothing but a bunch of handwaving. That's why I'm suggesting partitioning mechanism syntax from assignment semantics. Environments that insist on using the mechanism have the obligation to deal with this hard stuff. But we don't have to, both because we can't do it now and because it needs to be different for different environments. However, as usual, this sort of partitioning only works when one or two real-world cases are applied. IMO, this means that this spec needs to be accompanied by two specifications for the policy-side that provides details for using the mechanism in different environments. Hmmm. Military. Emergency Services. That's two. >> The environment will be left with individual clients taking more >> than their fair share. Or trying to. > >> Absent very specific rules to be applied consistently across the >> trust environment, what is most likely is that every client will >> always claim top priority and no one will actually get it. (This >> is a well-known phenomenon for this sort of game-theoretic >> condition.) > > I have no good explanation for it, but the evidence I've seen says > otherwise: Quite a few existing systems support message > prioritization, but I've yet to encounter a case where everybody > claims the top priority. But what you've described are situations where prioritization didn't matter. So user's had no incentive to use it. Although I can't cite papers, I recall hearing of extensive research (and experience in non-Internet contexts) that demonstrate the "everyone sets to max" phenomenon. On 6/5/2012 1:35 AM, Pete Resnick wrote: > I find more than 5 "priorities" complete > overkill, That's my assumption, to. One can easily argue for 3. In any event, for more than 5, I suggest that there needs to be explicit justification that is based on documented real-world models. (I don't care whether they are Internet-based. If there are useful models elsewhere, we can assume they might show up on the Internet.) > and I think the likelihood that in a modern SMTP system any > of these priorities will cause a significant change in delivery time > (or order, for that matter) to be exceedingly low. 1. Most systems experience little-to-no queuing. 2. Until an environment has a meaningful pattern of queuing, no this mechanism isn't need. 3. Some environments are known to experience queuing. That's why the combination of military and emergency should suffice as justification, IMO. However they don't seem to be getting referenced to provide their substance. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From leifj@mnt.se Tue Jun 5 05:09:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E0E21F8686 for ; Tue, 5 Jun 2012 05:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYz2gKc9HNL0 for ; Tue, 5 Jun 2012 05:09:30 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 74C9521F85D2 for ; Tue, 5 Jun 2012 05:09:29 -0700 (PDT) Received: from [10.101.1.96] (static-88.131.62.36.addr.tdcsong.se [88.131.62.36]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q55C8vv2010014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2012 14:09:08 +0200 (CEST) Message-ID: <4FCDF6D9.3070309@mnt.se> Date: Tue, 05 Jun 2012 14:08:57 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tobias Gondrom References: <4FCCC936.3030600@gondrom.org> <4FCCE496.1030800@gondrom.org> <4FCD0562.10300@sunet.se> <4FCDED3C.80300@gondrom.org> In-Reply-To: <4FCDED3C.80300@gondrom.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ietf-krb-wg@anl.gov, apps-discuss@ietf.org, iesg@ietf.org, draft-ietf-krb-wg-kdc-model.all@tools.ietf.org, hartmans-ietf@mit.edu, jhutz@cmu.edu Subject: Re: [apps-discuss] AppsDir review of draft-ietf-krb-wg-kdc-model X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 12:09:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > To me this reads that, first the schemas will not have direct Correct. Direct interoperability between (say) XML schema and LDAP schema is not a useful goal. The fact that they represent the same underlying model is. Does that clarify things? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/N9tUACgkQ8Jx8FtbMZneLbwCgsX+Zi9/noL1o3Q/1hhpOVhBh eN8An17oppZSQn6lzfhmfSyqR4EJMkRw =s/FA -----END PGP SIGNATURE----- From tobias.gondrom@gondrom.org Tue Jun 5 05:29:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2065B21F8667 for ; Tue, 5 Jun 2012 05:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.778 X-Spam-Level: X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 120kCDZ5EUgR for ; Tue, 5 Jun 2012 05:29:20 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1517521F8682 for ; Tue, 5 Jun 2012 05:29:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=eLCr7yyin+9+8xgw2IO4lQwZJDmL3ky0Ql2O0dRAN2az87Erq9NC/YdKXoPw2ebH27gLF0tsYQm2b5GBm6ci0462qXxq/zSeGSgIT0/hs6Q3sMTT0VCMZ6uCmRCp0tbb; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; Received: (qmail 19612 invoked from network); 5 Jun 2012 14:29:17 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.69?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Jun 2012 14:29:17 +0200 Message-ID: <4FCDFB9D.1020804@gondrom.org> Date: Tue, 05 Jun 2012 13:29:17 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: leifj@mnt.se References: <4FCCC936.3030600@gondrom.org> <4FCCE496.1030800@gondrom.org> <4FCD0562.10300@sunet.se> <4FCDED3C.80300@gondrom.org> <4FCDF6D9.3070309@mnt.se> In-Reply-To: <4FCDF6D9.3070309@mnt.se> Content-Type: multipart/alternative; boundary="------------020705050509040605090508" Cc: ietf-krb-wg@anl.gov, apps-discuss@ietf.org, iesg@ietf.org, draft-ietf-krb-wg-kdc-model.all@tools.ietf.org, hartmans-ietf@mit.edu, jhutz@cmu.edu Subject: Re: [apps-discuss] AppsDir review of draft-ietf-krb-wg-kdc-model X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 12:29:21 -0000 This is a multi-part message in MIME format. --------------020705050509040605090508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/06/12 13:08, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> To me this reads that, first the schemas will not have direct > Correct. Direct interoperability between (say) XML schema and > LDAP schema is not a useful goal. The fact that they represent > the same underlying model is. > > Does that clarify things? > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk/N9tUACgkQ8Jx8FtbMZneLbwCgsX+Zi9/noL1o3Q/1hhpOVhBh > eN8An17oppZSQn6lzfhmfSyqR4EJMkRw > =s/FA > -----END PGP SIGNATURE----- Thank you for the confirmation. Question: In the light of this, why does the ID aim for Standards Track (and not for Informational)? Best regards, Tobias --------------020705050509040605090508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/06/12 13:08, Leif Johansson wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


To me this reads that, first the schemas will not have direct
Correct. Direct interoperability between (say) XML schema and
LDAP schema is not a useful goal. The fact that they represent
the same underlying model is.

Does that clarify things?

	Cheers Leif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/N9tUACgkQ8Jx8FtbMZneLbwCgsX+Zi9/noL1o3Q/1hhpOVhBh
eN8An17oppZSQn6lzfhmfSyqR4EJMkRw
=s/FA
-----END PGP SIGNATURE-----
Thank you for the confirmation.
Question: In the light of this, why does the ID aim for Standards Track (and not for Informational)?

Best regards, Tobias

--------------020705050509040605090508-- From leifj@sunet.se Tue Jun 5 05:37:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E6C21F866E; Tue, 5 Jun 2012 05:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-9o+DvEWFJl; Tue, 5 Jun 2012 05:37:35 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 817E421F8683; Tue, 5 Jun 2012 05:37:34 -0700 (PDT) Received: from [10.101.1.96] (static-88.131.62.36.addr.tdcsong.se [88.131.62.36]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q55CbI5w014379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2012 14:37:22 +0200 (CEST) Message-ID: <4FCDFD77.6040900@sunet.se> Date: Tue, 05 Jun 2012 14:37:11 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tobias Gondrom References: <4FCCC936.3030600@gondrom.org> <4FCCE496.1030800@gondrom.org> <4FCD0562.10300@sunet.se> <4FCDED3C.80300@gondrom.org> <4FCDF6D9.3070309@mnt.se> <4FCDFB9D.1020804@gondrom.org> In-Reply-To: <4FCDFB9D.1020804@gondrom.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ietf-krb-wg@anl.gov, apps-discuss@ietf.org, iesg@ietf.org, draft-ietf-krb-wg-kdc-model.all@tools.ietf.org, hartmans-ietf@mit.edu, jhutz@cmu.edu Subject: Re: [apps-discuss] AppsDir review of draft-ietf-krb-wg-kdc-model X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 12:37:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/05/2012 02:29 PM, Tobias Gondrom wrote: > On 05/06/12 13:08, Leif Johansson wrote: > >>>> To me this reads that, first the schemas will not have >>>> direct > Correct. Direct interoperability between (say) XML schema and LDAP > schema is not a useful goal. The fact that they represent the same > underlying model is. > > Does that clarify things? > > Cheers Leif Thank you for the confirmation. Question: In the light > of this, why does the ID aim for Standards Track (and not for > Informational)? Because a standards-track LDAP schema (say) may need to _implement_ this information-model. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/N/XYACgkQ8Jx8FtbMZnfjRwCfQ3ZzjxtOGed0zsuauuYREwvX 2aMAn1Ose8xTl4bCahoXJOoDzE8xC355 =NTYv -----END PGP SIGNATURE----- From fanf2@hermes.cam.ac.uk Tue Jun 5 06:51:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1969821F8680; Tue, 5 Jun 2012 06:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrRLLf8ZjGHW; Tue, 5 Jun 2012 06:51:48 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id E087F21F85F2; Tue, 5 Jun 2012 06:51:47 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51976) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SbuAX-0005Ov-Py (Exim 4.72) (return-path ); Tue, 05 Jun 2012 14:51:33 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SbuAW-0006Pr-Vx (Exim 4.67) (return-path ); Tue, 05 Jun 2012 14:51:33 +0100 Date: Tue, 5 Jun 2012 14:51:32 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Peter Saint-Andre In-Reply-To: <4FC927D2.9080903@stpeter.im> Message-ID: References: <01OG68WJL5MG0006TF@mauve.mrochek.com> <4FC927D2.9080903@stpeter.im> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Ned Freed , apps-discuss@ietf.org, dane@ietf.org Subject: Re: [apps-discuss] [dane] DANE for MUAs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 13:51:50 -0000 Peter Saint-Andre wrote: > Ned Freed wrote: > > > > I've been thinking about this as well, and due to the different ways > > the DNS is used in these cases, I think it it at least makes sense to > > do them separately. But we should do all the email SRV ones at once. > > Ned, I tend to agree. Let's define them separately for now (Matt Miller > and I are working on an XMPP+DANE spec) and then see what the > commonalities are before we try to define a more generic approach. Yes, that was what I had in mind. It's possible that we might find commonalities before the separate-protocol drafts get to RFC stage, but we clearly need to bash out some details. It will be particularly useful to compare XMPP and email. Tony. -- f.anthony.n.finch http://dotat.at/ Humber, Thames: South 4 or 5, backing southeast 5 or 6. Slight or moderate. Showers then rain. Good, becoming moderate or poor. From jhutz@cmu.edu Tue Jun 5 06:54:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD4421F866E; Tue, 5 Jun 2012 06:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4w8WhvhpVbD; Tue, 5 Jun 2012 06:54:03 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF8121F85F2; Tue, 5 Jun 2012 06:54:03 -0700 (PDT) Received: from [192.168.202.157] (pool-96-236-205-96.pitbpa.fios.verizon.net [96.236.205.96]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q55Dru11019642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2012 09:53:57 -0400 (EDT) From: Jeffrey Hutzelman To: Tobias Gondrom In-Reply-To: <4FCDFB9D.1020804@gondrom.org> References: <4FCCC936.3030600@gondrom.org> <4FCCE496.1030800@gondrom.org> <4FCD0562.10300@sunet.se> <4FCDED3C.80300@gondrom.org> <4FCDF6D9.3070309@mnt.se> <4FCDFB9D.1020804@gondrom.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 05 Jun 2012 09:53:56 -0400 Message-ID: <1338904436.3279.280.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: ietf-krb-wg@anl.gov, apps-discuss@ietf.org, iesg@ietf.org, draft-ietf-krb-wg-kdc-model.all@tools.ietf.org, hartmans-ietf@mit.edu, jhutz@cmu.edu Subject: Re: [apps-discuss] AppsDir review of draft-ietf-krb-wg-kdc-model X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 13:54:04 -0000 On Tue, 2012-06-05 at 13:29 +0100, Tobias Gondrom wrote: > Question: In the light of this, why does the ID aim for Standards > Track (and not for Informational)? Because it is intended to be the basis for standards-track schema documents, which will specify presentation but incorporate semantics by reference from this document. Multiple schemas/DTDs/whatever based on this document are isomorphic representations of the same data, and the structure and semantics of that data are standardized here. -- Jeff From tobias.gondrom@gondrom.org Tue Jun 5 07:41:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B32821F8707 for ; Tue, 5 Jun 2012 07:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.777 X-Spam-Level: X-Spam-Status: No, score=-96.777 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJ5fHBjH6zQc for ; Tue, 5 Jun 2012 07:41:21 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8D19721F870B for ; Tue, 5 Jun 2012 07:41:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=VW0k4VvOogCErEL2Y/J5mrPqJXuIJfOyMCipJN/wF46xTr50RDBX1OaAKoW98ktmKZsg0GdwFXYc5c3KTwzslONuZudGKhuBCE02zYpplp6u81/edTnJd8Gsc4C3LcJk; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Priority:References:In-Reply-To:Content-Type; Received: (qmail 21534 invoked from network); 5 Jun 2012 16:41:17 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.69?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Jun 2012 16:41:17 +0200 Message-ID: <4FCE1A8C.9060205@gondrom.org> Date: Tue, 05 Jun 2012 15:41:16 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: jhutz@cmu.edu X-Priority: 4 (Low) References: <4FCCC936.3030600@gondrom.org> <4FCCE496.1030800@gondrom.org> <4FCD0562.10300@sunet.se> <4FCDED3C.80300@gondrom.org> <4FCDF6D9.3070309@mnt.se> <4FCDFB9D.1020804@gondrom.org> <1338904436.3279.280.camel@destiny.pc.cs.cmu.edu> In-Reply-To: <1338904436.3279.280.camel@destiny.pc.cs.cmu.edu> Content-Type: multipart/alternative; boundary="------------080804020407050507050507" Cc: ietf-krb-wg@anl.gov, apps-discuss@ietf.org, iesg@ietf.org, draft-ietf-krb-wg-kdc-model.all@tools.ietf.org, hartmans-ietf@mit.edu Subject: Re: [apps-discuss] AppsDir review of draft-ietf-krb-wg-kdc-model X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 14:41:21 -0000 This is a multi-part message in MIME format. --------------080804020407050507050507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 05/06/12 14:53, Jeffrey Hutzelman wrote: > On Tue, 2012-06-05 at 13:29 +0100, Tobias Gondrom wrote: >> Question: In the light of this, why does the ID aim for Standards >> Track (and not for Informational)? > Because it is intended to be the basis for standards-track schema > documents, which will specify presentation but incorporate semantics by > reference from this document. Multiple schemas/DTDs/whatever based on > this document are isomorphic representations of the same data, and the > structure and semantics of that data are standardized here. > > -- Jeff > Ok. Can see your point. Best regards, Tobias --------------080804020407050507050507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05/06/12 14:53, Jeffrey Hutzelman wrote:
On Tue, 2012-06-05 at 13:29 +0100, Tobias Gondrom wrote:
Question: In the light of this, why does the ID aim for Standards
Track (and not for Informational)?
Because it is intended to be the basis for standards-track schema
documents, which will specify presentation but incorporate semantics by
reference from this document.  Multiple schemas/DTDs/whatever based on
this document are isomorphic representations of the same data, and the
structure and semantics of that data are standardized here.

-- Jeff


Ok. Can see your point.

Best regards, Tobias

--------------080804020407050507050507-- From carlberg@g11.org.uk Mon Jun 4 17:18:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24ECA21F885D; Mon, 4 Jun 2012 17:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pe-71zFuYYvi; Mon, 4 Jun 2012 17:18:19 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFEE21F8844; Mon, 4 Jun 2012 17:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=zb5VdgOZdSSdyUeaw+4QbEXM+O1JHNXsnNKl+Ac2xcQ=; b=YBdrZjXdsPhVKWzTnGlYT8A7vujEnYpegtDA0PtpTVG6edfc8HrOSm3RutZl+hlrNZCYVJ0tZ1QXzP2/ta6ROcu2haUxJZukngEaFf4MWtfgleGK90Atho6c9krTvmJi; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:52967 helo=miro-2.private) by portland.eukhosting.net with esmtpa (Exim 4.77) (envelope-from ) id 1SbhTN-0005Uj-MV; Tue, 05 Jun 2012 00:18:09 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: Date: Mon, 4 Jun 2012 20:18:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> <01OGAJ8GBR2Q0006TF@mauve.mrochek.com> To: John C Klensin X-Mailer: Apple Mail (2.1278) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Tue, 05 Jun 2012 08:36:03 -0700 Cc: Ned Freed , apps-discuss@ietf.org, draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 00:18:20 -0000 On Jun 4, 2012, at 7:14 PM, John C Klensin wrote: > Yes in principle. In practice, I've seen one set of communities > that have repeatedly expressed high levels of demand for > prioritization. Those communities are military or ones with > aspirations to behave like military ones. For those > communities, "messages from the General get more delivery > priority than those from the Lieutenant" have obvious meaning > and obvious intent. Moreover, the obvious response, especially > if someone is a communications officer in that chain of command, > is to salute and say, "yessir, we will transmit the General's > message with instructions to process it at higher priority". > If what happens after that is that this information is passed > along but no MTA does a thing about it, your observation about a > second or two takes over, there is a report back to the General > of complete conformance to his wishes and recognition of his > exalted status, and everyone is happy. And, if that trick > doesn't work, it is always possible to artificially delay the > Lieutenant's mail for a while, even if the General has no mail > in the queue, just to help prove that the General is important. > Simply dumping the Lieutenant's mail into the queue when it > arrives while trying to immediately process the General's mail > for delivery or forwarding would probably be a sufficient > implementation. I don't have enough data to claim that > scenario occurs many times around the world every day, but it > has got to be close. so what you describe above is what I've called role-based = prioritization. its the easiest form of prioritization to implement and = deploy because its typically associated with a role (sargent, general, = etc.) and its generally stagnant and stays associated with a user or = device. several systems for both voice and messaging have been built = over the past 50 years or so using this form of prioritization. another type of system (that I worked on about 25 years ago) is what I = refer to as content-based prioritization, where the prioritization is = attributed to the content of the message. So in this case, one could = have a case where the user (or a proxy) decides and associates a = priority based on the information in the message to be sent. So in this = case, you could have a case where the lowly Sargent trumps the General = (kind a cool :-). And by far, this is the hardest system to = build/deploy because one needs to avoid the trap that Dave brought up = earlier in that given the freedom, everyone wants to have the highest = priority. In the past few years, some communities have had to rely on the = prioritization made available in X.400. However, these and other = communities wish to migrate to SMTP, hence the interest in produce the = draft-melnikov-smtp-priority draft. So what i wanted to point out is = that people have indeed worked on these systems and gained experience in = the subject area, and we'd like to migrate this to SMTP, as opposed to = just relying on proprietary hacks. cheers, -ken From carlberg@g11.org.uk Tue Jun 5 04:23:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A6521F865A; Tue, 5 Jun 2012 04:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yu20xvdGGVIm; Tue, 5 Jun 2012 04:23:22 -0700 (PDT) Received: from portland.eukhosting.net (portland.ukserverhosting.net [92.48.103.133]) by ietfa.amsl.com (Postfix) with ESMTP id 874D721F864A; Tue, 5 Jun 2012 04:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=8onANVC7J/YoVbpcJCkxcmcap3kTrhW9R+iDhjrWjIY=; b=C3nXAYv0YVOcVcSQCYCOp0HIeKwGyGKKTu7enXGqc4jbrNjfD+FldTFuXfYUfJnr/CGFqggBYO2WYbRV8AVocor5olOQBhIAA15+jNhSUyXuA/xV1EzLTW0aHLEo7LJc; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:54912 helo=miro-2.private) by portland.eukhosting.net with esmtpa (Exim 4.77) (envelope-from ) id 1Sbrr0-0004H9-2Q; Tue, 05 Jun 2012 11:23:14 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <1E3DCEC5990AF898F1E3582D@PST.JCK.COM> Date: Tue, 5 Jun 2012 07:23:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6828E9C8-3C2A-46C9-8BD1-1308000CD91B@g11.org.uk> References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> <01OGAJ8GBR2Q0006TF@mauve.mrochek.com> <1E3DCEC5990AF898F1E3582D@PST.JCK.COM> To: John C Klensin X-Mailer: Apple Mail (2.1278) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Tue, 05 Jun 2012 08:36:12 -0700 Cc: Ned Freed , apps-discuss@ietf.org, draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 11:23:23 -0000 On Jun 5, 2012, at 6:07 AM, John C Klensin wrote: > Sorry, the Sargent never trumps the General. He may be sending > a message on behalf of a body that can, with that body's > authorization, or may, more generally, have authorizations the > General does not, but... yes, the Sargent can trump the General. The simple example is a General = is at his headquarters and sends a message describing new operational = responsibilities for his staff -- mundane stuff. The Sargent is at a = remote Atoll monitoring live Satcom images and sees that a nuclear bomb = has just exploded and sends a message to that effect. In cases where = there is contention of resources between message switching/forwarding = centers/servers, the Sargent's message trumps the General's. I was part = of the team that wrote the code to do this. (and sorry, I can't go into = any indepth descriptions of the systems, operating environment, etc. I = just wanted to point out that this form of content-prioritization has = been done in the past). >> In the past few years, some communities have had to rely on >> the prioritization made available in X.400. However, these >> and other communities wish to migrate to SMTP, hence the >> interest in produce the draft-melnikov-smtp-priority draft. >> So what i wanted to point out is that people have indeed >> worked on these systems and gained experience in the subject >> area, and we'd like to migrate this to SMTP, as opposed to >> just relying on proprietary hacks. >=20 > I'm tempted to say that, if you want the X.400 service model, > you should be looking to improve on MIXER, not SMTP. I might actually, my understanding is that there is no interest in the X.400 = service model. There is an interest, though, in the specification of a = prioritization capability in SMTP, which has been accomplished in X.400. = A slight, but subtle difference. cheers, -ken From macar@cloudmark.com Tue Jun 5 11:10:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565CB21F8716 for ; Tue, 5 Jun 2012 11:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5sR7unIcqgE for ; Tue, 5 Jun 2012 11:10:03 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6004821F85DB for ; Tue, 5 Jun 2012 11:10:03 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id Ji9r1j0010ZaKgw01i9ryV; Tue, 05 Jun 2012 11:09:51 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=dpJZ+ic4 c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=OzVNOVH2-ZIA:10 a=H8j7-3xrJYgA:10 a=-bUu6MBLYPwA:10 a=zutiEJmiVI4A:10 a=8nJEP1OIZ-IA:10 a=b6nfwRhkAAAA:8 a=48vgC7mUAAAA:8 a=_xtiB1xY00unlXvkgRsA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from [172.20.2.21] (172.20.2.21) by auth-smtp.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 5 Jun 2012 11:09:52 -0700 Message-ID: <4FCE4B6F.8070708@cloudmark.com> Date: Tue, 5 Jun 2012 11:09:51 -0700 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: References: <4F4FD8A5.6010603@cloudmark.com> <1330638350.2531.11.camel@neutron> <4F514AF9.5010506@cloudmark.com> <9452079D1A51524AA5749AD23E003928077013@exch-mbx901.corp.cloudmark.com> <01173171-110F-4FBE-993A-E858B51E9068@mnot.net> <9452079D1A51524AA5749AD23E00392813E630@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392813E630@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.2.21] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1338919791; bh=yyYpTP9TzkC14z5rnNjGA9zFuTjyv2RSWnSKaQd1kSM=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=HeJEf0Woz2E8lV9CCfYrFlS9LyKIh5BfmIZnd0B3ZBVkLM2Uv43PGbbP1zy26FVwe 5JAfzwKT02e/6XUrTv9wrErjtInb5/J4eOcmBVR7600+pjkjVqOMc3onm2aUeakjma 88CUfKe01+8muRsrI63MQ69rXwHcogtFcpX6yb0U= Subject: Re: [apps-discuss] json-pointer #5 - semantics [was: Feedback on draft-ietf-appsawg-json-pointer-00] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 18:10:04 -0000 On 05/31/2012 09:42 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mark Nottingham >> Sent: Wednesday, May 30, 2012 8:46 PM >> To: IETF Apps Discuss >> Subject: [apps-discuss] json-pointer #5 - semantics [was: Feedback on draft-ietf-appsawg-json-pointer-00] >> It seems like we need to add language stating that failing to match >> a particular token can be considered an error, or can be used by a >> particular application to effect some other behaviour. Make sense? At first blush. But I think a spec that says "this can be an error or it can be implementation-defined" doesn't really constrain an implementation's behavior enough to be useful. As Murray writes: > I think the right approach is to say explicitly in pointer that it's > left to the application using pointer to decide whether a match > failure is an error or should be handled in some other way. I think language that says "An application of JSON pointer needs to define semantics for these cases" would be helpful, maybe with an example for Patch. -- Mike Acar - - macar at cloudmark dot com From sm@elandsys.com Tue Jun 5 12:02:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8F321F87AB for ; Tue, 5 Jun 2012 12:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyJPOitdCZMv for ; Tue, 5 Jun 2012 12:02:47 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9A121F87A9 for ; Tue, 5 Jun 2012 12:02:47 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.116]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q55J2OEC014264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2012 12:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1338922958; i=@elandsys.com; bh=mEd1xKu7RDirIoJHTcme4rXavfJLXRI0u31meqzD2Ro=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Tp2o5Tz70IQ6fMsLCWwJWmfa/LVg0q+dWiOVwYLMAPdIXMf9uxNYPPbZHeWF15sgx ZPEX7TjYeaBpt8wQUYpTlc1m+iOEAm5m4wLKc67vKGCCZNrcm3iTRzqu4n+6EhhTYt 0zkq9+/aT4hmiy9n3kz5B/GettI0GQtjzM9dLWFE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1338922958; i=@elandsys.com; bh=mEd1xKu7RDirIoJHTcme4rXavfJLXRI0u31meqzD2Ro=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=w6rZXJJFftDpJ8EjoCZNW6FG30U9OFAdD0RB7EJcxrv7nfh/I+jsLHxFYY+zZHWXA rMLmQgelQGToTmkPaab1G6lVPNFFCUYZ09y+kmMHdzJfjYHBglDP1lU5RP4lQN6oBA W17NB74r3GbNz5ucwMt1Pj5PWUh4Tdvx7O5YmhGw= Message-Id: <6.2.5.6.2.20120605105404.0adade48@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Jun 2012 11:01:38 -0700 To: appsawg-chairs@tools.ietf.org From: S Moonesamy In-Reply-To: <20120604215059.13159.71937.idtracker@ietfa.amsl.com> References: <20120604215059.13159.71937.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-appsawg-about-uri-scheme@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-about-uri-scheme-06: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 19:02:54 -0000 At 14:50 04-06-2012, Stephen Farrell wrote: >Stephen Farrell has entered the following ballot position for >draft-ietf-appsawg-about-uri-scheme-06: No Objection [snip] >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >The FCFS registration scheme could lead to anyone >registering an about-token that's in current use in a >browser. Why isn't expert review more suitable here to >protect against such abuse? For example, nothing >here prevents me from registering about:config, which >is used by >1 browser. I don't get why that is not >a problem. (This is almost a discuss btw, I'd really like >to see a response if possible before the telechat.) I'll suggest adding the following text to the fifth paragraph of Section 5.2.1: An existing assignment may be duplicated if the registered token is used in more than one Web browser implementation. >Why does about-token "correspond" to hier-part from 3986? >What would "about://example.com/foo/bar" mean? I'd have >thought that omitting the authority would be correct for >this scheme - why am I wrong? I suggest removing the last sentence from Section 2.1. The first paragraph of Section 2.2 can be modified as follows: The resource which a particular "about" URI references is denoted by part of the URI. It is not a hierarchical element for a naming authority. The specifies additional information about its handling and/or the information that should be returned by the resource which the URI references. Regards, S. Moonesamy From pbryan@anode.ca Tue Jun 5 16:22:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F7421F8687 for ; Tue, 5 Jun 2012 16:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnSKeQ5aKw0f for ; Tue, 5 Jun 2012 16:22:16 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 1F63721F8682 for ; Tue, 5 Jun 2012 16:22:16 -0700 (PDT) Received: from [10.125.20.55] (unknown [209.52.95.1]) by maple.anode.ca (Postfix) with ESMTPSA id 616CD6488; Tue, 5 Jun 2012 23:22:14 +0000 (UTC) From: "Paul C. Bryan" To: Mike Acar In-Reply-To: <4FCE4B6F.8070708@cloudmark.com> References: <4F4FD8A5.6010603@cloudmark.com> <1330638350.2531.11.camel@neutron> <4F514AF9.5010506@cloudmark.com> <9452079D1A51524AA5749AD23E003928077013@exch-mbx901.corp.cloudmark.com> <01173171-110F-4FBE-993A-E858B51E9068@mnot.net> <9452079D1A51524AA5749AD23E00392813E630@exch-mbx901.corp.cloudmark.com> <4FCE4B6F.8070708@cloudmark.com> Content-Type: multipart/alternative; boundary="=-ynzwT8NQBIfpVJcTudrE" Date: Tue, 05 Jun 2012 13:41:30 -0700 Message-ID: <1338928890.10251.6.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] json-pointer #5 - semantics [was: Feedback on draft-ietf-appsawg-json-pointer-00] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 23:22:18 -0000 --=-ynzwT8NQBIfpVJcTudrE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Tue, 2012-06-05 at 11:09 -0700, Mike Acar wrote: > On 05/31/2012 09:42 AM, Murray S. Kucherawy wrote: > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mark Nottingham > >> Sent: Wednesday, May 30, 2012 8:46 PM > >> To: IETF Apps Discuss > >> Subject: [apps-discuss] json-pointer #5 - semantics [was: Feedback on draft-ietf-appsawg-json-pointer-00] > > >> It seems like we need to add language stating that failing to match > >> a particular token can be considered an error, or can be used by a > >> particular application to effect some other behaviour. Make sense? > > At first blush. But I think a spec that says "this can be an error or it > can be implementation-defined" doesn't really constrain an > implementation's behavior enough to be useful. > > As Murray writes: > > > I think the right approach is to say explicitly in pointer that it's > > left to the application using pointer to decide whether a match > > failure is an error or should be handled in some other way. > > I think language that says "An application of JSON pointer needs to > define semantics for these cases" would be helpful, maybe with an > example for Patch. +1 --=-ynzwT8NQBIfpVJcTudrE Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 2012-06-05 at 11:09 -0700, Mike Acar wrote:
On 05/31/2012 09:42 AM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mark Nottingham
>> Sent: Wednesday, May 30, 2012 8:46 PM
>> To: IETF Apps Discuss
>> Subject: [apps-discuss] json-pointer #5 - semantics [was: Feedback on draft-ietf-appsawg-json-pointer-00]

>> It seems like we need to add language stating that failing to match
>> a particular token can be considered an error, or can be used by a
>> particular application to effect some other behaviour. Make sense?

At first blush. But I think a spec that says "this can be an error or it 
can be implementation-defined" doesn't really constrain an 
implementation's behavior enough to be useful.

As Murray writes:

> I think the right approach is to say explicitly in pointer that it's
> left to the application using pointer to decide whether a match
> failure is an error or should be handled in some other way.

I think language that says "An application of JSON pointer needs to 
define semantics for these cases" would be helpful, maybe with an 
example for Patch.

+1

--=-ynzwT8NQBIfpVJcTudrE-- From duerst@it.aoyama.ac.jp Tue Jun 5 17:28:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706B411E80AE for ; Tue, 5 Jun 2012 17:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.465 X-Spam-Level: X-Spam-Status: No, score=-99.465 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byROxISy08DF for ; Tue, 5 Jun 2012 17:28:16 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5C35311E80AB for ; Tue, 5 Jun 2012 17:28:06 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q560Rtes027796 for ; Wed, 6 Jun 2012 09:27:55 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 0837_65a6_75775f58_af6e_11e1_8df3_001d096c5782; Wed, 06 Jun 2012 09:27:54 +0900 Received: from [IPv6:::1] ([133.2.210.1]:41805) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 6 Jun 2012 09:27:58 +0900 Message-ID: <4FCEA408.2000009@it.aoyama.ac.jp> Date: Wed, 06 Jun 2012 09:27:52 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> <01OGAJ8GBR2Q0006TF@mauve.mrochek.com> <4FCDF13F.3000106@dcrocker.net> In-Reply-To: <4FCDF13F.3000106@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-melnikov-smtp-priority.all@tools.ietf.org, Ned Freed , iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 00:28:16 -0000 On 2012/06/05 20:45, Dave Crocker wrote: > The modification for some prioritization -- the role-based usage that's > been cited -- is protracted declining of service to lower rank > originators. That's no longer 'queuing' in an operational sense, it's a > termination of service for some. Besides the military example, that's > what happens for telephone emergency mode, as I understand it. That's definitely what happened in Japan after the 2011-03-11 earthquake, and to a lesser extent in other situations. Regards, Martin. From touch@isi.edu Tue Jun 5 17:42:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C5B21F85DB; Tue, 5 Jun 2012 17:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.705 X-Spam-Level: X-Spam-Status: No, score=-102.705 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3R-xKWdhNX0; Tue, 5 Jun 2012 17:42:34 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id DB3FB21F8602; Tue, 5 Jun 2012 17:42:34 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q560gFO9026508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Jun 2012 17:42:15 -0700 (PDT) Message-ID: <4FCEA767.30404@isi.edu> Date: Tue, 05 Jun 2012 17:42:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "C. M. Heard" References: <4FCA0E7F.7020109@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Apps Discussion , Internet Area , IETF Discussion Subject: Re: [apps-discuss] [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 00:42:35 -0000 Hi, all, On 6/2/2012 9:21 PM, C. M. Heard wrote: > On Sat, 2 Jun 2012, Joe Touch wrote: >> Hi, Eliot, >> >> On Jun 2, 2012, at 6:00 AM, Eliot Lear wrote: >> >>> >>> Document: draft-ietf-intarea-ipv4-id-update-05 >>> Title: Updated Specification of the IPv4 ID Field >>> Reviewer: Eliot Lear >>> Review Date: 2 June 2012 >>> IETF Last Call Date: 31 May 2012 >>> >>> >>> Summary: This draft is quite well written, and is very nearly ready for publication. >>> >>> This draft is well written, and from the applications >>> perspective represents an important step to improving >>> performance and error reduction. It uses a new requirements >>> call-out style that I would class as experimental, but not bad. >>> It is worth people reading this draft and deciding if they agree >>> with Joe's approach. > > FWIW, I thought it was helpful. > >>> Major issues: >>> >>> None (Yay!). >>> >>> Minor issues: >>> >>> Section 4 needs to be reconciled a bit with Section 6.1. Specifically: >>> >>>> The IPv4 ID field can be useful for other purposes. >>> >>> >>> And >>> >>> >> IPv4 ID field MUST NOT be used for purposes other than >>> fragmentation and reassembly. >>> >>> >>> My suggestion is to drop the above sentence from Section 4. >> >> The two are not contradictory - the ID can be useful, but >> generating it correctly is prohibitive and typically not done. > > After re-reading the text I agree with Eliot that it is confusing. > Dropping the sentence in Section 4 would be fine. Another > possibility would be to reword it along the following lines: > > Other uses have been envisioned for the IPv4 ID field. That's much better, IMO. >>> In Section 6.1: >>> >>> >>>> Datagram de-duplication can be accomplished using hash-based >>>> duplicate detection for cases where the ID field is absent. >>>> >>> >>> Under what circumstances would the ID field be absent? >> >> Replace "absent" with "known not unique". > > Better, I think, would be "not known to be unique". Sure. >>>> >> Sources of non-atomic IPv4 datagrams using strong integrity checks >>>> MAY reuse the ID within MSL values smaller than is typical. >>>> >>> >>> Is the issue really the source using strong integrity checks or >>> the destination in this context? What is typical? >> >> The onus is on the source (of non-atomic datagrams) - if it >> includes strong integrity checks (that are presumably validated by >> the receiver), it then has more flexibility in its generation of >> the iD values. >> >>> Nit: >>> >>> Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3? >> >> Not subsections of 2, but perhaps "3, 3.1, 3.2"? > > That would be fine but I'm also OK with leaving the document the way > it is (especially if it would get it into the publication queue > faster). I'll check. I'm not sure if it matters whether I do a rev inbetween IETF LC and final RFC Editor processing. If so, I'll check on this to see if it can be done with minimal content impact (maybe some fluff to explain the flow, but no semantic changes). Joe From touch@isi.edu Tue Jun 5 17:46:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1FB21F86B7; Tue, 5 Jun 2012 17:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hEsg8yX+SFg; Tue, 5 Jun 2012 17:46:10 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2C921F86AA; Tue, 5 Jun 2012 17:46:10 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q560jqv7027613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Jun 2012 17:45:52 -0700 (PDT) Message-ID: <4FCEA840.9030204@isi.edu> Date: Tue, 05 Jun 2012 17:45:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "C. M. Heard" References: <4FCA0E7F.7020109@cisco.com> <1338699237.5620.3.camel@gwz-laptop> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Glen Zorn , Internet Area , IETF Discussion , Apps Discussion Subject: Re: [apps-discuss] [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 00:46:11 -0000 On 6/2/2012 10:00 PM, C. M. Heard wrote: > On Sun, 3 Jun 2012, Glen Zorn wrote: >> On Sat, 2012-06-02 at 21:21 -0700, C. M. Heard wrote: >> >> ... >> >>>>> In Section 6.1: >>>>> >>>>> >>>>>> Datagram de-duplication can be accomplished using hash-based >>>>>> duplicate detection for cases where the ID field is absent. >>>>>> >>>>> >>>>> Under what circumstances would the ID field be absent? >>>> >>>> Replace "absent" with "known not unique". >>> >>> Better, I think, would be "not known to be unique". >> >> Except that the two are not semantically equivalent. Sorry - I didn't catch that. When the datagram is atomic, under the new rules, we would *assume* that the ID field was not unique for a src/dst/protocol triple within the expected time (120 seconds). I.e., the ID field is "assumed to not be useful for such purposes", which might be more accurate. Joe > > Indeed. That was why I suggested the change. > > //cmh > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From suresh.krishnan@ericsson.com Wed Jun 6 07:45:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7220D21F856C for ; Wed, 6 Jun 2012 07:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnPboEKuo6Bg for ; Wed, 6 Jun 2012 07:45:18 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8406A21F8535 for ; Wed, 6 Jun 2012 07:45:04 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q56Ej0i5011822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Jun 2012 09:45:02 -0500 Received: from [142.133.112.108] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 6 Jun 2012 10:44:59 -0400 Message-ID: <4FCF6CEB.9090402@ericsson.com> Date: Wed, 6 Jun 2012 10:44:59 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Joseph Yee References: <4D0553BA-8A40-4DF0-83D4-26F7E0E77430@afilias.info> In-Reply-To: <4D0553BA-8A40-4DF0-83D4-26F7E0E77430@afilias.info> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 06 Jun 2012 08:05:46 -0700 Cc: "draft-ietf-6man-lineid.all@tools.ietf.org" , "Apps-Discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-6man-lineid-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 14:45:19 -0000 Hi Joseph, Thanks for your comments. Please find responses inline. On 06/02/2012 06:53 PM, Joseph Yee wrote: > All, > > I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). > > Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. > > Document: draft-ietf-6man-lineid-04 > Title: The Line Identification Destination Option > Reviewer: Joseph Yee > Review Date: June 2, 2012 > > > Summary: "This draft is almost ready for publication as an Experimental RFC but has a few issues that should be fixed before publication", > > > Major Issues: > none > > Minor Issues: > section 6.2, 8th line > "advertisement(es. The Edge Router then forms...." > There is no matching close bracket thru the rest of paragraph& section. This may be a typo (nits), but I am not entirely sure, so I put it as minor. It was a typo. It has been fixed in -05. > > section 6.2, line 15 > "All BBF Access Nodes multicast address [to be allocated]..." > Shouldn't this document define the address for IANA consideration? If it's to be determined by WG before Last Call or to be documented (or already documented) by another RFC, please ignore. IANA will allocate a free address out of the multicast address block. We are guessing that it is going to be FF02:0:0:0:0:0:1:7, but the actual value is not that important. > > > Nits: > none > > Note and Question > This is just my personal thought and question, it may be just my lack of knowledge in the subject matter. > > If I am right, this drafts is to help making distinction at Edge Router if multiple end point or AN do not use vLAN (hence N:1). > In section 2, it says that it's experimental and not recommend for general deployment. If it's not recommended, what's missing to make it "safe" or "good enough" for general deployment? Is it something to do with 1:1 or vLAN environment to know how to handle ILO data first? Would it better to document the issues in security consideration? or expand section 2 a bit more? The basic issue is that Router Solicitations are not retransmitted reliably until a router is found. If the home ethernet link comes up before the DSL line comes up, the RSs will never be retransmitted by the host to reach the edge router. This is why the draft is targeted only to scenarios where there is no other way of distinguishing multiple subscriber premises (n:1 vlan). Thanks Suresh From martin.thomson@gmail.com Wed Jun 6 08:22:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4553321F88D9 for ; Wed, 6 Jun 2012 08:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.929 X-Spam-Level: X-Spam-Status: No, score=-3.929 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APHI+rLtPsTP for ; Wed, 6 Jun 2012 08:22:18 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AE39A21F88D0 for ; Wed, 6 Jun 2012 08:22:17 -0700 (PDT) Received: by bkty8 with SMTP id y8so6723920bkt.31 for ; Wed, 06 Jun 2012 08:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wZlnjwbiWfQH3LE089U+KuU95bqFySNN3iRbCzxsGvc=; b=ce5ir0m8FjuD5cXgwkK5NcwiEB7ZR4KW9skl7Eam2/Tr1qKYzQliurpSAgfWmG7xXv HbMkMYYhKjcQ2QgNBGdBRfQD6bNvP3UVU1TqDl1k+x6iGslQYqXeC804MNsfExNXohmh BUDde9CZPhlygMYY0v2lywgIHyVJQSyrGtPzM5fYkhNHGekNA/p1XNj9vIHTNXjz/8j/ AihbVuPTMP5HnnvW/cW70rIOzs6meUEmwlHLRjYdyV4yIK5zoq1jlqcB4y3eB0JOpV7J QM5/f4KkXadPf/xqwkBqn2iW01q7nurVPI6Zblwk47zv8rJLMjgqrE2pCFruWQzNNZeS Twkw== MIME-Version: 1.0 Received: by 10.204.149.216 with SMTP id u24mr12665127bkv.36.1338996135573; Wed, 06 Jun 2012 08:22:15 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Wed, 6 Jun 2012 08:22:15 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E00392813E630@exch-mbx901.corp.cloudmark.com> References: <4F4FD8A5.6010603@cloudmark.com> <1330638350.2531.11.camel@neutron> <4F514AF9.5010506@cloudmark.com> <9452079D1A51524AA5749AD23E003928077013@exch-mbx901.corp.cloudmark.com> <01173171-110F-4FBE-993A-E858B51E9068@mnot.net> <9452079D1A51524AA5749AD23E00392813E630@exch-mbx901.corp.cloudmark.com> Date: Wed, 6 Jun 2012 08:22:15 -0700 Message-ID: From: Martin Thomson To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] json-pointer #5 - semantics [was: Feedback on draft-ietf-appsawg-json-pointer-00] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 15:22:19 -0000 On 31 May 2012 09:42, Murray S. Kucherawy wrote: > I think the right approach is to say explicitly in pointer that it's left= to the application using pointer to decide whether a match failure is an e= rror or should be handled in some other way. =C2=A0There are some cases whe= re one might abort totally, or might create the path being referenced. =C2= =A0Patch could, for example, abort on a "change" instruction that reference= s a nonexistent token, while "add" referencing a nonexistent token could cr= eate the intermediate objects needed to contain the new token. I disagree with what appears to be an emerging consensus, for one reason. There is an inherent ambiguity in pointers that requires a concrete document to resolve. Numerical indices can be used in two contexts: /1 =3D> "foo" { "1": "foo" } [ "foo" ] Without a concrete document, I can't decide what the pointer "points" at. That said, there is no stopping someone from going off-spec. But I'd prefer to keep it just that: off-spec. From sm@elandsys.com Wed Jun 6 13:04:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8296121F87DF; Wed, 6 Jun 2012 13:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrTlXeLxABTl; Wed, 6 Jun 2012 13:04:39 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3762D21F874C; Wed, 6 Jun 2012 13:04:39 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.116]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q56K472Q016559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2012 13:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339013063; i=@elandsys.com; bh=L0vQ/uxOenve9vlsbpse/8khHWByOeuoFtFb4d/Ztc4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AXV1B6kYPQczl6iKaUgEx2SYjrpbTwNydRVTjtBXPOntkuv7UIn7m4l9m0ZMoY/mh 3UtwsI586ngIwhhTSLBv2vfaw1n8LOJDbPziLu1JnRsGgwCsDiNrykhUVwCZQSBXcZ X5EtRvL8dlYN6iIkmCDcpiTYleV6A1GtJYZCSot8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1339013063; i=@elandsys.com; bh=L0vQ/uxOenve9vlsbpse/8khHWByOeuoFtFb4d/Ztc4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lOL0tpEntyollw18EYc4mhfH5/0wP6KWQBjEwEtsE50ytMNrOj13r0OT4t5HXFqC7 5o7Sjqrmof7HuWl7vVc+VjqwSScl9XutnB1YLdyK620gWQSoToSm+iBhsv0rEz/4bs F93EPgTGQjouph5gS9QszzeMDb5IoSuW4NsKaqOI= Message-Id: <6.2.5.6.2.20120606125009.0850e990@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Jun 2012 13:00:28 -0700 To: Stephen Farrell From: S Moonesamy In-Reply-To: <4FCDC047.9060103@cs.tcd.ie> References: <20120604215059.13159.71937.idtracker@ietfa.amsl.com> <4FCD317A.1050903@isode.com> <4FCD339A.8060801@cs.tcd.ie> <6.2.5.6.2.20120604153959.0a1b0018@elandnews.com> <4FCD3B39.2060708@cs.tcd.ie> <4FCDC047.9060103@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-about-uri-scheme-06: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 20:04:41 -0000 Hi Stephen, I'll defer to Barry for the changes to avoid any delay. In response to the FCFS registration scheme part of the comment, I'll add the following text to the fifth paragraph of Section 5.2.1: An existing assignment may be duplicated if the registered token is used in more than one Web browser implementation. For the second part about "hier-part", I'll remove the last sentence from Section 2.1 of draft-ietf-appsawg-about-uri-scheme-06. The first paragraph of Section 2.2 will be as follows: The resource which a particular "about" URI references is denoted by part of the URI. It is not a hierarchical element for a naming authority. The specifies additional information about its handling and/or the information that should be returned by the resource which the URI references. Regards, S. Moonesamy From pbryan@anode.ca Wed Jun 6 13:56:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149AF21F861A for ; Wed, 6 Jun 2012 13:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNXFb7uap-05 for ; Wed, 6 Jun 2012 13:56:13 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 9C42E21F85F4 for ; Wed, 6 Jun 2012 13:56:12 -0700 (PDT) Received: from [10.125.20.55] (unknown [209.52.95.1]) by maple.anode.ca (Postfix) with ESMTPSA id C37C36471; Wed, 6 Jun 2012 20:56:11 +0000 (UTC) From: "Paul C. Bryan" To: Martin Thomson In-Reply-To: References: <4F4FD8A5.6010603@cloudmark.com> <1330638350.2531.11.camel@neutron> <4F514AF9.5010506@cloudmark.com> <9452079D1A51524AA5749AD23E003928077013@exch-mbx901.corp.cloudmark.com> <01173171-110F-4FBE-993A-E858B51E9068@mnot.net> <9452079D1A51524AA5749AD23E00392813E630@exch-mbx901.corp.cloudmark.com> Content-Type: multipart/alternative; boundary="=-Ynz2C1YeSKYvzVGY1LjS" Date: Wed, 06 Jun 2012 13:56:06 -0700 Message-ID: <1339016166.24342.1.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: IETF Apps Discuss , "Murray S. Kucherawy" Subject: Re: [apps-discuss] json-pointer #5 - semantics [was: Feedback on draft-ietf-appsawg-json-pointer-00] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 20:56:14 -0000 --=-Ynz2C1YeSKYvzVGY1LjS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Can you elaborate on what the utility is of deciding what a pointer points at without a concrete document to resolve it to? Paul On Wed, 2012-06-06 at 08:22 -0700, Martin Thomson wrote: > On 31 May 2012 09:42, Murray S. Kucherawy wrote: > > I think the right approach is to say explicitly in pointer that it's left to the application using pointer to decide whether a match failure is an error or should be handled in some other way. There are some cases where one might abort totally, or might create the path being referenced. Patch could, for example, abort on a "change" instruction that references a nonexistent token, while "add" referencing a nonexistent token could create the intermediate objects needed to contain the new token. > > I disagree with what appears to be an emerging consensus, for one > reason. There is an inherent ambiguity in pointers that requires a > concrete document to resolve. Numerical indices can be used in two > contexts: > > /1 => "foo" > { "1": "foo" } > [ "foo" ] > > Without a concrete document, I can't decide what the pointer "points" at. > > That said, there is no stopping someone from going off-spec. But I'd > prefer to keep it just that: off-spec. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-Ynz2C1YeSKYvzVGY1LjS Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Can you elaborate on what the utility is of deciding what a pointer points at without a concrete document to resolve it to?

Paul

On Wed, 2012-06-06 at 08:22 -0700, Martin Thomson wrote:
On 31 May 2012 09:42, Murray S. Kucherawy <msk@cloudmark.com> wrote:
> I think the right approach is to say explicitly in pointer that it's left to the application using pointer to decide whether a match failure is an error or should be handled in some other way.  There are some cases where one might abort totally, or might create the path being referenced.  Patch could, for example, abort on a "change" instruction that references a nonexistent token, while "add" referencing a nonexistent token could create the intermediate objects needed to contain the new token.

I disagree with what appears to be an emerging consensus, for one
reason.  There is an inherent ambiguity in pointers that requires a
concrete document to resolve.  Numerical indices can be used in two
contexts:

  /1 => "foo"
  { "1": "foo" }
  [ "foo" ]

Without a concrete document, I can't decide what the pointer "points" at.

That said, there is no stopping someone from going off-spec.  But I'd
prefer to keep it just that: off-spec.
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--=-Ynz2C1YeSKYvzVGY1LjS-- From stephen.farrell@cs.tcd.ie Wed Jun 6 15:18:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE6E11E80E1; Wed, 6 Jun 2012 15:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqQksaz-nlGG; Wed, 6 Jun 2012 15:18:10 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id AA6E511E8074; Wed, 6 Jun 2012 15:18:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 692861714DD; Wed, 6 Jun 2012 23:18:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339021088; bh=kTHsN+qLv6FKbH pa1SqVw8j/Ge/yaYdvf5bULmBptuI=; b=klyBg+NLrrf3E+QO1gh6zFHkqdGW2p cU3lk8G1aoJRGDLaL1xx2eQ2P64Go+IQltSjyEL2RWNWWx2szpIE+j24TJ4fBO6n fK8ic9rEKfFyzBxk1GNtmskXo/7QCLiNNab6hXH81vVLj1kuNLP1TJz+FniObWNb xZKYYpEybKfrXOisegfi+EacvWE2RcXAf/5UlaY6lXaalOJ7x1L3Z0mrjGh6x8Jz GPETo58ULfK4i72I0zYkHpZa0ujDLQRHPfenOIgmGyaSaid7/eGCPoQ1DumSpZtK UTGNhZ6+3FRG/X6aCRP7/fK6iwLZDrNM96c0SdEPvyucx05BqYBNmgRw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id UFvjN0ayMJwI; Wed, 6 Jun 2012 23:18:08 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.77.44]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A410D171479; Wed, 6 Jun 2012 23:18:03 +0100 (IST) Message-ID: <4FCFD71B.7030405@cs.tcd.ie> Date: Wed, 06 Jun 2012 23:18:03 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: S Moonesamy References: <20120604215059.13159.71937.idtracker@ietfa.amsl.com> <4FCD317A.1050903@isode.com> <4FCD339A.8060801@cs.tcd.ie> <6.2.5.6.2.20120604153959.0a1b0018@elandnews.com> <4FCD3B39.2060708@cs.tcd.ie> <4FCDC047.9060103@cs.tcd.ie> <6.2.5.6.2.20120606125009.0850e990@elandnews.com> In-Reply-To: <6.2.5.6.2.20120606125009.0850e990@elandnews.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: appsawg-chairs@tools.ietf.org, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-about-uri-scheme-06: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 22:18:15 -0000 Hi SM, Those look like fine changes to me. Thanks for taking my comments into account, Cheers, S. On 06/06/2012 09:00 PM, S Moonesamy wrote: > Hi Stephen, > > I'll defer to Barry for the changes to avoid any delay. > > In response to the FCFS registration scheme part of the comment, I'll > add the following text to the fifth paragraph of Section 5.2.1: > > An existing assignment may be duplicated if the registered token is > used in more than one Web browser implementation. > > For the second part about "hier-part", I'll remove the last sentence > from Section 2.1 of draft-ietf-appsawg-about-uri-scheme-06. The first > paragraph of Section 2.2 will be as follows: > > The resource which a particular "about" URI references is denoted by > part of the URI. It is not a hierarchical element for > a naming authority. The specifies additional > information about its handling and/or the information that should be > returned by the resource which the URI references. > > Regards, > S. Moonesamy > From mikekelly321@gmail.com Wed Jun 6 18:50:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB85711E80C1 for ; Wed, 6 Jun 2012 18:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXbV2ml8EO3M for ; Wed, 6 Jun 2012 18:50:28 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B12A11E80BC for ; Wed, 6 Jun 2012 18:50:28 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so176394obb.31 for ; Wed, 06 Jun 2012 18:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JHLW07SKCkaQ4trasN6OJStdj77I3pbT57TpAgMhwV0=; b=qjcPN2JL9UvzS6bag+2rdcsD7oP8J+1QRd/RihSs77SwqBHrv5iioia/8oxMSM8Qcg +TlV25j3HFsZAlyW7GRro3rXdB3n+juPpfePFiJgEFffGbF9gc7UeYpxiESr1u75HBso BW0vFi8pzu3iQCuC+s3uPfilw0CJBSyEmXikHXZEGwHU036m3lRX8WYqYiK9bBmINo3y gwDbpNm60YBq8BxPWEE4xegnZ2M4SiY9xvSxHA9SvDPkcmxkwriUT/h3P+V9o04DDZGi 2LRC3Zx0O4Zg2va9RWXjGAbL7WLOEDYxt17U63L/4axcfJXmKgeSmXVjP58SSC3qMKXy y1jQ== MIME-Version: 1.0 Received: by 10.60.172.195 with SMTP id be3mr267583oec.48.1339033827928; Wed, 06 Jun 2012 18:50:27 -0700 (PDT) Received: by 10.60.28.195 with HTTP; Wed, 6 Jun 2012 18:50:27 -0700 (PDT) Date: Thu, 7 Jun 2012 02:50:27 +0100 Message-ID: From: Mike Kelly To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 01:50:29 -0000 Hello, I've published a draft of a media type for linking with JSON, and thought it might be of interest to people on this list http://www.ietf.org/id/draft-kelly-json-hal-00.txt Feedback welcome.. Best, Mike From mnot@mnot.net Wed Jun 6 19:39:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D497711E8102 for ; Wed, 6 Jun 2012 19:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.145 X-Spam-Level: X-Spam-Status: No, score=-103.145 tagged_above=-999 required=5 tests=[AWL=-1.146, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDdE3ysiJQZd for ; Wed, 6 Jun 2012 19:39:35 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4210A11E80C1 for ; Wed, 6 Jun 2012 19:39:35 -0700 (PDT) Received: from [10.4.229.165] (unknown [69.20.3.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 08C6922E1EB; Wed, 6 Jun 2012 22:39:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: Date: Thu, 7 Jun 2012 12:39:24 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C09861C-2A2A-474B-8D8D-E6CFB19176DD@mnot.net> <25C12394-42A4-4EF6-B820-28C5B8CC7D0F@mnot.net> To: mike amundsen X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] FYI: "home" document format for APIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 02:39:37 -0000 On 16/05/2012, at 10:42 PM, mike amundsen wrote: > Mark: >=20 > OK, I think I have a general sense of what you're working on here. = check me: > - clients will be coded to "start" w/ this document (and keep a fresh = copy on hand while interacting w/ the related service) > - while the document currently includes URI templates to describe = valid GET requests, there are currently no body templates to describe = valid PUT/POST requests > - this document is not the source of semantic interactions for = client-server interaction (that will still be in the primary response = representations from the service); it is merely an additional descriptor = document to aide in knowing what transitions are possible and (in some = cases) how to compose a valid transition request > - the document will not contain schema, data bindings or other similar = information >=20 > That pretty close at least? Yes. > Finally, while you have quite a bit of prose saying this document is = not static, "the client can decide at run-time", "follow your nose", = etc. I don't yet see details on _how_ this document could be used at = run-time to "lead" clients through a set of state transitions; not sure = what clients will "follow" in this document. For now I will assume this = is due to a limitation on my part and will wait for some additional = drafts and possibly some examples/pseudo-code to help me out. Absolutely. I'm looking to integrate this into APIs like OpenStack's, so = it should become more apparent over time.=20 Cheers, >=20 > Thanks. >=20 > mca > http://amundsen.com/blog/ > http://twitter.com@mamund > http://mamund.com/foaf.rdf#me >=20 >=20 >=20 >=20 > On Wed, May 16, 2012 at 12:30 AM, Mark Nottingham = wrote: >=20 > On 16/05/2012, at 11:56 AM, mike amundsen wrote: >=20 > > since i forgot to say it in my first comment; thanks for offering = this up. i am looking forward to learning more about it. >=20 > Thanks. >=20 >=20 > > _when_ should a client retrieve this document? at design-time? at = run-time on the _first_ call to the domain space? and then each time the = caching expires after that? >=20 > It's up to the client; they just need to use a fresh copy when they = use it. The simplest (but least efficient) design would be to fetch it = before every request; next would be to fetch-and-cache upon first use. = However, some clients might want to have a thread/process/task keeping a = copy fresh in the "background" as long as they're interested in that = service. >=20 >=20 > > > do you have a "recommendation" on this item? IOW, a suggested best > > > practice on how the client will "discover" the proper home = document? > > > /.welknown/? in the response?, etc.? > > > >> What I have in mind is that the client will be given a "starting = point" -- i.e., the home page document, usually expressed as a URL, and = all interaction will follow from that. For me, it makes sense if that = URL is the "root" (home) document for the authority (e.g., = . > >> > >> For a particular use case, one *could* register a well-known URL to = shorten that URL to just a hostname, but I hope that won't be the usual = thing. > > > > so, a client should be coded to pick up this document form a = pre-determined location (i.e. the service documentation will publish a = URI for the document.). >=20 > Yes. Just as I go to http://www.amazon.com/ to buy [insert most = products here]. >=20 >=20 > > > 2) use the linked home document as a guide when parsing/processing = the > > > current representation? > > > >> At this point, I'm reluctant to define this. The Web works because = media types *are* effectively guides to parsing representations. > >> media types *are* guides to parsing. this _is_ a media type, right? = this is the guide to parsing, right? > >> > >> That said, I want to make the representation types capable of = carrying more data than just the media type (such as a profile), but I'm = keenly aware that doing so will encourage people to do things like put = schema in there, so they can do "data binding" to objects. IMO that's = asking for trouble. > > > > so you want to "discourage" certain information from appearing in = this document, rigiht (i.e. no schema should appear, no binding of UI to = data elements should appear, what else)? >=20 > Possibly. I'd say that I want to vet what gets in very carefully, = because in the past people have gone so far off the rails with this kind = of format, and once it's out in the open, people are going to try to = bend it to fit those patterns / tools / expectations. >=20 >=20 > >> There might be some useful cases for that (e.g., doing QA on the = API, having an intermediary do something with it), but all of the = experience we've had with "data binding" has made be extremely wary of = doing this without a lot of consideration. > > > > can you give an example of how this document could be used in QA? >=20 > Well, effectively QA is a client, and it has to be able to consume the = API. Beyond that, you may want to annotate the document with QA-specific = information (e.g., "I expect THIS resource/representation to meet THOSE = tests"). >=20 >=20 > >> I'm fine with describing (again, as a hint) the expected semantics = of the document; if the media type covers this, great, if not, that's = where I'm thinking profiles might help. It's describing the syntax where = it gets sticky. > > > > i;m not clear on this answer. are you saying "the media type" =3D=3D=3D= not this document? what expected semantics to you have in mind here? >=20 > I mean the syntax/semantics of the request and responses = representations send in interactions driven by this format. So, "the = media type" is their media type(s). >=20 >=20 > > > not sure how to "know" what args are available for anything other = than > > > GET, how are PUT/POST representations described? > > > >> The assumed convention is that what you can GET you can PUT = (assuming PUT is allowed). The accept-post hint covers POSTs. > > > > i can see (using URI templates how GET requests can be composed = using information in this document. i can't see details on how to = compose a PUT using the example. am i missing something? are clients = expected to parse the URI template vars and use that to compose a body = for PUT/POST? >=20 > See below. >=20 >=20 > > > 3) use the linked home document to determine which hypermedia = options > > > to present to the user/user-agent (for each response)? > > > >> Please explain? > > > > i assume that the document will contain several (possibly dozens) of = Resource Objects. i assume that the client application would consume = this document and then use it to build up a UI that shows each of the = Resource Objects along with the possible arguments. Users will then = select the one they like, fill in the details and execute the request. = am i wrong in this? >=20 > That's one possible use of it, yes. >=20 >=20 > > > i can see how the client code might scan the home document and = present > > > controls to express the various templates (i.e. could be converted > > > into HTML.FORM elements, etc.) i assume ALL the templates would be > > > presented to the user/user-agent ALL the time, right? > > > >> That's up to the client. > > > > Yep, i understand it's up to the client. what i am unclear on is = _how_ the client will decide which items to "show" is this done by = hard-coding the client to only show selected controls at certain times = (determined by the client)? or is the decision on which Object Resources = to render decided at run-time by the client? and if it's decided at = runtime, how is that decision made? >=20 > I'm circumspect about use of the term "show" here, but pushing on, the = document certainly can/should be "personalised" to indicate what = resources, etc. are available to the client. Of course, actually = attempting interaction gives authoritative information, and interacting = with resources might expose further information that wasn't available in = the home document. >=20 >=20 > > > also, it seems the design includes read-only templating (URI = templates > > > for GET), but nothing line for POST/PUT. > > > >> What caused you to make that assumption? > > > > i assumed that the "href-template" and "href-vars" describe the = details on composing a URI used for GET (possibly DELETE). i assumed the = home document does not contain similar descriptions for composing a body = for PUT/POST since i could not find "body-template" and "body-vars" = elements in your design. >=20 > I'm purposefully punting on body / format constraints for the time = being, but will get to it. >=20 >=20 > > > I assume write actions would > > > not be provided at runtime and would only be available via > > > documentation that devs would consult ahead of time (before ever = using > > > this "service") and hard-code into the client, right? > > > >> I'm not sure what you mean by "write actions." Do you mean PUT, or = something more fine-grained? > > > > by "write actions" i mean the unsafe HTTP methods POST & PUT. this = goes back to my previous follow up. while i see details in your document = on composing URIs, i don't see details on composing bodies. i see the = it's possible to *tell* clients a PUT is possible. i don't see that it = is possible to tell clients what a valid PUT body looks like. i assumed, = then, that information would be in written documentation that the client = developer would consult when coding the client. >=20 > OK, see above. >=20 >=20 > > > my initial reaction is that this home document design is optimized = to > > > for use as a design-time IDL (ala WADL) instead of a run-time > > > interaction guide (ala HTML hypermedia). > > > >> Can you be more specific? On its own, that's not a helpful comment. > > > > my current understanding of your I-D is that it desctibes a static = resource which contains details on a "context-free" list of possible = actions on Object Resources. this looks to me very much like WADL/WSDL. = alternatively, designs like Mike Kelly's HAL or my Collection+JSON = describe dynamic representations that contain lists of "context-bound" = possible actions within the response itself (similar to HTML). does this = make sense? is it an accurate characterization of your I-D? >=20 > No. It's very much the opposite; e.g., from the draft: >=20 > > In contrast, a "follow your nose" API advertises the resources > > available to clients using link relations [RFC5988] and the = formats > > they support using internet media types [RFC4288]. A client can = then > > decide - at "run time" - which resources to interact with based = upon > > its capabilities (as described by link relations), and the server = can > > safely add new resources and formats without disturbing clients = that > > are not yet aware of them. > > > > As such, the client needs to be able to discover this information > > quickly and efficiently use it to interact with the server. Just = as > > with a human-targeted "home page" for a site, we can create a = "home > > document" for a HTTP API (often, at the same URI, found through > > server-driven content negotiation) that describes it to = non-browser > > clients. >=20 > and: >=20 > > o Home documents can be personalised, just as "normal" home = pages > > can. For example, you might advertise different URIs, and/or > > different kinds of link relations, depending on the client's > > identity. >=20 > and: >=20 > > Note that the home document is a "living" document; it does not > > represent a "contract", but rather is expected to be inspected = before > > each interaction. In particular, links from the home document = MUST > > NOT be assumed to be valid beyond the freshness lifetime of the = home > > document, as per HTTP's caching model [RFC2616]. >=20 > I'm happy to expand upon this further in the draft, but I thought I'd = already used a fairly large sledgehammer / clue-by-four. >=20 >=20 > > > any sample (or pseudo-code) worked up that would show using the = home > > > document at runtime? > > > >> Am working on it... > > > > cool. keep me posted. if you'd like, i'd be happy to attempt to = build something using this desgin once you think it is (and I am) = ready. >=20 > Great; will do. >=20 >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 >=20 -- Mark Nottingham http://www.mnot.net/ From superuser@gmail.com Wed Jun 6 22:27:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5554321F8787 for ; Wed, 6 Jun 2012 22:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QRC+GnqdFQL for ; Wed, 6 Jun 2012 22:27:54 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D13221F8783 for ; Wed, 6 Jun 2012 22:27:54 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so287921lbb.31 for ; Wed, 06 Jun 2012 22:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=cEDbJ/6iqPbPaBZ2RDgf+qfrTNCzVwNA/tYwB2CsYYY=; b=PwFOp+s6i0XxOkRNyRVQetf+U5mx4+ih8f9EnWM+LPfV7Yc60ABXLayAdY0WxE549W 5QgZIJZZ81TBAwJ1ycSM9uxRbL06dUgbvtv9uAsaSkY0hMZEVrWupncJSLBMS4wFuQ3L FL/OboUCZ3xpLEZ475h6GUIsoYqsB9kh4pNAK4Q4KHeuC44/tZTDruXKO+9K7VH1FYYW 1bKPuClpi3NT3kc+iEf+94Fk+ly8CGs5x7ConmfbqLwKYyDBtB3tMiFHZLquaUfcNbet MbiugmwkpfrSpK/BvNqv9+E9OlcbQwqVP4ABtXlWXgOb3kv1PBY8W027G5WMrvR02sMS H7Ag== MIME-Version: 1.0 Received: by 10.112.83.169 with SMTP id r9mr558785lby.66.1339046873246; Wed, 06 Jun 2012 22:27:53 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 6 Jun 2012 22:27:53 -0700 (PDT) Date: Wed, 6 Jun 2012 22:27:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=f46d0401fc4337acce04c1db25e9 Subject: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 05:27:55 -0000 --f46d0401fc4337acce04c1db25e9 Content-Type: text/plain; charset=ISO-8859-1 Some private comments I've received on this draft (reminder: it's in WGLC!) have led to the following updates which Dave and I agree to, and will appear in the next version of the document as long as the working group agrees. 1) Change the IANA rules for registering new states to Expert Review. Specification Requires is overkill. (Expert Review might be too, but I didn't feel totally comfortable busting it down that far. What do others think?) 2) Provide more discussion of what the "value" token in the ABNF is for, including examples. The general idea is to include additional unstructured data about the state the message has entered, such as "quarantine/spam" or "moderation/not-subscribed". The token is optional. 3) Add a reference to Section 7.6 of RFC5321 to Security Considerations. -MSK, as document editor --f46d0401fc4337acce04c1db25e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Some private comments I've received on this draft (reminder: it's i= n WGLC!) have led to the following updates which Dave and I agree to, and w= ill appear in the next version of the document as long as the working group= agrees.

1) Change the IANA rules for registering new states to Expert Review. S= pecification Requires is overkill.=A0 (Expert Review might be too, but I di= dn't feel totally comfortable busting it down that far.=A0 What do othe= rs think?)

2) Provide more discussion of what the "value" token in the A= BNF is for, including examples.=A0 The general idea is to include additiona= l unstructured data about the state the message has entered, such as "= quarantine/spam" or "moderation/not-subscribed".=A0 The toke= n is optional.

3) Add a reference to Section 7.6 of RFC5321 to Security Considerations= .

-MSK, as document editor
--f46d0401fc4337acce04c1db25e9-- From barryleiba@gmail.com Thu Jun 7 00:47:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A21D21F863D; Thu, 7 Jun 2012 00:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.961 X-Spam-Level: X-Spam-Status: No, score=-102.961 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcMwW-n8rUad; Thu, 7 Jun 2012 00:47:34 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id A372D21F863B; Thu, 7 Jun 2012 00:47:34 -0700 (PDT) Received: by qabj40 with SMTP id j40so307669qab.15 for ; Thu, 07 Jun 2012 00:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LPXkT6YIPmfMDKsSk4Jbbw4KJ56zPg04/PsPns9ovJY=; b=aLhoWDoEwScgxjUbMt17uW0JoaSn7Z6vM8JEACql6Ir7vDsNvPnH4HUvty+g5sojMa HMHjgFI0u5mEWqdozNOCDQ+iPtAuVr3Nttj83LXIlTUhWe4xK2L4QCVxv7E/UBWlWOwv AFjJG3Z9/UszktIQfSmHD9S4OGOlW8n3BAtM42mNSzu/kVjy5scOTOYyUntsyDIk+qtW aPpFW2V9JAWPjDL9R+hok94am3TmWwDjFsePwsKhii3z3w+WtioGx0XWWaCPY4HLWh00 h3EqhwwLmM6s1ZOTC9bROL5zHTsxoKGMAGyuMTUSAT0Zw3iKNC3JodC7vIH9l902tn3v 7gbw== MIME-Version: 1.0 Received: by 10.229.136.10 with SMTP id p10mr319747qct.131.1339055254079; Thu, 07 Jun 2012 00:47:34 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.82.129 with HTTP; Thu, 7 Jun 2012 00:47:34 -0700 (PDT) In-Reply-To: <4FCFD71B.7030405@cs.tcd.ie> References: <20120604215059.13159.71937.idtracker@ietfa.amsl.com> <4FCD317A.1050903@isode.com> <4FCD339A.8060801@cs.tcd.ie> <6.2.5.6.2.20120604153959.0a1b0018@elandnews.com> <4FCD3B39.2060708@cs.tcd.ie> <4FCDC047.9060103@cs.tcd.ie> <6.2.5.6.2.20120606125009.0850e990@elandnews.com> <4FCFD71B.7030405@cs.tcd.ie> Date: Thu, 7 Jun 2012 03:47:34 -0400 X-Google-Sender-Auth: uUUQOFdQJZQoNNxAYnXWDGMxUVU Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: multipart/alternative; boundary=00248c6a6646c10a1204c1dd184c Cc: "apps-discuss@ietf.org" , S Moonesamy , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-about-uri-scheme-06: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 07:47:35 -0000 --00248c6a6646c10a1204c1dd184c Content-Type: text/plain; charset=ISO-8859-1 > > Those look like fine changes to me. Thanks for taking > my comments into account, > Great; SM, please post a new version when you're ready. Barry --00248c6a6646c10a1204c1dd184c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Those look like fine changes to me. Thanks f= or taking
my comments into account,

Great; SM, pl= ease post a new version when you're ready.

Bar= ry
=A0
--00248c6a6646c10a1204c1dd184c-- From internet-drafts@ietf.org Thu Jun 7 01:35:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D3221F8758; Thu, 7 Jun 2012 01:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5M1ANeCeRNn; Thu, 7 Jun 2012 01:35:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3317721F874F; Thu, 7 Jun 2012 01:35:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120607083526.803.30833.idtracker@ietfa.amsl.com> Date: Thu, 07 Jun 2012 01:35:26 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-about-uri-scheme-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 08:35:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : The "about" URI Scheme Author(s) : S. Moonesamy Filename : draft-ietf-appsawg-about-uri-scheme-07.txt Pages : 6 Date : 2012-06-07 This document describes the "about" URI scheme, which is widely used by web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-about-uri-scheme-07.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-about-uri-scheme-07.t= xt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-about-uri-scheme/ From barryleiba.mailing.lists@gmail.com Thu Jun 7 03:59:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEDE21F87CD for ; Thu, 7 Jun 2012 03:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.962 X-Spam-Level: X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPNA9szSyywP for ; Thu, 7 Jun 2012 03:59:35 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7746D21F87C0 for ; Thu, 7 Jun 2012 03:59:35 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so532287lbb.31 for ; Thu, 07 Jun 2012 03:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2XeLj6dYK0oWK6ExVl/zusGLsJfrbavnN6PgAZDO6MI=; b=NJK4VUrNdJp/Gyzdvh6UUELvMegblmjd/JiHemqzyBijHxWudEmneLURhsKgiZBY8f cJKdQzpXyRXIfO0vDSeM4U2upSKiQIHl4genIvjPgrEA0zhubeQVMege/+DkJjtmtqjT 3alwOaCo/ETl34G5ofXX0mq2fhHqVEBsR0yp5E/aKO7Yj7P3jbZsi/RRkWK2BYuoIkVF WC7FTbVq5qZYw5y+Dml6EAb+hjcodWjSbGwpuNbgzQJfS8z9yTNa0ulpg9hdRcpUv+/C cJCiqaoBb40u6qYOrl0mGVb0G/7JmdGgaU7wR0K7fVBR+ZePogDkHOA1NNmWDx6MAtAY F71g== MIME-Version: 1.0 Received: by 10.152.103.11 with SMTP id fs11mr1981492lab.23.1339066774417; Thu, 07 Jun 2012 03:59:34 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Thu, 7 Jun 2012 03:59:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 Jun 2012 06:59:34 -0400 X-Google-Sender-Auth: SPi2HzLCxjv08PI-pXyydLslWII Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=f46d040715c56b701704c1dfc71b Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 10:59:36 -0000 --f46d040715c56b701704c1dfc71b Content-Type: text/plain; charset=ISO-8859-1 > > 1) Change the IANA rules for registering new states to Expert Review. > Specification Requires is overkill. (Expert Review might be too, but I > didn't feel totally comfortable busting it down that far. What do others > think?) > I think this is a good idea. I think FCFS would also be adequate, and encourage the WG to use that. The reason is that it's far better to encourage people to register status codes that they want to use, and not to put barriers in the way. The usual reluctance to use FCFS is concern that people will register a bunch of garbage. In fact, (1) this hasn't ever happened and (2) IANA would ask the IESG to intervene if they got a suspicious flood of registration requests. In any case, you're going to need to change the template if you don't require a specification. I suggest this: OLD Specification: The specification document that defines the queue state being registered. NEW Specification: A pointer to a specification document that defines the queue state being registered, if one exists; else, a more detailed description of the queue state, to aid in interoperable usage. Barry --f46d040715c56b701704c1dfc71b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1) Change the IANA rules for registering new= states to Expert Review. Specification Requires is overkill.=A0 (Expert Re= view might be too, but I didn't feel totally comfortable busting it dow= n that far.=A0 What do others think?)

<= /div>I think this is a good idea. =A0I think FCFS would also be adequate, a= nd encourage the WG to use that. =A0The reason is that it's far better = to encourage people to register status codes that they want to use, and not= to put barriers in the way. =A0The usual reluctance to use FCFS is concern= that people will register a bunch of garbage. =A0In fact, (1) this hasn= 9;t ever happened and (2) IANA would ask the IESG to intervene if they got = a suspicious flood of registration requests.

In any case, you're going to need to change th= e template if you don't require a specification. =A0 I suggest this:

OLD
Specification: The specification document that defines the q= ueue state being registered.

NEW
Specification: A poin= ter to a specification document that defines the queue state being register= ed, if one exists; else, a more detailed description of the queue state, to= aid in interoperable usage.

Barry

--f46d040715c56b701704c1dfc71b-- From dhc@dcrocker.net Thu Jun 7 04:12:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A3121F86C7 for ; Thu, 7 Jun 2012 04:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmUMm69Yjjqp for ; Thu, 7 Jun 2012 04:12:42 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A5A1F21F869E for ; Thu, 7 Jun 2012 04:12:42 -0700 (PDT) Received: from [10.102.2.236] ([212.184.65.20]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q57BCdpP031384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 7 Jun 2012 04:12:41 -0700 Message-ID: <4FD08CA3.6080504@dcrocker.net> Date: Thu, 07 Jun 2012 13:12:35 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 07 Jun 2012 04:12:42 -0700 (PDT) Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 11:12:43 -0000 On 6/7/2012 12:59 PM, Barry Leiba wrote: > I think this is a good idea. I think FCFS would also be adequate, and > encourage the WG to use that. The reason is that it's far better to > encourage people to register status codes that they want to use, and not > to put barriers in the way. The usual reluctance to use FCFS is concern > that people will register a bunch of garbage. In fact, (1) this hasn't > ever happened and (2) IANA would ask the IESG to intervene if they got a > suspicious flood of registration requests. +1 The justification for expert is "quality control". The side-effect is a disincentive to register. Do we make it easier and let in some cruft along with the good stuff or do we make it harder and keep out some good stuff because registering is too much hassle? I think the latter is the better choice, because the cruft doesn't actually hurt anything and there's a very, very large namespace that can afford to be wasted. As Barry notes, the actual 'threat' is quite small and the damage from its being realized is also negligible. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From alexey.melnikov@isode.com Thu Jun 7 05:43:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCDD21F87E0; Thu, 7 Jun 2012 05:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.181 X-Spam-Level: X-Spam-Status: No, score=-100.181 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SARE_HEAD_HDR_XIDKEY=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fA9NPE9FVHd4; Thu, 7 Jun 2012 05:43:02 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 720C321F871C; Thu, 7 Jun 2012 05:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1339072980; d=isode.com; s=selector; i=@isode.com; bh=CzQtOk0K3C9SrxkMSPAZNBrtUoVmfQ3urDKmkazUyL0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ggRxE86yDeNdbCbgTbNhwpSNgM9XsHWuC8RvzPRzi+PVcFxYfIC8QAkiO3PhYkVkcq2rxH TWpZuLfqkeWU+WDJaIhGhY9HBkCOHgp9w0WDrGy20sXydtv1kU/S2SQhN4AOPXKAv21PqN B8Qa5sWs9GDIN2XpqKCmTKkK0a1Qxx0=; Received: from [94.197.138.37] (94.197.138.37.threembb.co.uk [94.197.138.37]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 7 Jun 2012 13:42:59 +0100 References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> <01OGAJ8GBR2Q0006TF@mauve.mrochek.com> <4FCDF13F.3000106@dcrocker.net> In-Reply-To: <4FCDF13F.3000106@dcrocker.net> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 X-Identity-Key: id1 Fcc: imap://mel@imap.isode.com/Sent Message-Id: X-Account-Key: account1 From: Alexey Melnikov X-Mailer: iPad Mail (9B206) X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 Date: Thu, 7 Jun 2012 13:42:54 +0100 To: "dcrocker@bbiw.net" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "draft-melnikov-smtp-priority.all@tools.ietf.org" , Ned Freed , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 12:43:02 -0000 Hi Dave, On 5 Jun 2012, at 12:45, Dave Crocker wrote: > My hope is that I can respond to Ned without contradicting him. I'm > prefacing with that statement because this is proving a challenging > topic having -- as he notes -- some unexpected characteristics... >=20 > On 6/4/2012 11:47 PM, Ned Freed wrote: >> OTOH, it may actually work very well, if for no other reason than >> most modern mail systems are able to deliver messages in a matter of >> seconds most of the time, which will make it difficult for a human >> user to observe any tangible difference for different priorities. >=20 > Priority is a mechanism intended to deal with situations of limited > resources. In other guises, that's an aspect of queuing. An > observation made by Kleinrock and others about such queuing is that it > only works well in periods of transient congestion. In protracted > periods the only thing that suffices is more capacity and in periods of > no queuing, there's no need for the mechanism. >=20 > Perceiving no difference equates to "we don't need the mechanism". >=20 > The modification for some prioritization -- the role-based usage that's > been cited -- is protracted declining of service to lower rank > originators. That's no longer 'queuing' in an operational sense, it's a > termination of service for some. Besides the military example, that's > what happens for telephone emergency mode, as I understand it. >=20 > So as soon as we say that user's perceive no difference, we are saying > that this mechanism isn't needed. >=20 > Therefore we need to define use cases that /do/ need to show a > difference. I believe the military case and the emergency service case > have plenty of experience in that regard, establishing the value of > traffic segmentation. I believe both of these are mentioned in the 1st paragraph of the Introducti= on. If you think something is missing, please suggest some text. >=20 >=20 >> All that said, I am completly at a loss as to what, if anything, to >> do about all of this. To nail down what prioritization means in an >> operational sense requires a far more detailed model of how >> MSA/MTA/MDAs work than we currently have. >=20 > I think the basic syntax of prioritization is simple: differential > labeling of the object with a rank-ordering value. Handling of labeled > objects will, at a minimum, simply mean taking higher-labeled stuff > before lower-labeled stuff. >=20 > In more sophisticated queue-management situations, handling could be > more complex. (I've just heard of recent work by van Jacobsen, for IP > routers, that provides an example, but the details don't matter here.) >=20 >=20 >> There's a reason why every specification I've seen that mentions >> email prioritization, going back as far as FIPS PUB 98 (RFC 841) and >> including X.400, GOSIP, various LAN email systems, either omits >> entirely any description of what priorization actually means or >> contains nothing but a bunch of handwaving. >=20 > That's why I'm suggesting partitioning mechanism syntax from assignment > semantics. Environments that insist on using the mechanism have the > obligation to deal with this hard stuff. But we don't have to, both > because we can't do it now and because it needs to be different for > different environments. >=20 > However, as usual, this sort of partitioning only works when one or two > real-world cases are applied. IMO, this means that this spec needs to > be accompanied by two specifications for the policy-side that provides > details for using the mechanism in different environments. Hmmm. > Military. Emergency Services. That's two. I am working to address this (-16 doesn't quite do that). >=20 >>> The environment will be left with individual clients taking more >>> than their fair share. Or trying to. >>=20 >>> Absent very specific rules to be applied consistently across the >>> trust environment, what is most likely is that every client will >>> always claim top priority and no one will actually get it. (This >>> is a well-known phenomenon for this sort of game-theoretic >>> condition.) >>=20 >> I have no good explanation for it, but the evidence I've seen says >> otherwise: Quite a few existing systems support message >> prioritization, but I've yet to encounter a case where everybody >> claims the top priority. >=20 > But what you've described are situations where prioritization didn't > matter. So user's had no incentive to use it. >=20 > Although I can't cite papers, I recall hearing of extensive research > (and experience in non-Internet contexts) that demonstrate the "everyone > sets to max" phenomenon. >=20 >=20 > On 6/5/2012 1:35 AM, Pete Resnick wrote: >> I find more than 5 "priorities" complete >> overkill, >=20 > That's my assumption, to. One can easily argue for 3. >=20 > In any event, for more than 5, I suggest that there needs to be explicit j= ustification that is based on documented real-world models. (I don't care w= hether they are Internet-based. If there are useful models elsewhere, we ca= n assume they might show up on the Internet.) Hmm, Appendix A? Also see the new Appendix E in -16. >=20 >> and I think the likelihood that in a modern SMTP system any >> of these priorities will cause a significant change in delivery time >> (or order, for that matter) to be exceedingly low. >=20 > 1. Most systems experience little-to-no queuing. >=20 > 2. Until an environment has a meaningful pattern of queuing, no this mecha= nism isn't need. >=20 > 3. Some environments are known to experience queuing. That's why the comb= ination of military and emergency should suffice as justification, IMO. How= ever they don't seem to be getting referenced to provide their substance. Well, there are Appendices A, B and C. But as I said above, I will work on m= ore text. From dcrocker@bbiw.net Thu Jun 7 06:47:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8ACD21F88CF; Thu, 7 Jun 2012 06:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLZiCPHdgOBU; Thu, 7 Jun 2012 06:47:31 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 94A4921F88D2; Thu, 7 Jun 2012 06:47:31 -0700 (PDT) Received: from [10.102.2.236] ([212.184.65.20]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q57DlRbb006369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Jun 2012 06:47:29 -0700 Message-ID: <4FD0B0EB.4050000@bbiw.net> Date: Thu, 07 Jun 2012 15:47:23 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> <01OGAJ8GBR2Q0006TF@mauve.mrochek.com> <4FCDF13F.3000106@dcrocker.net> In-Reply-To: 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]); Thu, 07 Jun 2012 06:47:31 -0700 (PDT) Cc: "draft-melnikov-smtp-priority.all@tools.ietf.org" , Ned Freed , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 13:47:33 -0000 On 6/7/2012 2:42 PM, Alexey Melnikov wrote: >> Therefore we need to define use cases that /do/ need to show a >> difference. I believe the military case and the emergency service case >> have plenty of experience in that regard, establishing the value of >> traffic segmentation. > > I believe both of these are mentioned in the 1st paragraph of the Introduction. > If you think something is missing, please suggest some text. "Mentioned" is an accurate choice of vocabulary. By calling for use cases, I mean sufficient description to make the nature, needs and dynamics sufficiently clear that they motivate design choices. This is in contrast with having the document assume that the reader knows what the use requires. >>>> The environment will be left with individual clients taking more >>>> than their fair share. Or trying to. >>> >>>> Absent very specific rules to be applied consistently across the >>>> trust environment, what is most likely is that every client will >>>> always claim top priority and no one will actually get it. (This >>>> is a well-known phenomenon for this sort of game-theoretic >>>> condition.) >>> >>> I have no good explanation for it, but the evidence I've seen says >>> otherwise: Quite a few existing systems support message >>> prioritization, but I've yet to encounter a case where everybody >>> claims the top priority. >> >> But what you've described are situations where prioritization didn't >> matter. So user's had no incentive to use it. >> >> Although I can't cite papers, I recall hearing of extensive research >> (and experience in non-Internet contexts) that demonstrate the "everyone >> sets to max" phenomenon. >> >> >> On 6/5/2012 1:35 AM, Pete Resnick wrote: >>> I find more than 5 "priorities" complete >>> overkill, >> >> That's my assumption, to. One can easily argue for 3. >> >> In any event, for more than 5, I suggest that there needs to be explicit justification that is based on documented real-world models. (I don't care whether they are Internet-based. If there are useful models elsewhere, we can assume they might show up on the Internet.) > > Hmm, Appendix A? Probably. So... For more than 6, I suggest that... > Also see the new Appendix E in -16. well that argues from some additional room, but provides no rationale for having a space more than 3 times larger. Since the values are transmitted as text, no that you don't really need to specify specific numbers, other than to say it is a decimal number. That is, the specific range is a function of the specific profile that defines the semantics of the numbers. >> >>> and I think the likelihood that in a modern SMTP system any >>> of these priorities will cause a significant change in delivery time >>> (or order, for that matter) to be exceedingly low. >> >> 1. Most systems experience little-to-no queuing. >> >> 2. Until an environment has a meaningful pattern of queuing, no this mechanism isn't need. >> >> 3. Some environments are known to experience queuing. That's why the combination of military and emergency should suffice as justification, IMO. However they don't seem to be getting referenced to provide their substance. > > > Well, there are Appendices A, B and C. But as I said above, I will work on more text. ack d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Thu Jun 7 07:01:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EF321F8693 for ; Thu, 7 Jun 2012 07:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh-Elh5RpqGx for ; Thu, 7 Jun 2012 07:01:15 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C155A21F867E for ; Thu, 7 Jun 2012 07:01:14 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so686686lbb.31 for ; Thu, 07 Jun 2012 07:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jI9CY945Awz6VxZ1DXKIpwA14mBMC2zQSIPx9a5UPxA=; b=lSKv0SkwLq5XRq67nVrCRMsLwOnTBGtM1dDW8pgSAEs4p8qQkidt8fVpakT8s9FTy3 kynFd9cjXHRf96LR1A8T4ZZJoC+iUE5eJEWyK6EBgqijkUOsQdBdU5Cp3w0UIj0Z55X3 ZY+4V15iGBxmxBkTxqq4uPfQvaaqoI2/SCtTxuIe8T2E8uydo40IdTZ7zIduk4+s4liu gf16JLcc/eC4Qs7Fjy6Ry3z0uUtReg7zHYAIzScRWzGPHM3ZakDbsNCI7u0+nGvxIgn9 CtkKhwiUsZT9k/UsssQJcYUPGDgbWyjRV3mHXMjnyQPO6JeAzDkoFNxfDGMaQuPDeSca 8PTw== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr2705320lab.9.1339077673705; Thu, 07 Jun 2012 07:01:13 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 7 Jun 2012 07:01:13 -0700 (PDT) In-Reply-To: <4FD08CA3.6080504@dcrocker.net> References: <4FD08CA3.6080504@dcrocker.net> Date: Thu, 7 Jun 2012 07:01:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=e89a8f22c4111160a404c1e25137 Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 14:01:15 -0000 --e89a8f22c4111160a404c1e25137 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 7, 2012 at 4:12 AM, Dave Crocker wrote: > > > On 6/7/2012 12:59 PM, Barry Leiba wrote: > >> I think this is a good idea. I think FCFS would also be adequate, and >> encourage the WG to use that. The reason is that it's far better to >> encourage people to register status codes that they want to use, and not >> to put barriers in the way. The usual reluctance to use FCFS is concern >> that people will register a bunch of garbage. In fact, (1) this hasn't >> ever happened and (2) IANA would ask the IESG to intervene if they got a >> suspicious flood of registration requests. >> > > +1 > > The justification for expert is "quality control". The side-effect is a > disincentive to register. > > Do we make it easier and let in some cruft along with the good stuff or do > we make it harder and keep out some good stuff because registering is too > much hassle? > > I think the latter is the better choice, because the cruft doesn't > actually hurt anything and there's a very, very large namespace that can > afford to be wasted. > > As Barry notes, the actual 'threat' is quite small and the damage from its > being realized is also negligible. > > OK, I'll take it down to FCFS for the version that goes to the IESG. Unless there's objection I'll try to get that posted this weekend, which is about half way through WGLC. Thanks, -MSK --e89a8f22c4111160a404c1e25137 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 7, 2012 at 4:12 AM, Dave Crocker <dh= c@dcrocker.net> wrote:


On 6/7/2012 12:59 PM, Barry Leiba wrote:
I think this is a good idea. =A0I think FCFS would also be adequate, and encourage the WG to use that. =A0The reason is that it's far better to<= br> encourage people to register status codes that they want to use, and not to put barriers in the way. =A0The usual reluctance to use FCFS is concern<= br> that people will register a bunch of garbage. =A0In fact, (1) this hasn'= ;t
ever happened and (2) IANA would ask the IESG to intervene if they got a suspicious flood of registration requests.

+1

The justification for expert is "quality control". =A0The side-ef= fect is a disincentive to register.

Do we make it easier and let in some cruft along with the good stuff or do = we make it harder and keep out some good stuff because registering is too m= uch hassle?

I think the latter is the better choice, because the cruft doesn't actu= ally hurt anything and there's a very, very large namespace that can af= ford to be wasted.

As Barry notes, the actual 'threat' is quite small and the damage f= rom its being realized is also negligible.


OK, I'll take it down to FCFS f= or the version that goes to the IESG.=A0 Unless there's objection I'= ;ll try to get that posted this weekend, which is about half way through WG= LC.

Thanks,
-MSK

--e89a8f22c4111160a404c1e25137-- From dhc@dcrocker.net Thu Jun 7 07:22:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBD521F8611 for ; Thu, 7 Jun 2012 07:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PntSuR5Fen-3 for ; Thu, 7 Jun 2012 07:22:11 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F20F721F881E for ; Thu, 7 Jun 2012 07:21:58 -0700 (PDT) Received: from [10.102.2.236] ([212.184.65.20]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q57ELsKH007261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Jun 2012 07:21:56 -0700 Message-ID: <4FD0B8FF.6080302@dcrocker.net> Date: Thu, 07 Jun 2012 16:21:51 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4FD08CA3.6080504@dcrocker.net> In-Reply-To: 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]); Thu, 07 Jun 2012 07:21:56 -0700 (PDT) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 14:22:11 -0000 On 6/7/2012 4:01 PM, Murray S. Kucherawy wrote: > Do we make it easier and let in some cruft along with the good stuff or > do we make it harder and keep out some good stuff because registering is > too much hassle? > > I think the latter is the better choice, because the cruft doesn't > actually hurt anything and there's a very, very large namespace that can > afford to be wasted. Murray correctly interpreted what I meant, but I feel compelled to correct the email and archive by noting that I meant former and not latter... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From fanf2@hermes.cam.ac.uk Thu Jun 7 07:48:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECEC21F8914; Thu, 7 Jun 2012 07:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcGXGFyzjrZj; Thu, 7 Jun 2012 07:48:23 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id F1C0321F8912; Thu, 7 Jun 2012 07:48:22 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:36650) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Sce0Z-000692-Yh (Exim 4.72) (return-path ); Thu, 07 Jun 2012 15:48:19 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Sce0Z-0003A0-Ef (Exim 4.67) (return-path ); Thu, 07 Jun 2012 15:48:19 +0100 Date: Thu, 7 Jun 2012 15:48:19 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Peter Saint-Andre In-Reply-To: <4FC928DE.6070503@stpeter.im> Message-ID: References: <20120601170306.GA32180@isc.upenn.edu> <4FC928DE.6070503@stpeter.im> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [apps-discuss] [dane] DANE for MUAs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 14:48:24 -0000 Peter Saint-Andre wrote: > On 6/1/12 11:03 AM, Shumon Huque wrote: > > On Fri, Jun 01, 2012 at 05:47:50PM +0100, Tony Finch wrote: > >> > >> I presume that the client would not actually use mail.example.net as a > >> reference identifier unless DNSSEC is in use, otherwise that would not be > >> secure and is therefore forbidden according to the rules a few paragraphs > >> earlier in RFC 6125. > > > > That sounds correct to me. > > Agreed. That's the approach Matt Miller and I are taking for secure > delegation in XMPP (we'll submit an I-D soonish). I have a review in the works :-) While I was investigating this yesterday I had a look at gmail.com's RFC 6186 email SRV setup since I thought I might use it as an example. Sadly their servers have the wrong certificates - they can only authenticate {imap,pop,smtp}.gmail.com not gmail.com. I've written this up in more detail at http://fanf.livejournal.com/120855.html and notified security@google.com. I don't entirely blame them for this error since RFC 6125's abstractions are a bit confusing and the email example doesn't mention the "derived domain" caveat. Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: West veering northwest 5 or 6. Moderate or rough. Occasional rain. Moderate or good. From martin.thomson@gmail.com Thu Jun 7 08:33:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9787A21F86FA for ; Thu, 7 Jun 2012 08:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.058 X-Spam-Level: X-Spam-Status: No, score=-4.058 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiGkFvwnE7VT for ; Thu, 7 Jun 2012 08:33:11 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF22821F86D5 for ; Thu, 7 Jun 2012 08:33:10 -0700 (PDT) Received: by bkty8 with SMTP id y8so796209bkt.31 for ; Thu, 07 Jun 2012 08:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dJwUF6bzS4jInXwDg7xBSHumbUSPKemw8WhhdeYdHEA=; b=i9aht1GqiMqkx05I0Y3W8aD7OS7jaLEL3jApQybAjiHS4XCuwraVBdDVOB6soo4O7P GBLGaUB7iXeJA/sDnWWY2tEKm6jCIiRzrZrcm6ecPvOCABXnJYBHURER7pojrwl1ht72 Ils9BB9UgB+E5eIqI2Gb43T3KY5Ot1TgaoPXYyY9Otp00Ytn2uZKMTybvjf3ugtoBQoB SHwdv5p4/ExD85Ads9Mw4lMO1YmKlGxHahwye4nx7u6aQjUdhkIgnicKrSchJQwS2RDe rnBGb+p8YUJ8tm7JccsJr6ek83WEKOtJwi+zS18l/WDmTdUQOqMoHOyuk9TZHSgJZwM1 W1EA== MIME-Version: 1.0 Received: by 10.204.150.84 with SMTP id x20mr1905374bkv.26.1339083189672; Thu, 07 Jun 2012 08:33:09 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Thu, 7 Jun 2012 08:33:09 -0700 (PDT) In-Reply-To: <1339016166.24342.1.camel@pbryan-wsl.internal.salesforce.com> References: <4F4FD8A5.6010603@cloudmark.com> <1330638350.2531.11.camel@neutron> <4F514AF9.5010506@cloudmark.com> <9452079D1A51524AA5749AD23E003928077013@exch-mbx901.corp.cloudmark.com> <01173171-110F-4FBE-993A-E858B51E9068@mnot.net> <9452079D1A51524AA5749AD23E00392813E630@exch-mbx901.corp.cloudmark.com> <1339016166.24342.1.camel@pbryan-wsl.internal.salesforce.com> Date: Thu, 7 Jun 2012 08:33:09 -0700 Message-ID: From: Martin Thomson To: "Paul C. Bryan" Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss , "Murray S. Kucherawy" Subject: Re: [apps-discuss] json-pointer #5 - semantics [was: Feedback on draft-ietf-appsawg-json-pointer-00] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:33:11 -0000 On 6 June 2012 13:56, Paul C. Bryan wrote: > Can you elaborate on what the utility is of deciding what a pointer points > at without a concrete document to resolve it to? There are a number of applications that have been invented that use XPath and XML to do just this. Including, "insert new content at this location", or "you are missing an element at this location". But I don't think that it's wise to support those applications. Ever. Even the best of these applications had major issues. c.f. XML patch ops, XCAP, etc... From stpeter@stpeter.im Thu Jun 7 08:42:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA7521F8894; Thu, 7 Jun 2012 08:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.798 X-Spam-Level: X-Spam-Status: No, score=-102.798 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zi041FPNqOM5; Thu, 7 Jun 2012 08:42:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A14C721F8811; Thu, 7 Jun 2012 08:42:27 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 64B4D400A4; Thu, 7 Jun 2012 09:59:20 -0600 (MDT) Message-ID: <4FD0CBE1.2070802@stpeter.im> Date: Thu, 07 Jun 2012 09:42:25 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Tony Finch References: <20120601170306.GA32180@isc.upenn.edu> <4FC928DE.6070503@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [apps-discuss] [dane] DANE for MUAs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:42:28 -0000 On 6/7/12 8:48 AM, Tony Finch wrote: > Peter Saint-Andre wrote: >> On 6/1/12 11:03 AM, Shumon Huque wrote: >>> On Fri, Jun 01, 2012 at 05:47:50PM +0100, Tony Finch wrote: >>>> >>>> I presume that the client would not actually use mail.example.net as a >>>> reference identifier unless DNSSEC is in use, otherwise that would not be >>>> secure and is therefore forbidden according to the rules a few paragraphs >>>> earlier in RFC 6125. >>> >>> That sounds correct to me. >> >> Agreed. That's the approach Matt Miller and I are taking for secure >> delegation in XMPP (we'll submit an I-D soonish). > > I have a review in the works :-) Thanks. > While I was investigating this yesterday I had a look at gmail.com's > RFC 6186 email SRV setup since I thought I might use it as an example. > Sadly their servers have the wrong certificates - they can only > authenticate {imap,pop,smtp}.gmail.com not gmail.com. I've written this up > in more detail at http://fanf.livejournal.com/120855.html and notified > security@google.com. I don't entirely blame them for this error since > RFC 6125's abstractions are a bit confusing and the email example doesn't > mention the "derived domain" caveat. The more I think about it, the more I realize that RFC 6125 will need to be updated to reflect the use of derived domains under secure delegation. But let's work on our separate email and XMPP I-Ds first. :) Peter -- Peter Saint-Andre https://stpeter.im/ From ned.freed@mrochek.com Thu Jun 7 19:24:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BB411E80A5 for ; Thu, 7 Jun 2012 19:24:02 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzYqqwjzZgmW for ; Thu, 7 Jun 2012 19:24:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4E89711E8080 for ; Thu, 7 Jun 2012 19:24:02 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGEYVH3ZO0002SRU@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 7 Jun 2012 19:23:57 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGBNHXOPCG000058@mauve.mrochek.com>; Thu, 7 Jun 2012 19:23:51 -0700 (PDT) Message-id: <01OGEYVDDGU2000058@mauve.mrochek.com> Date: Thu, 07 Jun 2012 19:19:50 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 07 Jun 2012 06:59:34 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: Barry Leiba Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 02:24:02 -0000 > > > > 1) Change the IANA rules for registering new states to Expert Review. > > Specification Requires is overkill. (Expert Review might be too, but I > > didn't feel totally comfortable busting it down that far. What do others > > think?) > > > I think this is a good idea. I think FCFS would also be adequate, and > encourage the WG to use that. The reason is that it's far better to > encourage people to register status codes that they want to use, and not to > put barriers in the way. The usual reluctance to use FCFS is concern that > people will register a bunch of garbage. In fact, (1) this hasn't ever > happened and (2) IANA would ask the IESG to intervene if they got a > suspicious flood of registration requests. I'm OK with moving to expert review, but the idea of going to FCFS makes me pretty uncomfortable. The problem here is that it's possible to think about MTA states in a lot of different ways, some of which don't map well if at all onto actual implementations. While the risk is low, I think expert review is needed to make sure things stay sane. > In any case, you're going to need to change the template if you don't > require a specification. I suggest this: > OLD > Specification: The specification document that defines the queue state > being registered. > NEW > Specification: A pointer to a specification document that defines the queue > state being registered, if one exists; else, a more detailed description of > the queue state, to aid in interoperable usage. Sounds about right to me. Ned From ned.freed@mrochek.com Thu Jun 7 19:38:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED4D21F85F0 for ; Thu, 7 Jun 2012 19:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7clndaMYGfNq for ; Thu, 7 Jun 2012 19:38:33 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B7EAE21F85D8 for ; Thu, 7 Jun 2012 19:38:33 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGEZDILKVK0036PR@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 7 Jun 2012 19:38:29 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGBNHXOPCG000058@mauve.mrochek.com>; Thu, 7 Jun 2012 19:38:25 -0700 (PDT) Message-id: <01OGEZDG0T8M000058@mauve.mrochek.com> Date: Thu, 07 Jun 2012 19:24:31 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 07 Jun 2012 13:12:35 +0200" <4FD08CA3.6080504@dcrocker.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4FD08CA3.6080504@dcrocker.net> To: Dave Crocker Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 02:38:34 -0000 > On 6/7/2012 12:59 PM, Barry Leiba wrote: > > I think this is a good idea. I think FCFS would also be adequate, and > > encourage the WG to use that. The reason is that it's far better to > > encourage people to register status codes that they want to use, and not > > to put barriers in the way. The usual reluctance to use FCFS is concern > > that people will register a bunch of garbage. In fact, (1) this hasn't > > ever happened Um, in the case of media types at least, it hasn't happened *because* of expert review. I can point at several examples of registration attempts that didn't make any sense and which were rejected for that reason. > and (2) IANA would ask the IESG to intervene if they got a > > suspicious flood of registration requests. > +1 > The justification for expert is "quality control". The side-effect is a > disincentive to register. Er, not really. From a registrant's point of view the process is essentially the same with or without expert review: Fill in a form, submit it, wait for a response. What matters is the *content* of the form and the *timliness* of the response. We initially screwed up both of those with media types: The rules for filling out the form were much too strict, we didn't define the form content adequately, and when the form was submitted responses were nowhere near timely and in fact sometimes there was no response at all. Oh, and we called for mailing list review of all proposals, and then didn't respond to review requests in a timely way. And I'm not seeing overly onerous content requirements here. So the only factor is whether or not an expert can be found that can review in a timely way. If that proves to be impossible then maybe FCFS makes sense, but if not I'd prefer to see expert review remain. > Do we make it easier and let in some cruft along with the good stuff or > do we make it harder and keep out some good stuff because registering is > too much hassle? In this particular case cruft has a potential negative consequence: Someone looks at the registry and says "why doesn't your product produce this state". And they may not like the response that the state doesn't make a lick of sense. > I think the latter is the better choice, because the cruft doesn't > actually hurt anything and there's a very, very large namespace that can > afford to be wasted. > As Barry notes, the actual 'threat' is quite small and the damage from > its being realized is also negligible. The threat is indeed very small. Not so sure about the damage. Ned From dret@berkeley.edu Thu Jun 7 20:27:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998E711E80C1 for ; Thu, 7 Jun 2012 20:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqp-TXJn+tbc for ; Thu, 7 Jun 2012 20:27:06 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 19E8C11E80AB for ; Thu, 7 Jun 2012 20:27:04 -0700 (PDT) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.64]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Scpqo-0004gy-9x; Thu, 07 Jun 2012 20:27:03 -0700 Message-ID: <4FD17102.8020003@berkeley.edu> Date: Thu, 07 Jun 2012 20:26:58 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: REST Discuss , application-layer protocols , hypermedia-web@googlegroups.com References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] draft-wilde-profile-link-02 published X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 03:27:06 -0000 hello. "The 'profile' Link Relation Type" is now available as version 02 (draft-wilde-profile-link-02) at http://tools.ietf.org/html/draft-wilde-profile-link. please send feedback to the apps-discuss@ietf.org mailing list. thanks. the draft's abstract reads: "This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined to not alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms." kind regards, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From ned.freed@mrochek.com Thu Jun 7 21:38:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D730111E80BD for ; Thu, 7 Jun 2012 21:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWQRmNyrCV8L for ; Thu, 7 Jun 2012 21:38:44 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB1011E80B2 for ; Thu, 7 Jun 2012 21:38:44 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGF3KJK8BK00374P@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 7 Jun 2012 21:38:41 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGBNHXOPCG000058@mauve.mrochek.com>; Thu, 7 Jun 2012 21:38:37 -0700 (PDT) Message-id: <01OGF3KH2VL0000058@mauve.mrochek.com> Date: Thu, 07 Jun 2012 21:37:04 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 07 Jun 2012 07:01:13 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4FD08CA3.6080504@dcrocker.net> To: "Murray S. Kucherawy" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 04:38:46 -0000 > OK, I'll take it down to FCFS for the version that goes to the IESG. > Unless there's objection I'll try to get that posted this weekend, which is > about half way through WGLC. If that's the consensus then I won't object. As I say, I think the liklihood of there being a problem is low, but I do think the possibility for a problem exists. Oh, and my bad for not catching the original specification required requirement, which was clearly overkill. Ned From dhc@dcrocker.net Thu Jun 7 22:09:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB6D11E80B2 for ; Thu, 7 Jun 2012 22:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5jFFatcjQyP for ; Thu, 7 Jun 2012 22:09:28 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 877AD11E80CE for ; Thu, 7 Jun 2012 22:09:28 -0700 (PDT) Received: from [192.168.2.101] (e179037154.adsl.alicedsl.de [85.179.37.154]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q5859O7M026971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Jun 2012 22:09:26 -0700 Message-ID: <4FD188FF.1080201@dcrocker.net> Date: Fri, 08 Jun 2012 07:09:19 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ned Freed References: <01OGEYVDDGU2000058@mauve.mrochek.com> In-Reply-To: <01OGEYVDDGU2000058@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 07 Jun 2012 22:09:28 -0700 (PDT) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 05:09:29 -0000 On 6/8/2012 4:19 AM, Ned Freed wrote: > The problem here is that it's possible to think about MTA states in a lot of > different ways, some of which don't map well if at all onto actual > implementations. While the risk is low, I think expert review is needed to make > sure things stay sane. Ned, You are of course right that one can get the choice(s) very wrong. And I've no trouble believe that some form of getting it wrong could have a toxic effect. My question is what the actual damage of that is likely to be in the real world, /over time/. That is, not just what is the likelihood that a site will use one of these potentially damaging values, but what is the likelihood that it will persist? The world of MTA software developers is small enough to prompt me to believe that even if one of them gets this seriously wrong, a) it will get corrected quickly through natural forces, or b) they will have a plethora of other serious problems with their software and worrying about this one isn't worth the effort. In contrast, Expert Review imposes quite an expensive /ongoing/ load on /us/, for every registration, nevermind on the folk who want to do the registering. I see that as a very poor value proposition, especially in terms of community resources. Which is why I favor FCFS. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From internet-drafts@ietf.org Fri Jun 8 07:05:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A293921F8703; Fri, 8 Jun 2012 07:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npEQe38vy1dW; Fri, 8 Jun 2012 07:05:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3498B21F85D0; Fri, 8 Jun 2012 07:05:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120608140502.3246.76800.idtracker@ietfa.amsl.com> Date: Fri, 08 Jun 2012 07:05:02 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 14:05:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Forwarded HTTP Extension Author(s) : Andreas Petersson Martin Nilsson Filename : draft-ietf-appsawg-http-forwarded-03.txt Pages : 14 Date : 2012-06-08 This document standardizes an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, e.g., the originating IP address of a request or IP number of the proxy on the user-agent-facing interface. Given a trusted path of proxying components, this makes it possible to arrange so that each subsequent component will have access to e.g., all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-http-forwarded-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-http-forwarded-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ From jasnell@gmail.com Fri Jun 8 08:00:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D333B21F852A for ; Fri, 8 Jun 2012 08:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPteBkNxs8tR for ; Fri, 8 Jun 2012 08:00:12 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1C54F21F8516 for ; Fri, 8 Jun 2012 08:00:11 -0700 (PDT) Received: by wgbds1 with SMTP id ds1so1393242wgb.4 for ; Fri, 08 Jun 2012 08:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=m42YxMcwydWXOgrQR1ynXY2kZ75BzVtlKMX6vNxTVIo=; b=VIAOdmip3zYFSUkXE2b+t3n5Q/yD/eqAVe7yEzGbnu1ShmurIHgWa+tCuob7EvT/Fv AowKAcShLTJvfAprCHE9WK2NJ1di5OX1nXvju8Cvems77q+1dR3/5cyluqoipGkbLUd9 F00I06Ycnz+t85f2PtoLYpdu/hUeNtatYMdP7Lt5vwyd9Vt9qb/LctKpy67ZX3l+5aaq pJ5+ok/BN6xtk1cYAtHV1/I3inbUDK1PvGJ21Bg3xhQ4Vp+TKx0RyFB1JdUNhQVF97GE mM+w2vZL8mmGmskfNTP23TgebYEwwnF6CsSJK4sUoEwd2XYbiXQOifpjjRollSExJZtr ygHQ== Received: by 10.216.209.95 with SMTP id r73mr1514395weo.157.1339167611041; Fri, 08 Jun 2012 08:00:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.104.12 with HTTP; Fri, 8 Jun 2012 07:59:50 -0700 (PDT) From: James M Snell Date: Fri, 8 Jun 2012 07:59:50 -0700 Message-ID: To: Apps Discuss Content-Type: text/plain; charset=UTF-8 Subject: [apps-discuss] Additional Link Relations Draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 15:00:14 -0000 All, just wanted to send a quick note mentioning the "Additional Link Relations" draft [1]. The document proposes the registration of five new Link Relations per RFC 5988. These include: - "about" - "preview" - "privacy-policy" - "terms-of-service" - "type" Discussion and feedback should be directed to the apps-discuss list. - James [1] http://tools.ietf.org/html/draft-snell-additional-link-relations-04 From jasnell@gmail.com Fri Jun 8 10:36:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE06F11E808C for ; Fri, 8 Jun 2012 10:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO6b0+2OUVaY for ; Fri, 8 Jun 2012 10:36:42 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB9011E8086 for ; Fri, 8 Jun 2012 10:36:41 -0700 (PDT) Received: by wgbds1 with SMTP id ds1so1524279wgb.4 for ; Fri, 08 Jun 2012 10:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=ZnEvTBmSLRQ4q9RJkkheLdHGoCj6WJ70CWqOiVAuSgk=; b=Zzmh79c6dzPXMvAUAsYQH2sQ9HoTeroghKYukCVzncemdyBrq90dlHrHJR2HvvGUAC AbtLwPHPAa4dM6dGpwgYuSokUmyRsClqHzBP2PYqzH5DSK9mEv2plRgcycZ/UK1SakSa cHxYBm/lOz7ErQE1pe8IFQ/mutI8uqDORv0oTAKkwKpYfV0pOTKNrzWHwWn/Z7yia3aJ GaMTcW4izbU+07k0/rDwpnjIGTddFVblgG4EGRWyKpYMdeK4LfDVIQ/fhLSWbukSV8JM PfpASXfeEAwIyLV+A6S0U3tz839pMGaBhl/GRqFJu0MtmkGVLvxTwbdBL0ze+feZcniu dRvw== Received: by 10.216.209.95 with SMTP id r73mr1830577weo.157.1339177000232; Fri, 08 Jun 2012 10:36:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.104.12 with HTTP; Fri, 8 Jun 2012 10:36:19 -0700 (PDT) From: James M Snell Date: Fri, 8 Jun 2012 10:36:19 -0700 Message-ID: To: Apps Discuss Content-Type: text/plain; charset=UTF-8 Subject: [apps-discuss] FYI: For review... draft-snell-merge-patch-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 17:36:42 -0000 Hello All, I have submitted an updated version of draft-snell-merge-patch [1] that fixes a few editorial issues. Feedback is quite welcome. - James [1] http://www.ietf.org/id/draft-snell-merge-patch-02.txt From martin.thomson@gmail.com Fri Jun 8 12:02:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E886A11E8115 for ; Fri, 8 Jun 2012 12:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.329 X-Spam-Level: X-Spam-Status: No, score=-4.329 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kd3YOygrFJk for ; Fri, 8 Jun 2012 12:02:00 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42EB411E80F2 for ; Fri, 8 Jun 2012 12:01:44 -0700 (PDT) Received: by bkty8 with SMTP id y8so2395480bkt.31 for ; Fri, 08 Jun 2012 12:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h4n/Dxw+c0wBQVqWqy+M4hvFxyHxD+RLkiCZqI/faFA=; b=k7V45SsQ6qXxyzS92KOWTlH5Ry4DC/EgyuQpcZj4W3Ieo3SX7nJV4Pkt4bY6XFmSuQ GZC2PJsHOUwQV6+/tegxnXfTSEnpABUUNxB2lqeP2mkQv4j9UO6BjgYk5uCtmcBto0dU ED7WoEZaqzOMIOq1ixGPlqcMBaiJgH7dMxkT6BUoMWVB9HZJH6RMV6kk6kXASSTs7Icn Im7p/m0BQrY8TA5QIHQXDEBnYv9awoVZaEZ34hu+tfAQYsn3tQtRkPgSdQ5tU8zaQke+ lxJs++xgcmA9LgyO6fN3GzTmmV6BMvKua9UUlvgSPEgo2xcBLk78PRnWKP5yGDhtDy+z IqTQ== MIME-Version: 1.0 Received: by 10.204.152.73 with SMTP id f9mr6897511bkw.3.1339182103807; Fri, 08 Jun 2012 12:01:43 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Fri, 8 Jun 2012 12:01:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jun 2012 12:01:43 -0700 Message-ID: From: Martin Thomson To: Mike Kelly Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 19:02:01 -0000 On 6 June 2012 18:50, Mike Kelly wrote: > http://www.ietf.org/id/draft-kelly-json-hal-00.txt > > Feedback welcome.. Let's test that theory... I was initially inclined to call this an abomination, but that would require fairly strong substantiation. Let's just go with unnecessary. Some colleagues gave me an overview of an API that uses something very much like this. And aside from the initial aesthetic reaction, I have two complaints: - _links is almost useless - _embedded is an unnecessary optimization Let's first attack the concept of generic linking. It didn't work for XML. Reason: A user of a particular document needs to understand the semantics attached to a particular link in order to make sense of it and generic labels rarely work. For instance, I need to understand that a link labelled "fishCannery" leads to a resource that describes a fish cannery. The value added by _links is limited to signaling to a generic application that the value of "fishCannery" is not just a string, but a URI. In practice, none of the fields other than href are used. Now, the optimization. Well, mostly, it's just an optimization. The folks I was talking to who used it, used it because they wanted to save on HTTP requests (or they were using long polling and wanted to push multiple "events" at the same time). They had decomposed their application into resources, then discovered that it was a little slow when you want to pull multiple linked resources because it added round trips. There are better solutions; c.f. httpbis discussion on server push. In an HTTP context, embedding messes with caching, cannot be regarded as authoritative, and doesn't benefit from resource metadata. So, what's wrong with JSON? --Martin p.s. It should be application/+hal+json if you want to get super pedantic on media types, since hal is just another layer. c.f. the profile link relation type for a discussion on why a media type (or subtype marking) might be unnecessary. From mikekelly321@gmail.com Fri Jun 8 12:37:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0536611E80F6 for ; Fri, 8 Jun 2012 12:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clKjLEt4xfIz for ; Fri, 8 Jun 2012 12:37:13 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7195711E8120 for ; Fri, 8 Jun 2012 12:36:59 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so3584096obb.31 for ; Fri, 08 Jun 2012 12:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=a9B7/yFC0AjRRy1R5eKj+69B53tqlNOlJEXQRYRR5DM=; b=ReOVYpCso6CFcHaUMAHGKbV71Vzkpmo6v1prUsnljgxxxwl6siYcKFa3gAnvEDLFPD 8CGoYtzMnoVRFmQQJhp6BLVDgovnK7CSTfE9ewsnl793u9Fx979U/GEGFxXBOL5XplZf lWie9qFhn07TNL4aejUzQSV1aXeds7APEL7pspoZf/TC+fJke+h78y70rKiUTlfTTvm0 PUSJVqQ2jSOVLYYgUy5FsmpmiZYUBhxIEzneVOxEkKZ32f0/BkGEsJojH33rBA2lzD0r 6MlO1Hu2Nm7KiXsVobqX+jFRgzY3tDR46+6ySv1pAkIkErlQCPlPnSdO7BqRhx6IIWh2 KYww== MIME-Version: 1.0 Received: by 10.182.110.10 with SMTP id hw10mr8330664obb.61.1339184219092; Fri, 08 Jun 2012 12:36:59 -0700 (PDT) Received: by 10.60.28.195 with HTTP; Fri, 8 Jun 2012 12:36:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jun 2012 20:36:58 +0100 Message-ID: From: Mike Kelly To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 19:37:14 -0000 Hi Martin thanks for sharing your thoughts The spec is a WIP and you can read the latest version here: https://raw.github.com/mikekelly/hal-rfc/master/draft-kelly-json-hal-00.txt further comments inline On Fri, Jun 8, 2012 at 8:01 PM, Martin Thomson w= rote: > On 6 June 2012 18:50, Mike Kelly wrote: >> http://www.ietf.org/id/draft-kelly-json-hal-00.txt >> >> Feedback welcome.. > > Let's test that theory... > > I was initially inclined to call this an abomination, but that would > require fairly strong substantiation. =A0Let's just go with unnecessary. > > Some colleagues gave me an overview of an API that uses something very > much like this. =A0And aside from the initial aesthetic reaction, I have > two complaints: > > - _links is almost useless > - _embedded is an unnecessary optimization > > Let's first attack the concept of generic linking. =A0It didn't work for > XML. =A0Reason: A user of a particular document needs to understand the > semantics attached to a particular link in order to make sense of it > and generic labels rarely work. Technically, according to the Web Linking specification referenced a link relation type should either be registered with IANA or a URI. Exposing an HTML document describing the semantics of the link at its URI provides an avenue for making sense of a link that clearly can work. I've written a 'browser' for HAL which lets you surf a HAL API and allows you to pull up documentation as-you-go for relations that are URIs. > For instance, I need to understand that a link labelled "fishCannery" > leads to a resource that describes a fish cannery. =A0The value added by > _links is limited to signaling to a generic application that the value > of "fishCannery" is not just a string, but a URI. =A0In practice, none > of the fields other than href are used. There is value in that, it allows someone to build a generic link traversal DSL which you could then apply out of the box to your app like so: follow the "fishCannery" link and then query the "search" link setting "fish" equal to "tuna" > Now, the optimization. =A0Well, mostly, it's just an optimization. =A0The > folks I was talking to who used it, used it because they wanted to > save on HTTP requests (or they were using long polling and wanted to > push multiple "events" at the same time). =A0They had decomposed their > application into resources, then discovered that it was a little slow > when you want to pull multiple linked resources because it added round > trips. Yes, this is exactly the purpose of _embedded. They are parts of a representation that actually represent the state of some other, related, resource rather. Data URIs in links are another way to achieve something similar but (iirc) they have a size limit, and there is the obvious issue of human-readability. > There are better solutions; c.f. httpbis discussion on server > push. Don't know enough to comment, sounds dubious that HTTP can eliminate need for embedding. > In an HTTP context, embedding messes with caching, cannot be regarded > as authoritative, and doesn't benefit from resource metadata. > > So, what's wrong with JSON? It doesn't have these linking or embedding semantics. We have no standard to build re-usable libraries and tooling around, this is an attempt to establish a base standard without over-complicating the issue. > p.s. It should be application/+hal+json if > you want to get super pedantic on media types, since hal is just > another layer. =A0c.f. the profile link relation type for a discussion > on why a media type (or subtype marking) might be unnecessary. yes you could use a profile if you were so inclined. Personally, I am happy to rely on a preceding relation to provide the context/meaning of a given resource. I don't think this discussion is relevant here though. Cheers, Mike From martin.thomson@gmail.com Fri Jun 8 14:02:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A8711E80ED for ; Fri, 8 Jun 2012 14:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.304 X-Spam-Level: X-Spam-Status: No, score=-4.304 tagged_above=-999 required=5 tests=[AWL=-0.705, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPaFHlf5jgxc for ; Fri, 8 Jun 2012 14:02:50 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0C6A11E80E9 for ; Fri, 8 Jun 2012 14:02:49 -0700 (PDT) Received: by bkty8 with SMTP id y8so2479408bkt.31 for ; Fri, 08 Jun 2012 14:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=O7qumcdGq0S7XLXp0bZwngbDdElqM9+ft/C4KLff1EI=; b=jcsAw2ZARxsn5eaFrJxynfmT0mEtCyi0LF6ccNkQonNY9EAQdBYa4BEJqLuOmk5kHu criwt22JymQA14/qqmsQcdiEkobaeVyhK4CbMrmd4SX9fVzl+zpm3TRvslQOhSa4uf28 u2H1Em3+qpugHMjSBzMAt657EqxkIc7M4tr0nCxFfV2lKAi15sj2RfTkdc5/8oYwZCJV yWxh9FutbTYgpJXD6OQx01tw1Y+paUeB26LoPdME4HC78AR8n+xXo1kdddJEmy8aHdQl F2emKgYCNkk3j3L58qagyG9K0aPMfUtQ4k6gB11QxI6GUVPYLKL4Li3+C3vlLKmT5Wll CmTQ== MIME-Version: 1.0 Received: by 10.205.33.136 with SMTP id so8mr6809566bkb.1.1339189368929; Fri, 08 Jun 2012 14:02:48 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Fri, 8 Jun 2012 14:02:48 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jun 2012 14:02:48 -0700 Message-ID: From: Martin Thomson To: Mike Kelly Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 21:02:50 -0000 Hi Mike, As you can probably see, it's unlikely that I'll be a HAL customer. If I wanted this sort of stuff, I know how to use XML. That means that you can choose to assign appropriate weight to this feedback. On 8 June 2012 12:36, Mike Kelly wrote: > Technically, according to the Web Linking specification referenced a > link relation type should either be registered with IANA or a URI. > Exposing an HTML document describing the semantics of the link at its > URI provides an avenue for making sense of a link that clearly can > work. I've written a 'browser' for HAL which lets you surf a HAL API > and allows you to pull up documentation as-you-go for relations that > are URIs. No question, HAL let's you walk the graph, but it takes a human being to make any sense of anything. So, as I said, next to useless. > There is value in that, it allows someone to build a generic link > traversal DSL which you could then apply out of the box to your app > like so: > > follow the "fishCannery" link and then > =C2=A0query the "search" link setting "fish" equal to "tuna" How does your generic app know what value to put anywhere? Again, you rely on magic (the human ability to infer meaning based on context), or some content-specific markings with an application that understands those markings. I guess that I'm just attacking whole idea of self-describing formats. JSON aint one. That's a feature, not a drawback. > Yes, this is exactly the purpose of _embedded. They are parts of a > representation that actually represent the state of some other, > related, resource rather. Data URIs in links are another way to > achieve something similar but (iirc) they have a size limit, and there > is the obvious issue of human-readability. Using data: URIs has another drawback: you don't get to learn the http URI for the resource. > Don't know enough to comment, sounds dubious that HTTP can eliminate > need for embedding. Well, it's a real problem. And people want to solve it. Doing something at the HTTP layer makes sense. So Good For Them. I'd prefer not to see further codification of the problem. > It doesn't have these linking or embedding semantics. We have no > standard to build re-usable libraries and tooling around, this is an > attempt to establish a base standard without over-complicating the > issue. Yeah, one of the real advantages of JSON is that that crap doesn't exist. I know how that can be frustrating, but I tend to see that as a real strength of the format. I like being able to write: var turnip =3D JSON.parse(input); var genus =3D http.get(turnip.genus); return JSON.stringify(genus); ...without being burdened by a framework that is "helping" me. --Martin From GK@ninebynine.org Fri Jun 8 14:43:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1A511E81AD for ; Fri, 8 Jun 2012 14:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NjrZnZFzBWb for ; Fri, 8 Jun 2012 14:43:21 -0700 (PDT) Received: from relay1.mail.ox.ac.uk (relay1.mail.ox.ac.uk [129.67.1.165]) by ietfa.amsl.com (Postfix) with ESMTP id D254311E813C for ; Fri, 8 Jun 2012 14:43:20 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay1.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1Sd6xj-0004jh-4q; Fri, 08 Jun 2012 22:43:19 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Sd6xj-0006ba-4P; Fri, 08 Jun 2012 22:43:19 +0100 Message-ID: <4FD271F5.8070906@ninebynine.org> Date: Fri, 08 Jun 2012 22:43:17 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Mike Kelly References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 21:43:22 -0000 I'd be interested to hear how you think JSON-HAL compares with RDF in general (http://www.w3.org/standards/techs/rdf) and the JSON-LD encoding of RDF in particular (http://json-ld.org/spec/latest/json-ld-syntax/). My immediate reaction is that there's a lot of overlap, even reinvention, here. RDF has been in development for over 10 years, and there are now many and varied tools for working with it. #g -- On 07/06/2012 02:50, Mike Kelly wrote: > Hello, > > I've published a draft of a media type for linking with JSON, and > thought it might be of interest to people on this list > > http://www.ietf.org/id/draft-kelly-json-hal-00.txt > > Feedback welcome.. > > Best, > Mike > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From mikekelly321@gmail.com Fri Jun 8 14:55:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80CE21F8547 for ; Fri, 8 Jun 2012 14:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5ZoQIfmm1rm for ; Fri, 8 Jun 2012 14:55:15 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1893321F853F for ; Fri, 8 Jun 2012 14:55:15 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1922527ggn.31 for ; Fri, 08 Jun 2012 14:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=o3V+KscjStFNjQxjC6gK6kDoqVztMXGR8/DicpHT1SA=; b=hRTr6lq1VXLTbm2ds1cDodjgjS/8y+a1cNpSTFT5ypGBHOWmGoWs1HrCBgJx+/ySaA uEZagbMuY1WOZo70JLrHYYEBNcAuUEV1KMu3TeF4du1WY5q4sYBZR9bavEDq9Ah3/GGr 3tgWqMQzVkcKOutMZyjkkCsR7yqC941rgguPbbUFHfjL8kzt3PFY+f7r03h+rRh4S9r6 +HHPpwrm4qmoPvZYZ97HQp3vNGp0yBT2k1mBzAByaFx82KhurFf8JoCbOpRTMx9JDGV5 +/ljzHX3TG220Ip7wvnBCiKtdc9/Qs1D0okImSPC5ddv2UQ85uLm5OH1w2g9NMGzdTVB mvyw== MIME-Version: 1.0 Received: by 10.60.20.70 with SMTP id l6mr8863149oee.38.1339192514611; Fri, 08 Jun 2012 14:55:14 -0700 (PDT) Received: by 10.60.28.195 with HTTP; Fri, 8 Jun 2012 14:55:14 -0700 (PDT) In-Reply-To: <4FD271F5.8070906@ninebynine.org> References: <4FD271F5.8070906@ninebynine.org> Date: Fri, 8 Jun 2012 22:55:14 +0100 Message-ID: From: Mike Kelly To: Graham Klyne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 21:55:15 -0000 On Fri, Jun 8, 2012 at 10:43 PM, Graham Klyne wrote: > I'd be interested to hear how you think JSON-HAL compares with RDF in > general (http://www.w3.org/standards/techs/rdf) and the JSON-LD encoding = of > RDF in particular (http://json-ld.org/spec/latest/json-ld-syntax/). > > My immediate reaction is that there's a lot of overlap, even reinvention, > here. =A0RDF has been in development for over 10 years, and there are now= many > and varied tools for working with it. > The obvious difference is complexity, HAL is considerably more simple than JSON-LD; the HAL spec is tiny in comparison. HAL does no impose any graph model on the resource state, it's just plain JSON. The only triple'ish things in HAL are links and embeddings. Ian Davis actually produced a tool for converting RDF into HAL (with some loss), but I can't find the link and not even sure if it is still available. Cheers, M From dhc@dcrocker.net Fri Jun 8 17:51:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9944711E81C1 for ; Fri, 8 Jun 2012 17:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuhgo1Oh39wL for ; Fri, 8 Jun 2012 17:51:14 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E7BFE11E81C2 for ; Fri, 8 Jun 2012 17:51:14 -0700 (PDT) Received: from [192.168.8.23] (ip-64-134-241-130.public.wayport.net [64.134.241.130]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q590p8kf001462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Jun 2012 17:51:13 -0700 Message-ID: <4FD29DF5.5010206@dcrocker.net> Date: Sat, 09 Jun 2012 02:51:01 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ned Freed References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> In-Reply-To: <01OGEZDG0T8M000058@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 08 Jun 2012 17:51:14 -0700 (PDT) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 00:51:15 -0000 On 6/8/2012 4:24 AM, Ned Freed wrote: >> The justification for expert is "quality control". The side-effect >> is a disincentive to register. > > Er, not really. From a registrant's point of view the process is > essentially the same with or without expert review: Fill in a form, > submit it, wait for a response. Whether, that's not correct. The structure isn't even the same. When there is review, there is a sub-process that is absent from FCFS. That's a significant difference in form. > What matters is the *content* of the form and the *timliness* of the > response. Right. And since we don't to empty processes, the process entails dealing with that review, either by the potentially chilling effect of spending significant time trying to anticipate objections and respond to them, or in reactively responding to actual concerns of the reviewer. Hence, both the politics and the effort are substantially different. > And I'm not seeing overly onerous content requirements here. Of course not. You're an informed and reasonable guy. Not all reviewers are like that. And not all submitters know enough to anticipate the concerns of reviewers. So the > only factor is whether or not an expert can be found that can review > in a timely way. If that proves to be impossible then maybe FCFS > makes sense, but if not I'd prefer to see expert review remain. But this assumes a point I'm suggesting we consider carefully: Having the process of finding the reviewer and managing the review process isn't free. These are not like alternative routing algorithms: screwups have contained damage. That makes the cost/benefit tradeoff questionable. >> Do we make it easier and let in some cruft along with the good >> stuff or do we make it harder and keep out some good stuff because >> registering is too much hassle? > > In this particular case cruft has a potential negative consequence: > Someone looks at the registry and says "why doesn't your product > produce this state". And they may not like the response that the > state doesn't make a lick of sense. the word 'might' undermines the strength of this point. >> I think the latter is the better choice, because the cruft doesn't >> actually hurt anything and there's a very, very large namespace >> that can afford to be wasted. > >> As Barry notes, the actual 'threat' is quite small and the damage >> from its being realized is also negligible. > > The threat is indeed very small. Not so sure about the damage. I think the strategic media content threat is from bad media types, not bad registrations. By bad media types, I mean bad technologies that get into a position of market leverage. And we can't do anything about them. -- Dave Crocker Brandenburg InternetWorking bbiw.net From jasnell@gmail.com Fri Jun 8 18:04:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D1E11E80FE for ; Fri, 8 Jun 2012 18:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=1.236, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4z7PMUVnuAZx for ; Fri, 8 Jun 2012 18:04:53 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44FC111E80E2 for ; Fri, 8 Jun 2012 18:04:53 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so905025wib.13 for ; Fri, 08 Jun 2012 18:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=8IBLwuziz53Pmjb1G9m3U8IpPD4/1Q+lG233f+LE0nk=; b=OTtGD17lK9l2kLoVWs+x6+mMXfrvwG/NIn8rXKw6DPeXMP7wOmR4HHmLzAFUccIO+9 kWuPpFJMbnfyy91c4/IOdkyfkiFgGlG6s4SSc491Clo7LsrWjG82AWonYQxPVzAMPN/T 8mM2o2SBelKd8ujCCPjvo/IXL+jJmFFMAIG8YOWMt/rgye+ha3iSYWFlu36zyM3/0q3Y yxRz3S4VZeoQpuYcYi/RCfZpZlhjhjxBIeY6P+wuND6zHyemrIdDmPMZjSgo2BjHE5A8 /OGjFAln8aLR1OAS6XnkITrVz1phvHcKgOI+KERsmHmg1wJp6ww5H13q6/YgsO/1slzK yoZg== Received: by 10.180.102.36 with SMTP id fl4mr4501861wib.2.1339203892185; Fri, 08 Jun 2012 18:04:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.104.12 with HTTP; Fri, 8 Jun 2012 18:04:31 -0700 (PDT) In-Reply-To: References: From: James M Snell Date: Fri, 8 Jun 2012 18:04:31 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 01:04:55 -0000 On Fri, Jun 8, 2012 at 2:02 PM, Martin Thomson w= rote: >[snip] > On 8 June 2012 12:36, Mike Kelly wrote: >> Technically, according to the Web Linking specification referenced a >> link relation type should either be registered with IANA or a URI. >> Exposing an HTML document describing the semantics of the link at its >> URI provides an avenue for making sense of a link that clearly can >> work. I've written a 'browser' for HAL which lets you surf a HAL API >> and allows you to pull up documentation as-you-go for relations that >> are URIs. > > No question, HAL let's you walk the graph, but it takes a human being > to make any sense of anything. =C2=A0So, as I said, next to useless. >[snip] I think the most important consideration with this is: what will developers *actually* do with the additional metadata vs. what they *are able* to do. There is a distinct, and very practical difference. Within the Atom format, when we defined the structure of a generic link, we allowed for all kinds of additional metadata and that model served as part of the basis for RFC 5988. And while the structure allows for a great deal of potential use cases, the overall majority of ACTUAL code focus solely on two attributes: the rel and the href. Everything else tends to be ignored except in very specific application cases. It's great that we can enable specific cases, but we should not assume, necessarily, that a greater capacity for more metadata is always a good thing. Within the Activity Streams format (http://activitystrea.ms) there is also working going on to define a basic mechanism for links within a JSON Activity Stream. The mechanism I have proposed is very similar to that seen in HAL except that it skips the object structure for a link and just goes with Strings containing absolute IRI's. For example: { "totalItems": 10, "links": { "next": "http://example.org?page=3D2", "previous": "http://example.org?page=3D1" }, "items": [ ... ] } In this case, a developer is already going to have a reasonable assumption as to what kind of resource the next and previous links point to; and all the other metadata that is typically associated with the generic link model simply is not necessary. An application that understands how to process multi-paged activity streams following this convention is going to know already to go looking for the next and previous properties under link so there is no need at all (in this case) for a "generic browser". The code necessary to support an implementation of this is going to be very clear and concise. It comes down to a tradeoff. Either we have a focused, concise, efficient, minimal serialization that requires more application specific handling or we have a generic, verbose, less-efficient serialization that allows more generalized reasoning and browsing. There are valid arguments for both, for certain, but I can see many scenarios where HAL will just be way too verbose to be practical. - James From mikekelly321@gmail.com Sat Jun 9 00:55:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A82621F85B5 for ; Sat, 9 Jun 2012 00:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmeXzjbJqvZM for ; Sat, 9 Jun 2012 00:55:43 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3049621F85B4 for ; Sat, 9 Jun 2012 00:55:27 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4714242obb.31 for ; Sat, 09 Jun 2012 00:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b3MV3dCTGuxJGBk2PsoxDccUF5zBsKDsV0cjsnfzGR4=; b=iuiH1f0Z4A2rqdZ68jApW6Awbsk05YKTRxmaGepDOTAZaDIdcBABvETobYxI4sqcuS dw5USJ5kNSed6kFByir9YVX8mkEoNCFJD1hsvzAVVobimkr4Bh1zrn0PSq+4mKV8etAe GCXOqlTL3wz7bbetfWXM5YLBdKBsPtHWjvgnTASMcoQtt2iRymml24nmHfLqQmPxlHw5 cnwBU0/vOQmOOMJLXd2CA80Y16mzPO8EiIy9bYMQ6IfmtymkjVby0v2hfvnlydr8zf3Q QcBTrzXFWoQDLOhzbBQpsC7agCC87xPrBcptBpi936WJLD5/pKvZxH/CP3fqYG3fCfyn 5EIA== MIME-Version: 1.0 Received: by 10.60.30.101 with SMTP id r5mr9840757oeh.68.1339228526761; Sat, 09 Jun 2012 00:55:26 -0700 (PDT) Received: by 10.60.28.195 with HTTP; Sat, 9 Jun 2012 00:55:26 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Jun 2012 08:55:26 +0100 Message-ID: From: Mike Kelly To: James M Snell Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 07:55:44 -0000 On Sat, Jun 9, 2012 at 2:04 AM, James M Snell wrote: > HAL will just be way too verbose to be practical. I think 'way too verbose' is overstating the importance of this. You are the first person to raise this as an issue at all, let alone as a significant one. Link Objects are necessary to allow for the "templated" indicator (for when the link is a URI Template), for including the additional link params established in the Web Linking RFC, and to provide the opportunity for extension of link objects in any future types wanting to extend HAL e.g. by adding additional controls or hints. Fwiw, I did actually consider also adding a direct string as you have suggested here but decided against in the interests of simplicity/consistency, given that the Link Object approach is unavoidable (for the reasons stated above). On another note - HAL has been established for a while now (as a less formal, public specification) and has a growing list of server and client tooling, seems to me like it would be a win for Activity Streams to adopt HAL's already established conventions, given that your recent new proposal is so close to it anyway. Cheers, M From hub.ryck@gmail.com Sat Jun 9 01:33:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9757321F8602 for ; Sat, 9 Jun 2012 01:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFTPU1Qsw61o for ; Sat, 9 Jun 2012 01:33:46 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 56F2821F85C5 for ; Sat, 9 Jun 2012 01:33:36 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3493955pbc.31 for ; Sat, 09 Jun 2012 01:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G0q0K6dKfuWErVT6U8HTrJrseTvrK2U4SSESLVQlWAc=; b=GMKnKAHLBkWohuj7zlpfT5C8ZRd695nTq+dWk8Ves4SZytKebZsYaHlNwVhGG6B+Cn +ET5tEvKF7Vae9XpXdRRcCYkLfSi7IFV1nxkKBTZrPTxfggIbOfdYovuwS6+PJjXyoCW OwQOs/ejQrF9TiWGkJylMsVgjOv7tEIKAdx7SakKBocGHtAQXkrkcCyKmcmP7VTqola8 iExOhmg9ZBEwM22rLGdpE5OOmNjuyNoj5qi/AvuOKn0nFHUDRJEkZI092mnSHk7pQA8j BfjpOVXkycjhl+Kprv2HLI7g2bWr+2nCjHJC3hfcXN/EW3Z7W4oS0wpwGk/Cc4eG2+Vk GKEw== MIME-Version: 1.0 Received: by 10.68.221.132 with SMTP id qe4mr3762796pbc.128.1339230816140; Sat, 09 Jun 2012 01:33:36 -0700 (PDT) Received: by 10.68.16.104 with HTTP; Sat, 9 Jun 2012 01:33:36 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20120421143240.07253358@elandnews.com> <6.2.5.6.2.20120429134847.08f02068@resistor.net> Date: Sat, 9 Jun 2012 10:33:36 +0200 Message-ID: From: hub ryck To: Barry Leiba Content-Type: multipart/alternative; boundary=e89a8ff251f0117b7e04c205f9cf Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-hryckelynck-writing-rfcs-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 08:33:46 -0000 --e89a8ff251f0117b7e04c205f9cf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Barry, Thank you for the information. As requested I : - changed the name to =3D> draft-hryckelynck-mail- > > accepted-previous-sending > - posted a new version > - asked action@ietf.org, to note it in the tracker > > Hubert Barry Leiba barryleiba@computer.org > > 17 mai (Il y a 2 jours) > > =E0 moi, apps-discuss > > Traduire le message > D=E9sactiver pour : anglais > Addressing only one question: > > > > 2012/5/17 Barry Leiba > >> Addressing only one question: >> >> >> You might wish to choose a different filename for the draft as the >> >> "writing-rfcs" does not say much about the subject of the draft. >> > >> > I did a mistake when I posted the first version. I wanted to change th= e >> name >> > but I don't know how. The problem is, when I post a new version, if I >> change >> > the name how the site will related it to the previous version ? >> >> Post a -00 version with the new name, then send email to >> action@ietf.org, asking them to note in the tracker that >> draft-hryckelynck-new-name replaces draft-hryckelynck-writing-rfcs. >> >> Barry >> > > --e89a8ff251f0117b7e04c205f9cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Barry,

Thank you for the information. As requested I :

= - changed the name to =3D> draft-hryckelynck-mail-
accepted-previous-sending
- posted a new version
- asked = action@ietf.org, t= o note it in the tracker

Hubert

Barry Leiba barryleiba@computer.org
=A0=A0=A0
17 mai (Il y a 2 jours)
=A0=A0=A0 =A0=A0=A0
=E0 moi, a= pps-discuss
=A0=A0
Traduire le message
D=E9sactiver pour : anglai= s
Addressing only one question:


2012/5/17 Barry Leiba &l= t;barryleiba@c= omputer.org>
Addressing only one question:

>> You might wish to choose a different filename for the draft as the=
>> "writing-rfcs" does not say much about the subject of th= e draft.
>
> I did a mistake when I posted the first version. I wanted to change th= e name
> but I don't know how. The problem is, when I post a new version, i= f I change
> the name how the site will related it to the previous version ?

Post a -00 version with the new name, then send email to
action@ietf.org, a= sking them to note in the tracker that
draft-hryckelynck-new-name replaces draft-hryckelynck-writing-rfcs.

Barry



--e89a8ff251f0117b7e04c205f9cf-- From barryleiba.mailing.lists@gmail.com Sat Jun 9 01:52:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF60D21F89DA for ; Sat, 9 Jun 2012 01:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2OHIGrpTAQ8 for ; Sat, 9 Jun 2012 01:52:10 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C47B121F89D9 for ; Sat, 9 Jun 2012 01:52:09 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2644815lbb.31 for ; Sat, 09 Jun 2012 01:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wn+zDoyxwV9xKoxs/ZyGeO0wPAymMLEilAAHLis0nKY=; b=hSg0Yb0iwTUgvEElkyVyU4qeY2Cea9PpkAY2JrtvVxgrm8wqrQcINnLJbuoifG6IcI NIzIVX7g8LBYtptjGJfnjUMlmCSDFbZ3ZQ/89rUieFvbEa6bG+o+AL3N0HbfKEL5dhss /I7PDFAHX1dt8gxiWzqUcOgwpdIAdhlHoavdHUsMoYIww+UEJ2Sepvx3Om07CFD9KNX/ FKTBiXZgK5LQfvbUk0C++nHcouwZDfvzjyT7zh16VxY+TENgMyEhA8R7hraviP+36ZkC kH1Dm64ak7LPeIiSOpi1p2xSb/WMoEsyTY+7llaL+Rp+wXLMOAgfwM5f4Rbq0uqlc2FE sHmQ== MIME-Version: 1.0 Received: by 10.152.108.144 with SMTP id hk16mr11147939lab.2.1339231928784; Sat, 09 Jun 2012 01:52:08 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Sat, 9 Jun 2012 01:52:08 -0700 (PDT) In-Reply-To: <4FD29DF5.5010206@dcrocker.net> References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> Date: Sat, 9 Jun 2012 04:52:08 -0400 X-Google-Sender-Auth: knVqVpRJcCHLtg52pDtjLAacVXY Message-ID: From: Barry Leiba To: "dcrocker@bbiw.net" Content-Type: multipart/alternative; boundary=bcaec54d4dd66315b704c2063b4e Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 08:52:10 -0000 --bcaec54d4dd66315b704c2063b4e Content-Type: text/plain; charset=ISO-8859-1 > I think the strategic media content threat is from bad media types, not bad > registrations. By bad media types, I mean bad technologies that get into a > position of market leverage. And we can't do anything about them. Exactly, and that's my point: having the registrations is the important point. Not allowing registrations is not likely to prevent usage. If someone wants to start using a silly, ill-advised status code, with a poor definition, they can and will do so whether we allow them to register it or not. If it's really stupid, it won't get any uptake. If it catches on, we should have registered it. I think that we need to use more FCFS registrations, in general, and not have to have a designated expert (or worse, write new RFCs) for every registration in every registry. For some it absolutely makes sense. For media types, it's often hard to get the details right, and the expert review helps people along with that. I don't think it makes sense for this particular one. Barry --bcaec54d4dd66315b704c2063b4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> I think the strategic media content threat is from bad media types= , not bad
> registrations. =A0By bad media types,= I mean bad technologies that get into a
> position of market leverage. =A0And we can't do anything about= them.

Exactly, and that's my point: having the registrati= ons is the important point. =A0Not allowing registrations is not likely to = prevent usage. =A0If someone wants to start using a silly, ill-advised stat= us code, with a poor definition, they can and will do so whether we allow t= hem to register it or not. =A0If it's really stupid, it won't get a= ny uptake. If it catches on, we should have registered it.

I think that we need to use more FCFS registrations, in= general, and not have to have a designated expert (or worse, write new RFC= s) for every registration in every registry. =A0For some it absolutely make= s sense. =A0For media types, it's often hard to get the details right, = and the expert review helps people along with that. =A0I don't think it= makes sense for this particular one.

Barry
=
--bcaec54d4dd66315b704c2063b4e-- From ned.freed@mrochek.com Sat Jun 9 01:57:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932BD21F89E0 for ; Sat, 9 Jun 2012 01:57:19 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usszNT3CvDSz for ; Sat, 9 Jun 2012 01:57:19 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 947B621F89DF for ; Sat, 9 Jun 2012 01:57:16 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGGQW1UJLC00304I@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 9 Jun 2012 01:57:05 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGBNHXOPCG000058@mauve.mrochek.com>; Sat, 9 Jun 2012 01:56:49 -0700 (PDT) Message-id: <01OGGQVX62JC000058@mauve.mrochek.com> Date: Sat, 09 Jun 2012 01:44:16 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 09 Jun 2012 02:51:01 +0200" <4FD29DF5.5010206@dcrocker.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> To: Dave Crocker Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 08:57:19 -0000 > On 6/8/2012 4:24 AM, Ned Freed wrote: > >> The justification for expert is "quality control". The side-effect > >> is a disincentive to register. > > > > Er, not really. From a registrant's point of view the process is > > essentially the same with or without expert review: Fill in a form, > > submit it, wait for a response. > Whether, that's not correct. The structure isn't even the same. > When there is review, there is a sub-process that is absent from FCFS. > That's a significant difference in form. Again, this isn't as apparent as you seem to think. > > What matters is the *content* of the form and the *timliness* of the > > response. > Right. And since we don't to empty processes, the process entails > dealing with that review, either by the potentially chilling effect of > spending significant time trying to anticipate objections and respond to > them, or in reactively responding to actual concerns of the reviewer. > Hence, both the politics and the effort are substantially different. The evidence says otherwise. For example, the private SNMP MIB registration used to be FCFS (and apparently no longer exists), yet we struggled mightily to figure out how to do it. Port numbers, OTOH, were a snap, even though they involve expert review. > > And I'm not seeing overly onerous content requirements here. > Of course not. You're an informed and reasonable guy. Not all > reviewers are like that. And not all submitters know enough to > anticipate the concerns of reviewers. Fair point. There is always a chance of the reviewer being unreasonable. > So the > > only factor is whether or not an expert can be found that can review > > in a timely way. If that proves to be impossible then maybe FCFS > > makes sense, but if not I'd prefer to see expert review remain. > But this assumes a point I'm suggesting we consider carefully: Having > the process of finding the reviewer and managing the review process > isn't free. These are not like alternative routing algorithms: > screwups have contained damage. That makes the cost/benefit tradeoff > questionable. I think the number of these is certain to be very small so the cost will be low. > >> Do we make it easier and let in some cruft along with the good > >> stuff or do we make it harder and keep out some good stuff because > >> registering is too much hassle? > > > > In this particular case cruft has a potential negative consequence: > > Someone looks at the registry and says "why doesn't your product > > produce this state". And they may not like the response that the > > state doesn't make a lick of sense. > the word 'might' undermines the strength of this point. The claim that "The reviewwer might be slow or unreasonable." has similar issues. > >> I think the latter is the better choice, because the cruft doesn't > >> actually hurt anything and there's a very, very large namespace > >> that can afford to be wasted. > > > >> As Barry notes, the actual 'threat' is quite small and the damage > >> from its being realized is also negligible. > > > > The threat is indeed very small. Not so sure about the damage. > I think the strategic media content threat is from bad media types, not > bad registrations. By bad media types, I mean bad technologies that get > into a position of market leverage. And we can't do anything about them. I wasn't talking about media types. Ned From ned.freed@mrochek.com Sat Jun 9 02:35:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24D321F89D8 for ; Sat, 9 Jun 2012 02:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QOBppijIPrB for ; Sat, 9 Jun 2012 02:35:30 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6515821F89D6 for ; Sat, 9 Jun 2012 02:35:28 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGGS8CIAB4003DMZ@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 9 Jun 2012 02:35:06 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGBNHXOPCG000058@mauve.mrochek.com>; Sat, 9 Jun 2012 02:34:58 -0700 (PDT) Message-id: <01OGGS87OI0Q000058@mauve.mrochek.com> Date: Sat, 09 Jun 2012 02:33:23 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 09 Jun 2012 04:52:08 -0400" MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> To: Barry Leiba Cc: Ned Freed , "dcrocker@bbiw.net" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 09:35:30 -0000 > > I think the strategic media content threat is from bad media types, not > bad > > registrations. By bad media types, I mean bad technologies that get into > a > > position of market leverage. And we can't do anything about them. > Exactly, and that's my point: having the registrations is the important > point. Not allowing registrations is not likely to prevent usage. If > someone wants to start using a silly, ill-advised status code, with a poor > definition, they can and will do so whether we allow them to register it or > not. If it's really stupid, it won't get any uptake. If it catches on, we > should have registered it. > I think that we need to use more FCFS registrations, in general, and not > have to have a designated expert (or worse, write new RFCs) for every > registration in every registry. For some it absolutely makes sense. For > media types, it's often hard to get the details right, and the expert > review helps people along with that. I don't think it makes sense for this > particular one. As I said before, if the consensus is for FCFS, I'm willing to go along since the number of this is likely to be small and so is the risk. Ned From jpalme@dsv.su.se Sat Jun 9 03:30:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61DE21F866C for ; Sat, 9 Jun 2012 03:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.666 X-Spam-Level: X-Spam-Status: No, score=0.666 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lv0gJRUYAzdI for ; Sat, 9 Jun 2012 03:30:06 -0700 (PDT) Received: from smtprelay-b12.telenor.se (smtprelay-b12.telenor.se [62.127.194.21]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBC521F8669 for ; Sat, 9 Jun 2012 03:30:05 -0700 (PDT) Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-b12.telenor.se (Postfix) with ESMTP id 0BBE0D11D for ; Sat, 9 Jun 2012 12:30:04 +0200 (CEST) X-SENDER-IP: [85.224.107.178] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMbAGIk009V4GuyOWdsb2JhbAANOLRtBAEBAQEgF4JIBAEBAQEDOg8FIwgQCxIGFQkFCzESBg4ZGgMEhShIgWO4SIsnCw+CKIMnA49YkEeHXIFUAQQCAg X-IronPort-AV: E=Sophos;i="4.77,381,1336341600"; d="scan'208";a="136461272" Received: from c-b26be055.022-17-73746f16.cust.bredbandsbolaget.se (HELO [192.168.0.101]) ([85.224.107.178]) by ipb3.telenor.se with ESMTP; 09 Jun 2012 12:30:01 +0200 Mime-Version: 1.0 Message-Id: In-Reply-To: <1338941672.9269273@apps.rackspace.com> References: <1338941672.9269273@apps.rackspace.com> Date: Sat, 9 Jun 2012 12:18:29 +0200 To: apps-discuss@ietf.org From: Jacob Palme Content-Type: text/plain; charset="us-ascii" Cc: isoc-members-announce@elists.isoc.org Subject: Re: [apps-discuss] [ISOC] NEWS RELEASE: World IPv6 Launch Unites Industry Leaders to Redefine the Global Internet X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 10:30:07 -0000 What happens if (a) I have an IPV4 IP-address, and send a mail to someone who has an IPV6 IP-address. And that someone replies to my mail. Will the mails reach their recipients? Or the reverse, (b) I have an IPV6 IP-address, and send a mail to someone who has an IPV4 IP-address. And that someone replies to my mail. Will the mails reach their recipients? Also if my SMTP server uses IPV4, or uses IPV6, and my correspondents SMTP sever uses IPv4, or uses IPV6. Also if my POP or IMAC server uses IPV4, or uses IPV6, and my correspondents POP or IMAC server uses IPV4 or IPV6. What happens if I have an IPV4 address and send an HTTP request to Google, will Google reply as if had an IPV6 address? And if I have an old-style IPV4 web browser, will I then not be able to see Google's response? I am using Eudora 6.2.4 (2006) copyright QUALCOMM, will I not be able to send and receive e-mail in the future, unless I switch to a newer, IPV6 aware mail client? I am also using a Spamfire Spam filter, vesiron 1.6.2 anno 2003 Matterform Media, which I assume has never heard of IPV6. Will my spam filter and all the many hundreds of spam recognition commands which I have stored for Spamfire, stop working when my POP server switches to IPV6, stop working? Spamfire is not any more supported by its ceator Matterform, who made a much less competent version 2 of Spamfire, which I refused to switch to. Or will all the world's servers support both IPV4 or IPV6 depending on the protocol of the clients which access them? If so, what is meant when "Google, Facebook, YouTube, and Yahoo!" will permanently enable IPV6? Do I have to throw away all computers and mobile phones and replace them with IPV6 versions? Or does it only mean that they will use IPV6 if accessed by someone who has an IPV6 client? I am using an internet service provider, who gives me an IP number using DHPC when I connect to it. Will my internet service provider in the future (when?) give me IPV6 addresses using DHCP? Does this mean that I have to replace all internet client software on all my computers with IPV6 enabled client software? I am sure that hardware and software vendors will wrap their hands in pleasure of having to sell replacement for all the world's hardware and software. I am accustomed to them using other methods to force me to buy new hardware and software every three or every five years or so. Assume a library where all the pages of all the books turn blank after three years. That is the way, which the computer world works. Will the switch to IPV6 be another way of making book pages go blank? And then allow a few selected books be readable again if I buy new hardware and software? At 20.14 -0400 12-06-05, cover@isoc.org wrote: >World IPv6 Launch Unites Industry Leaders to Redefine the Global Internet > >As leading websites, ISPs, and home router equipment manufacturers support IPv6 by default, it becomes the new normal for the Internet > >[WASHINGTON, D.C. and GENEVA, Switzerland, -- 5 June 2012] - To ensure the Internet can continue to grow and connect billions more people and devices around the world, thousands of companies and millions of websites have now permanently enabled the next generation of Internet Protocol (IPv6) for their products and services. Participants in World IPv6 Launch include the four most visited websites in the world - Google, Facebook, YouTube, and Yahoo! - as well as home router manufacturers and Internet Service Providers in more than 100 countries. By making IPv6 the "new normal," these companies are enabling millions of end users to enjoy its benefits without having to do anything themselves. > >World IPv6 Launch is organized by the Internet Society as part of its mission to ensure that the Internet remains open and accessible for everyone - including the other five billion people not yet connected to the Internet. "The support of IPv6 from these thousands of organizations delivers a critical message to the world: IPv6 is not just a 'nice to have'; it is ready for business today and will very soon be a 'must have,'" said Leslie Daigle, Chief Internet Technology Officer, Internet Society. "We believe that the commitment of these companies to deploy IPv6 will ensure that they remain industry leaders. Any company wishing to be effective in the new Internet should do the same." > >The World IPv6 Day in 2011 was a 24-hour test that focused on websites. This year, World IPv6 Launch is a permanent commitment across the Internet industry, including ISPs and home networking equipment manufacturers around the world, laying the foundation to accelerate the deployment of IPv6 across the global Internet. Major websites are permanently enabling IPv6 starting 6 June 2012 at 0000 UTC on their main websites. ISPs will permanently enable IPv6 across a significant portion of their current and all new residential wireline subscribers. Home networking equipment manufacturers will enable IPv6 by default through their range of home router products, and recent commitments to IPv6 by companies beyond websites demonstrates a broader support of the new Internet Protocol. > >This is imperative as the last blocks of the 4.3 billion IP addresses enabled by the current Internet Protocol (IPv4) were assigned to the Regional Internet Registries in February 2011. Already there is no remaining IPv4 address space to be distributed in the Asia Pacific region, and very soon the rest of the globe will follow. IPv4 address space is expected to run out in Europe this year, in the U.S. next year, and in Latin America and Africa in 2014. IPv6 provides more than 340 trillion, trillion, trillion addresses (an essentially unlimited number), which will help connect the billions of people that are not connected today, allow a wide range of devices to connect directly with one another, and help ensure the Internet can continue its current growth rate indefinitely. > >For more information about World IPv6 Launch and the participating companies, as well as links to useful information for users and how other companies can participate in the continued deployment of IPv6, visit: http://www.worldipv6launch.org > >About the need for IPv6 >IPv4 has approximately four billion IP addresses (the sequence of numbers assigned to each Internet-connected device). The explosion in the number of people, devices, and web services on the Internet means that IPv4 is running out of space. IPv6, the next-generation Internet protocol which provides more than 340 trillion, trillion, trillion addresses, will connect the billions of people not connected today and will help ensure the Internet can continue its current growth rate indefinitely. > >About the Internet Society >The Internet Society is the trusted independent source for Internet information and thought leadership from around the world. With its principled vision and substantial technological foundation, the Internet Society promotes open dialogue on Internet policy, technology, and future development among users, companies, governments, and other organizations. Working with its members and Chapters around the world, the Internet Society enables the continued evolution and growth of the Internet for everyone. For more information, visit www.internetsociety.org. > > >Supporting Quotes from World IPv6 Launch Participants: > >Akamai >"IPv6 is critical to the future of the Internet's underlying architecture, and to supporting the billions of devices that will connect to the Internet over the coming years," said Tom Leighton, chief scientist and co-founder, Akamai. "Having expanded our global IPv6 footprint to over 50 countries, Akamai enables Web sites to reach a growing audience over IPv6 with the performance and reliability that they have come to expect, and demand, from IPv4. We applaud the work of The Internet Society and so many of today's businesses that have prepared for this important transition - ensuring the Internet remains a robust, collaborative, and infinitely accessible platform." > >AT&T >"With ubiquitous IP connectivity becoming a reality, IPv6 is critical to ensuring applications and services can reach users anywhere they live and work. AT&T has been a leader in the transition to IPv6 for many years, and we're excited to participate in World IPv6 Launch by enabling IPv6 by default for nearly one million of our broadband subscribers and dual-stack enabling our enterprise, consumer, and corporate websites and portals." Krish Prabhu, President of AT&T Labs and Chief Technology Officer for AT&T > >Bing for Microsoft >"World IPv6 Launch is a significant milestone in achieving the next generation of the Internet, and Bing is proud to have worked alongside so many dedicated industry leaders to make this day possible," said Derrick Connell, corporate vice president of Bing for Microsoft. "All of us at Microsoft who have worked together with our industry partners to make World IPv6 Launch a reality look forward to advancing our work and support as IPv6 becomes adopted on a broader scale." > >Cisco >Cisco SVP Engineering and General Manager Service Provider Business, Pankaj Patel, says, "The Internet has fueled remarkable economic growth and innovation that would have never happened without a network. Today, we face an explosion of connected devices moving data and content, especially video, and of applications and services coming from the Cloud. IPv6 enables the network -- the platform on which innovation is built -- to scale and make more growth more possible, today and into the future." > >Comcast >"We at Comcast take great pride in being an innovator and technical leader. As a result of our team's hard work, enabling IPv6 in over a third of our network, I am happy to report that by today we have exceeded our goal of 1% of our customer base being enabled with IPv6 for World IPv6 Launch! Thank you to the Internet Society and others for organizing and participating in this important event!" - John Schanz, Chief Network Officer, Comcast > >Facebook >"As more and more people and devices connect to the web, supporting IPv6 has become crucial to the future scalability of the Internet," said Jay Parikh, Vice President of Infrastructure at Facebook. "It's awesome to see so many people and companies working together across the world to make progress on this transition." > >Google >"IPv6 is key to preserving the health and openness of the Internet for decades to come," said Stephen Stuart, Distinguished Engineer at Google. "We're proud to be one of the founding participants in World IPv6 Launch, and we look forward to the day when IPv6 is available to Internet users everywhere." > >Internode >"At Internode we are already using IPv6 (Internet Protocol version 6) to deliver Internet access to more than two per cent of our customers. During the past five years, Internode has acquired a great deal of understanding from deploying IPv6 on our national and international broadband networks, thereby providing a risk-free pathway for our customers when they use IPv6 and it is now ready for prime time," said Internode founder and managing director Simon Hackett. "The most important lesson for Internode is that done right, customers will not even notice the change to IPv6. Internode commends the World IPv6 Launch as the time that website publishers, other Internet Service Providers and all companies manufacturing equipment for Internet access should also enable IPv6 access by default." > >Yahoo! >"Yahoo! is proud to be part of this historic effort to transition to the next generation Internet Protocol. Together, we are helping ensure the long-term health and growth of the Internet, which has become a critical part of people's lives around the globe." - Jason Fesler, Distinguished Architect and IPv6 Evangelist, Yahoo! > > >_______________________________________________ >To manage your ISOC subscriptions or unsubscribe, >please log into the ISOC Member Portal: >https://portal.isoc.org/ >Then choose Interests & Subscriptions from the My Account menu. -- Jacob Palme , university professor emeritus for more info see URL: http://www.dsv.su.se/jpalme/ From msimoni@gmail.com Sat Jun 9 04:00:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1402621F87CB for ; Sat, 9 Jun 2012 04:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzwI5Ow+cvhz for ; Sat, 9 Jun 2012 04:00:04 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 77D2421F87C7 for ; Sat, 9 Jun 2012 04:00:04 -0700 (PDT) Received: by qadz3 with SMTP id z3so1158152qad.10 for ; Sat, 09 Jun 2012 04:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wqO2TkmBcxtt5dUE7MXtTdQJNdOBlh/PC6aQ/fsecR4=; b=ix9HS+quFtATufsYrcrAIMyUuEdt7kQXRHSzIl6tGzcss7wWuR9DXWA19bCik7rH0E O4AspUC4iwk/ymBJu0uqC/r6axr9CDJz6r9x/2orDww6lfYswaw9kH3qWs9UrBOx8x47 W1HE+R5xdBETFm4j4PWkT2uM1p2aH7tZAb0mhKYseO7Wx9rhhcwOBc5XD8A8cb+H0oji dXf87Y/eDX3c9FPDKeJDhfslx7jv8VTs+skpIqRCfs94K18L6r3Z8MZYTVuwt11vH8er XcBqO/LM6Urus3xP2/EPqO127iG4dgexCQotv5BLdQ+DuI6zQ6DnGewMVwkPwloTHhRp gI7w== MIME-Version: 1.0 Received: by 10.224.183.17 with SMTP id ce17mr2145925qab.8.1339239603968; Sat, 09 Jun 2012 04:00:03 -0700 (PDT) Received: by 10.229.191.68 with HTTP; Sat, 9 Jun 2012 04:00:03 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Jun 2012 13:00:03 +0200 Message-ID: From: Manuel Simoni To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 11:00:05 -0000 On Fri, Jun 8, 2012 at 9:01 PM, Martin Thomson w= rote: > On 6 June 2012 18:50, Mike Kelly wrote: >> http://www.ietf.org/id/draft-kelly-json-hal-00.txt >> >> Feedback welcome.. > > Let's test that theory... > > I was initially inclined to call this an abomination, but that would > require fairly strong substantiation. =A0Let's just go with unnecessary. > > Some colleagues gave me an overview of an API that uses something very > much like this. =A0And aside from the initial aesthetic reaction, I have > two complaints: > > - _links is almost useless > - _embedded is an unnecessary optimization Disagree vehemently on the first point. Generic links in JSON are as useful as generic links in HTML. I agree on the second point. _embedded turns the specification from a generic linking thing into a quite specific application profile. Maybe there should be two specifications, one for _links, and one for _embedded? Manuel Simoni From mikekelly321@gmail.com Sat Jun 9 04:05:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2720C21F8781 for ; Sat, 9 Jun 2012 04:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKxOxzggEr9v for ; Sat, 9 Jun 2012 04:05:40 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7514821F8780 for ; Sat, 9 Jun 2012 04:05:40 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so5073816obb.31 for ; Sat, 09 Jun 2012 04:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lvmc0s1GnTP10b4ZrpwQd2khz+snEl5m81RV8AhygpQ=; b=VRVjXwlEucgmnEdPFkTQH3kI1/5pqawNlc903K95TKCPVI//XXGRKA6y9pUspyJZ6e AKUXz0mvyBzTag8KCvKoDWb0k/ykW4LO1N1fsCkIR/ywdLWq87ppwBxpiQkCJe+hEj6n mcW0vVR84AjXOFyPTgACwX4FMUN2CeYTt7AXofaR1qMsi+OFhRm2WfjP6Gande1No1uK RBbmau8K/rLcpQhQ5dhNCIDH33/nBCEHJAgoAnT4G7S56d17OWG04VCbxe4zqjmEGcWP eUne8ecK1emAGombR5+g+BO/n6lsuxhTVGIxXUnZHM2LjPFt0v2jRjtQ5Ij8EvUBEanP hKWw== MIME-Version: 1.0 Received: by 10.182.151.113 with SMTP id up17mr10298041obb.40.1339239940035; Sat, 09 Jun 2012 04:05:40 -0700 (PDT) Received: by 10.60.28.195 with HTTP; Sat, 9 Jun 2012 04:05:39 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Jun 2012 12:05:39 +0100 Message-ID: From: Mike Kelly To: Manuel Simoni Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 11:05:41 -0000 On Sat, Jun 9, 2012 at 12:00 PM, Manuel Simoni wrote: > On Fri, Jun 8, 2012 at 9:01 PM, Martin Thomson = wrote: >> On 6 June 2012 18:50, Mike Kelly wrote: >>> http://www.ietf.org/id/draft-kelly-json-hal-00.txt >>> >>> Feedback welcome.. >> >> Let's test that theory... >> >> I was initially inclined to call this an abomination, but that would >> require fairly strong substantiation. =A0Let's just go with unnecessary. >> >> Some colleagues gave me an overview of an API that uses something very >> much like this. =A0And aside from the initial aesthetic reaction, I have >> two complaints: >> >> - _links is almost useless >> - _embedded is an unnecessary optimization > > Disagree vehemently on the first point. Generic links in JSON are as > useful as generic links in HTML. > > I agree on the second point. _embedded turns the specification from a > generic linking thing into a quite specific application profile. Hi Manuel, Embedded representations is a very common approach for reducing HTTP requests in applications, and it is a form of hypertext so I think it belongs in HAL. Cheers, M From barryleiba.mailing.lists@gmail.com Sat Jun 9 07:50:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95FC21F8691 for ; Sat, 9 Jun 2012 07:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEMKD9N6Iumy for ; Sat, 9 Jun 2012 07:50:23 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6F421F868A for ; Sat, 9 Jun 2012 07:50:22 -0700 (PDT) Received: by lagv3 with SMTP id v3so2777205lag.31 for ; Sat, 09 Jun 2012 07:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Gp/gkJ6XbRBVJlyeGxTgF3Heqx2FiSlFBXRkT/e6l8k=; b=wPd6/OVzmyJ8/dZ8NVVpirYCgHtTJmBdv7vhitzEABcf8tZoCqlSYl9MSOQGHXezGt D/TLV+8sv317793r7ehZswUscbVcsyB+NfwU0MZm7UV5wrPvmBkq8udGd61LbLI32OnG cu/2NmHjJxLXcSwsyjlUasBTNfmBxxkH2YGyXVmUGdQzjUevnXo3h1kCEZxUvstpYq+j i3qeDzipDtULcBpVkho8A7tknSGA+5Q2lRfVAVQ7zf+ho3g4+biDp6DO6X7YfXK4cnok fgqXwwmVdis1wL++qwVsTwBNOo3q/SO6RQsacUUGorKHJOjRSYwKoOHNj2S+XSXi/iaz Zodg== MIME-Version: 1.0 Received: by 10.112.26.131 with SMTP id l3mr877643lbg.80.1339253421747; Sat, 09 Jun 2012 07:50:21 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Sat, 9 Jun 2012 07:50:21 -0700 (PDT) In-Reply-To: <01OGGS87OI0Q000058@mauve.mrochek.com> References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> <01OGGS87OI0Q000058@mauve.mrochek.com> Date: Sat, 9 Jun 2012 10:50:21 -0400 X-Google-Sender-Auth: SAO9wGsifaSOfmOyfQvyhJSFymE Message-ID: From: Barry Leiba To: "apps-discuss@ietf.org" Content-Type: multipart/alternative; boundary=bcaec55555a477ae9504c20b3c97 Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 14:50:24 -0000 --bcaec55555a477ae9504c20b3c97 Content-Type: text/plain; charset=ISO-8859-1 On Saturday, June 9, 2012, Ned Freed wrote: > As I said before, if the consensus is for FCFS, I'm willing to go along since > the number of this is likely to be small and so is the risk. And so I'd like to hear from more people about this. The document said Specification Required, and we're talking about changing it to either Expert Review or First Come First Served. You've seen the arguments on both sides so far, but we've only heard from me, Dave, and Ned. Will others give opinions, please? Barry --bcaec55555a477ae9504c20b3c97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Saturday, June 9, 2012, Ned Freed wrote:
> As I said before, if the consensus is for FCFS, I'm willing to go = along since
> the number of this is likely to be small and so is the = risk.

And so I'd like to hear from more pe= ople about this. =A0The document said Specification Required, and we're= talking about changing it to either Expert Review or First Come First Serv= ed. =A0You've seen the arguments on both sides so far, but we've on= ly heard from me, Dave, and Ned.

Will others give opinions, please?

=
Barry
--bcaec55555a477ae9504c20b3c97-- From superuser@gmail.com Sat Jun 9 08:28:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A6D21F8849 for ; Sat, 9 Jun 2012 08:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5rFitQNDoFn for ; Sat, 9 Jun 2012 08:28:43 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A545E21F8841 for ; Sat, 9 Jun 2012 08:28:42 -0700 (PDT) Received: by lagv3 with SMTP id v3so2800609lag.31 for ; Sat, 09 Jun 2012 08:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BJ8H6F8itMkzF3cNRHIc3rpB5+oG8Mibk2Jhj7Tn9l8=; b=CohkUhprCuDsSjvkb5wtTfWPPdu6lO7yA3SHDnrM7ROzjqSiiaNhjlt2nsuZp6fALw auBZ2ZuzcDk21YC0uHyRRk0QMt9Zlipnllz/7HQGH17l1y0O6AIDplL40sMlidpkooxF 3/L39GbSjoNzUNbvmgXGjEXtunP/8xYzejD0P0LOgE4dYPKzH3Wm1KmXdoLKZ55k7r8M Bh8xaI2zDh3unVg7e6bFj3KXW9gGJ3o7uoUwo217FpHzZlfmo2ccr0Ejz3Ic9vtGX2lI mOUSU2HyMkiPOA+T2/ob8LX5Cc2VgvVwbEvQRWYLXQAIEFNp9BCH+Pgw+nJKDuPhGffs apmw== MIME-Version: 1.0 Received: by 10.152.104.47 with SMTP id gb15mr3220839lab.45.1339255721657; Sat, 09 Jun 2012 08:28:41 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sat, 9 Jun 2012 08:28:41 -0700 (PDT) In-Reply-To: References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> <01OGGS87OI0Q000058@mauve.mrochek.com> Date: Sat, 9 Jun 2012 08:28:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=f46d0421824d8d846304c20bc58c Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 15:28:44 -0000 --f46d0421824d8d846304c20bc58c Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 9, 2012 at 7:50 AM, Barry Leiba wrote: > On Saturday, June 9, 2012, Ned Freed wrote: > > As I said before, if the consensus is for FCFS, I'm willing to go along > since > > the number of this is likely to be small and so is the risk. > > And so I'd like to hear from more people about this. The document said > Specification Required, and we're talking about changing it to either > Expert Review or First Come First Served. You've seen the arguments on > both sides so far, but we've only heard from me, Dave, and Ned. > > Will others give opinions, please? > > > Ultimately either of the two is fine with me. However, I'm leaning towards FCFS since I agree that the number of these being registered beyond the set already listed in the document is likely to be very small, and the damage done by a bogus registration is really quite minimal since this is trace data unlikely to be parsed by machines. -MSK --f46d0421824d8d846304c20bc58c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 9, 2012 at 7:50 AM, Barry Leiba <barryleiba@computer.org> wrote:
On Saturday, June 9, 2012, Ned Freed wrote:
> As I said before, if the consensus is for FCFS, I'm willing to go = along since
> the number of this is likely to be small and so is the = risk.

And so I'd like to hear from m= ore people about this. =A0The document said Specification Required, and we&= #39;re talking about changing it to either Expert Review or First Come Firs= t Served. =A0You've seen the arguments on both sides so far, but we'= ;ve only heard from me, Dave, and Ned.

Will others give opinions, please?



Ultimately either of the two is fine with me= .=A0 However, I'm leaning towards FCFS since I agree that the number of= these being registered beyond the set already listed in the document is li= kely to be very small, and the damage done by a bogus registration is reall= y quite minimal since this is trace data unlikely to be parsed by machines.=

-MSK

--f46d0421824d8d846304c20bc58c-- From jasnell@gmail.com Sat Jun 9 09:52:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717EC21F8805 for ; Sat, 9 Jun 2012 09:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Afeng25-B6wv for ; Sat, 9 Jun 2012 09:52:06 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 02B0A21F87EF for ; Sat, 9 Jun 2012 09:52:05 -0700 (PDT) Received: by werb13 with SMTP id b13so1778301wer.31 for ; Sat, 09 Jun 2012 09:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EN+jX89NZODNifqr8ha4qU9Z+9AHj709eQno8ioAZsM=; b=FBMy/nAj/aFs3gIo3dYiQ2yoq2uoN5LGPVsgOz02B6n942zeiieoq4qkBwN2I9eGAO HP/hZKa+UHxduZXgTYsljnvWyaXrf2FGDK7xMvLufw+nzYJ6YZNQrGy7wqpThJV3hsH4 MjSAeQwiWN0+KYTisOT2Tvy3aq9N1toByc/d5QeRyDO7eNhD/qa0a93ajf5YgbzAWh9D Bfg1fDN+Onp2dbwglOtG19mVcEFnvwvtGBtDjPFmmTEuPVjY8vBtcM2EBwj0ETA09XPX xzIaPJYgoU/JDtSCmdjG7hND4QpP+af6aCiZyqslFCDujULKBsEpFeZan1qCOdmQjtMA 6aLw== Received: by 10.216.209.95 with SMTP id r73mr3583936weo.157.1339260724908; Sat, 09 Jun 2012 09:52:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.104.12 with HTTP; Sat, 9 Jun 2012 09:51:44 -0700 (PDT) In-Reply-To: References: From: James M Snell Date: Sat, 9 Jun 2012 09:51:44 -0700 Message-ID: To: Mike Kelly Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 16:52:08 -0000 On Sat, Jun 9, 2012 at 12:55 AM, Mike Kelly wrote: > On Sat, Jun 9, 2012 at 2:04 AM, James M Snell wrote: >> HAL will just be way too verbose to be practical. > > I think 'way too verbose' is overstating the importance of this. You > are the first person to raise this as an issue at all, let alone as a > significant one. > Deep breath please and consider the *complete* statement I made... which was: There are valid arguments for both, for certain, but I can see many scenarios where HAL will just be way too verbose to be practical. Please allow me to stress the parts where I said, "there are valid arguments for both" and "I can see many scenarios..." It would be highly counterproductive to assume that HAL is appropriate for all possible scenarios; all my feedback was intended to do was indicate that, for the subset of interesting and relevant cases I've worked with in the content and activity syndication space, complex link structures tend towards overkill. That's not to say there's no place for them, not by any stretch of the imagination. > Link Objects are necessary to allow for the "templated" indicator (for > when the link is a URI Template), for including the additional link > params established in the Web Linking RFC, and to provide the > opportunity for extension of link objects in any future types wanting > to extend HAL e.g. by adding additional controls or hints. > Ok. That all granted, for the majority of cases I've worked with, when you boil everything down, I still, most often, only need a url and a rel. > Fwiw, I did actually consider also adding a direct string as you have > suggested here but decided against in the interests of > simplicity/consistency, given that the Link Object approach is > unavoidable (for the reasons stated above). > > On another note - HAL has been established for a while now (as a less > formal, public specification) and has a growing list of server and > client tooling, seems to me like it would be a win for Activity > Streams to adopt HAL's already established conventions, given that > your recent new proposal is so close to it anyway. > If the HAL spec is being used to address real application problems, then that's fantastic. For activity streams, my opinions tend to be driven more by the specific implementation requirements and a desire to keep things as simple as they possibly can be. My note was merely intended to provide (hopefully) constructive feedback from the perspective of someone else who has dealt (many many times) with the notion of generic linking mechanisms in JSON and XML data formats. Take it for what it's worth. - James > Cheers, > M From ned.freed@mrochek.com Sat Jun 9 10:29:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C989D21F87A8 for ; Sat, 9 Jun 2012 10:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdykPCLLN00u for ; Sat, 9 Jun 2012 10:29:33 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 41BF821F87DC for ; Sat, 9 Jun 2012 10:29:30 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGH8S7Q55C0036TU@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 9 Jun 2012 10:29:14 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGBNHXOPCG000058@mauve.mrochek.com>; Sat, 9 Jun 2012 10:29:08 -0700 (PDT) Message-id: <01OGH8S3ROHQ000058@mauve.mrochek.com> Date: Sat, 09 Jun 2012 08:32:05 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 09 Jun 2012 12:18:29 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <1338941672.9269273@apps.rackspace.com> To: Jacob Palme Cc: isoc-members-announce@elists.isoc.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [ISOC] NEWS RELEASE: World IPv6 Launch Unites Industry Leaders to Redefine the Global Internet X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 17:29:34 -0000 > What happens if > (a) I have an IPV4 IP-address, and send a mail to someone who > has an IPV6 IP-address. And that someone replies to my mail. > Will the mails reach their recipients? First of all, the question is not well posed because you haven't specified the roles or operations involved. "Someones" do not exhange mail, MUAs submit and retrieve mail, MSA and MTAs transfer mail, MDAs deliver mail, and mail is delivered to and retrieved from message stores. All of these operations can be done over the network. If you're talking about MTAs transferring mail, then an MTA that only has an IPv4 address cannot send mail to an MTA that only has an IPv6 address. So the operation you described fails before a response could even occur. If, OTOH, you're talking about MUAs, then there are most intermediate steps involved and haven't specified their characteristis in sufficient detail to respond. All that said, the present day reality, as well as the likely reality for all but the very long term, is that while MTAs may choose to support IPv6, and perhaps even use it exclusively in some unusual situations, any generally accessible Internet MTA has to have IPv4 addresses and be able to make and accept IPv4 connections to be able to function. So the "what if" scenario you posit cannot occur. As for MUAs, there are scenarios where it is perfectly reasonable to transition to IPv6 exclusively for submission and retrieval. There are also scenarios where that isn't possible. > Or the reverse, > (b) I have an IPV6 IP-address, and send a mail to someone who > has an IPV4 IP-address. And that someone replies to my mail. > Will the mails reach their recipients? Same response. > Also if my SMTP server uses IPV4, or uses IPV6, and my > correspondents SMTP sever uses IPv4, or uses IPV6. Also if > my POP or IMAC server uses IPV4, or uses IPV6, and my > correspondents POP or IMAC server uses IPV4 or IPV6. See above. > What happens if I have an IPV4 address and send an HTTP > request to Google, will Google reply as if had an IPV6 > address? > And if I have an old-style IPV4 web browser, will > I then not be able to see Google's response? Since the response in HTTP occurs on the same connection, this is a "can't happen" case. > I am using Eudora 6.2.4 (2006) copyright QUALCOMM, will I > not be able to send and receive e-mail in the future, > unless I switch to a newer, IPV6 aware mail client? The cases where MUAs will use IPv6 exclusively are ones where the network environment is controlled and restricted, e.g. some cellular networks. You won't be able to connect your Eudora client to such networks in any case, irrespective of the protocols it does or does not support. But yes, it's possible that at some point in the distant future - almost certainly the *very* distant future - IPv4 will be abandoned in favor of IPv6 for email. If and when that happens, your Eudora client, assuming you would even be able to run it at that point, will cease to work. So what? Time marches on. There are literally truckloads of applications that only run on systems that are no longer available. For that matter, there are applications that depend on network protocols that are no longer supported. This is reality; deal with it. > I am also using a Spamfire Spam filter, vesiron 1.6.2 anno > 2003 Matterform Media, which I assume has never heard of > IPV6. Will my spam filter and all the many hundreds of spam > recognition commands which I have stored for Spamfire, stop > working when my POP server switches to IPV6, stop working? > Spamfire is not any more supported by its ceator > Matterform, who made a much less competent version 2 of > Spamfire, which I refused to switch to. Sure, that could also fail. But it is far more likely that all the rules you spent time building will become irrelevant or obsolete *long* before you're faced with any sort of mandatory IPv6 transition. > Or will all the world's servers support both IPV4 or IPV6 > depending on the protocol of the clients which access them? > If so, what is meant when "Google, Facebook, YouTube, and > Yahoo!" will permanently enable IPV6? At least some of these already have "permanently enabled IPv6", which modulo the "happy eyeballs" issue doesn't affect IPv4 at all. The issue you're worried about is them disabling IPv4. And like email transitioning to IPv6, that is not going to happen for a *very* long time, assuming it ever happens. > Do I have to throw > away all computers and mobile phones and replace them with > IPV6 versions? Or does it only mean that they will use IPV6 > if accessed by someone who has an IPV6 client? Same response again: At some point in the distant future IPv4 may go away. When that happens yes, IPv4-only gear will cease to work. > I am using an internet service provider, who gives me an IP > number using DHPC when I connect to it. Will my internet > service provider in the future (when?) give me IPV6 > addresses using DHCP? Does this mean that I have to replace > all internet client software on all my computers with IPV6 > enabled client software? Same response. > I am sure that hardware and software vendors will wrap > their hands in pleasure of having to sell replacement for > all the world's hardware and software. I am accustomed to > them using other methods to force me to buy new hardware > and software every three or every five years or so. Total nonsense. We're lucky if hardware and software vendors see past next quarter revenue. The time horizon for a transition to an IPv6-only world is best measured in decades, assuming it even happens. It's like thinking a mosquito would be ecstatic about the effect of global warming. > Assume a library where all the pages of all the books turn > blank after three years. That is the way, which the > computer world works. Will the switch to IPV6 be another > way of making book pages go blank? The loss of access to existing media is a real, and very serious, problem. IPv6 has almost nothing to do with it. > And then allow a few selected books be readable again if I > buy new hardware and software? Again, this is a serious problem, but IPv6 is not part of it. Ned From mikekelly321@gmail.com Sat Jun 9 11:39:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A830521F847D for ; Sat, 9 Jun 2012 11:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qONqfJKNucYr for ; Sat, 9 Jun 2012 11:39:58 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D37DD21F847B for ; Sat, 9 Jun 2012 11:39:57 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so5789446obb.31 for ; Sat, 09 Jun 2012 11:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=VHTLc5Bg1A6YaL2DcH/7+e6olTltwhwLrTPYo4rM8bQ=; b=PJHjmjUlLQuNZDfC7z1UkgLgyLv9GvutxCsUpnyrnYG7n0BtYCNkLvA10Urpmy4xV7 G/qoH3E6XTZHLHw5o3mUVOYj5+j7HpWRCvg9G5yHTpybSfUE0Fe96itsQLikixYle7Ny a0b7+eA+1SA14cQspq1Ezw9nGhsoXVwKziptBPiWvEcuwyXi85BDgI0cq+LswMvikMSP tKZuRD4gwwb2+uy2ISvOebnOsWITwaR/iignmrYx7NHsyI1SuJqbKIscLC2arlLpwyRi 0v2IC3swesbPcwy563GdUx/0VZ2i63ikoY5vHA2IAFWmCvJidiwYNbSUqj6K2fiLPDyS R9Sw== MIME-Version: 1.0 Received: by 10.182.174.36 with SMTP id bp4mr11384320obc.53.1339267197440; Sat, 09 Jun 2012 11:39:57 -0700 (PDT) Received: by 10.60.28.195 with HTTP; Sat, 9 Jun 2012 11:39:57 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Jun 2012 19:39:57 +0100 Message-ID: From: Mike Kelly To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 18:39:58 -0000 Hi James, Thanks for sharing your thoughts, I have some follow up questions in line On Sat, Jun 9, 2012 at 5:51 PM, James M Snell wrote: > On Sat, Jun 9, 2012 at 12:55 AM, Mike Kelly wrot= e: >> On Sat, Jun 9, 2012 at 2:04 AM, James M Snell wrote: >>> HAL will just be way too verbose to be practical. >> >> I think 'way too verbose' is overstating the importance of this. You >> are the first person to raise this as an issue at all, let alone as a >> significant one. >> > > Deep breath please and consider the *complete* statement I made... which = was: > > =A0There are valid arguments for both, for certain, but I can see many > =A0scenarios where HAL will just be way too verbose to be practical. > > Please allow me to stress the parts where I said, "there are valid > arguments for both" and "I can see many scenarios..." > > It would be highly counterproductive to assume that HAL is appropriate > for all possible scenarios; all my feedback was intended to do was > indicate that, for the subset of interesting and relevant cases I've > worked with in the content and activity syndication space, complex > link structures tend towards overkill. That's not to say there's no > place for them, not by any stretch of the imagination. To be clear, there's no anxiety or animosity from my end on this - I'm simply trying to understand why you would pick such emotive language as "way too verbose to be practical" when all we're really talking about is a very small difference in design. I understood your rationale for proposing your slightly optimised alternative for activity streams. I did (and still don't) understand why you believe HAL's slightly-less-optimal approach to be so significant as to render it "way too verbose" and/or "impractical".. at worst it's marginally sub-optimal for some basic use cases. >> Link Objects are necessary to allow for the "templated" indicator (for >> when the link is a URI Template), for including the additional link >> params established in the Web Linking RFC, and to provide the >> opportunity for extension of link objects in any future types wanting >> to extend HAL e.g. by adding additional controls or hints. >> > > Ok. That all granted, for the majority of cases I've worked with, when > you boil everything down, I still, most often, only need a url and a > rel. A rel and a url are all that is required to produce a valid link with HAL. This is a valid link object: { "foo": { "href": "/bar" } } Just to re-iterate, HAL's linking conventions have been around for just under 2 years now, and you are the first person to consider this a pressing issue. >> Fwiw, I did actually consider also adding a direct string as you have >> suggested here but decided against in the interests of >> simplicity/consistency, given that the Link Object approach is >> unavoidable (for the reasons stated above). >> >> On another note - HAL has been established for a while now (as a less >> formal, public specification) and has a growing list of server and >> client tooling, seems to me like it would be a win for Activity >> Streams to adopt HAL's already established conventions, given that >> your recent new proposal is so close to it anyway. >> > > If the HAL spec is being used to address real application problems, > then that's fantastic. For activity streams, my opinions tend to be > driven more by the specific implementation requirements and a desire > to keep things as simple as they possibly can be. My note was merely > intended to provide (hopefully) constructive feedback from the > perspective of someone else who has dealt (many many times) with the > notion of generic linking mechanisms in JSON and XML data formats. > Take it for what it's worth. So, just to clarify.. your desire for simplicity is so strong that a very minor optimisation that will: - harm the expressiveness of links - damage future extensibility - not benefit from existing libraries is still 'the right option' for activtity streams over adopting a design that has existed for almost 2 years, has seen decent adoption and brings with it a handful of libraries in various programming languages? Maybe I've missed something vital but at the moment I do not understand where you are coming from. Sorry. Cheers, M From sm@resistor.net Sat Jun 9 13:55:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5C421F867B for ; Sat, 9 Jun 2012 13:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOQxCk0Km1qL for ; Sat, 9 Jun 2012 13:55:56 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0817821F8675 for ; Sat, 9 Jun 2012 13:55:55 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q59Ktgck028821; Sat, 9 Jun 2012 13:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339275348; i=@resistor.net; bh=WGbp2txOcn9y0YcYaYpWBApGNVzjozYVC2BT6PhQLVE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=KwQuNCtMy6Hp+tAhteNTOz3YQPrvepXtODLTh+GUWEKWgQBeVE7oFSxfUt9g0gvHh Uav+WByAtIo6OFBVbAKXdv5GV0QQEs75e/dR8lnfvsOKMcsLk6P0UzfjQ15p2DU2LJ zChMmpOWJQDsYXCM0+oNFzvgHvitPfCzJTl0/05Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1339275348; i=@resistor.net; bh=WGbp2txOcn9y0YcYaYpWBApGNVzjozYVC2BT6PhQLVE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oXBjK8bsmT+CDde92f28EAJlgxBRqxiDzi+aVoCgE5xQMs/L1Bn8Gdu9YaO3ajeHJ FjnRC20gSWqKu8tD7sIP3QkL79cnqSAJ/ptoEYT/hXsYQyRqb4Isbp3Gqoafpcd0M8 d+WI2ddNikFfq9VK6xd96qn3hzZ9HjtVMnK+DSqE= Message-Id: <6.2.5.6.2.20120609133050.08dc2cb0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 09 Jun 2012 13:52:19 -0700 To: Jacob Palme , apps-discuss@ietf.org From: SM In-Reply-To: References: <1338941672.9269273@apps.rackspace.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: isoc-members-announce@elists.isoc.org Subject: Re: [apps-discuss] [ISOC] NEWS RELEASE: World IPv6 Launch Unites Industry Leaders to Redefine the Global Internet X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 20:55:58 -0000 Hi Jacob, At 03:18 09-06-2012, Jacob Palme wrote: >What happens if >(a) I have an IPV4 IP-address, and send a mail to someone who >has an IPV6 IP-address. And that someone replies to my mail. >Will the mails reach their recipients? No. >Or the reverse, >(b) I have an IPV6 IP-address, and send a mail to someone who >has an IPV4 IP-address. And that someone replies to my mail. >Will the mails reach their recipients? No. >What happens if I have an IPV4 address and send an HTTP >request to Google, will Google reply as if had an IPV6 >address? And if I have an old-style IPV4 web browser, will >I then not be able to see Google's response? No. >I am using Eudora 6.2.4 (2006) copyright QUALCOMM, will I >not be able to send and receive e-mail in the future, >unless I switch to a newer, IPV6 aware mail client? Short answer, you may have to switch. The long answer is that you can tunnel between IPv4 and IPv6 if your operating system supports that. >I am also using a Spamfire Spam filter, vesiron 1.6.2 anno >2003 Matterform Media, which I assume has never heard of >IPV6. Will my spam filter and all the many hundreds of spam >recognition commands which I have stored for Spamfire, stop >working when my POP server switches to IPV6, stop working? Yes. >Or will all the world's servers support both IPV4 or IPV6 >depending on the protocol of the clients which access them? It is better to support both during the long transition period. >If so, what is meant when "Google, Facebook, YouTube, and >Yahoo!" will permanently enable IPV6? Do I have to throw >away all computers and mobile phones and replace them with >IPV6 versions? Or does it only mean that they will use IPV6 >if accessed by someone who has an IPV6 client? It means that they will use IPv6 for IPv6 clients. >I am using an internet service provider, who gives me an IP >number using DHPC when I connect to it. Will my internet >service provider in the future (when?) give me IPV6 >addresses using DHCP? If it supports that technology, yes. > Does this mean that I have to replace >all internet client software on all my computers with IPV6 >enabled client software? If IPv6 is widely used, yes. >I am sure that hardware and software vendors will wrap >their hands in pleasure of having to sell replacement for >all the world's hardware and software. I am accustomed to >them using other methods to force me to buy new hardware >and software every three or every five years or so. :-) >Assume a library where all the pages of all the books turn >blank after three years. That is the way, which the >computer world works. Will the switch to IPV6 be another >way of making book pages go blank? Yes. >And then allow a few selected books be readable again if I >buy new hardware and software? Yes. Regards, -sm From superuser@gmail.com Sun Jun 10 00:02:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5BF21F8698 for ; Sun, 10 Jun 2012 00:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYb-p4Aalcih for ; Sun, 10 Jun 2012 00:02:35 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC6121F8690 for ; Sun, 10 Jun 2012 00:02:31 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3393149lbb.31 for ; Sun, 10 Jun 2012 00:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6+QsNYw120+xWbYu5RJGLcXXG4kMRMe116NN8C/3I/0=; b=qX89QHhCFNQARGbRYWNSZECki99HkYERbxkFGTt925UB7YMAvuWU240OKbEW7+9FF3 u1XkUN8XwhDnxzgnYK/hIY2z+VLziTfM5wOppVFQciwX662WvqUQvKEtbDzDO6/+g5hv ELAT7rojjUAnEjjP1j3PCwJCNQcEWWv0HfEuKpYgjBiH3byTZqv2NleVbTH8h0CL9Jds wVGADZUycChATBDWdQEDdUVas+w8bWM/x4TcxXehAwPMt2xXcPEvCn83qoiUlT0zjCq9 AFcpR5vrtG/5cP/Q+jCLMu1AkyWToPI/5c33Q59Jkc/PtP6A+TDmJOS0cjdpPwD3i61j vl1w== MIME-Version: 1.0 Received: by 10.112.49.100 with SMTP id t4mr1606624lbn.10.1339311750912; Sun, 10 Jun 2012 00:02:30 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sun, 10 Jun 2012 00:02:30 -0700 (PDT) Date: Sun, 10 Jun 2012 00:02:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=bcaec554d63c28198604c218d125 Subject: [apps-discuss] draft-ietf-appsawg-media-type-regs and "provisional" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 07:02:36 -0000 --bcaec554d63c28198604c218d125 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Barry asked me to review the IETF Last Call comments on the above draft before it gets scheduled for a telechat, to make sure there's nothing outstanding that needs to be addressed in the document. I just spent a chunk of time reviewing the debate about "provisional", which I think is the only unresolved issue before we move forward with it. I think we should proceed with it as-is. I recognize that Mark and PSA both don't like what's there on this point, but ultimately I agree with Ned and John that this isn't introducing a new problem, nor is it introducing a terminology change, and the "problem" that already exists since RFC3864 hasn't caused any detectable harm. Mark could address this if he feels so moved in his happiana efforts, but I don't think it's a showstopper for this particular document. -MSK, as document shepherd --bcaec554d63c28198604c218d125 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Barry asked me to review the IETF Last Call comments on the = above draft before it gets scheduled for a telechat, to make sure there'= ;s nothing outstanding that needs to be addressed in the document.=A0 I jus= t spent a chunk of time reviewing the debate about "provisional",= =20 which I think is the only unresolved issue before we move forward with it.<= br>
I think we should proceed with it as-is.=A0 I recognize that Mark and PSA= =20 both don't like what's there on this point, but ultimately I agree = with Ned and John=20 that this isn't introducing a new problem, nor is it introducing a=20 terminology change, and the "problem" that already exists since R= FC3864=20 hasn't caused any detectable harm.

Mark could address this if he feels so moved in his happiana efforts, b= ut I don't think it's a showstopper for this particular document.
-MSK, as document shepherd

--bcaec554d63c28198604c218d125-- From michiel@unhosted.org Sun Jun 10 00:07:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B5821F86A5 for ; Sun, 10 Jun 2012 00:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+NA2dsIaFLj for ; Sun, 10 Jun 2012 00:07:03 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D38EB21F869F for ; Sun, 10 Jun 2012 00:07:02 -0700 (PDT) Received: by dacx6 with SMTP id x6so4042480dac.31 for ; Sun, 10 Jun 2012 00:07:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=/e689xjWbu4BqBg5PsiTf5viiyp3c7r0VFPVSCHDNYQ=; b=aja8Z3HvaWcC7LtI5V4vujwT0c3lSmMiQzhb0R+rCQzKdK4o0CMV3mrLxpKZMAUwzz TGAo21srFnL5OFkl5PuPwMrTp1SS5R0++bEwIWRhAeG1YmEgYdrODG6FNYsDnzf+Dayw PBan5F7dIE7nxNTt6ON9b88AgOWeLLeXAG1WZVQ0Ocf32e9lGRKLB3PguR/uDF026nMO b6OM8iDboXHAXRIcefzXfbKQTtIFoGQnmInaUmqMGXtNfG4wEcTu85aKVdgvwJh4JO8Z X5dFhfVq6ALyQcoEcATgwwgxemKUHPDx8JA3OTrnZO+28fDvEprweP+6cUX9J12gWEFJ GBxw== MIME-Version: 1.0 Received: by 10.68.212.102 with SMTP id nj6mr13712850pbc.15.1339312022441; Sun, 10 Jun 2012 00:07:02 -0700 (PDT) Received: by 10.68.57.102 with HTTP; Sun, 10 Jun 2012 00:07:02 -0700 (PDT) X-Originating-IP: [178.0.223.216] Date: Sun, 10 Jun 2012 09:07:02 +0200 Message-ID: From: Michiel de Jong To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmn52bPQEHSgsDqNbJ2EqQoQnCIPRUw3ABJ9PmtSMJ8FLIVbQF818WVuQbkCQFi4+ke9hld Subject: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 07:07:04 -0000 The webfinger spec (http://tools.ietf.org/html/draft-jones-appsawg-webfinger-05 ) and the simple web discovery spec (http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 ) are being merged into one thing. We need a name to refer to the result of this merge. This means we need to pick one of the names to go forward with, and deprecate the other name, or pick a new name altogether and deprecate both current names. I think currently 'bare user@host vs acct:user@host' and 'xml or json vs only json' are two points that still need to be resolved before the merge is complete, right? Anyway, that's not the topic of this thread - let's just suppose a consensus will be reached, and the specs will be merged. Then, I think Blaine Cook, Paul Jones and Mike Jones have all indicated in previous threads that they are open to picking 'simple web discovery' as the new name. FWIW, i personally am the kind of person who enjoys giving nice names to things, and i particularly enjoy saying 'webfinger' because it's more creative, less boring, and funnier as a name. Also, to me it makes perfect sense that it's "finger for the web". However, in my experience explaining to people that remoteStorage (http://www.w3.org/community/unhosted/wiki/RemoteStorage ) combines XHR with CORS, OAuth and webfinger, people usually know what XHR is (especially if i call it AJAX), 50% know what OAuth is, and for CORS the face i get from them is 'oh that must be some sort of special mechanism'. The face i sometimes (not always) get for webfinger is 'huh? is that a real thing?'. :) also, when i do explain webfinger to people, unless they look like old school finger users, i tell them it is 'a simple mechanism for discovering service on the web'. So it is my opinion that 'simple web discovery' would be a (more boring, but) better name than 'webfinger'. A downside would be that we need to update it everywhere, but i guess we can get over that. maybe other people have other experiences or insights about this name choice? Cheers, Michiel From melvincarvalho@gmail.com Sun Jun 10 00:38:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CD421F864E for ; Sun, 10 Jun 2012 00:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UNvybP2Ha3C for ; Sun, 10 Jun 2012 00:38:22 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7141A21F8608 for ; Sun, 10 Jun 2012 00:38:22 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1968816vcq.31 for ; Sun, 10 Jun 2012 00:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K4Q3HlK9l+vERBJ2PfVl2XB1EwJCuvCu1PZls27ueZo=; b=ar5RPg3QRQ/04iC73lyILAfbFtJX7L2UX6CRbOdRjht3ObfyCjvgKmSoUF90OU2pDm cfCSm/0ako2CwQmTksRJoqGpEcD9CzCZe2zZGyamA6oA2XAteNnsW/+KMDerh0jnUeL0 Y0/nAIh9fDU0JspDnV4N6kjh4BXO3DCQ1hDT8+CbKFF4zFuJNaBAidqC7tYGxfdOF7wQ M0cwsLphnvLgj3pnVDGluppd5Y6OcXV7Z6mhiL9MvC/THfPd4ZqydAxEe3RI05yvTwnI KDDYt7xg9vbs1fgndK3Qwg/ycxLO+JVR47Wf5OKxCzddjP2/IRB4emtUP+ETBw2YngUY W3jA== MIME-Version: 1.0 Received: by 10.221.1.80 with SMTP id np16mr10105117vcb.33.1339313901811; Sun, 10 Jun 2012 00:38:21 -0700 (PDT) Received: by 10.52.166.102 with HTTP; Sun, 10 Jun 2012 00:38:21 -0700 (PDT) In-Reply-To: References: Date: Sun, 10 Jun 2012 09:38:21 +0200 Message-ID: From: Melvin Carvalho To: Michiel de Jong Content-Type: multipart/alternative; boundary=bcaec54eefb25c37ea04c219518f Cc: Apps Discuss Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 07:38:23 -0000 --bcaec54eefb25c37ea04c219518f Content-Type: text/plain; charset=ISO-8859-1 On 10 June 2012 09:07, Michiel de Jong wrote: > The webfinger spec > (http://tools.ietf.org/html/draft-jones-appsawg-webfinger-05 ) and the > simple web discovery spec > (http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 ) are > being merged into one thing. > > We need a name to refer to the result of this merge. This means we > need to pick one of the names to go forward with, and deprecate the > other name, or pick a new name altogether and deprecate both current > names. > > I think currently 'bare user@host vs acct:user@host' and 'xml or json > vs only json' are two points that still need to be resolved before the > merge is complete, right? Anyway, that's not the topic of this thread > - let's just suppose a consensus will be reached, and the specs will > be merged. > > Then, I think Blaine Cook, Paul Jones and Mike Jones have all > indicated in previous threads that they are open to picking 'simple > web discovery' as the new name. > > FWIW, i personally am the kind of person who enjoys giving nice names > to things, and i particularly enjoy saying 'webfinger' because it's > more creative, less boring, and funnier as a name. Also, to me it > makes perfect sense that it's "finger for the web". However, in my > experience explaining to people that remoteStorage > (http://www.w3.org/community/unhosted/wiki/RemoteStorage ) combines > XHR with CORS, OAuth and webfinger, people usually know what XHR is > (especially if i call it AJAX), 50% know what OAuth is, and for CORS > the face i get from them is 'oh that must be some sort of special > mechanism'. > > The face i sometimes (not always) get for webfinger is 'huh? is that a > real thing?'. :) also, when i do explain webfinger to people, unless > they look like old school finger users, i tell them it is 'a simple > mechanism for discovering service on the web'. So it is my opinion > that 'simple web discovery' would be a (more boring, but) better name > than 'webfinger'. A downside would be that we need to update it > everywhere, but i guess we can get over that. > > maybe other people have other experiences or insights about this name > choice? > +1 Simple Web Discovery Feedback I've heard is that 'Webfinger' sounds cool to those that remember finger, but maybe a bit 'creepy' otherwise. > > > Cheers, > Michiel > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --bcaec54eefb25c37ea04c219518f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 10 June 2012 09:07, Michiel de Jong <= span dir=3D"ltr"><michiel@unhosted.org> wrote:
The webfinger spec
(http://tools.ietf.org/html/draft-jones-appsawg-webfinger-05= ) and the
simple web discovery spec
(http://tools.ietf.org/html/draft-jones-simple-web-discov= ery-02 ) are
being merged into one thing.

We need a name to refer to the result of this merge. This means we
need to pick one of the names to go forward with, and deprecate the
other name, or pick a new name altogether and deprecate both current
names.

I think currently 'bare user@host vs acct:user@host' and 'xml o= r json
vs only json' are two points that still need to be resolved before the<= br> merge is complete, right? Anyway, that's not the topic of this thread - let's just suppose a consensus will be reached, and the specs will be merged.

Then, I think Blaine Cook, Paul Jones and Mike Jones have all
indicated in previous threads that they are open to picking 'simple
web discovery' as the new name.

FWIW, i personally am the kind of person who enjoys giving nice names
to things, and i particularly enjoy saying 'webfinger' because it&#= 39;s
more creative, less boring, and funnier as a name. Also, to me it
makes perfect sense that it's "finger for the web". However, = in my
experience explaining to people that remoteStorage
(http://www.w3.org/community/unhosted/wiki/RemoteStorage ) c= ombines
XHR with CORS, OAuth and webfinger, people usually know what XHR is
(especially if i call it AJAX), 50% know what OAuth is, and for CORS
the face i get from them is 'oh that must be some sort of special
mechanism'.

The face i sometimes (not always) get for webfinger is 'huh? is that a<= br> real thing?'. :) also, when i do explain webfinger to people, unless they look like old school finger users, i tell them it is 'a simple
mechanism for =A0discovering service on the web'. So it is my opinion that 'simple web discovery' would be a (more boring, but) better na= me
than 'webfinger'. A downside would be that we need to update it
everywhere, but i guess we can get over that.

maybe other people have other experiences or insights about this name choic= e?

+1 Simple Web Discovery

Feedback I'v= e heard is that 'Webfinger' sounds cool to those that remember fing= er, but maybe a bit 'creepy' otherwise.
=A0


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

--bcaec54eefb25c37ea04c219518f-- From yaojk@cnnic.cn Sun Jun 10 02:39:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5535221F85CC for ; Sun, 10 Jun 2012 02:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.799 X-Spam-Level: X-Spam-Status: No, score=-98.799 tagged_above=-999 required=5 tests=[J_CHICKENPOX_63=0.6, J_CHICKENPOX_93=0.6, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+LqM2Z6i3FW for ; Sun, 10 Jun 2012 02:39:17 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 3889E21F85C7 for ; Sun, 10 Jun 2012 02:39:15 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO computer) (127.0.0.1) by 127.0.0.1 with SMTP; Sun, 10 Jun 2012 17:39:11 +0800 Message-ID: <000801cd46ec$e3c77be0$ca01a8c0@computer> From: "Jiankang Yao" To: , References: <000301cd4061$a194a090$e4bde1b0$@cn> Date: Sun, 10 Jun 2012 17:39:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3664 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-v6ops-6204bis-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 09:39:18 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-v6ops-6204bis-09Title: Basic Requirements for IPv6 Customer Edge Routers Reviewer: Jiankang Yao Review Date: 10 June 2012 Summary: This draft is almost ready for publication as an Informational RFC.Major Issues: noneMinor Issues: noneNits: 1)In abstract, "Specifically, the current version of this document ",I think that "the current version of this document"-->"this document" may be better.the current version always let the reader think that what the next version is.2)In reference,the reference rfc2030 is not used. From superuser@gmail.com Sun Jun 10 14:11:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B9221F8546 for ; Sun, 10 Jun 2012 14:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD6scgeyzebB for ; Sun, 10 Jun 2012 14:11:05 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 796A421F8547 for ; Sun, 10 Jun 2012 14:11:05 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3753856lbb.31 for ; Sun, 10 Jun 2012 14:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RAZ/gbfQ+TYCtoDousZ7Vifb91K7qTJral6lwEcrubg=; b=GRcjlvYEHoECHV14fLO1y6PnNEPLv6astBrtf/2RnUVcDDnS6ccrvZkI5iXDLBxTDz pu8mMRUPSCnhCSXd1HmrQ51PHCOMalsgithPRJaJE/WExwSk5Ff+jGKqPaoDAGAwkuPh qJ6t2zrHdzzuEV5ZDAomX2CovDzxS+ngl72SYjpjR52ilq93BRcawACLGqxR0FHxlkHa k7TVVuz27dW0ySb1ShM/NJzm9lM2MMdLgPicW1+55Qt2fPb6vV2oW4/zQDUbKilDT7Bp xgseoNf6tI3lsDP1wVenu6i2KA9VVZ34EeK4Kif+E7O2u0doOSk+f4kXlYMpP3kG52vH xl0w== MIME-Version: 1.0 Received: by 10.112.39.135 with SMTP id p7mr2303015lbk.78.1339362661450; Sun, 10 Jun 2012 14:11:01 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sun, 10 Jun 2012 14:11:01 -0700 (PDT) Date: Sun, 10 Jun 2012 14:11:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=485b390f7a76a9445504c224ab1b Subject: [apps-discuss] Agenda items for Vancouver X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 21:11:06 -0000 --485b390f7a76a9445504c224ab1b Content-Type: text/plain; charset=ISO-8859-1 If anyone would like to request time on the APPSAWG/APPAREA agenda for the Vancouver meeting, please send your request to appsawg-chairs@tools.ietf.org. We have one request in-hand already. The deadline for submitting a draft agenda is July 18th, so please get your requests in well ahead of that date. -MSK, APPSAWG co-chair --485b390f7a76a9445504c224ab1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If anyone would like to request time on the APPSAWG/APPAREA agenda for the = Vancouver meeting, please send your request to appsawg-chairs@tools.ietf.org.=A0 We have one requ= est in-hand already.

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

-MSK, APPSAWG co-chair
--485b390f7a76a9445504c224ab1b-- From ned.freed@mrochek.com Sun Jun 10 15:58:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9C821F8552 for ; Sun, 10 Jun 2012 15:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNjqPdabH+iC for ; Sun, 10 Jun 2012 15:58:06 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id AD56621F8454 for ; Sun, 10 Jun 2012 15:58:06 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGIYK9GFHC003I29@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 10 Jun 2012 15:58:04 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGBNHXOPCG000058@mauve.mrochek.com>; Sun, 10 Jun 2012 15:58:02 -0700 (PDT) Message-id: <01OGIYK8E5LM000058@mauve.mrochek.com> Date: Sun, 10 Jun 2012 12:33:14 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 10 Jun 2012 00:02:30 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: "Murray S. Kucherawy" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-media-type-regs and "provisional" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 22:58:07 -0000 > Barry asked me to review the IETF Last Call comments on the above draft > before it gets scheduled for a telechat, to make sure there's nothing > outstanding that needs to be addressed in the document. I just spent a > chunk of time reviewing the debate about "provisional", which I think is > the only unresolved issue before we move forward with it. Sorry you felt you had to do that. Anyway, in regards to the "provisional" issue, I do not regard it as unresolved in any way. > I think we should proceed with it as-is. I recognize that Mark and PSA > both don't like what's there on this point, but ultimately I agree with Ned > and John that this isn't introducing a new problem, nor is it introducing a > terminology change, and the "problem" that already exists since RFC3864 > hasn't caused any detectable harm. OK, maybe I'm missing something here, but ... As I understand it the issue Mark raised was the separation of provisional entries from the main registry. This was because he misunderstood the semantics of these entries. Such entries are NOT intended to be in active use - they don't contain anything approaching enough information to be used. As such, it is entirely inappropriate for them to be on the same page as approved entries.. When this was pointed out to him, he fell back on the argument that this isn't how other provisional registries in the IETF work, specifically referring to RFC 3864. And he called this the "underlying problem". But he never actually objected to the nature of the media types registry once it was explained why it was structured this way, possibly because the registry was added specifically at the request of the W3C and it has exactly the characteristics they wanted it to have. As for the terminology issue, there are two problems with that. First, what RFC 3864 calls a "provisional" registry is in fact nothing of the sort. It's a permanent registry - entries, one made, are never removed. The most you can do is move them from provisional to permanent status. Of course this usage directly contradicts what the word "provisional" actually means. We're using the term correctly, RFC 3864 is not. If this actually an issue for the IESG we'll switch to "pro tem". But that won't fix the mistake in RFC 3864. And when I pointed this out, AFAIK there was no response. The second problem is funnier. Guess how the RFC 3864 registry, which has been held up as a model, is structured. That's right, two separate pages. In the case of RFC 3864 separate pages are actually totally inappropriate, but they are not only appropriate, they are essential, here. Anyway, after all this is over I have every intention of filing an errata on RFC 3864 pointing out that it's misusing the term "provisional". And just for the lutz, I may also point out that the separate pages is also an error. > Mark could address this if he feels so moved in his happiana efforts, but I > don't think it's a showstopper for this particular document. I don't see how. Happiana is about, well, I'm not entirely sure what it's about any more. But one thing it cannot do is make fundamental changes to how IANA registries are structured. If there's any attempt to do that, I for one will strongly object, and if necessary, appeal. Ned From ned.freed@mrochek.com Sun Jun 10 16:00:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB4E21F8559 for ; Sun, 10 Jun 2012 16:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.37 X-Spam-Level: X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=-1.185, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDlLATQyXvGe for ; Sun, 10 Jun 2012 16:00:42 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B595721F8557 for ; Sun, 10 Jun 2012 16:00:42 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGIYNI9ZB40032K6@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 10 Jun 2012 16:00:41 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGBNHXOPCG000058@mauve.mrochek.com>; Sun, 10 Jun 2012 16:00:39 -0700 (PDT) Message-id: <01OGIYNH2LPW000058@mauve.mrochek.com> Date: Sun, 10 Jun 2012 15:59:41 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 10 Jun 2012 00:02:30 -0700" MIME-version: 1.0 References: To: "Murray S. Kucherawy" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-media-type-regs and "provisional" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 23:00:43 -0000 One additional point. I've summarized Mark's position as best I could from the existing traffic. If he feels I have done so in error, he should feel free to correct me. Ned From julian.reschke@gmx.de Sun Jun 10 23:37:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81AF21F84AF for ; Sun, 10 Jun 2012 23:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAxOE-A4mze4 for ; Sun, 10 Jun 2012 23:37:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D1C6621F84AC for ; Sun, 10 Jun 2012 23:37:21 -0700 (PDT) Received: (qmail invoked by alias); 11 Jun 2012 06:37:20 -0000 Received: from p54BB2C9C.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.44.156] by mail.gmx.net (mp012) with SMTP; 11 Jun 2012 08:37:20 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/zcVJTf/jzSaKjtA2pwQKyGMqZtr2T2l9A42vF4n ioyBDYi0Q35y4f Message-ID: <4FD5921F.4090600@gmx.de> Date: Mon, 11 Jun 2012 08:37:19 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: James M Snell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps Discuss Subject: Re: [apps-discuss] FYI: For review... draft-snell-merge-patch-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 06:37:22 -0000 On 2012-06-08 19:36, James M Snell wrote: > Hello All, > > I have submitted an updated version of draft-snell-merge-patch [1] > that fixes a few editorial issues. > > Feedback is quite welcome. Hi there. a) "application/json+merge-patch" seems like a good thing; however, I wonder whether it wouldn't be simpler to just declare the described semantics as "the" PATCH semantics for application/json? b) on the other hand, "application/merge-patch" seems to be a fundamentally bad idea; after all, it's not really a media type; if you want to develop this further, I strongly recommend moving it into a separate spec. Best regards, Julian From mnot@mnot.net Mon Jun 11 05:16:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02CF21F856C for ; Mon, 11 Jun 2012 05:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC7SfEYPxHAs for ; Mon, 11 Jun 2012 05:16:15 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id EC65C21F8568 for ; Mon, 11 Jun 2012 05:16:14 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.56.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E1A5950A6B; Mon, 11 Jun 2012 08:16:06 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <01OGIYK8E5LM000058@mauve.mrochek.com> Date: Mon, 11 Jun 2012 22:16:03 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01OGIYK8E5LM000058@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1278) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-media-type-regs and "provisional" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 12:16:15 -0000 You know, there's such a thing as a CC: header, guys... Anyway, a few comments below: On 11/06/2012, at 5:33 AM, Ned Freed wrote: >=20 > As I understand it the issue Mark raised was the separation of = provisional > entries from the main registry. This was because he misunderstood the = semantics > of these entries. Such entries are NOT intended to be in active use - = they > don't contain anything approaching enough information to be used. As = such, it > is entirely inappropriate for them to be on the same page as approved = entries.. > When this was pointed out to him, he fell back on the argument that = this isn't > how other provisional registries in the IETF work, specifically = referring to > RFC 3864. And he called this the "underlying problem". But he never = actually > objected to the nature of the media types registry once it was = explained why it > was structured this way, possibly because the registry was added = specifically > at the request of the W3C and it has exactly the characteristics they = wanted it > to have. Agreed. > As for the terminology issue, there are two problems with that. First, = what RFC > 3864 calls a "provisional" registry is in fact nothing of the sort. = It's a > permanent registry - entries, one made, are never removed. The most = you can do > is move them from provisional to permanent status. Agreed; I think I said before that its use of the term is unfortunate. > Of course this usage directly contradicts what the word "provisional" = actually > means. We're using the term correctly, RFC 3864 is not. If this = actually an > issue for the IESG we'll switch to "pro tem". But that won't fix the > mistake in RFC 3864. In principle, agreed, although who knows when.=20 > The second problem is funnier. Guess how the RFC 3864 registry, which = has been > held up as a model Not true. > is structured. That's right, two separate pages. In the > case of RFC 3864 separate pages are actually totally inappropriate, = but they > are not only appropriate, they are essential, here. Yep, we've asked IANA to change this, no response yet... > Anyway, after all this is over I have every intention of filing an = errata on > RFC 3864 pointing out that it's misusing the term "provisional". And = just for > the lutz, I may also point out that the separate pages is also an = error. I think the term that the kids use is "lulz."=20 >> Mark could address this if he feels so moved in his happiana efforts, = but I >> don't think it's a showstopper for this particular document. >=20 > I don't see how. Happiana is about, well, I'm not entirely sure what = it's about > any more. You had that information previously? A pity, it would have been = useful... > But one thing it cannot do is make fundamental changes to how IANA > registries are structured. If there's any attempt to do that, I for = one will > strongly object, and if necessary, appeal. Agreed. Perhaps the most straightforward thing to do at this point is put a = sentence on the IANA registry page to the effect that the sense of = "provisional" in this registry is different than that used for headers = (I don't think it's a good idea to put that sentence in the spec, = because as Ned says, hopefully we can fix the header registry one day). Cheers, -- Mark Nottingham http://www.mnot.net/ From superuser@gmail.com Mon Jun 11 05:25:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B5821F8569 for ; Mon, 11 Jun 2012 05:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMZjaxC2Z4Rd for ; Mon, 11 Jun 2012 05:25:42 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D70C121F8567 for ; Mon, 11 Jun 2012 05:25:41 -0700 (PDT) Received: by lagv3 with SMTP id v3so4147370lag.31 for ; Mon, 11 Jun 2012 05:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=n9VFZJIFxEPBvBVwsbO99lizACAIk4akhp6LCJvHLNw=; b=yekG7eHR1/Z+u9yQz4CKAvihNbym0psdAFkouplGMoyr6tftbqpZ5LVtBasQpOHQMq 85ENs+bVzka+tlAM3jTak6rKPWR36m2bOzhcoyUpX8D/Ptg0LCi9o83Ca+21zMx7C9pE oT2aVYMLxeH/G6MnEuO4yD0RrV2u0/Yx9XIDGrThIn1lWV/PRD+bF0/CB65iCvzXivrL oll+QTaPgj22GXWIMIMyBSBl53D4Mu5miAaxIl/YVvDelZk9mkUhBsfhutHDD9tOvTco vHEgR8XcnITRn34j6B4zFz6siBw5cw92D/5o5qpeEeF1PJWcXDixdgfbGGIbOAOArnyi 4/EQ== MIME-Version: 1.0 Received: by 10.112.83.198 with SMTP id s6mr3091821lby.76.1339417540772; Mon, 11 Jun 2012 05:25:40 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 11 Jun 2012 05:25:40 -0700 (PDT) Date: Mon, 11 Jun 2012 05:25:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=f46d04016b23b941ca04c23172e4 Subject: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 12:25:42 -0000 --f46d04016b23b941ca04c23172e4 Content-Type: text/plain; charset=ISO-8859-1 This note begins a Working Group Last Call on draft-ietf-appsawg-media-type-suffix-regs, ending Monday, June 25. Please review the document and comment on it. Note that its "parent" document, draft-ietf-appsawg-media-type-regs, is now in IESG Evaluation. Thanks, -MSK, APPSAWG co-chair --f46d04016b23b941ca04c23172e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This note begins a Working Group Last Call on draft-ietf-appsawg-media-type= -suffix-regs, ending Monday, June 25.=A0 Please review the document and com= ment on it.

Note that its "parent" document, draft-ietf-ap= psawg-media-type-regs, is now in IESG Evaluation.

Thanks,
-MSK, APPSAWG co-chair

--f46d04016b23b941ca04c23172e4-- From mnot@mnot.net Mon Jun 11 05:30:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6386821F858A for ; Mon, 11 Jun 2012 05:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=-3.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVNhDSNNC+Xo for ; Mon, 11 Jun 2012 05:30:05 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id BA27221F855D for ; Mon, 11 Jun 2012 05:30:05 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.56.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 81928509B4; Mon, 11 Jun 2012 08:29:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4FD5921F.4090600@gmx.de> Date: Mon, 11 Jun 2012 22:29:55 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FD5921F.4090600@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss Subject: Re: [apps-discuss] FYI: For review... draft-snell-merge-patch-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 12:30:06 -0000 On 11/06/2012, at 4:37 PM, Julian Reschke wrote: > On 2012-06-08 19:36, James M Snell wrote: >> Hello All, >>=20 >> I have submitted an updated version of draft-snell-merge-patch [1] >> that fixes a few editorial issues. >>=20 >> Feedback is quite welcome. >=20 > Hi there. >=20 > a) "application/json+merge-patch" seems like a good thing; however, I = wonder whether it wouldn't be simpler to just declare the described = semantics as "the" PATCH semantics for application/json? Can that be done retroactively? > b) on the other hand, "application/merge-patch" seems to be a = fundamentally bad idea; after all, it's not really a media type; if you = want to develop this further, I strongly recommend moving it into a = separate spec. I'm not sure it's a good idea, full stop; are the semantics actually = clear for any conceivable target format?=20 I'm also -1 on doing a +merge-patch suffix. If it's possible to abuse an = ill-defined naming convention, this is it. -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Mon Jun 11 05:40:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176B821F84E1 for ; Mon, 11 Jun 2012 05:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ru2qCNiHfRP for ; Mon, 11 Jun 2012 05:40:11 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 184E121F8497 for ; Mon, 11 Jun 2012 05:40:10 -0700 (PDT) Received: (qmail invoked by alias); 11 Jun 2012 12:40:09 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp034) with SMTP; 11 Jun 2012 14:40:09 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18HYoZT3LMHjhPE64r0U2RFY7z069dmwRNMm2bnfH HCzHLC5pv8FVx3 Message-ID: <4FD5E729.4050206@gmx.de> Date: Mon, 11 Jun 2012 14:40:09 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: Mark Nottingham References: <4FD5921F.4090600@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Apps Discuss Subject: Re: [apps-discuss] FYI: For review... draft-snell-merge-patch-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 12:40:12 -0000 On 2012-06-11 14:29, Mark Nottingham wrote: > > On 11/06/2012, at 4:37 PM, Julian Reschke wrote: > >> On 2012-06-08 19:36, James M Snell wrote: >>> Hello All, >>> >>> I have submitted an updated version of draft-snell-merge-patch [1] >>> that fixes a few editorial issues. >>> >>> Feedback is quite welcome. >> >> Hi there. >> >> a) "application/json+merge-patch" seems like a good thing; however, I wonder whether it wouldn't be simpler to just declare the described semantics as "the" PATCH semantics for application/json? > > Can that be done retroactively? If we update RFC 4627? > ... Best regards, Julian From wmills@yahoo-inc.com Mon Jun 11 07:29:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9B821F84EC for ; Mon, 11 Jun 2012 07:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.184 X-Spam-Level: X-Spam-Status: No, score=-15.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFMCfRu-bS5T for ; Mon, 11 Jun 2012 07:29:07 -0700 (PDT) Received: from nm20.bullet.mail.sp2.yahoo.com (nm20.bullet.mail.sp2.yahoo.com [98.139.91.90]) by ietfa.amsl.com (Postfix) with SMTP id 804BC21F84AF for ; Mon, 11 Jun 2012 07:29:06 -0700 (PDT) Received: from [98.139.91.62] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jun 2012 14:29:06 -0000 Received: from [98.139.91.47] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jun 2012 14:28:06 -0000 Received: from [127.0.0.1] by omp1047.mail.sp2.yahoo.com with NNFMP; 11 Jun 2012 14:28:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 830073.49324.bm@omp1047.mail.sp2.yahoo.com Received: (qmail 94772 invoked by uid 60001); 11 Jun 2012 14:28:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339424886; bh=ln0dng1va3LEtGyXVD+OPd9i92H9JdpVUzRPHeDfyvQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=LrzaNPpqNXequaaZ+Bz3kNNiceOodzSeBaQ+CuGn38KNqtzY5L9hNrrtPSNuQvfL8vF4YS1GPcOz3PWQSQMe7CyBmTtNE/48vrM0pHsTpRkkXL6LO/yT0U0mDYS+qWmZFjBEmFnDZQKNi6ubaDKwcH7YrZ8ufyPCsquHQprm9ZU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=KTdTNarrudylxcLl6zKr4V5l+3oCbGBnXr1DZ58xwhsfDhNURykGnTgn/I5M9M6H7kRGoaWa2AvG4zdRAF0PxBuv2+eA6Y8W0dCbbvogYfV+PS4cbwdyuhdUAeWGvUJup0x+BD5MWfccXGu45YoTXs08PjWBlC75eA+nUJmpk+I=; X-YMail-OSG: r3xlLK8VM1kLPW.QhzfUaIYHuBNgcaOBlPPdtLFY4tBXC6u 8BNFsfTMQWkBl6zBWTog20AnKUQuV2zlBiECAcoF7.CGIJMT_tUW9oBl6V0u AAppkeoM1YrdV9IUZOuo75FjnguPAEE1om5M8gWDtPV0zhTw6FlrlR4kx7VM uNfR.6bxVbYoCDwvoXlKEm0PxgYx0g3reeeEXZeIbSHFVRGhBUHNINVVk8Kk .KrF8dOAojuDRab5sGO5oufgALpv3baJMIX1FADxwIWhzVxNRls04lh0_Pz3 0IwUqrhURFePKtqyGxmGoGAjTLRGwPJsBBF66T6G3AhnguGGPFf8Twp5ojFi rXWIKw_hMvl7W7qcfATn6CYXW_LocWV9rTt4MXXWoIo4.EiAoMJ74AJGb5XQ WeDJOAPfbBadn.rXllfm5x_8uomEFs_AuC56A2mTCWrtU1gg9yRleJo6pZRS 61mXWEvKEvfFUYK.diH1EA.Im3go1iHZ1z1mp70hmxF_7I6BSWCxjmWhyF4U X5U9OERDaKPa5fVVeFBX0Y9np Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Mon, 11 Jun 2012 07:28:06 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: Message-ID: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Mon, 11 Jun 2012 07:28:06 -0700 (PDT) From: William Mills To: Michiel de Jong , Apps Discuss In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-802201582-1339424886=:85821" Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 14:29:08 -0000 ---1238014912-802201582-1339424886=:85821 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I think it would be odd to change the working name of the extant draft for = what is really a relatively small set of changes.=A0 I do not think we shou= ld change the name.=0A=0A-bill=0A=0AP.S. if we were starting from scratch p= icking names I would favor SWD over WF=0A=0A=0A=0A=0A=0A>__________________= ______________=0A> From: Michiel de Jong =0A>To: Apps= Discuss =0A>Sent: Sunday, June 10, 2012 12:07 AM= =0A>Subject: [apps-discuss] using the name "simple web discovery" to replac= e the name "webfinger"?=0A> =0A>The webfinger spec=0A>(http://tools.ietf.or= g/html/draft-jones-appsawg-webfinger-05 ) and the=0A>simple web discovery s= pec=0A>(http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 ) ar= e=0A>being merged into one thing.=0A>=0A>We need a name to refer to the res= ult of this merge. This means we=0A>need to pick one of the names to go for= ward with, and deprecate the=0A>other name, or pick a new name altogether a= nd deprecate both current=0A>names.=0A>=0A>I think currently 'bare user@hos= t vs acct:user@host' and 'xml or json=0A>vs only json' are two points that = still need to be resolved before the=0A>merge is complete, right? Anyway, t= hat's not the topic of this thread=0A>- let's just suppose a consensus will= be reached, and the specs will=0A>be merged.=0A>=0A>Then, I think Blaine C= ook, Paul Jones and Mike Jones have all=0A>indicated in previous threads th= at they are open to picking 'simple=0A>web discovery' as the new name.=0A>= =0A>FWIW, i personally am the kind of person who enjoys giving nice names= =0A>to things, and i particularly enjoy saying 'webfinger' because it's=0A>= more creative, less boring, and funnier as a name. Also, to me it=0A>makes = perfect sense that it's "finger for the web". However, in my=0A>experience = explaining to people that remoteStorage=0A>(http://www.w3.org/community/unh= osted/wiki/RemoteStorage ) combines=0A>XHR with CORS, OAuth and webfinger, = people usually know what XHR is=0A>(especially if i call it AJAX), 50% know= what OAuth is, and for CORS=0A>the face i get from them is 'oh that must b= e some sort of special=0A>mechanism'.=0A>=0A>The face i sometimes (not alwa= ys) get for webfinger is 'huh? is that a=0A>real thing?'. :) also, when i d= o explain webfinger to people, unless=0A>they look like old school finger u= sers, i tell them it is 'a simple=0A>mechanism for=A0 discovering service o= n the web'. So it is my opinion=0A>that 'simple web discovery' would be a (= more boring, but) better name=0A>than 'webfinger'. A downside would be that= we need to update it=0A>everywhere, but i guess we can get over that.=0A>= =0A>maybe other people have other experiences or insights about this name c= hoice?=0A>=0A>=0A>Cheers,=0A>Michiel=0A>___________________________________= ____________=0A>apps-discuss mailing list=0A>apps-discuss@ietf.org=0A>https= ://www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A> ---1238014912-802201582-1339424886=:85821 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I think it would be odd to change the working name of the extant draft fo= r what is really a relatively small set of changes.  I do not think we= should change the name.

-bill

P.S.= if we were starting from scratch picking names I would favor SWD over WF



<= b>From: Michiel de Jong <michiel@u= nhosted.org>
To: Ap= ps Discuss <apps-discuss@ietf.org>
Sent: Sunday, June 10, 2012 12:07 AM
Subject: [apps-discuss] using the name "= simple web discovery" to replace the name "webfinger"?
<= br>=0AThe webfinger spec
(http://tools.ietf.org/html/draft-jones-appsawg= -webfinger-05 ) and the
simple web discovery spec
(http://tools.ietf.= org/html/draft-jones-simple-web-discovery-02 ) are
being merged into one= thing.

We need a name to refer to the result of this merge. This me= ans we
need to pick one of the names to go forward with, and deprecate t= he
other name, or pick a new name altogether and deprecate both current<= br>names.

I think currently 'bare user@host vs acct:user@host' and '= xml or json
vs only json' are two points that still need to be resolved = before the
merge is complete, right? Anyway, that's not the topic of thi= s thread
- let's just suppose a consensus will be reached, and the specs= will
be merged.

Then, I think Blaine Cook, Paul Jones and Mike J= ones have all
indicated in previous threads that they are open to pickin= g 'simple
web discovery' as the new name.

FWIW, i personally am the kind of person who enjoys giving nice names
to things, and i partic= ularly enjoy saying 'webfinger' because it's
more creative, less boring,= and funnier as a name. Also, to me it
makes perfect sense that it's "fi= nger for the web". However, in my
experience explaining to people that r= emoteStorage
(http://www.w3.org/community/unhosted/wiki/RemoteStorage ) = combines
XHR with CORS, OAuth and webfinger, people usually know what XH= R is
(especially if i call it AJAX), 50% know what OAuth is, and for COR= S
the face i get from them is 'oh that must be some sort of special
m= echanism'.

The face i sometimes (not always) get for webfinger is 'h= uh? is that a
real thing?'. :) also, when i do explain webfinger to peop= le, unless
they look like old school finger users, i tell them it is 'a = simple
mechanism for  discovering service on the web'. So it is my = opinion
that 'simple web discovery' would be a (more boring, but) better name
than 'webfinger'. A downside would be that we need to updat= e it
everywhere, but i guess we can get over that.

maybe other pe= ople have other experiences or insights about this name choice?


= Cheers,
Michiel
_______________________________________________
ap= ps-discuss mailing list
apps-discuss@ietf.org
https:= //www.ietf.org/mailman/listinfo/apps-discuss


=
---1238014912-802201582-1339424886=:85821-- From stpeter@stpeter.im Mon Jun 11 07:34:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4783F21F859E for ; Mon, 11 Jun 2012 07:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x21TrXssuQV8 for ; Mon, 11 Jun 2012 07:34:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BE84021F8633 for ; Mon, 11 Jun 2012 07:34:52 -0700 (PDT) Received: from [64.101.72.28] (unknown [64.101.72.28]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E0F644005A; Mon, 11 Jun 2012 08:51:57 -0600 (MDT) Message-ID: <4FD6020A.7090702@stpeter.im> Date: Mon, 11 Jun 2012 08:34:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: William Mills References: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> In-Reply-To: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 14:34:55 -0000 Agreed. I think that, at this point, such a name change would be confusing. And I've had enough of confusing name changes this year (yes, I'm on the SCIM list...). On 6/11/12 8:28 AM, William Mills wrote: > I think it would be odd to change the working name of the extant draft > for what is really a relatively small set of changes. I do not think we > should change the name. > > -bill > > P.S. if we were starting from scratch picking names I would favor SWD > over WF > > > > ------------------------------------------------------------------------ > *From:* Michiel de Jong > *To:* Apps Discuss > *Sent:* Sunday, June 10, 2012 12:07 AM > *Subject:* [apps-discuss] using the name "simple web discovery" to > replace the name "webfinger"? > > The webfinger spec > (http://tools.ietf.org/html/draft-jones-appsawg-webfinger-05 ) and the > simple web discovery spec > (http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 ) are > being merged into one thing. > > We need a name to refer to the result of this merge. This means we > need to pick one of the names to go forward with, and deprecate the > other name, or pick a new name altogether and deprecate both current > names. > > I think currently 'bare user@host vs acct:user@host' and 'xml or json > vs only json' are two points that still need to be resolved before the > merge is complete, right? Anyway, that's not the topic of this thread > - let's just suppose a consensus will be reached, and the specs will > be merged. > > Then, I think Blaine Cook, Paul Jones and Mike Jones have all > indicated in previous threads that they are open to picking 'simple > web discovery' as the new name. > > FWIW, i personally am the kind of person who enjoys giving nice names > to things, and i particularly enjoy saying 'webfinger' because it's > more creative, less boring, and funnier as a name. Also, to me it > makes perfect sense that it's "finger for the web". However, in my > experience explaining to people that remoteStorage > (http://www.w3.org/community/unhosted/wiki/RemoteStorage ) combines > XHR with CORS, OAuth and webfinger, people usually know what XHR is > (especially if i call it AJAX), 50% know what OAuth is, and for CORS > the face i get from them is 'oh that must be some sort of special > mechanism'. > > The face i sometimes (not always) get for webfinger is 'huh? is that a > real thing?'. :) also, when i do explain webfinger to people, unless > they look like old school finger users, i tell them it is 'a simple > mechanism for discovering service on the web'. So it is my opinion > that 'simple web discovery' would be a (more boring, but) better name > than 'webfinger'. A downside would be that we need to update it > everywhere, but i guess we can get over that. > > maybe other people have other experiences or insights about this > name choice? > > > Cheers, > Michiel > _______________________________________________ > 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 > -- Peter Saint-Andre https://stpeter.im/ From bobwyman@gmail.com Mon Jun 11 07:55:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8F521F8639 for ; Mon, 11 Jun 2012 07:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUME-lvoyTmP for ; Mon, 11 Jun 2012 07:55:27 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD86B21F8573 for ; Mon, 11 Jun 2012 07:55:26 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3031003ggn.31 for ; Mon, 11 Jun 2012 07:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PSS7XVyECwhHYLPAEOz7gMA6u+hkUhYubpkslXSyCUk=; b=zXqmYLUxNAJb9PPKdpJ+hYPe70dlORjQW+9qn+1Vq3laXIDc6AzQCirhDvLqUKnNNM 9CnU8KFdNG0+6dwWGPHAPjGIx7ldtQ0FKb8BIUNrBWgCsM+G8GWwOubpiRGZXeWSB8U8 8NvtgVvVb+oV3obDSpxGNamPOI5OdAQ8/IzohdD/viNOaqdzJ3rDGQgPUhIZUHlCqDiW 54R2ilA7+yU6lzAXOpOV75zzjodgFuA230K+p+xUD5Cb6kRPptwEc39AL7pdYOxujlEV 3qTQ+EmJt7vu0c0bQXCZbA/hIHzi+Ej+D1tdf2PPp/fzwkBsVHys1IDXE97/X2p5vbBa 9jBQ== MIME-Version: 1.0 Received: by 10.101.23.4 with SMTP id a4mr6520408anj.13.1339426526459; Mon, 11 Jun 2012 07:55:26 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.100.95.20 with HTTP; Mon, 11 Jun 2012 07:55:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Jun 2012 10:55:26 -0400 X-Google-Sender-Auth: aHKzhElrCXqbTCh0Glxrr3js3r8 Message-ID: From: Bob Wyman To: Michiel de Jong Content-Type: multipart/alternative; boundary=00504502eb954ff8b404c2338aa1 Cc: Apps Discuss Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 14:55:28 -0000 --00504502eb954ff8b404c2338aa1 Content-Type: text/plain; charset=ISO-8859-1 I oppose changing the name. We've been talking about WebFinger for many years now and much context and history would be lost if the name changed. The SWD stuff is a relative newcomer not to mention a fairly vague name. I see no value in changing the name -- only downsides. bob wyman On Sun, Jun 10, 2012 at 3:07 AM, Michiel de Jong wrote: > The webfinger spec > (http://tools.ietf.org/html/draft-jones-appsawg-webfinger-05 ) and the > simple web discovery spec > (http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 ) are > being merged into one thing. > > We need a name to refer to the result of this merge. This means we > need to pick one of the names to go forward with, and deprecate the > other name, or pick a new name altogether and deprecate both current > names. > > I think currently 'bare user@host vs acct:user@host' and 'xml or json > vs only json' are two points that still need to be resolved before the > merge is complete, right? Anyway, that's not the topic of this thread > - let's just suppose a consensus will be reached, and the specs will > be merged. > > Then, I think Blaine Cook, Paul Jones and Mike Jones have all > indicated in previous threads that they are open to picking 'simple > web discovery' as the new name. > > FWIW, i personally am the kind of person who enjoys giving nice names > to things, and i particularly enjoy saying 'webfinger' because it's > more creative, less boring, and funnier as a name. Also, to me it > makes perfect sense that it's "finger for the web". However, in my > experience explaining to people that remoteStorage > (http://www.w3.org/community/unhosted/wiki/RemoteStorage ) combines > XHR with CORS, OAuth and webfinger, people usually know what XHR is > (especially if i call it AJAX), 50% know what OAuth is, and for CORS > the face i get from them is 'oh that must be some sort of special > mechanism'. > > The face i sometimes (not always) get for webfinger is 'huh? is that a > real thing?'. :) also, when i do explain webfinger to people, unless > they look like old school finger users, i tell them it is 'a simple > mechanism for discovering service on the web'. So it is my opinion > that 'simple web discovery' would be a (more boring, but) better name > than 'webfinger'. A downside would be that we need to update it > everywhere, but i guess we can get over that. > > maybe other people have other experiences or insights about this name > choice? > > > Cheers, > Michiel > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --00504502eb954ff8b404c2338aa1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I oppose changing the name. We've been talking about WebFinger for many= years now and much context and history would be lost if the name changed. = The SWD stuff is a relative newcomer not to mention a fairly vague name. I = see no value in changing the name -- only downsides.

bob wyman

On Sun, Jun 10, = 2012 at 3:07 AM, Michiel de Jong <michiel@unhosted.org> w= rote:
The webfinger spec
(http://tools.ietf.org/html/draft-jones-appsawg-webfinger-05= ) and the
simple web discovery spec
(http://tools.ietf.org/html/draft-jones-simple-web-discov= ery-02 ) are
being merged into one thing.

We need a name to refer to the result of this merge. This means we
need to pick one of the names to go forward with, and deprecate the
other name, or pick a new name altogether and deprecate both current
names.

I think currently 'bare user@host vs acct:user@host' and 'xml o= r json
vs only json' are two points that still need to be resolved before the<= br> merge is complete, right? Anyway, that's not the topic of this thread - let's just suppose a consensus will be reached, and the specs will be merged.

Then, I think Blaine Cook, Paul Jones and Mike Jones have all
indicated in previous threads that they are open to picking 'simple
web discovery' as the new name.

FWIW, i personally am the kind of person who enjoys giving nice names
to things, and i particularly enjoy saying 'webfinger' because it&#= 39;s
more creative, less boring, and funnier as a name. Also, to me it
makes perfect sense that it's "finger for the web". However, = in my
experience explaining to people that remoteStorage
(http://www.w3.org/community/unhosted/wiki/RemoteStorage ) c= ombines
XHR with CORS, OAuth and webfinger, people usually know what XHR is
(especially if i call it AJAX), 50% know what OAuth is, and for CORS
the face i get from them is 'oh that must be some sort of special
mechanism'.

The face i sometimes (not always) get for webfinger is 'huh? is that a<= br> real thing?'. :) also, when i do explain webfinger to people, unless they look like old school finger users, i tell them it is 'a simple
mechanism for =A0discovering service on the web'. So it is my opinion that 'simple web discovery' would be a (more boring, but) better na= me
than 'webfinger'. A downside would be that we need to update it
everywhere, but i guess we can get over that.

maybe other people have other experiences or insights about this name choic= e?


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

--00504502eb954ff8b404c2338aa1-- From paul.hoffman@vpnc.org Mon Jun 11 09:09:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F5A21F8637 for ; Mon, 11 Jun 2012 09:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aR84hzTENRzS for ; Mon, 11 Jun 2012 09:09:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4291021F8634 for ; Mon, 11 Jun 2012 09:09:17 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5BG9FvB057472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Jun 2012 09:09:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FD6020A.7090702@stpeter.im> Date: Mon, 11 Jun 2012 09:09:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <89991092-A5BD-412B-BBDD-6E0470A55662@vpnc.org> References: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD6020A.7090702@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:09:18 -0000 On Jun 11, 2012, at 7:34 AM, Peter Saint-Andre wrote: > Agreed. I think that, at this point, such a name change would be > confusing. The name "webfinger" is also confusing and not nearly as descriptive as = "web discovery" (which some people might think of as "simple"). The = confusion of changing the name now is limited; the confusion for using = the wrong name in the protocol is long-term. +1 to "[simple] web discovery".= From stpeter@stpeter.im Mon Jun 11 09:27:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE78421F8656 for ; Mon, 11 Jun 2012 09:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI6Nv97ngItH for ; Mon, 11 Jun 2012 09:27:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0DC21F864F for ; Mon, 11 Jun 2012 09:27:10 -0700 (PDT) Received: from [64.101.72.28] (unknown [64.101.72.28]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8AD534005A; Mon, 11 Jun 2012 10:44:15 -0600 (MDT) Message-ID: <4FD61C5C.9030701@stpeter.im> Date: Mon, 11 Jun 2012 10:27:08 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Paul Hoffman References: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD6020A.7090702@stpeter.im> <89991092-A5BD-412B-BBDD-6E0470A55662@vpnc.org> In-Reply-To: <89991092-A5BD-412B-BBDD-6E0470A55662@vpnc.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:27:10 -0000 On 6/11/12 10:09 AM, Paul Hoffman wrote: > On Jun 11, 2012, at 7:34 AM, Peter Saint-Andre wrote: > >> Agreed. I think that, at this point, such a name change would be >> confusing. > > The name "webfinger" is also confusing and not nearly as descriptive as "web discovery" (which some people might think of as "simple"). The confusion of changing the name now is limited; the confusion for using the wrong name in the protocol is long-term. > > +1 to "[simple] web discovery". But some members of the current IESG will probably object to "simple", as witness the SCIM debate. Peter -- Peter Saint-Andre https://stpeter.im/ From phil.hunt@oracle.com Mon Jun 11 09:29:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E01621F85CC for ; Mon, 11 Jun 2012 09:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wze8hHXZCaIA for ; Mon, 11 Jun 2012 09:29:02 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 994C021F85A3 for ; Mon, 11 Jun 2012 09:29:02 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5BGT0Xc006690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jun 2012 16:29:00 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5BGSxbG010062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2012 16:28:59 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5BGSx99010795; Mon, 11 Jun 2012 11:28:59 -0500 Received: from [192.168.1.7] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Jun 2012 09:28:59 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <4FD61C5C.9030701@stpeter.im> Date: Mon, 11 Jun 2012 09:28:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1F52E8CD-E2FF-4226-AD7F-49900DEDACC9@oracle.com> References: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD6020A.7090702@stpeter.im> <89991092-A5BD-412B-BBDD-6E0470A55662@vpnc.org> <4FD61C5C.9030701@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:29:03 -0000 I simply can't resist. "System for Web Discovery"? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-11, at 9:27 AM, Peter Saint-Andre wrote: > On 6/11/12 10:09 AM, Paul Hoffman wrote: >> On Jun 11, 2012, at 7:34 AM, Peter Saint-Andre wrote: >>=20 >>> Agreed. I think that, at this point, such a name change would be >>> confusing. >>=20 >> The name "webfinger" is also confusing and not nearly as descriptive = as "web discovery" (which some people might think of as "simple"). The = confusion of changing the name now is limited; the confusion for using = the wrong name in the protocol is long-term. >>=20 >> +1 to "[simple] web discovery". >=20 > But some members of the current IESG will probably object to "simple", > as witness the SCIM debate. >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From stpeter@stpeter.im Mon Jun 11 09:34:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D104021F8657 for ; Mon, 11 Jun 2012 09:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UYMbXRccQxR for ; Mon, 11 Jun 2012 09:34:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2B53E21F864F for ; Mon, 11 Jun 2012 09:34:47 -0700 (PDT) Received: from [64.101.72.28] (unknown [64.101.72.28]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id ED8F14005A; Mon, 11 Jun 2012 10:51:52 -0600 (MDT) Message-ID: <4FD61E25.7080306@stpeter.im> Date: Mon, 11 Jun 2012 10:34:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Phil Hunt References: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD6020A.7090702@stpeter.im> <89991092-A5BD-412B-BBDD-6E0470A55662@vpnc.org> <4FD61C5C.9030701@stpeter.im> <1F52E8CD-E2FF-4226-AD7F-49900DEDACC9@oracle.com> In-Reply-To: <1F52E8CD-E2FF-4226-AD7F-49900DEDACC9@oracle.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:34:48 -0000 On 6/11/12 10:28 AM, Phil Hunt wrote: > I simply can't resist. "System for Web Discovery"? Aaagh, please not another naming debate!!! But now that you mention it, there is a system for web discovery here: it consists of well-known URIs (RFC 5785), web linking (RFC 5988), the hostmeta document type (RFC 6145), the Extensible Resource Descriptor (XRD) and JavaScript Object Notation (JSON) Resource Descriptor (JRD) document types, the Link-based Resource Descriptor Document (LRDD) type, and now WebFinger. To rename WebFinger part of this stack "Web Discovery" would be confusing, IMHO. Peter -- Peter Saint-Andre https://stpeter.im/ From perpetual-tripper@wwelves.org Mon Jun 11 09:35:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02A521F8644 for ; Mon, 11 Jun 2012 09:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3u5LMsj49QA for ; Mon, 11 Jun 2012 09:35:56 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id 144BE21F8634 for ; Mon, 11 Jun 2012 09:35:56 -0700 (PDT) X-Originating-IP: 217.70.178.136 Received: from mfilter7-d.gandi.net (mfilter7-d.gandi.net [217.70.178.136]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id A5D66A80A0 for ; Mon, 11 Jun 2012 18:35:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter7-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter7-d.gandi.net (mfilter7-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 6plxR-ygMA8N for ; Mon, 11 Jun 2012 18:35:43 +0200 (CEST) X-Originating-IP: 217.11.53.243 Received: from localhost (243.53.11.217.in-addr.arpa.manitu.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 5078BA808E for ; Mon, 11 Jun 2012 18:35:43 +0200 (CEST) Content-Type: text/plain; charset=UTF-8 From: elf Pavlik To: apps-discuss In-reply-to: References: Date: Mon, 11 Jun 2012 16:35:41 +0000 Message-Id: <1339432324-sup-6939@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:35:57 -0000 Excerpts from Michiel de Jong's message of 2012-06-10 07:07:02 +0000: > The webfinger spec > (http://tools.ietf.org/html/draft-jones-appsawg-webfinger-05 ) and the > simple web discovery spec > (http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 ) are > being merged into one thing. >=20 > We need a name to refer to the result of this merge. This means we > need to pick one of the names to go forward with, and deprecate the > other name, or pick a new name altogether and deprecate both current > names. >=20 > I think currently 'bare user@host vs acct:user@host' and 'xml or json > vs only json' are two points that still need to be resolved before the > merge is complete, right? Anyway, that's not the topic of this thread > - let's just suppose a consensus will be reached, and the specs will > be merged. >=20 > Then, I think Blaine Cook, Paul Jones and Mike Jones have all > indicated in previous threads that they are open to picking 'simple > web discovery' as the new name. >=20 > FWIW, i personally am the kind of person who enjoys giving nice names > to things, and i particularly enjoy saying 'webfinger' because it's > more creative, less boring, and funnier as a name. Also, to me it > makes perfect sense that it's "finger for the web". However, in my > experience explaining to people that remoteStorage > (http://www.w3.org/community/unhosted/wiki/RemoteStorage ) combines > XHR with CORS, OAuth and webfinger, people usually know what XHR is > (especially if i call it AJAX), 50% know what OAuth is, and for CORS > the face i get from them is 'oh that must be some sort of special > mechanism'. >=20 > The face i sometimes (not always) get for webfinger is 'huh? is that a > real thing?'. :) also, when i do explain webfinger to people, unless > they look like old school finger users, i tell them it is 'a simple > mechanism for discovering service on the web'. So it is my opinion > that 'simple web discovery' would be a (more boring, but) better name > than 'webfinger'. A downside would be that we need to update it > everywhere, but i guess we can get over that. >=20 > maybe other people have other experiences or insights about this name c= hoice? i would keep in mind that quite a lot of code bases use 'webfinger', not = sure how many implementations use SWD in their sources ... From ajs@anvilwalrusden.com Mon Jun 11 09:37:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB3F21F8644 for ; Mon, 11 Jun 2012 09:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWmIO2vwN1zt for ; Mon, 11 Jun 2012 09:37:01 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE8A21F8634 for ; Mon, 11 Jun 2012 09:37:01 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A49861ECB41C for ; Mon, 11 Jun 2012 16:37:00 +0000 (UTC) Date: Mon, 11 Jun 2012 12:36:58 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20120611163658.GO11684@mail.yitter.info> References: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD6020A.7090702@stpeter.im> <89991092-A5BD-412B-BBDD-6E0470A55662@vpnc.org> <4FD61C5C.9030701@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD61C5C.9030701@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:37:02 -0000 On Mon, Jun 11, 2012 at 10:27:08AM -0600, Peter Saint-Andre wrote: > But some members of the current IESG will probably object to "simple", > as witness the SCIM debate. "Elementary" instead? A -- Andrew Sullivan ajs@anvilwalrusden.com From tbray@textuality.com Mon Jun 11 09:45:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE35521F85CC for ; Mon, 11 Jun 2012 09:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=-3.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3aMXh2k5EKB for ; Mon, 11 Jun 2012 09:45:42 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 170D721F85A3 for ; Mon, 11 Jun 2012 09:45:42 -0700 (PDT) Received: by yhq56 with SMTP id 56so3201552yhq.31 for ; Mon, 11 Jun 2012 09:45:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=UAPziDfrvd7sbdw8emAZ9rkEa1QZ4WDlxRgGhlQicrI=; b=cS2OBKd51jm4f9EiN1t/cybMqTasct7H3PSlODKfQlUy1oSyAucO9IS/o9XisGTWq6 OV1BKPB/QWd4jQQgfb5hy6lY5HABGCvCX8sWdowGsOOetBgPS917iGslRPOsSfm9cFU2 LdJ0bRmFkjUB4mVYUsj8/3FxZkaJ6kISZ5S3zYSQYDXQYSMG3SzHTJwJnj1UT+nEgNkq rKQuaRc1aPy8QtAgC72U3ADKEc6WFeKXCAkcK4hg8xigCxGoPSG5Co/w7Jb1b4+SQWHY LCRgL9w+eTB+OOkw8+4QVlnJaIbWKLUnsJaiWibqaTpQWr8oX+FsZQOLpX0bOYJRWO/t 6Zfg== MIME-Version: 1.0 Received: by 10.60.8.35 with SMTP id o3mr16994296oea.45.1339433141540; Mon, 11 Jun 2012 09:45:41 -0700 (PDT) Received: by 10.182.149.8 with HTTP; Mon, 11 Jun 2012 09:45:41 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <4FD61C5C.9030701@stpeter.im> References: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD6020A.7090702@stpeter.im> <89991092-A5BD-412B-BBDD-6E0470A55662@vpnc.org> <4FD61C5C.9030701@stpeter.im> Date: Mon, 11 Jun 2012 09:45:41 -0700 Message-ID: From: Tim Bray To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=e89a8fb1f79a9a15e904c23514c7 X-Gm-Message-State: ALoCoQnIRjtXjJExH0C0z9aMXd3sCEJyWJdFVTfARTIwmdw+t8LNjE3zepBp3F1IfX6GjdBLIoPX Cc: Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:45:42 -0000 --e89a8fb1f79a9a15e904c23514c7 Content-Type: text/plain; charset=ISO-8859-1 This bikeshed should totally be turquoise, as even a little thought will reveal. -T On Mon, Jun 11, 2012 at 9:27 AM, Peter Saint-Andre wrote: > On 6/11/12 10:09 AM, Paul Hoffman wrote: > > On Jun 11, 2012, at 7:34 AM, Peter Saint-Andre wrote: > > > >> Agreed. I think that, at this point, such a name change would be > >> confusing. > > > > The name "webfinger" is also confusing and not nearly as descriptive as > "web discovery" (which some people might think of as "simple"). The > confusion of changing the name now is limited; the confusion for using the > wrong name in the protocol is long-term. > > > > +1 to "[simple] web discovery". > > But some members of the current IESG will probably object to "simple", > as witness the SCIM debate. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --e89a8fb1f79a9a15e904c23514c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This bikeshed should totally be turquoise, as even a little thought will re= veal. -T

On Mon, Jun 11, 2012 at 9:27 AM,= Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 6/11/12 10:09 AM, Paul Hoffman wrote:
> On Jun 11, 2012, at 7:34 AM, Peter Saint-Andre wrote:
>
>> Agreed. I think that, at this point, such a name change would be >> confusing.
>
> The name "webfinger" is also confusing and not nearly as des= criptive as "web discovery" (which some people might think of as = "simple"). The confusion of changing the name now is limited; the= confusion for using the wrong name in the protocol is long-term.
>
> +1 to "[simple] web discovery".

But some members of the current IESG will probably object to "simple&q= uot;,
as witness the SCIM debate.

Peter

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



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

--e89a8fb1f79a9a15e904c23514c7-- From john-ietf@jck.com Mon Jun 11 11:32:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E7021F848A for ; Mon, 11 Jun 2012 11:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVQyh2excZCv for ; Mon, 11 Jun 2012 11:32:39 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id DEEEF21F849A for ; Mon, 11 Jun 2012 11:32:38 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Se9Je-000FyT-KV; Mon, 11 Jun 2012 14:26:14 -0400 Date: Mon, 11 Jun 2012 14:32:30 -0400 From: John C Klensin To: Paul Hoffman , Peter Saint-Andre Message-ID: In-Reply-To: <89991092-A5BD-412B-BBDD-6E0470A55662@vpnc.org> References: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD6020A.7090702@stpeter.im> <89991092-A5BD-412B-BBDD-6E0470A55662@vpnc.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps Discuss Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 18:32:39 -0000 --On Monday, June 11, 2012 09:09 -0700 Paul Hoffman wrote: > The name "webfinger" is also confusing and not nearly as > descriptive as "web discovery" (which some people might think > of as "simple"). The confusion of changing the name now is > limited; the confusion for using the wrong name in the > protocol is long-term. > > +1 to "[simple] web discovery". +1. And I'd skip "simple", which has has acquired funny semantics in the IETF. Either "web discovery" or come up with another term. "Finger-like Web Discovery" would be fairly ugly, but at least moderately precise and explanatory. As as Paul points out, "webfinger" is just confusing except to insiders. john From ned.freed@mrochek.com Mon Jun 11 12:00:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2404A11E80A1 for ; Mon, 11 Jun 2012 12:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41TRFlIKU9Mh for ; Mon, 11 Jun 2012 12:00:37 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 04B9911E8087 for ; Mon, 11 Jun 2012 12:00:34 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGK4DTSPKG003EXL@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 11 Jun 2012 11:55:28 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGJ34LA5S0000058@mauve.mrochek.com>; Mon, 11 Jun 2012 11:55:25 -0700 (PDT) Message-id: <01OGK4DRIGEK000058@mauve.mrochek.com> Date: Mon, 11 Jun 2012 11:43:37 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 11 Jun 2012 22:16:03 +1000" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OGIYK8E5LM000058@mauve.mrochek.com> To: Mark Nottingham Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-media-type-regs and "provisional" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 19:00:42 -0000 > You know, there's such a thing as a CC: header, guys... By that you mean I could have cc'ed you on my original response? Very true, but please be aware that there are plenty of people out there who yell at me when I do that: "I'm already on the freakin list, stop sending me extra mail." I figure I can't win so I usually do a reply-all and hope for the best... > ... > > The second problem is funnier. Guess how the RFC 3864 registry, which has been > > held up as a model > Not true. OK, sorry for assuming that. > > is structured. That's right, two separate pages. In the > > case of RFC 3864 separate pages are actually totally inappropriate, but they > > are not only appropriate, they are essential, here. > Yep, we've asked IANA to change this, no response yet... Good idea, although it may be difficult given the language in RFC 3864's IANA Considerations - pretty clearly calls for a separation there. IANA may be balking because of that. And while an errata could be filed, it would probably end up as "for future version". Processes can be irritating sometimes. > > Anyway, after all this is over I have every intention of filing an errata on > > RFC 3864 pointing out that it's misusing the term "provisional". And just for > > the lutz, I may also point out that the separate pages is also an error. > I think the term that the kids use is "lulz." My bad. > >> Mark could address this if he feels so moved in his happiana efforts, but I > >> don't think it's a showstopper for this particular document. > > > > I don't see how. Happiana is about, well, I'm not entirely sure what it's about > > any more. > You had that information previously? A pity, it would have been useful... ;-) I see we're pretty much in agreement here, and that's actually kind of unfortunate. I should add that I view your draft as having captured what could be reasonably captured out of all that. (I think I already mentioned that I tried to address all the points you raised in the media types work, but I stopped short of a reference because I was unsure of the ultimate fate of the draft.) > Perhaps the most straightforward thing to do at this point is put a sentence > on the IANA registry page to the effect that the sense of "provisional" in this > registry is different than that used for headers (I don't think it's a good > idea to put that sentence in the spec, because as Ned says, hopefully we can > fix the header registry one day). Works for me. Do you think this deserves a mention in the IANA Considerations? Personally, I think adding it would be a good idea, but I could be convinced otherwise. Ned From john-ietf@jck.com Mon Jun 11 12:35:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5690111E8091 for ; Mon, 11 Jun 2012 12:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEP9I3tdz4iw for ; Mon, 11 Jun 2012 12:35:10 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id D18E811E808A for ; Mon, 11 Jun 2012 12:35:10 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SeAIB-000G2s-Hs; Mon, 11 Jun 2012 15:28:47 -0400 Date: Mon, 11 Jun 2012 15:35:03 -0400 From: John C Klensin To: Ned Freed , Mark Nottingham Message-ID: <6590E4497FAC7B9634A449F8@JcK-HP8200.jck.com> In-Reply-To: <01OGK4DRIGEK000058@mauve.mrochek.com> References: <01OGIYK8E5LM000058@mauve.mrochek.com> <01OGK4DRIGEK000058@mauve.mrochek.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: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-media-type-regs and "provisional" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 19:35:11 -0000 --On Monday, June 11, 2012 11:43 -0700 Ned Freed wrote: >> Perhaps the most straightforward thing to do at this point is >> put a sentence on the IANA registry page to the effect that >> the sense of "provisional" in this registry is different than >> that used for headers (I don't think it's a good idea to put >> that sentence in the spec, because as Ned says, hopefully we >> can fix the header registry one day). > > Works for me. Do you think this deserves a mention in the IANA > Considerations? Personally, I think adding it would be a good > idea, but I could be convinced otherwise. I don't see any downside, especially (given the separation problem with the RFC 3864 registry that you point out) if we can specifically instruct IANA that that are likely to be asked to remove the comment with 3864 or its registries are updated. Let's not put it in and have trouble getting rid of it because this document said so. Sometimes I really wish for the days when IANA had more than enough authority for independent action and was able to consider "good sense" as a more important criterion than rigid procedure-following. Actually, most days. john From wmills@yahoo-inc.com Mon Jun 11 13:46:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618D321F8550 for ; Mon, 11 Jun 2012 13:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.391 X-Spam-Level: X-Spam-Status: No, score=-16.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gjDhCfOHr5V for ; Mon, 11 Jun 2012 13:46:01 -0700 (PDT) Received: from nm27.bullet.mail.ac4.yahoo.com (nm27.bullet.mail.ac4.yahoo.com [98.139.52.224]) by ietfa.amsl.com (Postfix) with SMTP id 5519A21F8467 for ; Mon, 11 Jun 2012 13:46:00 -0700 (PDT) Received: from [98.139.52.195] by nm27.bullet.mail.ac4.yahoo.com with NNFMP; 11 Jun 2012 20:45:57 -0000 Received: from [98.139.52.163] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 11 Jun 2012 20:45:57 -0000 Received: from [127.0.0.1] by omp1046.mail.ac4.yahoo.com with NNFMP; 11 Jun 2012 20:45:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 763840.64374.bm@omp1046.mail.ac4.yahoo.com Received: (qmail 65784 invoked by uid 60001); 11 Jun 2012 20:45:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339447557; bh=SYl0XDN96uiBRLFXb0kXpVyMVov3rasSdOv3IyQgS0M=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=G7IXgPgTJ3Q3wD2zH27jxRahuqIDZl6KKydEFxCp3tfZjUTrIJToKyAQ2UZsIrEmGJFx3OjHVzITR5wzSgezZ6VK1QWWEDmg07Z7s8OhH3IaSjXJBbrmmnxm7a/8PcxkqtJQJaMdmZQhV+mWtkGtyGua8tDBZ7spOaxRZsFybXc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=H/0ew72BuV2wa/xC2GmFAliizdykDQpvRso2d2O2dmSxdPtB348e6/0+EjSjAP7CvCalV57hMn6sDjSecOcMolbPGYCgR+/h8Jpv6w3mk+jpnUjejtE7Fo9sE1tLZX7Qxl7vx1fE6Grsk1PY0PwU8o+MD+cdM73NTpvOYZFVb+c=; X-YMail-OSG: gNc5U9cVM1mjiP2dpPUho69invAKvY5ZPDJGMdJHgfCYbg8 GfiP.5ZqbhG19CAHONiJF1_zsHjkSoA3X98qQ753UTvzdkzZXSMN8Zr8I7h4 L_tKW0U3qvcJ7loeNT4PN1i6llQgBVx_h_5.bHMTHPxaYct7jF0bgbdJT7cc oCF0b2uPFYhMSFLMY3lIDl_r2MaRxMyjN2OSk9VgpE8b7Wq9LomPgQ6pqDKx 2KZAn3pPibHES9KG0Nk3YiAEmAs1iTjgRMfUGFzFnbBXUuYTFcRoJu5DuBJW .rfMUOMcSxTga8sMw4WVDUOa5Y05MVA8BN8EQgwWzl74O1slnMOiSu2y0I_w Wz5vIoj7DrpYZL2YONtr_G_ehFa8Pwn4TimHUcJNucqIQ6ejs3PtcD0tv.WW jqlzsx1f4t3hEWosLP33X2ghtcOwtxkmEB2MGxrwvgxuXRaDpPed_ Received: from [209.131.62.115] by web31809.mail.mud.yahoo.com via HTTP; Mon, 11 Jun 2012 13:45:56 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD6020A.7090702@stpeter.im> <89991092-A5BD-412B-BBDD-6E0470A55662@vpnc.org> Message-ID: <1339447556.65766.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Mon, 11 Jun 2012 13:45:56 -0700 (PDT) From: William Mills To: John C Klensin , Paul Hoffman , Peter Saint-Andre In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-1862814023-1339447556=:65766" Cc: Apps Discuss Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 20:46:02 -0000 ---1395015409-1862814023-1339447556=:65766 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Here I think is the key question....=A0 If we did not have the SWD draft be= ing rolled in, would a name change be considered?=A0 Ignore the name SWD fo= r now, would we consider changing the name at all?=0A=0AI doubt it.=0A=0A-b= ill=0A=0A=0A=0A=0A>________________________________=0A> From: John C Klensi= n =0A>To: Paul Hoffman ; Peter Sa= int-Andre =0A>Cc: Apps Discuss = =0A>Sent: Monday, June 11, 2012 11:32 AM=0A>Subject: Re: [apps-discuss] us= ing the name "simple web discovery" to replace the name "webfinger"?=0A> = =0A>=0A>=0A>--On Monday, June 11, 2012 09:09 -0700 Paul Hoffman=0A> wrote:=0A>=0A>> The name "webfinger" is also confusing and = not nearly as=0A>> descriptive as "web discovery" (which some people might = think=0A>> of as "simple"). The confusion of changing the name now is=0A>> = limited; the confusion for using the wrong name in the=0A>> protocol is lon= g-term.=0A>> =0A>> +1 to "[simple] web discovery".=0A>=0A>+1.=A0 And I'd sk= ip "simple", which has has acquired funny=0A>semantics in the IETF.=A0 Eith= er "web discovery" or come up with=0A>another term.=A0 "Finger-like Web Dis= covery" would be fairly ugly,=0A>but at least moderately precise and explan= atory.=A0 As as Paul=0A>points out, "webfinger" is just confusing except to= insiders.=0A>=0A>=A0 john=0A>=0A>________________________________________= _______=0A>apps-discuss mailing list=0A>apps-discuss@ietf.org=0A>https://ww= w.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A> ---1395015409-1862814023-1339447556=:65766 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Here I think is the key question....  If we did not have the SWD dra= ft being rolled in, would a name change be considered?  Ignore the nam= e SWD for now, would we consider changing the name at all?

I doubt it.

<= /span>
-bill


From: John C Klensin <john-ietf@jck.com>
= To: Paul Hoffman <paul.hoffman@= vpnc.org>; Peter Saint-Andre <stpeter@stpeter.im>
Cc: Apps Discuss <apps-discuss@ietf= .org>
Sent: Monday= , June 11, 2012 11:32 AM
Subject:= Re: [apps-discuss] using the name "simple web discovery" to rep= lace the name "webfinger"?

=0A

--On Monday, J= une 11, 2012 09:09 -0700 Paul Hoffman
<paul.hoffman@vpnc.org> wrote:

> The name "webfinger" is also confusing and not n= early as
> descriptive as "web discovery" (which some people might th= ink
> of as "simple"). The confusion of changing the name now is
&= gt; limited; the confusion for using the wrong name in the
> protocol= is long-term.
>
> +1 to "[simple] web discovery".

+1.&= nbsp; And I'd skip "simple", which has has acquired funny
semantics in t= he IETF.  Either "web discovery" or come up with
another term. = ; "Finger-like Web Discovery" would be fairly ugly,
but at least moderat= ely precise and explanatory.  As as Paul
points out, "webfinger" is= just confusing except to insiders.

 =20 john

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


---1395015409-1862814023-1339447556=:65766-- From paul.hoffman@vpnc.org Mon Jun 11 13:50:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CEB21F856C for ; Mon, 11 Jun 2012 13:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1oTQBBSl+f0 for ; Mon, 11 Jun 2012 13:50:36 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2AF21F8505 for ; Mon, 11 Jun 2012 13:50:36 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5BKoYF3087246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Jun 2012 13:50:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <1339447556.65766.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Mon, 11 Jun 2012 13:50:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <07DB9653-EA18-4FE9-B93C-EE56D408A630@vpnc.org> References: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD6020A.7090702@stpeter.im> <89991092-A5BD-412B-BBDD-6E0470A55662@vpnc.org> <1339447556.65766.YahooMailNeo@web31809.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 20:50:36 -0000 On Jun 11, 2012, at 1:45 PM, William Mills wrote: > Here I think is the key question.... If we did not have the SWD draft = being rolled in, would a name change be considered? Ignore the name SWD = for now, would we consider changing the name at all? >=20 > I doubt it. Don't doubt it. At least a few of us were talking about it in the halls = in Paris. --Paul Hoffman From romeda@gmail.com Mon Jun 11 13:51:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1780921F8505 for ; Mon, 11 Jun 2012 13:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsAq061hxeb2 for ; Mon, 11 Jun 2012 13:51:14 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id EDE1011E8093 for ; Mon, 11 Jun 2012 13:51:13 -0700 (PDT) Received: by lagv3 with SMTP id v3so4610793lag.31 for ; Mon, 11 Jun 2012 13:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KyFQq29UJgvbTMzVCK71juXNt4qAGIKcxrwuVGNSETg=; b=HCwJsn3FEyVKb2QihZDdKxQYc8VHkkZUK2BRsqjAB15504b+gpLRgSwEHW4MZ0m9T4 EM5kn8OmjwW0I9QgKEuckVefHduQKFaelCswpvXmVCpnbZ1ScKBIFpRolM37VJiHj/yO jenb6b9s93IDkd+hamcoibWpOQVM/fl9WauFco+BZdm92xEvDzYBm1V5jAheeArzU4/a 5F2i0tyj1crJC1OxM5ud9bq4qXxTyH45h1R6DS6MUbKP2xsoes/mGI0ivgUJCVVOCroz kHT0b5fLL5O5W39a3mwASQNBNUVOQEABhRwmjfq8gIcaxzmuCM+Hl+/AscQOozwlYRRM sgPQ== Received: by 10.112.82.197 with SMTP id k5mr3683781lby.98.1339447872804; Mon, 11 Jun 2012 13:51:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.10.136 with HTTP; Mon, 11 Jun 2012 13:50:51 -0700 (PDT) In-Reply-To: References: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD6020A.7090702@stpeter.im> <89991092-A5BD-412B-BBDD-6E0470A55662@vpnc.org> <4FD61C5C.9030701@stpeter.im> From: Blaine Cook Date: Mon, 11 Jun 2012 21:50:51 +0100 Message-ID: To: Tim Bray Content-Type: text/plain; charset=UTF-8 Cc: Apps Discuss , Paul Hoffman Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 20:51:15 -0000 You're way off base here, Tim (don't worry, you're not alone). Clearly the merged spec should be called "Simple Web Finger II: Discovery". b. On 11 June 2012 17:45, Tim Bray wrote: > This bikeshed should totally be turquoise, as even a little thought will > reveal. -T > > > On Mon, Jun 11, 2012 at 9:27 AM, Peter Saint-Andre > wrote: >> >> On 6/11/12 10:09 AM, Paul Hoffman wrote: >> > On Jun 11, 2012, at 7:34 AM, Peter Saint-Andre wrote: >> > >> >> Agreed. I think that, at this point, such a name change would be >> >> confusing. >> > >> > The name "webfinger" is also confusing and not nearly as descriptive as >> > "web discovery" (which some people might think of as "simple"). The >> > confusion of changing the name now is limited; the confusion for using the >> > wrong name in the protocol is long-term. >> > >> > +1 to "[simple] web discovery". >> >> But some members of the current IESG will probably object to "simple", >> as witness the SCIM debate. >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From ve7jtb@ve7jtb.com Mon Jun 11 13:52:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9CD21F8505 for ; Mon, 11 Jun 2012 13:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EFp-is5Vv1A for ; Mon, 11 Jun 2012 13:52:18 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BEE6A11E8098 for ; Mon, 11 Jun 2012 13:52:12 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2403419wgb.13 for ; Mon, 11 Jun 2012 13:52:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer:x-gm-message-state; bh=p7G+Pnaampy1eEAb+G5VDNTAcAfLKsJ2RfTLk+FVimE=; b=aTw3P2ZI1xP16K0xfYSbccGy2z8RpTsVsm6seQtXX9Vnv6STnaIhAeUrM0jcP6gyjB 9nOWq0CxgxWBYzGWU4ZETnlgWwj+HkcRkMWznqekJ+uLJIGN2GAbKE2dr4zytEvo2Crt drkdZIujieCq2xylOlTDyhMhCZo3Qbce7wBp6Dt4N6A4yH4XuyHcmVOD9SLE4bU40sg2 v1s0ym/48zqsSBGLDB8eDX19WGg+FzNVfldn39HF1hiGQ52fpK7sF5/YPtcN4P58aYeP BXWsOykwGnUGGrLUWDmJmdYUBdpCJfrCLgN+IE9DxUGjhYK+hpDBNhawDQIwPixdWQOC vdlg== Received: by 10.216.218.144 with SMTP id k16mr6947670wep.215.1339447932047; Mon, 11 Jun 2012 13:52:12 -0700 (PDT) Received: from [10.0.0.90] (host-92-27-146-217.static.as13285.net. [92.27.146.217]) by mx.google.com with ESMTPS id fo7sm807120wib.9.2012.06.11.13.52.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jun 2012 13:52:11 -0700 (PDT) From: John Bradley Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_BFB9CC16-129B-4B9E-A9C3-5267E6A044E3" Date: Mon, 11 Jun 2012 21:52:08 +0100 In-Reply-To: <1339447556.65766.YahooMailNeo@web31809.mail.mud.yahoo.com> To: Apps Discuss References: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD6020A.7090702@stpeter.im> <89991092-A5BD-412B-BBDD-6E0470A55662@vpnc.org> <1339447556.65766.YahooMailNeo@web31809.mail.mud.yahoo.com> Message-Id: <0C6BD428-9CBA-4C78-AAA7-546686ACAA87@ve7jtb.com> X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlSWTw2HPUK7pPjqMHdC6WfhPa1JzRD0AH+zd2CBf3q+3Ej7X6qK91QBDUtDQmOMBGMORNh Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 20:52:19 -0000 --Apple-Mail=_BFB9CC16-129B-4B9E-A9C3-5267E6A044E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I would prefer to get agreement on all the remaining issues needed = before the merge before worrying about the name. This was not an issue raised by any of the SWD people. =20 The scheme issue is probably the largest outstanding difference. I know Mike J. and Paul J. have been talking. Can we get a list of open issues, not including this distraction? John B. On 2012-06-11, at 9:45 PM, William Mills wrote: > Here I think is the key question.... If we did not have the SWD draft = being rolled in, would a name change be considered? Ignore the name SWD = for now, would we consider changing the name at all? >=20 > I doubt it. >=20 > -bill >=20 > From: John C Klensin > To: Paul Hoffman ; Peter Saint-Andre = =20 > Cc: Apps Discuss =20 > Sent: Monday, June 11, 2012 11:32 AM > Subject: Re: [apps-discuss] using the name "simple web discovery" to = replace the name "webfinger"? >=20 >=20 >=20 > --On Monday, June 11, 2012 09:09 -0700 Paul Hoffman > wrote: >=20 > > The name "webfinger" is also confusing and not nearly as > > descriptive as "web discovery" (which some people might think > > of as "simple"). The confusion of changing the name now is > > limited; the confusion for using the wrong name in the > > protocol is long-term. > >=20 > > +1 to "[simple] web discovery". >=20 > +1. And I'd skip "simple", which has has acquired funny > semantics in the IETF. Either "web discovery" or come up with > another term. "Finger-like Web Discovery" would be fairly ugly, > but at least moderately precise and explanatory. As as Paul > points out, "webfinger" is just confusing except to insiders. >=20 > john >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_BFB9CC16-129B-4B9E-A9C3-5267E6A044E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = would prefer to get agreement on all the remaining issues needed before = the merge before worrying about the name.

This was = not an issue raised by any of the SWD people. =  

The scheme issue is probably the largest = outstanding difference.

I know Mike J. and Paul = J. have been talking.

Can we get a list of open = issues,  not including this = distraction?

John B.

On = 2012-06-11, at 9:45 PM, William Mills wrote:

Here I = think is the key question....  If we did not have the SWD draft = being rolled in, would a name change be considered?  Ignore the = name SWD for now, would we consider changing the name at = all?

I doubt = it.

-bill

=
From: John C Klensin <john-ietf@jck.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>; = Peter Saint-Andre <stpeter@stpeter.im> =
Cc: Apps Discuss = <apps-discuss@ietf.org>=
Sent: Monday, = June 11, 2012 11:32 AM
Subject: Re: [apps-discuss] using the name "simple web = discovery" to replace the name "webfinger"?



--On Monday, June 11, 2012 09:09 -0700 Paul Hoffman
<paul.hoffman@vpnc.org> = wrote:

> The name "webfinger" is also confusing and not = nearly as
> descriptive as "web discovery" (which some people = might think
> of as "simple"). The confusion of changing the name = now is
> limited; the confusion for using the wrong name in = the
> protocol is long-term.
>
> +1 to "[simple] web = discovery".

+1.  And I'd skip "simple", which has has = acquired funny
semantics in the IETF.  Either "web discovery" or = come up with
another term.  "Finger-like Web Discovery" would be = fairly ugly,
but at least moderately precise and explanatory.  = As as Paul
points out, "webfinger" is just confusing except to = insiders.

 =20 = john

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

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

= --Apple-Mail=_BFB9CC16-129B-4B9E-A9C3-5267E6A044E3-- From ned.freed@mrochek.com Mon Jun 11 14:48:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84B821F852A; Mon, 11 Jun 2012 14:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OS-wd-cpVM2o; Mon, 11 Jun 2012 14:48:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CBE7121F8464; Mon, 11 Jun 2012 14:48:01 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGKA8FQ5FK003CJ7@mauve.mrochek.com>; Mon, 11 Jun 2012 14:42:56 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGIRBMUA6O0006TF@mauve.mrochek.com>; Mon, 11 Jun 2012 14:42:52 -0700 (PDT) Message-id: <01OGKA8DLA0Y0006TF@mauve.mrochek.com> Date: Mon, 11 Jun 2012 07:29:50 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 05 Jun 2012 07:23:15 -0400" <6828E9C8-3C2A-46C9-8BD1-1308000CD91B@g11.org.uk> MIME-version: 1.0 References: <6.2.5.6.2.20120521130747.0c219ab0@elandnews.com> <4FBDF199.2050300@isode.com> <4FC722A2.2050905@dcrocker.net> <4FC89931.5060201@isode.com> <4FC914DB.4000806@dcrocker.net> <4FCA6BFE.3050609@isode.com> <4FCD175D.30307@dcrocker.net> <01OGAJ8GBR2Q0006TF@mauve.mrochek.com> <1E3DCEC5990AF898F1E3582D@PST.JCK.COM> <6828E9C8-3C2A-46C9-8BD1-1308000CD91B@g11.org.uk> To: John C Klensin , Ned Freed , apps-discuss@ietf.org, draft-melnikov-smtp-priority.all@tools.ietf.org, iesg@ietf.org Cc: ken carlberg Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 21:48:04 -0000 This entire discussion has been growing increasingly abstract, and that's rarely a good thing in standards work. Rather than continue in that direction, I decided to do something I should have done a lot sooner: I implemented the draft. The fact that I have implemented this draft in Oracle Messaging Server does not imply any commitment on the part of Oracle to actually support this extension. And should Oracle decide to support it, this doesn't mean it will be done in any particular release or in any particular time frame. (Sorry about having to include that, but rules are rules.) Implementation work is usually very instructive, and this time was no exception. I'll list the simple things I learned first: (1) The draft says that the extension is valid for LMTP, but doesn't give any guidance as to what that means. This could be interpreted as saying that an implementation that uses LMTP has to support the MT-PRIORITY extension there to be compliant. That would in turn mean that prioritization has to be done on the LMTP server side, which may be a bit difficult as there's no queue there. Our implementation, and I suspect many others, handles prioritization on the LMTP client side. That said, it's entirely possible for the MT-PRIORITY to affect the LMTP server by changing processing or I/O handling in some way, or affect subsequent store access behavior, or may be needed just so it can be logged. So the extension should be allowed over LMTP, but some clarifying text is needed to say an implementation MAY choose to handle prioritization on the client side of the LMTP connection only. (2) The draft also allows MT-PRIORITY on submission, which of course makes complete sense. However, given the overall state of MUAs in the world today, it is next to certain that clients are going to be used that don't support it. (And please don't try the line that this can always be dealt with by requiring the use of certain clients. I'm talking about the real world, not fantasyland.) As such, there are going to be cases where the MSA needs to attach an MT-PRIORITY to messages that don't have one. It would be good to mention this, but even if it's not discussed there needs to be an enhanced status code defined to indicate when it has been done, and more generally to indicate when the MT-PRIORITY has been upgraded. (3) Implementations that support Sieve need to provide a way for Sieves to test the current MT-PRIORITY value. I implemented this as an environment item because that's a place that allows for implementation-specific values. The alternative would be to do it as a full-blown Sieve extension and add it to the envelope test. Given that MT-PRIORITY is an SMTP extension the envelope test is the natural place to do it, but a problem with that may be it restricts the test to implementations and situations where the envelope test itself is supported. This is not a problem for our implementation, but it may be a problem for others. Another issue is the lack of a defined comparator that will work with MT-PRIORITY values. i;ascii-numeric doesn't handle signed comparisons. An i;ascii-integer comparator is needed, so I added one and I think I'll go ahead and add the definition to the comparator registry. It may also be a bad idea to add all this in the current draft, especially given where this draft is in the process. But it needs to be done somewhere. (4) The draft doesn't say anything about logging. The current MT-PRIORITY value does appear in Received: fields, but that's not the same thing. Logging of how MT-PRIORITY is used is going to be a requirement in some environments, so a general suggestion along the lines of "MT-PRIORITY values SHOULD be logged as part of any logging of message transactions" is in order. (5) The suggested text for the X.3.TBD3 error code doesn't conform to the requirement that the text begin with the new priority value. (Note that the new error code suggested under (2) should have the same requirement.) (6) The draft talks about greylisting, but fails to mention that connection-level and SMTP HELO/HELO greylisting options exist, and when these options are used there's an issue if the trust relationship is established through the use of SASL. This needs to be pointed out. I also spotted a minor typo in the Introduction: sattelite -> satellite. The draft also spells out numbers in some places and writes them as actual numbers in others, making it hard to search for things. I don't care which approach is used as long as it is consistent. Now on to the more difficult stuff. I first need to say a few words about how our product is implemented. We have separate entities we call "channels" that messages can be routed to based on various criteria. Each channel has it's own queue for messages, and can be separately configured as to how many delivery threads to use, how frequently to retry, what IP address and port to use, and so on and so forth. Additionally, each queue supports three priorities, basically meaning higher priority messages get tended to first and will be retried more frequently. I realized right away that not only does a single channel approach not suffice because a single channel doesn't have enough available priorities (the draft requires six; see section 5), but also because even if we were to add additional queue priorities, it's unlikely that that would actually create a useful distinction between all the different priorities. For a useful distinction to exist, especially across so many different levels, you need access to things like different connections that shape traffic differently, and in our world that means different channels. So what I did was provide various hooks so that routing can be adjusted based on priority. The obvious way to configure things would be to have two channels and route three MT-PRIORITY levels to each one, but of course many other arrangements are possible, up to and including ones that fullly support 19 distinct levels. But there's no way I can guarantee that things will be configured this way. I can't even test for it, since I have no way of testing external conditions. And this is true no matter what implementation strategy I use, because any sufficiently flexible configuration mechanism can be used to defeat priority handling just as easily as it can be used to enforce it. What this means is that the six level business is really an operational requirement not an implementation requirement. What the implementation needs to do is provide the *means* to support at least six priority levels. That's all that can be reasonably expected, and the draft really needs to make that clear. This then raises the question of whether or not we should make use of this extension contingent on operational support of six levels. I think the answer to that is a rather emphatic "no" - it should be left to the service profile to decide how many levels they actually need. And that also needs to be made very clear - in particular, statements as to supporting six levels being a requirement, which sure sound like an operational requirement to me, need to either be qualified or removed. But this in turn raises another question: Should there be some indication of what service profile is being provided? Proposals have been made previously to do things like include the available priorities in the EHLO response. There are two problems with that: (1) It doesn't actually identify the profile, and (2) There's nothing a client can usefully do with the information. A better alternative would be to include some sort of profile name in the EHLO response. This wouldn't be for operational use, but rather for auditing purposes. Of course an implementation like ours, and I suspect most others, would not be done in a profile-specific way, so this would have to be a configuration option. And I'm not sufficiently fond of the idea to say it should be done. I'm only offering it as a suggestion. Notifications next. The draft says that notifications SHOULD be processed at the same priority as the message they are responding to. Having now implemented this, I'm somewhat tempted to make that a MUST, because if you try and do it any other way it's like opening a pandora's box of failure cases. Perhaps a warning to the effect that, "Regardless of the approach chosen, schemes which cause notifications to be completely lost MUST NOT be used." But the draft then goes on to say that: For delivery reports received by an MTA, processing rules specified in Section 4.1 apply. But note that while it might be tempting to handle all delivery reports (a.k.a. DSNs) at their stated priority, under the assumption that failure notices need to get through quickly in some situations, but such a policy creates an exposure to fake-DSN attacks if sources of DSNs can't be reliably established. This seemed to make sense until I tried to implement it, at which point I realized it makes no sense at all. The problem is fundamental: There is in general no way to tell whether or not you're dealing with a DSN. Yes, we have defined format for DSNs, but there are still plenty of things out there that generate DSNs in a different format. Even if we were to require support for NOTARY (and thus for our DSN format), we need to be able to make priority decisions during envelope processing, and the only indication there is the empty MAIL FROM. But while DSNs are required to use an empty MAIL FROM, the converse isn't true: Plenty of things other than DSNs use empty MAIL FROM. And if that wasn't enough, the implication here seems to be that DSNs are intrinsicly harder or more difficult to authenticate. Huh? That would seem to imply that DSNs arrive from some sort of alternate source, or we're supposed to base authentication decisions on the MAIL FROM. I don't know of any of the former and the latter is a *really* bad idea. DSNs are just messages that arrive from some source, and that source is either appropriately authenticated or it isn't. Yes, you can make make additional choices once you've received the message based on the content being a DSN, but that's no different than any other sort of content-based decisions. This isn't X.400, where DSNs aren't actually messages. I therefore strongly recommend dropping the entire paragraph except for the first sentence. And that's about it. I will say that having implementing the draft in what I think is is a useful way, I'm a lot more confident that this extension makes sense. I'll try to follow up on some of the other traffic on this topic in a bit. Ned From john-ietf@jck.com Mon Jun 11 14:51:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0DD21F853C for ; Mon, 11 Jun 2012 14:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27yRA4146vjG for ; Mon, 11 Jun 2012 14:51:11 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 126E521F8539 for ; Mon, 11 Jun 2012 14:51:11 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SeCPo-000GC3-K5; Mon, 11 Jun 2012 17:44:48 -0400 Date: Mon, 11 Jun 2012 17:51:05 -0400 From: John C Klensin To: John Bradley , Apps Discuss Message-ID: <20B76DB243AF2813F920DDD0@JcK-HP8200.jck.com> In-Reply-To: <0C6BD428-9CBA-4C78-AAA7-546686ACAA87@ve7jtb.com> References: <1339424886.85821.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD6020A.7090702@stpeter.im> <89991092-A5BD-412B-BBDD-6E0470A55662@vpnc.org> <1339447556.65766.YahooMailNeo@web31809.mail.mud.yahoo.com> <0C6BD428-9CBA-4C78-AAA7-546686ACAA87@ve7jtb.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 Subject: Re: [apps-discuss] using the name "simple web discovery" to replace the name "webfinger"? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 21:51:11 -0000 --On Monday, June 11, 2012 21:52 +0100 John Bradley wrote: > I would prefer to get agreement on all the remaining issues > needed before the merge before worrying about the name. > > This was not an issue raised by any of the SWD people. > > The scheme issue is probably the largest outstanding > difference. > > I know Mike J. and Paul J. have been talking. > > Can we get a list of open issues, not including this > distraction? John, You may reasonably consider it a distraction, but it is usually considered reasonable around the IETF for those who lack either the time or interest to be deeply involved in the details of a protocol specification to wait until there is a penultimate document in the WG (or even in IETF LC), do a review at that time, and then object to issues like naming, IANA templates, the details of Security Considerations and other "distractions". If that is the way you and others who are more actively involved prefer to have things unfold, it is fine with me. But, from experience, distractions that are dealt with well before someone asks the WG Chairs to initiate a WG Last Call, start shepherd writeups, etc., tend to be a lot less distracting than things that come up and get debated as part of the end game. john From duerst@it.aoyama.ac.jp Mon Jun 11 18:07:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25BE11E8099 for ; Mon, 11 Jun 2012 18:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.19 X-Spam-Level: X-Spam-Status: No, score=-98.19 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwZ87oOmpXJ5 for ; Mon, 11 Jun 2012 18:07:04 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2F47E11E8098 for ; Mon, 11 Jun 2012 18:07:04 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q5C16r4V010089 for ; Tue, 12 Jun 2012 10:06:53 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 7680_7a45_e5ff0cba_b42a_11e1_9745_001d096c5782; Tue, 12 Jun 2012 10:06:53 +0900 Received: from [IPv6:::1] ([133.2.210.1]:34619) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 12 Jun 2012 10:06:57 +0900 Message-ID: <4FD6962B.3050109@it.aoyama.ac.jp> Date: Tue, 12 Jun 2012 10:06:51 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Mark Nottingham References: <01OGIYK8E5LM000058@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-media-type-regs and "provisional" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 01:07:05 -0000 On 2012/06/11 21:16, Mark Nottingham wrote: > On 11/06/2012, at 5:33 AM, Ned Freed wrote: >> As for the terminology issue, there are two problems with that. First, what RFC >> 3864 calls a "provisional" registry is in fact nothing of the sort. It's a >> permanent registry - entries, one made, are never removed. The most you can do >> is move them from provisional to permanent status. > > Agreed; I think I said before that its use of the term is unfortunate. I think it's actually not too bad. From the point of view of the registry, the entry definitely can't be removed anymore. But from the point of view of the consumers of the registry, i.e. the users, I very much think that "provisional" sends the right message. It clearly sends a signal that maybe the exact definition may change, maybe more definite information will be available in the future, maybe it's not yet a good idea to use the code/label in production systems, and so on and so forth. Assuming that there are quite a bit more consumers than registrants and administrators, and that the later category can be informed better, having terminology optimized towards consumers shouldn't be such a bad idea. Regards, Martin. From ietfc@btconnect.com Tue Jun 12 02:37:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD1B21F84A7 for ; Tue, 12 Jun 2012 02:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6jhk548OhG7 for ; Tue, 12 Jun 2012 02:37:53 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8194921F8466 for ; Tue, 12 Jun 2012 02:37:53 -0700 (PDT) Received: from mail130-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Tue, 12 Jun 2012 09:36:51 +0000 Received: from mail130-ch1 (localhost [127.0.0.1]) by mail130-ch1-R.bigfish.com (Postfix) with ESMTP id 61EF43C026F; Tue, 12 Jun 2012 09:36:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I542M1432Izz1202hzz1033IL8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail130-ch1 (localhost.localdomain [127.0.0.1]) by mail130-ch1 (MessageSwitch) id 1339493809600223_3489; Tue, 12 Jun 2012 09:36:49 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail130-ch1.bigfish.com (Postfix) with ESMTP id 90CBE4E0068; Tue, 12 Jun 2012 09:36:49 +0000 (UTC) Received: from DB3PRD0702HT001.eurprd07.prod.outlook.com (157.55.224.141) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 12 Jun 2012 09:36:49 +0000 Received: from AMSPRD0610HT001.eurprd06.prod.outlook.com (157.56.248.85) by pod51017.outlook.com (10.3.4.141) with Microsoft SMTP Server (TLS) id 14.15.74.2; Tue, 12 Jun 2012 09:37:42 +0000 Message-ID: <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> From: t.petch To: Barry Leiba , References: <4FD08CA3.6080504@dcrocker.net><01OGEZDG0T8M000058@mauve.mrochek.com><4FD29DF5.5010206@dcrocker.net><01OGGS87OI0Q000058@mauve.mrochek.com> Date: Tue, 12 Jun 2012 10:34:14 +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-Originating-IP: [157.56.248.85] X-OriginatorOrg: btconnect.com Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 09:37:54 -0000 ----- Original Message ----- From: "Barry Leiba" To: Sent: Saturday, June 09, 2012 3:50 PM > On Saturday, June 9, 2012, Ned Freed wrote: > > As I said before, if the consensus is for FCFS, I'm willing to go along > since > > the number of this is likely to be small and so is the risk. > > And so I'd like to hear from more people about this. The document said > Specification Required, and we're talking about changing it to either > Expert Review or First Come First Served. You've seen the arguments on > both sides so far, but we've only heard from me, Dave, and Ned. > > Will others give opinions, please? I am a fan of Expert Review. It is a question of where the expertise is likely to be should it be needed to get technical aspects of the request into good shape; the originator of the request, IANA or the Expert. Expert Review gives us another bite of the cherry, FCFS assumes that the originator and IANA have all the necessary skills. Tom Petch > Barry From barryleiba.mailing.lists@gmail.com Tue Jun 12 07:53:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424EE21F86C3 for ; Tue, 12 Jun 2012 07:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EPiBtf71Nyq for ; Tue, 12 Jun 2012 07:53:50 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADA921F86BE for ; Tue, 12 Jun 2012 07:53:50 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so627636lbb.31 for ; Tue, 12 Jun 2012 07:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=VZWxomVpSxCL0GEIcDSvqYEQn4RzbsfVWRTsTB/fE3M=; b=D9NQbFDIZQZcKSYsM4upwxxqmDygfmbvukYejMIzA6CAQHrqaE+Ho91Y4S3HoukUJy p4tW02BLE4J2dh58GeZWnDscJsiSnP55XhI58w2aAugjDkrO16x5Rgjs4OsjrxpLKqU0 8IXqFCGr6HA160jgcP881O2vExRTzoC5y7poh2TzbjZTI3yEXSLjlJHpgYkRi7tF+dIw DqQ78dZHcR6vBp55E/ZSPQ9xh+JaERiWjJCKTzbOiKdPAhHob5aEiNMRr9fTjKt17PVF gK7LQESTCpW85kfwIqHhLFJdle8Y8ZsvV/pb5cKbjR7cGbSNk84kXwdzAFjthNOiiRtt l0cQ== MIME-Version: 1.0 Received: by 10.112.98.231 with SMTP id el7mr4820947lbb.14.1339512826512; Tue, 12 Jun 2012 07:53:46 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Tue, 12 Jun 2012 07:53:46 -0700 (PDT) In-Reply-To: <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> <01OGGS87OI0Q000058@mauve.mrochek.com> <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> Date: Tue, 12 Jun 2012 16:53:46 +0200 X-Google-Sender-Auth: F976SxaCzq5fbkV51oe3S5UP6vc Message-ID: From: Barry Leiba To: "apps-discuss@ietf.org" Content-Type: multipart/alternative; boundary=f46d0401698332466104c247a2c4 Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 14:53:51 -0000 --f46d0401698332466104c247a2c4 Content-Type: text/plain; charset=ISO-8859-1 > Expert Review gives us another bite of the cherry, FCFS assumes that the > originator and IANA have all the necessary skills. Or that the review isn't necessary. IANA is never expected to do such review. The arguments for FCFS here aren't that IANA can do it, but that for this registry review isn't necessary. Barry --f46d0401698332466104c247a2c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Expert Review gives us another = bite of the cherry, FCFS assumes that the
> originator and IANA have = all the necessary skills.

Or that the review= isn't necessary. =A0IANA is never expected to do such review.
The arguments for FCFS here= aren't that IANA can do it, but that for this registry review isn'= t necessary.

Barry
--f46d0401698332466104c247a2c4-- From ned.freed@mrochek.com Tue Jun 12 07:57:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990CC21F85A1 for ; Tue, 12 Jun 2012 07:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQu5svgJXReC for ; Tue, 12 Jun 2012 07:57:49 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id ED75321F8597 for ; Tue, 12 Jun 2012 07:57:48 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGLA77VI80003IL8@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 12 Jun 2012 07:52:44 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGIRBMUA6O0006TF@mauve.mrochek.com>; Tue, 12 Jun 2012 07:52:42 -0700 (PDT) Message-id: <01OGLA76FLMC0006TF@mauve.mrochek.com> Date: Tue, 12 Jun 2012 07:42:29 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 11 Jun 2012 15:35:03 -0400" <6590E4497FAC7B9634A449F8@JcK-HP8200.jck.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OGIYK8E5LM000058@mauve.mrochek.com> <01OGK4DRIGEK000058@mauve.mrochek.com> <6590E4497FAC7B9634A449F8@JcK-HP8200.jck.com> To: John C Klensin Cc: Mark Nottingham , Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-media-type-regs and "provisional" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 14:57:50 -0000 > --On Monday, June 11, 2012 11:43 -0700 Ned Freed > wrote: > >> Perhaps the most straightforward thing to do at this point is > >> put a sentence on the IANA registry page to the effect that > >> the sense of "provisional" in this registry is different than > >> that used for headers (I don't think it's a good idea to put > >> that sentence in the spec, because as Ned says, hopefully we > >> can fix the header registry one day). > > > > Works for me. Do you think this deserves a mention in the IANA > > Considerations? Personally, I think adding it would be a good > > idea, but I could be convinced otherwise. > I don't see any downside, especially (given the separation > problem with the RFC 3864 registry that you point out) if we can > specifically instruct IANA that that are likely to be asked to > remove the comment with 3864 or its registries are updated. > Let's not put it in and have trouble getting rid of it because > this document said so. OK, so how about: IANA is also request to add the following note at the beginning of the provisional registry: This registry, unlike some other provisional IANA registries, is only for temporary use. Entries in this registry are either finalized and move to the main media types registries, or are abandoned and deleted. Entries in this regisry are suitable for use for test purposes only. This would become the third paragraph of the IANA considerations section. As I wrote this I realized it could be done in a way that provides useful information about the registry content in addition to clarifying the discrepancy with other provisional registries. > Sometimes I really wish for the days when IANA had more than > enough authority for independent action and was able to consider > "good sense" as a more important criterion than rigid > procedure-following. Actually, most days. +1 Ned From dhc@dcrocker.net Tue Jun 12 07:59:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1080F21F85A1 for ; Tue, 12 Jun 2012 07:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtQotmbuu159 for ; Tue, 12 Jun 2012 07:59:15 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 81A7F21F86BE for ; Tue, 12 Jun 2012 07:59:15 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q5CEx6iX022844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jun 2012 07:59:07 -0700 Message-ID: <4FD75939.6060200@dcrocker.net> Date: Tue, 12 Jun 2012 07:59:05 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "t.petch" References: <4FD08CA3.6080504@dcrocker.net><01OGEZDG0T8M000058@mauve.mrochek.com><4FD29DF5.5010206@dcrocker.net><01OGGS87OI0Q000058@mauve.mrochek.com> <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> In-Reply-To: <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 12 Jun 2012 07:59:07 -0700 (PDT) Cc: Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 14:59:16 -0000 On 6/12/2012 2:34 AM, t.petch wrote: > I am a fan of Expert Review. It is a question of where the expertise is > likely to be should it be needed to get technical aspects of the request > into good shape; the originator of the request, IANA or the Expert. > Expert Review gives us another bite of the cherry, FCFS assumes that the > originator and IANA have all the necessary skills. On a separate list, abut 5 minutes ago, there is a discussion about Expert Review that just started. I found myself asserting that Expert Review will be used as a quality control for 'goodness' rather than protection against danger. The latter is actually the claimed purpose of Expert Review, not the former. This confusion is one of a number of reasons I think Expert Review needs to be limited to situations in which wayward specs can do systemic damage only. The received-state spec is not one of those. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john-ietf@jck.com Tue Jun 12 08:49:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E58821F8510 for ; Tue, 12 Jun 2012 08:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN5E-4ngpOE3 for ; Tue, 12 Jun 2012 08:49:13 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1DB21F8458 for ; Tue, 12 Jun 2012 08:49:13 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SeTF3-000IKz-5a; Tue, 12 Jun 2012 11:42:49 -0400 Date: Tue, 12 Jun 2012 11:49:06 -0400 From: John C Klensin To: Ned Freed Message-ID: <45CA009DE50D964470DB51A8@JcK-HP8200.jck.com> In-Reply-To: <01OGLA76FLMC0006TF@mauve.mrochek.com> References: <01OGLA76FLMC0006TF@mauve.mrochek.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: Mark Nottingham , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-media-type-regs and "provisional" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 15:49:14 -0000 Sounds about right. Editorial bits/nits below --On Tuesday, June 12, 2012 07:42 -0700 Ned Freed wrote: >> --On Monday, June 11, 2012 11:43 -0700 Ned Freed >> wrote: >... >> > Works for me. Do you think this deserves a mention in the >> > IANA Considerations? Personally, I think adding it would be >> > a good idea, but I could be convinced otherwise. > >> I don't see any downside, especially (given the separation >> problem with the RFC 3864 registry that you point out) if we >> can specifically instruct IANA that that are likely to be >> asked to remove the comment with 3864 or its registries are >> updated. Let's not put it in and have trouble getting rid of >> it because this document said so. > > OK, so how about: > > IANA is also request to add the following note at the s/request/requested/ > beginning of the provisional registry: > > This registry, unlike some other provisional IANA > registries, is only for temporary use. Entries in this > registry are either finalized and move to the main media s/move/moved/ > types registries, or are abandoned and deleted. Entries in > this regisry are suitable for use for test purposes only. s/regisry/registry/ And you might say "for use for test purposes and to alert others that the entry name is likely to be in use only" or words to that effect. > This would become the third paragraph of the IANA > considerations section. > > As I wrote this I realized it could be done in a way that > provides useful information about the registry content in > addition to clarifying the discrepancy with other provisional > registries. Agreed. If we have to put text in, let's maximize its utility. john From sm@elandsys.com Tue Jun 12 09:41:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F42121F8646 for ; Tue, 12 Jun 2012 09:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcEKR2BPy6oH for ; Tue, 12 Jun 2012 09:41:38 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 759AD21F8647 for ; Tue, 12 Jun 2012 09:41:37 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.27]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5CGfK6U010636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2012 09:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339519293; i=@elandsys.com; bh=fy7Ish0MAqHSrarJNgGUch/Wbomc9YslouqSIulIGR0=; h=Date:To:From:Subject:Cc; b=wkWvV/yC9t8jJXeNGOugFUWV/ZC6TNCq0/bjnWLacW1kJbJJmAUAkeRvUVp7kjPEt xLHAu/IV/tNN7Qkt5bwAtorK/5ADA2pYhGCuXzcZgIaQLYhYljcisaLMyCe08bSDNR H9KoiTntK/BrGMD+DeHNtqOEZBldvmO0eDI5s9/g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1339519293; i=@elandsys.com; bh=fy7Ish0MAqHSrarJNgGUch/Wbomc9YslouqSIulIGR0=; h=Date:To:From:Subject:Cc; b=3nNKJkf/0XSAxeRFjpulBZp8ag7+ntifUAqdDvlbcT6rPhn+2FPG7xxTCPYwE9i+4 zmXP8E+/3SN4VGAxLYmFKIKNMnyKWiWskutiUWu0SXmyX5MrrDIaSdRFW5Q5xP+qmy j+EvAcEO8DOc0npiPl+9OqlcVSl1fx+9JX/PvtR8= Message-Id: <6.2.5.6.2.20120612093200.0915d998@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 12 Jun 2012 09:40:39 -0700 To: Pete Resnick , Barry Leiba , Alexey Melnikov , "Murray S. Kucherawy" From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: [apps-discuss] Moving SMTP-related discussions to ietf-smtp X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 16:41:40 -0000 Hello, There is now an ietf-smtp mailing list [1] hosted by ietf.org for discussions about SMTP. I suggest moving non-APPSAWG discussions about SMTP from apps-discuss@ietf.org to ietf-smtp@ietf.org. Regards, S. Moonesamy 1. https://www.ietf.org/mailman/listinfo/ietf-smtp From dhc@dcrocker.net Tue Jun 12 09:49:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AB321F8667 for ; Tue, 12 Jun 2012 09:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42RPjfQvAlOb for ; Tue, 12 Jun 2012 09:49:18 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 608EF21F8663 for ; Tue, 12 Jun 2012 09:49:18 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q5CGn0rv025470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jun 2012 09:49:01 -0700 Message-ID: <4FD772FB.9060807@dcrocker.net> Date: Tue, 12 Jun 2012 09:48:59 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120612093200.0915d998@elandnews.com> In-Reply-To: <6.2.5.6.2.20120612093200.0915d998@elandnews.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, 12 Jun 2012 09:49:01 -0700 (PDT) Cc: Pete Resnick , Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] Moving SMTP-related discussions to ietf-smtp X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 16:49:19 -0000 On 6/12/2012 9:40 AM, S Moonesamy wrote: > > There is now an ietf-smtp mailing list [1] hosted by ietf.org for > discussions about SMTP. I suggest moving non-APPSAWG discussions about > SMTP from apps-discuss@ietf.org to ietf-smtp@ietf.org. is this meant to be cover SMTP details, specifically, or to cover all Internet Mail technical and operational details? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From tony@att.com Tue Jun 12 10:48:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEB721F850F for ; Tue, 12 Jun 2012 10:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykCYUklsSghX for ; Tue, 12 Jun 2012 10:48:19 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 58C1621F842C for ; Tue, 12 Jun 2012 10:48:14 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id dd087df4.0.574566.00-375.1577129.nbfkord-smmo04.seg.att.com (envelope-from ); Tue, 12 Jun 2012 17:48:14 +0000 (UTC) X-MXL-Hash: 4fd780de3a35501e-8d537eed581718c48d98e510a288403b1961a4c5 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5CHmD00005362 for ; Tue, 12 Jun 2012 13:48:13 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5CHm9Fs005334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Jun 2012 13:48:09 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Tue, 12 Jun 2012 13:47:54 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q5CHlrDs026117 for ; Tue, 12 Jun 2012 13:47:53 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q5CHlihf025880 for ; Tue, 12 Jun 2012 13:47:47 -0400 Received: from [135.91.110.142] (dn135-91-110-142.dhcpn.ugn.att.com[135.91.110.142]) by maillennium.att.com (mailgw1) with ESMTP id <20120612174353gw10060lb0e> (Authid: tony); Tue, 12 Jun 2012 17:43:53 +0000 X-Originating-IP: [135.91.110.142] Message-ID: <4FD780BF.5050902@att.com> Date: Tue, 12 Jun 2012 13:47:43 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <6.2.5.6.2.20120612093200.0915d998@elandnews.com> <4FD772FB.9060807@dcrocker.net> In-Reply-To: <4FD772FB.9060807@dcrocker.net> Content-Type: multipart/alternative; boundary="------------080600060809060109000408" X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=kKemRe_CjxUA:10 a=4JAii899aesA:10 a=cOacaWKlNH] X-AnalysisOut: [oA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=L6IORkpKAAAA:8 a=48vgC7mUAAAA:8 a=hDGh4BX4] X-AnalysisOut: [jwUna8cJWNcA:9 a=wPNLvfGTeEIA:10 a=kkUMZHjH4KkA:10 a=VHY5C] X-AnalysisOut: [wHZxh8A:10 a=lZB815dzVvQA:10 a=b8OvNEjoAAAA:8 a=mu4KIW5gJn] X-AnalysisOut: [76MMt16hcA:9 a=_W_S_7VecoQA:10 a=E1Snkw02GREA:10] Subject: Re: [apps-discuss] Moving SMTP-related discussions to ietf-smtp X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 17:48:20 -0000 This is a multi-part message in MIME format. --------------080600060809060109000408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit If it follows the charter of the original ietf-smtp@imc.org mailing list, it would be details specific to SMTP. In the past, we've split things between the mailing lists along protocol lines: ietf-smtp, ietf-imapext, ietf-pop3ext, and then ietf-822 for the mail format. We've never had a catchall mailing list for other internet mail technical or operational details. Is it time to rethink this? On 6/12/2012 12:48 PM, Dave Crocker wrote: > > > On 6/12/2012 9:40 AM, S Moonesamy wrote: >> >> There is now an ietf-smtp mailing list [1] hosted by ietf.org for >> discussions about SMTP. I suggest moving non-APPSAWG discussions about >> SMTP from apps-discuss@ietf.org to ietf-smtp@ietf.org. > > > is this meant to be cover SMTP details, specifically, or to cover all > Internet Mail technical and operational details? > > d/ --------------080600060809060109000408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If it follows the charter of the original ietf-smtp@imc.org mailing list, it would be details specific to SMTP.

In the past, we've split things between the mailing lists along protocol lines: ietf-smtp, ietf-imapext, ietf-pop3ext, and then ietf-822 for the mail format. We've never had a catchall mailing list for other internet mail technical or operational details.

Is it time to rethink this?

On 6/12/2012 12:48 PM, Dave Crocker wrote:


On 6/12/2012 9:40 AM, S Moonesamy wrote:

There is now an ietf-smtp mailing list [1] hosted by ietf.org for
discussions about SMTP.   I suggest moving non-APPSAWG discussions about
SMTP from apps-discuss@ietf.org to ietf-smtp@ietf.org.


is this meant to be cover SMTP details, specifically, or to cover all Internet Mail technical and operational details?

d/
--------------080600060809060109000408-- From ned.freed@mrochek.com Tue Jun 12 11:21:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1867C21F863E for ; Tue, 12 Jun 2012 11:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPIDYSg1LevI for ; Tue, 12 Jun 2012 11:21:08 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7A47D21F863C for ; Tue, 12 Jun 2012 11:21:08 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGLHADJFN40032RQ@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 12 Jun 2012 11:16:06 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGIRBMUA6O0006TF@mauve.mrochek.com>; Tue, 12 Jun 2012 11:16:03 -0700 (PDT) Message-id: <01OGLHABF90U0006TF@mauve.mrochek.com> Date: Tue, 12 Jun 2012 11:15:43 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 12 Jun 2012 11:49:06 -0400" <45CA009DE50D964470DB51A8@JcK-HP8200.jck.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OGLA76FLMC0006TF@mauve.mrochek.com> <45CA009DE50D964470DB51A8@JcK-HP8200.jck.com> To: John C Klensin Cc: Mark Nottingham , Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-media-type-regs and "provisional" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 18:21:09 -0000 > Sounds about right. Editorial bits/nits below I've updated the text accordingly. Ned > --On Tuesday, June 12, 2012 07:42 -0700 Ned Freed > wrote: > >> --On Monday, June 11, 2012 11:43 -0700 Ned Freed > >> wrote: > >... > >> > Works for me. Do you think this deserves a mention in the > >> > IANA Considerations? Personally, I think adding it would be > >> > a good idea, but I could be convinced otherwise. > > > >> I don't see any downside, especially (given the separation > >> problem with the RFC 3864 registry that you point out) if we > >> can specifically instruct IANA that that are likely to be > >> asked to remove the comment with 3864 or its registries are > >> updated. Let's not put it in and have trouble getting rid of > >> it because this document said so. > > > > OK, so how about: > > > > IANA is also request to add the following note at the > s/request/requested/ > > beginning of the provisional registry: > > > > This registry, unlike some other provisional IANA > > registries, is only for temporary use. Entries in this > > registry are either finalized and move to the main media > s/move/moved/ > > types registries, or are abandoned and deleted. Entries in > > this regisry are suitable for use for test purposes only. > s/regisry/registry/ > And you might say "for use for test purposes and to alert others > that the entry name is likely to be in use only" or words to > that effect. > > This would become the third paragraph of the IANA > > considerations section. > > > > As I wrote this I realized it could be done in a way that > > provides useful information about the registry content in > > addition to clarifying the discrepancy with other provisional > > registries. > Agreed. If we have to put text in, let's maximize its utility. > john From barryleiba@gmail.com Tue Jun 12 11:26:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E2821F8642 for ; Tue, 12 Jun 2012 11:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vPWsgTpTF1n for ; Tue, 12 Jun 2012 11:26:47 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCC2521F85C6 for ; Tue, 12 Jun 2012 11:26:46 -0700 (PDT) Received: by qcsq13 with SMTP id q13so423600qcs.31 for ; Tue, 12 Jun 2012 11:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Xcvm+HMp/wnh8c8c/4dBpFejJ1+WG9B8zRWkihwQC04=; b=CTyXY4tGAm1EkplTM7Ifv+Ohi7/wxejr7zLvqQlluSYxIZBTTxic1LTgcM6el/uFXn +D55lJQUA1vD7Wj3hk3pL4vMAJUUcmPDWf+2shG6A7SWEAZtxc95H5uE9HsCQF/QpZyz 8pihK8Po6Ay/TvLmL2uYMi9yjkKaQQUDyh7X5rAJuU4YfmSQUtSiPNLszdrmKtyWgQWm QJnLL025Vhmmc6dkuw1/1Wqw564E3wOl4fECphp/Azo+4Tvbg6j6b3afoOA5ObsY182Q lH8+gpB5PYzCIXoZpqzbaG9WKEvkvJ5k0YHOuOmWo6MItob1EtW64KuBy8Q8lMdKlKoN TUCw== MIME-Version: 1.0 Received: by 10.229.136.10 with SMTP id p10mr8782500qct.131.1339525606265; Tue, 12 Jun 2012 11:26:46 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Tue, 12 Jun 2012 11:26:46 -0700 (PDT) In-Reply-To: <4FD772FB.9060807@dcrocker.net> References: <6.2.5.6.2.20120612093200.0915d998@elandnews.com> <4FD772FB.9060807@dcrocker.net> Date: Tue, 12 Jun 2012 14:26:46 -0400 X-Google-Sender-Auth: -_Iy0_61VKb3hrWGfzt3Q63g65U Message-ID: From: Barry Leiba To: "dcrocker@bbiw.net" Content-Type: multipart/alternative; boundary=00248c6a6646edd4d804c24a9b54 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Moving SMTP-related discussions to ietf-smtp X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 18:26:47 -0000 --00248c6a6646edd4d804c24a9b54 Content-Type: text/plain; charset=ISO-8859-1 > > >> There is now an ietf-smtp mailing list [1] hosted by ietf.org for >> discussions about SMTP. I suggest moving non-APPSAWG discussions about >> SMTP from apps-discuss@ietf.org to ietf-smtp@ietf.org. >> > > is this meant to be cover SMTP details, specifically, or to cover all > Internet Mail technical and operational details? This is meant to exactly replace the old list at . Similarly for ietf-822, which is still in process. I'm getting a number of lists copied over from imc.org, subscriptions and archives and all. I'm still travelling, and Steve from AMS is just getting these done, so I haven't posted a general note about them yet. I'll do that on Friday, after I get home. Barry --00248c6a6646edd4d804c24a9b54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

There is now an ietf-smtp mailing list [1] hosted by ietf.org for
discussions about SMTP. =A0 I suggest moving non-APPSAWG discussions about<= br> SMTP from apps-discuss@ietf.org to ietf-smtp@ietf.org.

is this meant to be cover SMTP details, specifically, or to cover all Inter= net Mail technical and operational details?
=A0
This is meant to exactly replace the old= list at <Ietf-smtp@imc.org>= . =A0Similarly for ietf-822, which is still in process. =A0I'm getting = a number of lists copied over from imc.org, = subscriptions and archives and all.

I'm still travelling, and Steve from AMS is just ge= tting these done, so I haven't posted a general note about them yet. = =A0I'll do that on Friday, after I get home.

B= arry
--00248c6a6646edd4d804c24a9b54-- From sm@elandsys.com Tue Jun 12 14:03:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5629921F86B4 for ; Tue, 12 Jun 2012 14:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuICDi3NAOTi for ; Tue, 12 Jun 2012 14:03:19 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F31C21F86EB for ; Tue, 12 Jun 2012 14:03:19 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.27]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5CL2tTw018497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2012 14:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339534990; i=@elandsys.com; bh=CBgQ37bD5UdEd2BMADhl21d7kMTBomYObqmTDQmTAuA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oGi+KwrEz0QP+92VZcQktcr4VnhjeicnipYONHSaooKW3xy9SGL4TuEMkDwiUat++ yuhIrKvdmO5ofJEG+jhkhMcau09PE+GMQzETQ0xz7nPf7lMioHq/cJ9+kbRrHyxHyU 0a0wMXtwA1EE/9QOkD8jKLW1C3MwiIvHGZr6QCLg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1339534990; i=@elandsys.com; bh=CBgQ37bD5UdEd2BMADhl21d7kMTBomYObqmTDQmTAuA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=czc0+DPNbTZssGYPgK3mIF5MV1hX8/QSWAkMN3MqTNVn0GdrE7RMG7VW8dA1M0wgn Z3M3cNjKHyH+nRkpFAzzkjuz9TG+51G3bA+1EQ+17IOJV97Qe/JyoKjPHEgMVrbrr/ xO0O5TpM2XZfWVPC02AmZ4TuRNMINw959y/6gv1o= Message-Id: <6.2.5.6.2.20120612095623.0935a5f8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 12 Jun 2012 10:04:47 -0700 To: dcrocker@bbiw.net From: S Moonesamy In-Reply-To: <4FD772FB.9060807@dcrocker.net> References: <6.2.5.6.2.20120612093200.0915d998@elandnews.com> <4FD772FB.9060807@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Pete Resnick , Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] Moving SMTP-related discussions to ietf-smtp X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 21:03:20 -0000 Hi Dave, At 09:48 12-06-2012, Dave Crocker wrote: >is this meant to be cover SMTP details, specifically, or to cover >all Internet Mail technical and operational details? I suggest keeping the ietf-smtp mailing list as it was before and adding the SMTP related discussions we have been having on apps-discuss. That would cover SMTP and operational details including what you mentioned above. Such a change would help to reduce apps-discuss traffic. As a note Barry deserves credit for the moving the ietf-smtp mailing list to ietf.org. Regards, S. Moonesamy From dhc@dcrocker.net Tue Jun 12 14:13:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817DD21F8704 for ; Tue, 12 Jun 2012 14:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZnRz2Lrsrbx for ; Tue, 12 Jun 2012 14:13:41 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D8FD521F8703 for ; Tue, 12 Jun 2012 14:13:41 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q5CLDZ40030567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jun 2012 14:13:36 -0700 Message-ID: <4FD7B0FE.6030105@dcrocker.net> Date: Tue, 12 Jun 2012 14:13:34 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Barry Leiba References: <6.2.5.6.2.20120612093200.0915d998@elandnews.com> <4FD772FB.9060807@dcrocker.net> In-Reply-To: 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, 12 Jun 2012 14:13:36 -0700 (PDT) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Moving SMTP-related discussions to ietf-smtp X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 21:13:42 -0000 On 6/12/2012 11:26 AM, Barry Leiba wrote: > This is meant to exactly replace the old list at >. Similarly for ietf-822, which is still in > process. oh. ack. from the announcement I thought some mail-related traffic on apps-discuss was supposed to migrate to the 'new' list. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mnot@mnot.net Tue Jun 12 15:03:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B39521F86F1 for ; Tue, 12 Jun 2012 15:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.028 X-Spam-Level: X-Spam-Status: No, score=-106.028 tagged_above=-999 required=5 tests=[AWL=-3.429, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvRJFCe6icxv for ; Tue, 12 Jun 2012 15:03:54 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 9F58B21F86E2 for ; Tue, 12 Jun 2012 15:03:54 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.56.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 751B250A6A; Tue, 12 Jun 2012 18:03:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <01OGLHABF90U0006TF@mauve.mrochek.com> Date: Wed, 13 Jun 2012 08:03:41 +1000 Content-Transfer-Encoding: 7bit Message-Id: References: <01OGLA76FLMC0006TF@mauve.mrochek.com> <45CA009DE50D964470DB51A8@JcK-HP8200.jck.com> <01OGLHABF90U0006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1278) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-media-type-regs and "provisional" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 22:03:55 -0000 Looks about right. And a big +1 to untying at least one of IANA's hands. On 13/06/2012, at 4:15 AM, Ned Freed wrote: >> Sounds about right. Editorial bits/nits below > > I've updated the text accordingly. > > Ned > >> --On Tuesday, June 12, 2012 07:42 -0700 Ned Freed >> wrote: > >>>> --On Monday, June 11, 2012 11:43 -0700 Ned Freed >>>> wrote: > >>> ... >>>>> Works for me. Do you think this deserves a mention in the >>>>> IANA Considerations? Personally, I think adding it would be >>>>> a good idea, but I could be convinced otherwise. >>> >>>> I don't see any downside, especially (given the separation >>>> problem with the RFC 3864 registry that you point out) if we >>>> can specifically instruct IANA that that are likely to be >>>> asked to remove the comment with 3864 or its registries are >>>> updated. Let's not put it in and have trouble getting rid of >>>> it because this document said so. >>> >>> OK, so how about: >>> >>> IANA is also request to add the following note at the >> s/request/requested/ >>> beginning of the provisional registry: >>> >>> This registry, unlike some other provisional IANA >>> registries, is only for temporary use. Entries in this >>> registry are either finalized and move to the main media >> s/move/moved/ >>> types registries, or are abandoned and deleted. Entries in >>> this regisry are suitable for use for test purposes only. >> s/regisry/registry/ > >> And you might say "for use for test purposes and to alert others >> that the entry name is likely to be in use only" or words to >> that effect. > >>> This would become the third paragraph of the IANA >>> considerations section. >>> >>> As I wrote this I realized it could be done in a way that >>> provides useful information about the registry content in >>> addition to clarifying the discrepancy with other provisional >>> registries. > >> Agreed. If we have to put text in, let's maximize its utility. > >> john > -- Mark Nottingham http://www.mnot.net/ From internet-drafts@ietf.org Tue Jun 12 17:58:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB9121F873C; Tue, 12 Jun 2012 17:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+YQHpKQpXSb; Tue, 12 Jun 2012 17:58:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E036D21F8627; Tue, 12 Jun 2012 17:58:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120613005826.14469.64111.idtracker@ietfa.amsl.com> Date: Tue, 12 Jun 2012 17:58:26 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-12.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 00:58:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Media Type Specifications and Registration Procedures Author(s) : Ned Freed John C. Klensin Tony Hansen Filename : draft-ietf-appsawg-media-type-regs-12.txt Pages : 32 Date : 2012-06-04 Abstract: This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs There's also a htmlized version available at: http://tools.ietf.org/html/submission.filename }}-12 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-media-type-regs-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Jun 12 19:05:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A830821F8747; Tue, 12 Jun 2012 19:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Wmf10pE+h0x; Tue, 12 Jun 2012 19:05:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3D021F872A; Tue, 12 Jun 2012 19:05:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120613020534.9063.39473.idtracker@ietfa.amsl.com> Date: Tue, 12 Jun 2012 19:05:34 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 02:05:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Media Type Specifications and Registration Procedures Author(s) : Ned Freed John C. Klensin Tony Hansen Filename : draft-ietf-appsawg-media-type-regs-13.txt Pages : 32 Date : 2012-06-12 Abstract: This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs There's also a htmlized version available at: http://tools.ietf.org/html/submission.filename }}-13 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-media-type-regs-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alexey.melnikov@isode.com Wed Jun 13 05:58:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA02721F857A; Wed, 13 Jun 2012 05:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s67ev3iRP2Xl; Wed, 13 Jun 2012 05:58:27 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0658F21F8554; Wed, 13 Jun 2012 05:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1339584399; d=isode.com; s=selector; i=@isode.com; bh=uWLgdw/EuKzNiCteJBgvfOWbbfJipLb2UCZKGzAMfNs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=UFBO2g2pqLIL5iazrGOrjJdjXpHb5xhcMdct3QpCE5xKGAnlNyXEInlyxj/RgyCiO6EVsc iDfTF+e5ItswSGBa0A2UI4ckx1NuC1IW5E6EXfRdwPc+u5MX7f7lLOhm/SykLnCpPEKxk6 so3+IyLDM7OVNwU6JTucrTupESOLA3c=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 13 Jun 2012 11:46:38 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FD86FB2.2050002@isode.com> Date: Wed, 13 Jun 2012 11:47:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: apps-discuss@ietf.org, draft-ietf-nea-pt-tls.all@tools.ietf.org References: <4FCD0614.5050902@isode.com> In-Reply-To: <4FCD0614.5050902@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-nea-pt-tls-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 12:58:28 -0000 On 04/06/2012 20:01, Alexey Melnikov wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on APPSDIR, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate > ). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. The review is not > copied to the IESG as the Last Call has not been announced yet. > > Document: draft-ietf-nea-pt-tls-04 > Title: PT-TLS: A TCP-based Posture Transport (PT) Protocol > Reviewer: Alexey Melnikov > Review Date: June 4, 2012 > > Summary: This document is almost ready for publication as a Proposed > Standard, although some [mostly] SASL related issues remain. > > This document specifies PT-TLS, a TCP-based Posture Transport (PT) > protocol. The PT-TLS protocol carries the Network Endpoint > Assessment (NEA) message exchange under the protection of a Transport > Layer Security (TLS) secured tunnel. > > (Note, I've reviewed -04, but I think all of this still applies to -05.) Additional issues in -05: 1) I didn't find the updated text prohibiting TLS renegotiation to be any clearer in -05? Can you maybe try to explain what is allowed and what is not? 2) In the IANA Considerations: The PEN 0 (IETF) PT-TLS Message Type values between 9 and 2^32-2 inclusive are allocated for future assignment by the IANA. The value 2^32-1 is permanently reserved and is not to be allocated. Whom does the last sentence apply to? This registry? Or the IANA PEN registry being documented by draft-liang-iana-pen? From wmills@yahoo-inc.com Wed Jun 13 08:27:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63D921F8507 for ; Wed, 13 Jun 2012 08:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.448 X-Spam-Level: X-Spam-Status: No, score=-17.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O11pdUUkORwE for ; Wed, 13 Jun 2012 08:27:39 -0700 (PDT) Received: from nm24.bullet.mail.sp2.yahoo.com (nm24.bullet.mail.sp2.yahoo.com [98.139.91.94]) by ietfa.amsl.com (Postfix) with SMTP id B2D5321F84FD for ; Wed, 13 Jun 2012 08:27:39 -0700 (PDT) Received: from [72.30.22.77] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 15:27:36 -0000 Received: from [98.139.91.43] by tm11.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 15:27:36 -0000 Received: from [127.0.0.1] by omp1043.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 15:27:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 729650.42023.bm@omp1043.mail.sp2.yahoo.com Received: (qmail 53650 invoked by uid 60001); 13 Jun 2012 15:27:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339601256; bh=CXjd2AHHDCGUm6nZLZ2SYPvhyZdulHOcXb7OIBzIvDw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gaejzn+X+ngYMFi2Clvdl9zihVujQWmtM5+LZ3z1o45FdBXHeKGPmUBmF8ZMrrJ57jEM/fMuKWwtWJTO6AC2X6eDxRJ/xXgB/rKgQNR2hDhqpBovtfNFGvJMre+gDTZg0L9NVfEkMgRgyRyy1kDZCXxtAJgvD0ZNjjTDGsLWVIw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AfKewcGm/QuROApf+X5Ro91P47TkKqhABrSkcO86mo9F1YmctkmHgeGMl681Yj1ba9LVM2pRBlCXxIVUvc32vkgi+3c0bkPQ3bCscKZ6E1/osFmAkpKOVEKn/jVBEAInPEt3XLdPNEMiwtfE4gv3A9wejWpcIXWxKowebDmrt/c=; X-YMail-OSG: FpAbvqcVM1ksnjuFs5yyZtaO_19VWSkXRBaJl0CtvFRVsml wKuB3Bf1Rf53B17TbNI1xi4sRtVFedQjBHdUZZAI0CbOeoaTO2prUpKm99tx qwd3V7sNHXRGIFO4HFvgpwTwp54nU4nxc86PrsBx5cgh4MfB46QPN4X0b1h3 NI7DPY3yOp4YQxwkJLP7SXkYXhDG8G9zj93MgONldZPavj29G0JxQnTVeFjQ 7CTKoXL_LYmIaTfkm3cyQU0nGXX6DMEJvDpTkLHXBVN2gI.gIEzv.KG8qfcI bWR4K0oDaEg2Q0yw0l7uLQP3PW2aoEdhRHNjQQ4pmVGFf4YmGAkgbKfL.lZd bKjC1DjOV1df32LQuzGRTpYoTch4BI4zjf5J2i4A2UnDXzb6pT0EMoxw45oO fc5FVqozLKuzOntYWykxoIgPcwuVZ.fghi0VVcMlsEG603lljvAZ.CgxW5Rd zjrJ_bZBHNzQ2snLtzw.TxI_d6L.ghLX2vutm6X6WF6yNG.PAtKrJ4R_Bm95 Rj13g Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 08:27:36 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 Message-ID: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 08:27:36 -0700 (PDT) From: William Mills To: O Auth WG , Apps Discuss MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] OAuth discovery registration. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 15:27:40 -0000 =0A=0ASince for the OAUTH SASL mechanism I need discovery for clients to wo= rk, and I had to rip the in-band discovery out of that mechanism, and I nee= d it defined somewhere, I've drafted a small doc for the registration of li= nk relation types for OAuth.=A0 It's too late in the process to get this in= to the core OAuth 2 spec, and it doesn't really fit in the WebFinger. Submi= ssion info provided below.=0A=0A-bill=0A=0A--------------------------------= --------------------=0A=0AA new version of I-D, draft-wmills-oauth-lrdd-00.= txt=0Ahas been successfully submitted by William Mills and posted to the=0A= IETF repository.=0A=0AFilename:=A0=A0=A0 draft-wmills-oauth-lrdd=0ARevision= :=A0=A0=A0 00=0ATitle:=A0=A0=A0 =A0=A0=A0 LRDD Registry for OAuth 2=0ACreat= ion date:=A0=A0=A0 2012-06-13=0AWG ID:=A0=A0=A0 =A0=A0=A0 Individual Submis= sion=0ANumber of pages: 10=0AURL:=A0 =A0 =A0 =A0 =A0 =A0=A0http://www.ietf.= org/internet-drafts/draft-wmills-oauth-lrdd-00.txt=0AStatus:=A0 =A0 =A0 =A0= =A0=A0http://datatracker.ietf.org/doc/draft-wmills-oauth-lrdd=0AHtmlized:= =A0 =A0 =A0 =A0=A0http://tools.ietf.org/html/submission.filename=A0}}-00=0A= =0A=0AAbstract:=0A=A0 Defines link type registrations for the OAuth 2 authe= ntication=0A=A0 framework.=0A=0A=0A=0A=0AThe IETF Secretariat=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0=A0 From stpeter@stpeter.im Wed Jun 13 08:48:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A951E21F852C; Wed, 13 Jun 2012 08:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mjUgpgowE2d; Wed, 13 Jun 2012 08:48:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C821E21F8496; Wed, 13 Jun 2012 08:48:23 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 71A164005A; Wed, 13 Jun 2012 10:05:35 -0600 (MDT) Message-ID: <4FD8B646.3080509@stpeter.im> Date: Wed, 13 Jun 2012 09:48:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: William Mills References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> In-Reply-To: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: O Auth WG , Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] OAuth discovery registration. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 15:48:24 -0000 On 6/13/12 9:27 AM, William Mills wrote: > > Since for the OAUTH SASL mechanism I need discovery for clients to > work, and I had to rip the in-band discovery out of that mechanism, > and I need it defined somewhere, I've drafted a small doc for the > registration of link relation types for OAuth. It's too late in the > process to get this into the core OAuth 2 spec, and it doesn't really > fit in the WebFinger. Submission info provided below. Hi Bill, overall this looks good. A few nits: OLD This document defines the LRDD [RFC5988] link type registrations for the OAuth [I-D.ietf-oauth-v2] authentication framework. These link types are used during the endpoint discovery process using Web Host Metadata [I-D.hammer-hostmeta] and Webfinger [I-D.jones-appsawg-webfinger] by clients needing to discover the authentication endpoints for a service or site. It additionally defines link type registrations for OAuth 1.0a [RFC5849]. NEW This document defines the Link-based Resource Descriptor Documents (LRDD) [RFC6415] link type registrations for the OAuth [I-D.ietf-oauth-v2] authorization framework. These link types are used during the endpoint discovery process using Web Host Metadata [RFC6415] and Webfinger [I-D.jones-appsawg-webfinger] by clients needing to discover the authorization, token, and access token endpoints for an OAuth2 service or site. It additionally defines link type registrations for OAuth 1.0a [RFC5849] request initiation endpoints, authorization endpoints, and token endpoints. In Section 4.1.1, you register an "OAuth 2 Authentication Endpoint", however draft-ietf-oauth-v2 defines only an authorization endpoint, a token endpoint, and an access token endpoint. Whence this "authentication endpoint"? Is it just a typo? Also, is the lack of a link type for OAuth2 access token endpoints an oversight? It seems so. You have "Reference: [[this document]]" but I think you want: Reference: draft-ietf-oauth-v2 and Reference: RFC 5849 You can remove the reference for draft-hammer-hostmeta (RFC 6415 has what you need). Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Jun 13 09:08:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65CC21F848F; Wed, 13 Jun 2012 09:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9A7P2mgZF5S; Wed, 13 Jun 2012 09:08:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9181C21F8484; Wed, 13 Jun 2012 09:08:10 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2EEAF4005A; Wed, 13 Jun 2012 10:25:22 -0600 (MDT) Message-ID: <4FD8BAE7.4000005@stpeter.im> Date: Wed, 13 Jun 2012 10:08:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Eran Hammer References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201070221@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201070221@P3PWEX2MB008.ex2.secureserver.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: O Auth WG , Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] OAuth discovery registration. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 16:08:11 -0000 On 6/13/12 10:03 AM, Eran Hammer wrote: > These are straight link relation registrations, not LRDD (which has no registration process). Right you are! /psa From laurentwalter.goix@telecomitalia.it Wed Jun 13 09:44:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C27D21F85A3; Wed, 13 Jun 2012 09:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Seg+hSF8id4e; Wed, 13 Jun 2012 09:44:46 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id A14E221F855F; Wed, 13 Jun 2012 09:44:45 -0700 (PDT) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 13 Jun 2012 18:44:41 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Wed, 13 Jun 2012 18:44:41 +0200 From: Goix Laurent Walter To: Peter Saint-Andre , William Mills Date: Wed, 13 Jun 2012 18:44:19 +0200 Thread-Topic: [apps-discuss] [OAUTH-WG] OAuth discovery registration. Thread-Index: Ac1JfALVoc1LenjrTn2gdPnLEga53QABrMsw Message-ID: References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FD8B646.3080509@stpeter.im> In-Reply-To: <4FD8B646.3080509@stpeter.im> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: O Auth WG , Apps Discuss Subject: [apps-discuss] R: [OAUTH-WG] OAuth discovery registration. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 16:44:46 -0000 Thank you William for this initiative. I had similar concerns than Peter on authn vs authz. Under section 4.1.1 I would suggest to use "oauth2-authorize" instead of "o= auth2-authenticator", to be consistent with the "oauth2-token" pattern and = with the concepts of the oauth2 draft. The header of the pages still reference sasl/gss-api and would need to be u= pdated. Also, an example and/or use case section could be beneficial, e.g. to descr= ibe its usage in an xrd document. Other use cases may be mentioned as well = probably. I have also noticed that your draft is mentioned as "informational". It is = indeed your target or only a typo? Thanks walter > -----Messaggio originale----- > Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = Per > conto di Peter Saint-Andre > Inviato: mercoled=EC 13 giugno 2012 17.48 > A: William Mills > Cc: O Auth WG; Apps Discuss > Oggetto: Re: [apps-discuss] [OAUTH-WG] OAuth discovery registration. > > On 6/13/12 9:27 AM, William Mills wrote: > > > > Since for the OAUTH SASL mechanism I need discovery for clients to > > work, and I had to rip the in-band discovery out of that mechanism, > > and I need it defined somewhere, I've drafted a small doc for the > > registration of link relation types for OAuth. It's too late in the > > process to get this into the core OAuth 2 spec, and it doesn't really > > fit in the WebFinger. Submission info provided below. > > Hi Bill, overall this looks good. A few nits: > > OLD > This document defines the LRDD [RFC5988] link type registrations for > the OAuth [I-D.ietf-oauth-v2] authentication framework. These link > types are used during the endpoint discovery process using Web Host > Metadata [I-D.hammer-hostmeta] and Webfinger > [I-D.jones-appsawg-webfinger] by clients needing to discover the > authentication endpoints for a service or site. It additionally > defines link type registrations for OAuth 1.0a [RFC5849]. > > NEW > This document defines the Link-based Resource Descriptor > Documents (LRDD) [RFC6415] link type registrations for the > OAuth [I-D.ietf-oauth-v2] authorization framework. These link > types are used during the endpoint discovery process using Web > Host Metadata [RFC6415] and Webfinger > [I-D.jones-appsawg-webfinger] by clients needing to discover the > authorization, token, and access token endpoints for an OAuth2 > service or site. It additionally defines link type registrations for > OAuth > 1.0a [RFC5849] request initiation endpoints, authorization endpoints, > and token endpoints. > > In Section 4.1.1, you register an "OAuth 2 Authentication Endpoint", > however draft-ietf-oauth-v2 defines only an authorization endpoint, a > token endpoint, and an access token endpoint. Whence this > "authentication endpoint"? Is it just a typo? > > Also, is the lack of a link type for OAuth2 access token endpoints an > oversight? It seems so. > > You have "Reference: [[this document]]" but I think you want: > > Reference: draft-ietf-oauth-v2 > > and > > Reference: RFC 5849 > > You can remove the reference for draft-hammer-hostmeta (RFC 6415 has > what you need). > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From wmills@yahoo-inc.com Wed Jun 13 11:19:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0D621F850C for ; Wed, 13 Jun 2012 11:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.464 X-Spam-Level: X-Spam-Status: No, score=-17.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eM86mJZKZLy0 for ; Wed, 13 Jun 2012 11:19:59 -0700 (PDT) Received: from nm17-vm0.bullet.mail.sp2.yahoo.com (nm17-vm0.bullet.mail.sp2.yahoo.com [98.139.91.212]) by ietfa.amsl.com (Postfix) with SMTP id E901221F8507 for ; Wed, 13 Jun 2012 11:19:58 -0700 (PDT) Received: from [98.139.91.67] by nm17.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:19:55 -0000 Received: from [98.139.91.45] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:19:55 -0000 Received: from [127.0.0.1] by omp1045.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:19:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 210240.82359.bm@omp1045.mail.sp2.yahoo.com Received: (qmail 43502 invoked by uid 60001); 13 Jun 2012 18:19:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339611594; bh=bFg0LiwI25t9lff7jNuKxpxkg+Lee4vZC6+A5Mxy/e8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fS9ZmN6Ckl4Xlc+XrlJ0VmZRFdh2C/DyAb2avWp2t6IQwM1XPHk0B3Xy+jDD6GtwP8tY8HKEs7NMi5If4hZmM0rYDGUIeILirZ8C+d8qlEniTAKn5AFKibq3rPlR+hjVMa+Fbnob1Iovpmv/ACViWMWW0tDBeLKqU+j/LMklYGI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eggE3nn2E5ormUdYuNW8bASValVOH7/r4qaVdRGHQM1YB3MXEyLyHNnqv4AucEGGuNSENYpSCmETadMK0ROv6PZl3sTSatbaMaG0YeE1dOUWIasaT7tCzMXzcwVe9rZqBnZiscLeBPjUs8HRNUjpJ9LOEn5UuxGhi2JzrbiKOO0=; X-YMail-OSG: iO9qnJgVM1lSz3K5mw.nw.MORKTrm_U4x9Ra.qvB36bJ0YV Rs55lJ2bJxF2H9nSgC059Yr2CjS3D0kKh1spDyPb5aLIc3o4q2Clrkw.Dr8m afvgWsJ218nzgpVKTvIjm.9jqZ6Pw.T7_ejSsCmaRUufLDuD7hiSxgzWngf9 FIslMJk8nz4m644efgfeZsNo3YqGIkDgPhNOpa9jQItq_ClGdPUvj__oUwIt Tf3yKOkSuwXRMRancp10.YBRmCvNnC3jqVjnR24tlYDJRgDu_oyrYhvJyqrd NI3bU_vxD_T5yc3eaySqnqHVxlStXNedEhTymHITc_azl4rO0.zPCfIhDXqq tLpCRqeEdD7z4BhfQ11xNO3VXYmydchx5umvUufLzEKxfqEzPCtV8Kv2pbFn pFxgzWFEiu7s4WPaW3X8MauA7DVBcpauh1UFPJtlRGQiCgWUz3YOxGP1K_EP Ym3BFT_3uvL_ArvAjGoa5HVut.foYroLbOHb_3_piFc9ODpU- Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 11:19:54 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FD8B646.3080509@stpeter.im> Message-ID: <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 11:19:54 -0700 (PDT) From: William Mills To: Goix Laurent Walter , Peter Saint-Andre In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: O Auth WG , Apps Discuss Subject: Re: [apps-discuss] R: [OAUTH-WG] OAuth discovery registration. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: