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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 18:19:59 -0000 On the informational status, that seemed right, but I honestly don't know w= hat the correct choice is here.=A0=A0 The actual registration happens via e= -mail I believe, not via this document.=0A=0AThanks for the feedback!=0A=0A= -bill=0A=0A=0A=0A----- Original Message -----=0A> From: Goix Laurent Walter= =0A> To: Peter Saint-Andre ; William Mills =0A> Cc: O Auth WG ; Apps Discuss =0A> Sent: Wednesday, June 13= , 2012 9:44 AM=0A> Subject: R: [apps-discuss] [OAUTH-WG] OAuth discovery re= gistration.=0A> =0A>T hank you William for this initiative.=0A> =0A> I had = similar concerns than Peter on authn vs authz.=0A> =0A> Under section 4.1.1= I would suggest to use "oauth2-authorize" instead =0A> of "oauth2-authenti= cator", to be consistent with the =0A> "oauth2-token" pattern and with the = concepts of the oauth2 draft.=0A> =0A> The header of the pages still refere= nce sasl/gss-api and would need to be =0A> updated.=0A> =0A> Also, an examp= le and/or use case section could be beneficial, e.g. to describe =0A> its u= sage in an xrd document. Other use cases may be mentioned as well probably.= =0A> =0A> I have also noticed that your draft is mentioned as "informationa= l". =0A> It is indeed your target or only a typo?=0A> =0A> Thanks=0A> walte= r=0A> =0A>> -----Messaggio originale-----=0A>> Da: apps-discuss-bounces@i= etf.org [mailto:apps-discuss-bounces@ietf.org] =0A> Per=0A>> conto di Pete= r Saint-Andre=0A>> Inviato: mercoled=EC 13 giugno 2012 17.48=0A>> A: Will= iam Mills=0A>> Cc: O Auth WG; Apps Discuss=0A>> Oggetto: Re: [apps-discus= s] [OAUTH-WG] OAuth discovery registration.=0A>> =0A>> On 6/13/12 9:27 AM,= William Mills wrote:=0A>> >=0A>> > Since for the OAUTH SASL mechanism I = need discovery for clients to=0A>> > work, and I had to rip the in-band di= scovery out of that mechanism,=0A>> > and I need it defined somewhere, I'v= e drafted a small doc for the=0A>> > registration of link relation types f= or OAuth.=A0 It's too late in =0A> the=0A>> > process to get this into the= core OAuth 2 spec, and it doesn't =0A> really=0A>> > fit in the WebFinger= . Submission info provided below.=0A>> =0A>> Hi Bill, overall this looks g= ood. A few nits:=0A>> =0A>> OLD=0A>> =A0 =A0 This document defines the LRD= D [RFC5988] link type registrations for=0A>> =A0 =A0 the OAuth [I-D.ietf-oa= uth-v2] authentication framework.=A0 These link=0A>> =A0 =A0 types are used= during the endpoint discovery process using Web Host=0A>> =A0 =A0 Metadata= [I-D.hammer-hostmeta] and Webfinger=0A>> =A0 =A0 [I-D.jones-appsawg-webfin= ger] by clients needing to discover the=0A>> =A0 =A0 authentication endpoin= ts for a service or site.=A0 It additionally=0A>> =A0 =A0 defines link type= registrations for OAuth 1.0a [RFC5849].=0A>> =0A>> NEW=0A>> =A0 =A0 This = document defines the Link-based Resource Descriptor=0A>> =A0 =A0 Documents = (LRDD) [RFC6415] link type registrations for the=0A>> =A0 =A0 OAuth [I-D.ie= tf-oauth-v2] authorization framework.=A0 These link=0A>> =A0 =A0 types are = used during the endpoint discovery process using Web=0A>> =A0 =A0 Host Meta= data [RFC6415] and Webfinger=0A>> =A0 =A0 [I-D.jones-appsawg-webfinger] by = clients needing to discover the=0A>> =A0 =A0 authorization, token, and acce= ss token endpoints for an OAuth2=0A>> =A0 =A0 service or site.=A0 It additi= onally defines link type registrations for=0A>> OAuth=0A>> =A0 =A0 1.0a [R= FC5849] request initiation endpoints, authorization endpoints,=0A>> =A0 =A0= and token endpoints.=0A>> =0A>> In Section 4.1.1, you register an "OAuth = 2 Authentication =0A> Endpoint",=0A>> however draft-ietf-oauth-v2 defines = only an authorization endpoint, a=0A>> token endpoint, and an access token= endpoint. Whence this=0A>> "authentication endpoint"? Is it just a typo?= =0A>> =0A>> Also, is the lack of a link type for OAuth2 access token endpo= ints an=0A>> oversight? It seems so.=0A>> =0A>> You have "Reference: [[th= is document]]" but I think you want:=0A>> =0A>> Reference: draft-ietf-oaut= h-v2=0A>> =0A>> and=0A>> =0A>> Reference: RFC 5849=0A>> =0A>> You can re= move the reference for draft-hammer-hostmeta (RFC 6415 has=0A>> what you n= eed).=0A>> =0A>> Peter=0A>> =0A>> --=0A>> Peter Saint-Andre=0A>> https:= //stpeter.im/=0A>> =0A>> =0A>> =0A>> =0A>> _______________________________= ________________=0A>> apps-discuss mailing list=0A>> apps-discuss@ietf.or= g=0A>> https://www.ietf.org/mailman/listinfo/apps-discuss=0A> =0A> Questo = messaggio e i suoi allegati sono indirizzati esclusivamente alle persone = =0A> indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a =0A> conoscenza di queste informazioni sono rigorosamente vietate. Qualor= a abbiate =0A> ricevuto questo documento per errore siete cortesemente preg= ati di darne =0A> immediata comunicazione al mittente e di provvedere alla = sua distruzione, =0A> Grazie.=0A> =0A> This e-mail and any attachments is c= onfidential and may contain privileged =0A> information intended for the ad= dressee(s) only. Dissemination, copying, printing =0A> or use by anybody el= se is unauthorised. If you are not the intended recipient, =0A> please dele= te this message and any attachments and advise the sender by return =0A> e-= mail, Thanks.=0A> From wmills@yahoo-inc.com Wed Jun 13 11:40: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 6FFAC11E8094 for ; Wed, 13 Jun 2012 11:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.478 X-Spam-Level: X-Spam-Status: No, score=-17.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 XrCcPUuSogDI for ; Wed, 13 Jun 2012 11:40:06 -0700 (PDT) Received: from nm12-vm0.bullet.mail.sp2.yahoo.com (nm12-vm0.bullet.mail.sp2.yahoo.com [98.139.91.242]) by ietfa.amsl.com (Postfix) with SMTP id 4031111E8088 for ; Wed, 13 Jun 2012 11:40:06 -0700 (PDT) Received: from [72.30.22.93] by nm12.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:40:06 -0000 Received: from [98.139.91.26] by tm15.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:39:06 -0000 Received: from [127.0.0.1] by omp1026.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:39:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 164889.51267.bm@omp1026.mail.sp2.yahoo.com Received: (qmail 82567 invoked by uid 60001); 13 Jun 2012 18:39:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339612745; bh=wb/7Afz8Uxq/9JC2elrIUXFkrxfBa0LWmVNsD3Lhisk=; 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:Content-Transfer-Encoding; b=fv4bWx8K6yK7yMdudR3h+sQL8BlGU+y6TabC2UmBBg6X1qYscykcEAsULntN3SuHiwQ/Ja1QE1Y/r68rTOWhCmYosCe0m38Z3hk3tGND3maxdbuxn8dPGjJKeFOw57u0KGp2WdV6mYMGNAS4Emx6tZDPyCrPDl3fXz2AmtuThSI= 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:Content-Transfer-Encoding; b=cIjYCVRXmrnKWh+3lUAGhQeVFvAM3il/uz0FJkeVFe0ELdnjj/h8j26HDP21ObVSKnB9ymX+sB01iVdWlDe7nnVGQSbqigzrBFs+d4YPYAMQPji/WPIJP4W5lVAn4IMR4XOx8IdopmRhYW2bFm8HfRQpPi9+5SYQcZiQLz+BWZQ=; X-YMail-OSG: p3W5ow0VM1kPX0aYuux2Wsp.PrZHRctuKGjJvkmBMfGtLnN cvxAgR0zej1QIpVXV7v.ScsG_7osjdo3XNCpPib.hnJy618PSG02YuWbOJRZ cqLlf2W.CTP2U3rUbFDartDEazxGmJIuK8LxWYSUV1u0gXknT3TXfs7EE2K3 yJJy_Fx6Sd3nlSmwpqM0JDRjDDSyjCc7_DkChgGZLOAbpHj2uixlTtkxoBSI jXG4FRg.OlYRTTZbvtLuVyYCWXDNofMTgYep4t6by7ti0vF2CHIdEdjMcy3l nfmzvljmrIQv2Xg2UORNfP3x0suUhR0Ymuw0Df4nhOCDmOJr4i2t8t8t8ndR OTLjGzFAiAH4r_DlSckY9yW1FQcLHahkFYdMXLQMIpYtWGezVTi1i8xBhr03 pqiK70xs7zdZOVd3E6FJGYZgbulR9JeumZ2XTmQrymuH4otslOr0- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 11:39:05 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201070221@P3PWEX2MB008.ex2.secureserver.net> Message-ID: <1339612745.81200.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 11:39:05 -0700 (PDT) From: William Mills To: Eran Hammer , O Auth WG , Apps Discuss In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201070221@P3PWEX2MB008.ex2.secureserver.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] [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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 18:40:06 -0000 Worthwhile to change the document title?=0A=0AExamples are easy, can do.=0A= =0A=0A=0A----- Original Message -----=0A> From: Eran Hammer =0A> To: William Mills ; O Auth WG ; Apps Discuss =0A> Cc: =0A> Sent: Wednesday, Ju= ne 13, 2012 9:03 AM=0A> Subject: RE: [OAUTH-WG] OAuth discovery registratio= n.=0A> =0A>T hese are straight link relation registrations, not LRDD (which= has no =0A> registration process). It is helpful to put these registration= s in context and =0A> use LRDD/host-meta as an example of their use, but th= e actual registration =0A> request is simply for a link relation and nothin= g else.=0A> =0A> EH=0A> =0A>> -----Original Message-----=0A>> From: oauth= -bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=0A>> Of Willia= m Mills=0A>> Sent: Wednesday, June 13, 2012 8:28 AM=0A>> To: O Auth WG; A= pps Discuss=0A>> Subject: [OAUTH-WG] OAuth discovery registration.=0A>> = =0A>> =0A>> =0A>> Since for the OAUTH SASL mechanism I need discovery for = clients to work,=0A>> and I had to rip the in-band discovery out of that m= echanism, and I need it=0A>> defined somewhere, I've drafted a small doc f= or the registration of =0A> link=0A>> relation types for OAuth.=A0 It's to= o late in the process to get this =0A> into the core=0A>> OAuth 2 spec, an= d it doesn't really fit in the WebFinger. Submission =0A> info=0A>> provid= ed below.=0A>> =0A>> -bill=0A>> =0A>> -----------------------------------= -----------------=0A>> =0A>> A new version of I-D, draft-wmills-oauth-lrdd= -00.txt has been successfully=0A>> submitted by William Mills and posted t= o the IETF repository.=0A>> =0A>> Filename:=A0=A0=A0 draft-wmills-oauth-lr= dd=0A>> Revision:=A0=A0=A0 00=0A>> Title:=A0=A0=A0 =A0=A0=A0 LRDD Registr= y for OAuth 2=0A>> Creation date:=A0=A0=A0 2012-06-13=0A>> WG ID:=A0=A0= =A0 =A0=A0=A0 Individual Submission=0A>> Number of pages: 10=0A>> URL:=A0= =A0 =A0 =A0 =A0 =0A> =A0=A0http://www.ietf.org/internet-drafts/draft-wmill= s-oauth-lrdd-=0A>> 00.txt=0A>> Status:=A0 =A0 =A0 =A0 =A0=A0http://datatr= acker.ietf.org/doc/draft-wmills-oauth-lrdd=0A>> Htmlized:=A0 =A0 =A0 =A0= =A0http://tools.ietf.org/html/submission.filename=A0}}-00=0A>> =0A>> =0A>> = Abstract:=0A>> =A0 Defines link type registrations for the OAuth 2 authen= tication=0A>> =A0 framework.=0A>> =0A>> =0A>> =0A>> =0A>> The IETF Secret= ariat=0A>> _______________________________________________=0A>> OAuth mai= ling list=0A>> OAuth@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/= oauth=0A> From wmills@yahoo-inc.com Wed Jun 13 11:59: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 B202C21F8517 for ; Wed, 13 Jun 2012 11:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.086 X-Spam-Level: X-Spam-Status: No, score=-17.086 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, 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 krZKXxwApo+O for ; Wed, 13 Jun 2012 11:59:09 -0700 (PDT) Received: from nm11-vm0.bullet.mail.ac4.yahoo.com (nm11-vm0.bullet.mail.ac4.yahoo.com [98.139.53.196]) by ietfa.amsl.com (Postfix) with SMTP id 5A41B21F84E6 for ; Wed, 13 Jun 2012 11:59:09 -0700 (PDT) Received: from [98.139.52.195] by nm11.bullet.mail.ac4.yahoo.com with NNFMP; 13 Jun 2012 18:59:06 -0000 Received: from [98.139.52.166] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 13 Jun 2012 18:59:06 -0000 Received: from [127.0.0.1] by omp1049.mail.ac4.yahoo.com with NNFMP; 13 Jun 2012 18:59:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 366132.47804.bm@omp1049.mail.ac4.yahoo.com Received: (qmail 47041 invoked by uid 60001); 13 Jun 2012 18:59:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339613945; bh=0pHAAd8Hixq273DSXR0MwxqXLtSRu1gnn2x7Qdm+l8A=; 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=i5jhNCorHRTu8qcoDGkZeiUKZ01liHrBlUmQxtZ5gTDrPZ6MD6ZSzm0q1bYtvL9CjJmSev7O17uz4SKpjFEfJy2Rh2jiZJde/TZS/WIA0eOH8DrOqnbt0ljxU5g3FzQY0ngMugSp0/qqOWL37+Fw6DV1ioLSUPqloN7hfao4Haw= 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=cTZHIZKWVcNQV0hEGl27mxO4ulJiUnaOfs5G4EmqeQt5rB44tDlrdPW6f1XW+EMADZyLtqwoePykPYJ1wR4FVFv7Dtp4SAe9cwV5x06aSqTmHspPBqppxs3zXUB8GZ1byi35UNNPgfpCh1pSmEXQHCyl/8mrLzv+Bbw4kVkEODs=; X-YMail-OSG: uxAC5C8VM1l3d2zx9npU.jqZTxsT6r8E.fPJeOzfDLIk4Yz 3W8I0fMz9QQma.O5i8GBqerEqtoiy3G5lXYg0gczogAmJSABAYDMY9ArP2yG UFlRmYypQA53HkKqtqovGSq38dvzeys7DO04MoEWahcTuoAOX9dp_giN5uJd a_OBWzerHjTwo5PpnZkp982x6eTt_2wB15kXug8cT7pCEvTCjsuag4hHkNuv VJF36BgcLVD4AewlguJopVX51zJQh9T2DROpat4k.GAaeqXy6REjqKYgYRuN aDUhRPtmJ5eCn5rgGZGzCckEsucBVvcFc3OrnwJrO21bnr3tXqD8X36aPo5g UwuAqeNves3zOAmUzh2uXVxwdb6TNDbWu0gKHlEqA9dOiqz66W6KUMartGt3 WJtjX.l9_YR1eciGHMYalWWYF5t1Hq29QI4.EaDLYDjBpkCp1CbRyI7cYxXM kzBYebJnhKXlPCO5A93zSHvTBQLFgJZXxOELCRf6JutkypAT3lhkCFK9Y9L3 A9dLn1vykGK9LKauiAMfEL2c5fOB9IN3iRzUKFxYyOl6lLWzMRrfKhKdkkg4 ztE9m.vZvwtXaFpZvxONy83163aNugFloyR7TYlgLbAMin0HKyTsODzY.BNl YYBUwbdrG7ghYkrZtO7cO1VaN2KPChEm1hQ-- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 11:59:05 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> <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: <1339613945.46084.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 11:59:05 -0700 (PDT) From: William Mills To: Eve Maler In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss , O Auth WG Subject: Re: [apps-discuss] [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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 18:59:09 -0000 We certainly overlap, the thing you have that is not in the link type regis= trations is dynamic_client_registration_supported.=A0 We should be consiste= nt in naming, and ideally the OAuth related JSON elements from a JSON forma= t Webfinger request and your UMA stuff shoudl be identical.=A0 My concern w= ith using a JSON list structure for capability lists is how it would play i= n the LINK header itself, that seems a bit hairy to put a JSON list inside = a quoted application data value.=0A=0ADo we want something like a "capabili= ties" list which could include dynamic_client_registration_supported and pe= rhaps others?=0A=0A-bill=0A=0A=0A=0A=0A----- Original Message -----=0A> Fro= m: Eve Maler =0A> To: William Mills = =0A> Cc: Goix Laurent Walter ; Peter S= aint-Andre ; O Auth WG ; Apps Discuss <= apps-discuss@ietf.org>=0A> Sent: Wednesday, June 13, 2012 11:38 AM=0A> Subj= ect: Re: [OAUTH-WG] [apps-discuss] OAuth discovery registration.=0A> =0A> = Hi Bill-- In incorporating OAuth into several of the UMA flows, we found a = need =0A> for the authorization server to provide OAuth-related metadata al= ong with =0A> UMA-specific metadata. Originally it was strictly XRD- and ho= stmeta-based, but =0A> now uses a JSON format and is more akin to OpenID Co= nnect's metadata in =0A> style: =0A> =0A> http://docs.kantarainitiative.org= /uma/draft-uma-core.html#am-endpoints=0A> =0A> Do you feel that this new dr= aft is something that ultimately *should* replace =0A> the OAuth-specific p= arts of the metadata we've spec'd out for our use =0A> case? Note that we w= ent beyond just the two endpoints, also covering a feature =0A> toggle for = "dynamic_client_registration_supported" and lists of =0A> "oauth_token_prof= iles_supported" and =0A> "oauth_grant_types_supported". The purpose in doin= g this was to =0A> provide a machine-readable mechanism for aiding OAuth-le= vel interop.=0A> =0A> Thanks,=0A> =0A> =A0=A0=A0 Eve=0A> =0A> On 13 Jun 201= 2, at 11:19 AM, William Mills wrote:=0A> =0A>> On the informational status= , that seemed right, but I honestly don't =0A> know what the correct choice= is here.=A0 The actual registration happens via =0A> e-mail I believe, no= t via this document.=0A>> =0A>> Thanks for the feedback!=0A>> =0A>> -bill= =0A>> =0A>> =0A>> =0A>> ----- Original Message -----=0A>>> From: Goix Lau= rent Walter =0A>>> To: Peter Saint-An= dre ; William Mills =0A> =0A>>> = Cc: O Auth WG ; Apps Discuss =0A> = =0A>>> Sent: Wednesday, June 13, 2012 9:44 AM=0A>>> Subject: R: [apps-dis= cuss] [OAUTH-WG] OAuth discovery registration.=0A>>> =0A>>> T hank you Wil= liam for this initiative.=0A>>> =0A>>> I had similar concerns than Peter o= n authn vs authz.=0A>>> =0A>>> Under section 4.1.1 I would suggest to use = "oauth2-authorize" =0A> instead =0A>>> of "oauth2-authenticator", to be co= nsistent with the =0A>>> "oauth2-token" pattern and with the concepts of t= he oauth2 =0A> draft.=0A>>> =0A>>> The header of the pages still reference= sasl/gss-api and would need to =0A> be =0A>>> updated.=0A>>> =0A>>> Also= , an example and/or use case section could be beneficial, e.g. to =0A> desc= ribe =0A>>> its usage in an xrd document. Other use cases may be mentioned= as well =0A> probably.=0A>>> =0A>>> I have also noticed that your draft i= s mentioned as =0A> "informational". =0A>>> It is indeed your target or on= ly a typo?=0A>>> =0A>>> Thanks=0A>>> walter=0A>>> =0A>>>> -----Messaggio= originale-----=0A>>>> Da: apps-discuss-bounces@ietf.org =0A> [mailto:apps= -discuss-bounces@ietf.org] =0A>>> Per=0A>>>> conto di Peter Saint-Andre= =0A>>>> Inviato: mercoled=EC 13 giugno 2012 17.48=0A>>>> A: William Mills= =0A>>>> Cc: O Auth WG; Apps Discuss=0A>>>> Oggetto: Re: [apps-discuss] [O= AUTH-WG] OAuth discovery =0A> registration.=0A>>>> =0A>>>> On 6/13/12 9:27= AM, William Mills wrote:=0A>>>>> =0A>>>>> Since for the OAUTH SASL mechan= ism I need discovery for clients =0A> to=0A>>>>> work, and I had to rip th= e in-band discovery out of that =0A> mechanism,=0A>>>>> and I need it defi= ned somewhere, I've drafted a small doc =0A> for the=0A>>>>> registration = of link relation types for OAuth.=A0 It's too =0A> late in =0A>>> the=0A>>= >>> process to get this into the core OAuth 2 spec, and it =0A> doesn't = =0A>>> really=0A>>>>> fit in the WebFinger. Submission info provided belo= w.=0A>>>> =0A>>>> Hi Bill, overall this looks good. A few nits:=0A>>>> =0A= >>>> OLD=0A>>>> =A0 =A0 This document defines the LRDD [RFC5988] link typ= e =0A> registrations for=0A>>>> =A0 =A0 the OAuth [I-D.ietf-oauth-v2] auth= entication framework.=A0 These =0A> link=0A>>>> =A0 =A0 types are used dur= ing the endpoint discovery process using Web =0A> Host=0A>>>> =A0 =A0 Meta= data [I-D.hammer-hostmeta] and Webfinger=0A>>>> =A0 =A0 [I-D.jones-appsawg= -webfinger] by clients needing to discover =0A> the=0A>>>> =A0 =A0 authent= ication endpoints for a service or site.=A0 It =0A> additionally=0A>>>> =A0= =A0 defines link type registrations for OAuth 1.0a [RFC5849].=0A>>>> =0A>= >>> NEW=0A>>>> =A0 =A0 This document defines the Link-based Resource Desc= riptor=0A>>>> =A0 =A0 Documents (LRDD) [RFC6415] link type registrations f= or the=0A>>>> =A0 =A0 OAuth [I-D.ietf-oauth-v2] authorization framework.= =A0 These link=0A>>>> =A0 =A0 types are used during the endpoint discovery= process using Web=0A>>>> =A0 =A0 Host Metadata [RFC6415] and Webfinger=0A= >>>> =A0 =A0 [I-D.jones-appsawg-webfinger] by clients needing to discover = =0A> the=0A>>>> =A0 =A0 authorization, token, and access token endpoints f= or an OAuth2=0A>>>> =A0 =A0 service or site.=A0 It additionally defines li= nk type =0A> registrations for=0A>>>> OAuth=0A>>>> =A0 =A0 1.0a [RFC5849]= request initiation endpoints, authorization =0A> endpoints,=0A>>>> =A0 =A0= and token endpoints.=0A>>>> =0A>>>> In Section 4.1.1, you register an "O= Auth 2 Authentication =0A>>> Endpoint",=0A>>>> however draft-ietf-oauth-v= 2 defines only an authorization endpoint, =0A> a=0A>>>> token endpoint, an= d an access token endpoint. Whence this=0A>>>> "authentication endpoint"? = Is it just a typo?=0A>>>> =0A>>>> Also, is the lack of a link type for OAu= th2 access token endpoints =0A> an=0A>>>> oversight? It seems so.=0A>>>> = =0A>>>> You have "Reference: [[this document]]" but I think you =0A> want:= =0A>>>> =0A>>>> Reference: draft-ietf-oauth-v2=0A>>>> =0A>>>> and=0A>>>> = =0A>>>> Reference: RFC 5849=0A>>>> =0A>>>> You can remove the reference f= or draft-hammer-hostmeta (RFC 6415 =0A> has=0A>>>> what you need).=0A>>>> = =0A>>>> Peter=0A>>>> =0A>>>> --=0A>>>> Peter Saint-Andre=0A>>>> https:/= /stpeter.im/=0A>>>> =0A>>>> =0A>>>> =0A>>>> =0A>>>> ______________________= _________________________=0A>>>> apps-discuss mailing list=0A>>>> apps-di= scuss@ietf.org=0A>>>> https://www.ietf.org/mailman/listinfo/apps-discuss= =0A>>> =0A>>> Questo messaggio e i suoi allegati sono indirizzati esclusiv= amente alle =0A> persone =0A>>> indicate. La diffusione, copia o qualsiasi= altra azione derivante dalla =0A> =0A>>> conoscenza di queste informazion= i sono rigorosamente vietate. Qualora =0A> abbiate =0A>>> ricevuto questo = documento per errore siete cortesemente pregati di =0A> darne =0A>>> immed= iata comunicazione al mittente e di provvedere alla sua =0A> distruzione, = =0A>>> Grazie.=0A>>> =0A>>> This e-mail and any attachments is confidenti= al and may contain =0A> privileged =0A>>> information intended for the add= ressee(s) only. Dissemination, copying, =0A> printing =0A>>> or use by any= body else is unauthorised. If you are not the intended =0A> recipient, =0A>= >> please delete this message and any attachments and advise the sender by= =0A> return =0A>>> e-mail, Thanks.=0A>>> =0A>> _________________________= ______________________=0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> = https://www.ietf.org/mailman/listinfo/oauth=0A>> =0A> =0A> =0A> Eve Maler= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://= www.xmlgrrl.com/blog=0A> +1 425 345 6756=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 http://www.twitter.com/xmlgrrl=0A> From wmills@yahoo-inc.com Wed Jun 13 13:05: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 C799A11E808C for ; Wed, 13 Jun 2012 13:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.465 X-Spam-Level: X-Spam-Status: No, score=-17.465 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 eHVlOeWhLJHj for ; Wed, 13 Jun 2012 13:05:18 -0700 (PDT) Received: from nm25-vm0.bullet.mail.ac4.yahoo.com (nm25-vm0.bullet.mail.ac4.yahoo.com [98.139.52.240]) by ietfa.amsl.com (Postfix) with SMTP id 7449A21F861A for ; Wed, 13 Jun 2012 13:05:15 -0700 (PDT) Received: from [98.139.52.192] by nm25.bullet.mail.ac4.yahoo.com with NNFMP; 13 Jun 2012 20:05:11 -0000 Received: from [98.139.52.150] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 13 Jun 2012 20:05:11 -0000 Received: from [127.0.0.1] by omp1033.mail.ac4.yahoo.com with NNFMP; 13 Jun 2012 20:05:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 683897.10711.bm@omp1033.mail.ac4.yahoo.com Received: (qmail 560 invoked by uid 60001); 13 Jun 2012 20:05:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339617910; bh=cF94E/L3e1ce9glpPSEt1vwJbfQxwJi7IKNXJSu13ZA=; 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:Content-Transfer-Encoding; b=Sa0e00zI7F8kD+3LdkA9FaccTwTBksT8S8xu6BchjAsT5ADoWuFFae1xX1HmkAD0tq0bjdzzE5xy4XSxXf/NYXnFbyq8/fc96Uwb+mjZP6xadTLahxHCuvUMZ7W0oZj/EL6SNob+mS/plNRDeisBcXOEaQBivDBHROiS8sezaos= 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:Content-Transfer-Encoding; b=JAd0wcP6GhIZYlzlDmWYl1+wbL/m7eyJtJAXIJQcKyXaLq85H0V9LNTjor0mideoZs/3pCHuRpXyZ8qWjICggh0zN66nsJsLXvzrIfGHGUT8rgOd8KbmmGXU/lnklyg/MnPJHyrrC4dvo+9SYQChZNb/zJSn2CK2P/kAuabsRvo=; X-YMail-OSG: wo5rXsAVM1l9ylwTlK8e3PvASBVrGfE22o.21xF6izlUAdy O4Wusbc.e3yH4KVNj2Syr_0Ia.Cqm3V.X331i6wIIMHv7w_TqfrrEEL9llZk MI22RfOOdYmZDzby3zwfCApI6f06uhozvIRV3ymWtTNk1WZDz3PxQYy4bOlB .IeuenbcLWTBp9JNQEths5INrL2uZ6LZEjppfym6ujPK4WbNbrJ5vXXo7e49 WlV2idGGogf1GsSGo.zIQmUAFNn4sZtlNd2dq8LGSR_Rt7JnVlAbdJhdFxq6 IqNBQnhVCXhDsegy9uRW54hibLZYzZg84revIjI4ZkWyCyfd5_fof2ZL3WMx 9n0SLoeaSfiYTf7R18aBD1pAkpr_ld124exjaIL.Bng7bLj7l6k1gKvrZX.v _D2RpcblQrUqkW.3eWw4oiqPQRrFodUoyHrXqMlvm8B2mBds0rGaPiZmnQmk QcPWj5NeOpvQSf5TNVHU93dvQHpExWiVBmymu8VLEA0f6 Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 13:05:10 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: <1339617910.72530.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 13:05:10 -0700 (PDT) From: William Mills To: Apps Discuss , O Auth WG In-Reply-To: <4FD8B646.3080509@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] [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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 20:05:19 -0000 I've incorporated a number of changes and added examples.=A0 Thanks to all = for the feedback.=A0 I can do a new draft any time if that's useful.=0A=0A-= bill=0A=0A=0A=0A----- Original Message -----=0A> From: Peter Saint-Andre =0A> To: William Mills =0A> Cc: O A= uth WG ; Apps Discuss =0A> Sent: Wed= nesday, June 13, 2012 8:48 AM=0A> Subject: Re: [OAUTH-WG] OAuth discovery r= egistration.=0A> =0A> On 6/13/12 9:27 AM, William Mills wrote:=0A>> =0A>> = Since for the OAUTH SASL mechanism I need discovery for clients to=0A>> wo= rk, and I had to rip the in-band discovery out of that mechanism,=0A>> and= I need it defined somewhere, I've drafted a small doc for the=0A>> regist= ration of link relation types for OAuth.=A0 It's too late in the=0A>> proc= ess to get this into the core OAuth 2 spec, and it doesn't really=0A>> fit= in the WebFinger. Submission info provided below.=0A> =0A> Hi Bill, overal= l this looks good. A few nits:=0A> =0A> OLD=0A> =A0 This document defines = the LRDD [RFC5988] link type registrations for=0A> =A0 the OAuth [I-D.ietf= -oauth-v2] authentication framework.=A0 These link=0A> =A0 types are used = during the endpoint discovery process using Web Host=0A> =A0 Metadata [I-D= .hammer-hostmeta] and Webfinger=0A> =A0 [I-D.jones-appsawg-webfinger] by c= lients needing to discover the=0A> =A0 authentication endpoints for a serv= ice or site.=A0 It additionally=0A> =A0 defines link type registrations fo= r OAuth 1.0a [RFC5849].=0A> =0A> NEW=0A> =A0 This document defines the Lin= k-based Resource Descriptor=0A> =A0 Documents (LRDD) [RFC6415] link type r= egistrations for the=0A> =A0 OAuth [I-D.ietf-oauth-v2] authorization frame= work.=A0 These link=0A> =A0 types are used during the endpoint discovery p= rocess using Web=0A> =A0 Host Metadata [RFC6415] and Webfinger=0A> =A0 [I= -D.jones-appsawg-webfinger] by clients needing to discover the=0A> =A0 aut= horization, token, and access token endpoints for an OAuth2=0A> =A0 servic= e or site.=A0 It additionally defines link type registrations for=0A> OAuth= =0A> =A0 1.0a [RFC5849] request initiation endpoints, authorization endpoi= nts,=0A> =A0 and token endpoints.=0A> =0A> In Section 4.1.1, you register = an "OAuth 2 Authentication Endpoint",=0A> however draft-ietf-oauth-v2 defin= es only an authorization endpoint, a=0A> token endpoint, and an access toke= n endpoint. Whence this=0A> "authentication endpoint"? Is it just a typo?= =0A> =0A> Also, is the lack of a link type for OAuth2 access token endpoint= s an=0A> oversight? It seems so.=0A> =0A> You have "Reference: [[this docum= ent]]" but I think you want:=0A> =0A> Reference: draft-ietf-oauth-v2=0A> = =0A> and=0A> =0A> Reference: RFC 5849=0A> =0A> You can remove the reference= for draft-hammer-hostmeta (RFC 6415 has=0A> what you need).=0A> =0A> Peter= =0A> =0A> -- =0A> Peter Saint-Andre=0A> https://stpeter.im/=0A> From wmills@yahoo-inc.com Wed Jun 13 15:17:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0396D21F8595 for ; Wed, 13 Jun 2012 15:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.474 X-Spam-Level: X-Spam-Status: No, score=-17.474 tagged_above=-999 required=5 tests=[AWL=0.124, 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 xZ3xDwNY07Pf for ; Wed, 13 Jun 2012 15:17:23 -0700 (PDT) Received: from nm31-vm7.bullet.mail.ne1.yahoo.com (nm31-vm7.bullet.mail.ne1.yahoo.com [98.138.229.47]) by ietfa.amsl.com (Postfix) with SMTP id 71D1E21F8522 for ; Wed, 13 Jun 2012 15:17:23 -0700 (PDT) Received: from [98.138.90.57] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 22:17:20 -0000 Received: from [98.138.89.248] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 22:17:20 -0000 Received: from [127.0.0.1] by omp1040.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 22:17:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 482953.21345.bm@omp1040.mail.ne1.yahoo.com Received: (qmail 53447 invoked by uid 60001); 13 Jun 2012 22:17:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339625840; bh=r+ga6vt6V+5YiuhLl+jkKfVTYIzYJxHdlEbajQRjCFU=; 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=fgHev3Arwniam2KUlvqWMx4gBuh4jOZAnQg6UJFbpiEUoMo0fxoxYAV20/2QyKqzEuCupwhX3ZF4jKZzEWimOl7tnF735gJop7sl7iYvBkCo20ViFmr9bLaYC7gm7QDmKeyUp8Xb3fzjbmb8L74gMccYoIo+R62znr/pEVAGEFs= 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=cOP63KhDeFzixUe1hvXslQAJLE91dXr0nfHhE6rnDnkljL3Wfq997dvdHziWCFqT2yG/IiGpnmXHJVWnM1t1mOybhaFeF1YoTGLnJeCKwurIGLmFWIeqL0ytDMFQ3ShXJ04GtljrSmM470PIoGOQVOUM6N7255tocXTjBSr5Iaw=; X-YMail-OSG: TVivSAEVM1k7qE1FI.vtMMpf0mTrsWsvWiY0d0yG0GmbyMJ pElQlev2zDjqGIGUeb2h8fD2EobRJAxJfRz4l6Fw0qIb2Ew4riKEGtsDlMis 1JsRJBZTAB0lBidZZxo4M1bJeGNBkqrSwyx3v6UgBpY2Ifhx6dCqLx0ImjJ8 gyWaoRSmVwrpeSZBdXNW.lylsX.St7k3NODktJYeCra41E2Ga02FIE4EO.ol yObexzQPcHVix2W6cn0GY7vlCIfnbb4xUWfOUuqIrNlXP8dAj9Ohz9LJkeMC inQ_pOilc_McyEdF.l1I_SybmVvfmxFm2c3O2bWwfcvCUgKZfYgbu_dP.Msd 5FmtEVIQzvrk_3VT6N6uCm6S80TGTYlafQwg7c0TLQxrOHl8wPScgf4SLEJb uX8E7ZlHHnnxg.mQilWdmuQI2zqigQf4oymt3D1FSlG463ziJP2CYryj1mCD uXV5HCBJpat9.8SG3xEUlAxVhMJhFLxrDk6l7iT03cY4zejZZX0W5TTH_hEF Q.uVOW5v2Cj8PMpcWIFDpcq3r2FGGiF.lNpwNoDOqxtdS493BMuWFwtQJQbt WRkQTTeAyfQ3GIAlIS7OVOv8fzjo79UYqe207_cGzcwiN4xcze0pSlC.dFTg fCmvoXGYXhU6W5esAFa4- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 15:17:19 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> Message-ID: <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 15:17:19 -0700 (PDT) From: William Mills To: "Paul E. Jones" , 'Cyrus Daboo' , "apps-discuss@ietf.org" In-Reply-To: <059c01cd39c8$f3d027c0$db707740$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-370352827-1339625839=:48148" Subject: Re: [apps-discuss] Aggregated service discovery 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 22:17:25 -0000 ---1238014912-370352827-1339625839=:48148 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I was just thinking about this topic and found the thread in the archive.= =A0 I'm interested specifically in the use case of a client discovering IMA= P and SMTP services along with OAuth endpoints.=0A=0AXMPP, IMAP and POP all= have URI schemes defined, though SMTP does not.=A0 With things that alread= y have a dedicated scheme for a service type would it make sense to use the= "related" link type already defined?=A0 Then the client looks for "related= " links of the scheme they want to discover.=0A=0AThe "related" link type w= as registered as part of "Atom" http://www.iana.org/go/rfc4287, but it seem= s to fit.=0A=0AWe still have to deal with SMTP for what I want.=A0 DNS SRV = records certainly also work, but I like a one-stop-shop.=0A=0A-bill=0A=0A= =0A=0A=0A>________________________________=0A> From: Paul E. Jones =0A>To: 'Cyrus Daboo' ; apps-discuss@ietf.= org =0A>Sent: Thursday, May 24, 2012 9:19 AM=0A>Subject: Re: [apps-discuss]= Aggregated service discovery=0A> =0A>Cyrus,=0A>=0A>I apologize for not rep= lying sooner.=0A>=0A>I do believe WebFinger could be used to locate these s= ervices.=A0 I wasn't=0A>aware of RFC 6186 (and rushed right out to add it t= o my domain), but=0A>WebFinger could be used to provide an even better leve= l of granularity.=A0 It=0A>exists now, so I'm not sure if one would want to= migrate to WebFinger, but=0A>if it did I can imagine something like this:= =0A>=0A>GET /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com= =0A>=0A>Returning...=0A>=0A>{=0A>=A0 "subject" : "mailto:paulej@packetizer.= com",=0A>=A0 "links" :=0A>=A0 [=0A>=A0 =A0 {=0A>=A0 =A0 =A0 "rel" : "config= -email",=0A>=A0 =A0 =A0 "href" : "http://www.packetizer.com.com/config/emai= l/?user=3Dpaulej"=0A>=A0 =A0 }=0A>=A0 ]=0A>}=0A>=0A>The above document woul= d include a link relation that refers to mail server=0A>configuration.=A0 Q= uerying the /config/email/ URI might return a JSON document=0A>like this:= =0A>=0A>=0A>=A0 {=0A>=A0 =A0 "imaps" : "cluster23.imap.packetizer.com",=0A>= =A0 =A0 "smtp-submission" : "smtp.packetizer.com"=0A>=A0 }=0A>=0A>(Note: th= is is a trivial example, whereas we'd probably need to indicate use=0A>of S= SL, TLS, login requirements, etc.)=0A>=0A>It would accomplish something sim= ilar to SRV records, but provide a finer=0A>level of granularity to allow d= omain owners to assign users to different=0A>machines and specific configur= ations.=0A>=0A>Paul=0A>=0A>> -----Original Message-----=0A>> From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]=0A>> On Behalf= Of Cyrus Daboo=0A>> Sent: Tuesday, May 22, 2012 11:00 AM=0A>> To: apps-dis= cuss@ietf.org=0A>> Subject: [apps-discuss] Aggregated service discovery=0A>= > =0A>> Hi folks,=0A>> Today many protocols define their own "service disco= very" protocols (e.g.,=0A>> ,=0A>> ,=0A>> ).=0A>> =0A>> >From a client perspective, these each = work fine individually. But more=0A>> often than not, a client device actua= lly wants to be able to discover all=0A>> services a "service provider" has= available or provisioned for the user.=0A>> i.e., a user expects email, ca= lendar, contacts, IM, directory etc to be=0A>> setup in one step by the cli= ent, rather than having to go and setup each=0A>> service separately. Whils= t a client can present a single UI for such an=0A>> "aggregated service dis= covery" it still has to go use separate discovery=0A>> protocols for each s= ervice. This is expensive - lots of separate DNS=0A>> lookups, etc.=0A>> = =0A>> Several proprietary systems offer and "aggregated service discovery"= =0A>> protocol - in its simplest form a GET on a well known URI that return= s an=0A>> XML document listing available services and other useful configur= ation=0A>> information.=0A>> =0A>> It is time we had such a protocol for th= e IETF standard suite of=0A>> protocols.=0A>> In particular implementors in= volved in the Calendaring and Scheduling=0A>> Consortium are very keen to s= ee a good solution to this problem. So I am=0A>> starting a discussion on t= his here to solicit some ideas about how best to=0A>> approach this, with a= view to writing a draft.=0A>> =0A>> The obvious, and simplest approach, is= the HTTP GET on a .well-known URI=0A>> returning an XML or JSON document w= ith a standard "schema".=0A>> =0A>> Another possibility is to leverage the = webfinger work. I'd like to hear=0A>> from webfinger experts as to whether = a use case like this would be a=0A>> reasonable solution. Some concerns I h= ave are the security "scope".=0A>> Obviously service discovery is something= that a user does for themselves=0A>> and their service information should = be private, which seems somewhat=0A>> contrary to the primary user case for= webfinger whether other users are=0A>> looking up the information.=0A>> = =0A>> Security, simplicity and efficiency are the key goals for this protoc= ol.=0A>> =0A>> Comments, ideas?=0A>> =0A>> --=0A>> Cyrus Daboo=0A>> =0A>> _= ______________________________________________=0A>> apps-discuss mailing li= st=0A>> apps-discuss@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/ap= ps-discuss=0A>=0A>_______________________________________________=0A>apps-d= iscuss mailing list=0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailma= n/listinfo/apps-discuss=0A>=0A>=0A> ---1238014912-370352827-1339625839=:48148 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I was just thinking about this topic and found the thread in the archive.=   I'm interested specifically in the use case of a client discovering = IMAP and SMTP services along with OAuth endpoints.

XMPP, IMAP and POP all have URI schemes defined,= though SMTP does not.  With things that already have a dedicated sche= me for a service type would it make sense to use the "related" link type al= ready defined?  Then the client looks for "related" links of the schem= e they want to discover.

The "related" link type was registered as part of "Atom" http://www.iana.o= rg/go/rfc4287, but it seems to fit.

We still have to deal with SMTP for what I want.  DNS SRV records certainly also work, but I like a one-stop-shop.
<= div>
-bill

<= div dir=3D"ltr">
From: Paul E. Jones <paulej@pack= etizer.com>
To: 'Cy= rus Daboo' <cyrus@daboo.name>; apps-discuss@ietf.org
Sent: Thursday, May 24, 2012 9:19 AM<= br> Subject: Re: [apps-dis= cuss] Aggregated service discovery

=0ACyrus,

= I apologize for not replying sooner.

I do believe WebFinger could be= used to locate these services.  I wasn't
aware of RFC 6186 (and ru= shed right out to add it to my domain), but
WebFinger could be used to p= rovide an even better level of granularity.  It
exists now, so I'm = not sure if one would want to migrate to WebFinger, but
if it did I can = imagine something like this:

GET /.well-known/host-meta?resource=3Dm= ailto:paulej@packetizer.com

Returning...

{
&nbs= p; "subject" : "mailto:paulej@packetizer.com",
  "links"= :
  [
    {
      "rel" : "config-e= mail",
      "href" : "http://www.packetizer.com.com/conf= ig/email/?user=3Dpaulej"
    }
  ]
}

The above document would include a link relation that refers= to mail server
configuration.  Querying the /config/email/ URI mig= ht return a JSON document
like this:


  {
   = ; "imaps" : "cluster23.imap.packetizer.com",
    "smtp-submission= " : "smtp.packeti= zer.com"
  }

(Note: this is a trivial example, whereas w= e'd probably need to indicate use
of SSL, TLS, login requirements, etc.)=

It would accomplish something similar to SRV records, but provide a= finer
level of granularity to allow domain owners to assign users to di= fferent
machines and specific configurations.

Paul

> --= ---Original Message-----
> From: apps-discuss-bounces@ietf.or= g [mailto:apps-discuss-bounces@ietf.org]
= > On Behalf Of Cyrus Daboo
> Sent: Tuesday, May 22, 2012 11:00 AM<= br>> To: apps-discuss@ietf.org
> Subject: [apps-discuss= ] Aggregated service discovery
>
> Hi folks,
> Today man= y protocols define their own "service discovery" protocols (e.g.,
> &= lt;http://= tools.ietf.org/html/rfc6186>,
> <https://datatr= acker.ietf.org/doc/draft-daboo-srv-caldav/>,
> <http://tools.ietf.org/html/rfc6125>).
> > >From a client perspective, these each work fine individually. But= more
> often than not, a client device actually wants to be able to = discover all
> services a "service provider" has available or provisi= oned for the user.
> i.e., a user expects email, calendar, contacts, = IM, directory etc to be
> setup in one step by the client, rather tha= n having to go and setup each
> service separately. Whilst a client c= an present a single UI for such an
> "aggregated service discovery" i= t still has to go use separate discovery
> protocols for each service= . This is expensive - lots of separate DNS
> lookups, etc.
> > Several proprietary systems offer and "aggregated service discovery"=
> protocol - in its simplest form a GET on a well known URI that ret= urns an
> XML document listing available services and other useful configuration
> information.
>
> It is time we h= ad such a protocol for the IETF standard suite of
> protocols.
>= ; In particular implementors involved in the Calendaring and Scheduling
= > Consortium are very keen to see a good solution to this problem. So I = am
> starting a discussion on this here to solicit some ideas about h= ow best to
> approach this, with a view to writing a draft.
> <= br>> The obvious, and simplest approach, is the HTTP GET on a .well-know= n URI
> returning an XML or JSON document with a standard "schema".>
> Another possibility is to leverage the webfinger work. I'd = like to hear
> from webfinger experts as to whether a use case like t= his would be a
> reasonable solution. Some concerns I have are the se= curity "scope".
> Obviously service discovery is something that a use= r does for themselves
> and their service information should be private, which seems somewhat
> contrary to the primary user case= for webfinger whether other users are
> looking up the information.<= br>>
> Security, simplicity and efficiency are the key goals for = this protocol.
>
> Comments, ideas?
>
> --
>= ; Cyrus Daboo
>
> ____________________________________________= ___
> apps-discuss mailing list
> apps-discuss@ietf.org<= /a>
> https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
apps-discuss mailin= g list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

---1238014912-370352827-1339625839=:48148-- From stpeter@stpeter.im Wed Jun 13 15:45: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 D59DC11E80B2 for ; Wed, 13 Jun 2012 15:45:04 -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 u6bQfvBJC5Qz for ; Wed, 13 Jun 2012 15:45:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 101C011E80B5 for ; Wed, 13 Jun 2012 15:45:04 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 59DF740081; Wed, 13 Jun 2012 17:02:15 -0600 (MDT) Message-ID: <4FD917ED.2050805@stpeter.im> Date: Wed, 13 Jun 2012 16:45:01 -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: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> In-Reply-To: <1339625839.48148.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@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 22:45:05 -0000 On 6/13/12 4:17 PM, William Mills wrote: > I was just thinking about this topic and found the thread in the > archive. I'm interested specifically in the use case of a client > discovering IMAP and SMTP services along with OAuth endpoints. > > XMPP, IMAP and POP all have URI schemes defined, though SMTP does not. > With things that already have a dedicated scheme for a service type > would it make sense to use the "related" link type already defined? > Then the client looks for "related" links of the scheme they want to > discover. > > The "related" link type was registered as part of "Atom" > http://www.iana.org/go/rfc4287, but it seems to fit. > > We still have to deal with SMTP for what I want. DNS SRV records > certainly also work, but I like a one-stop-shop. Hi Bill, What exactly are you trying to discover? At least in XMPP, we've been using DNS SRV records for many years, and they seem to work just fine for discovering XMPP servers and the means for connecting to them. If you want to discover the IM or other accounts associated with an email address, then WebFinger seems more appropriate. Peter From wmills@yahoo-inc.com Wed Jun 13 15:55: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 0BA7211E8097 for ; Wed, 13 Jun 2012 15:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.483 X-Spam-Level: X-Spam-Status: No, score=-17.483 tagged_above=-999 required=5 tests=[AWL=0.115, 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 v-PMb038+d3J for ; Wed, 13 Jun 2012 15:55:00 -0700 (PDT) Received: from nm3.bullet.mail.bf1.yahoo.com (nm3.bullet.mail.bf1.yahoo.com [98.139.212.162]) by ietfa.amsl.com (Postfix) with SMTP id ED1AD21F850C for ; Wed, 13 Jun 2012 15:54:59 -0700 (PDT) Received: from [98.139.212.145] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jun 2012 22:54:59 -0000 Received: from [98.139.215.254] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jun 2012 22:54:59 -0000 Received: from [127.0.0.1] by omp1067.mail.bf1.yahoo.com with NNFMP; 13 Jun 2012 22:54:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 351882.86226.bm@omp1067.mail.bf1.yahoo.com Received: (qmail 1269 invoked by uid 60001); 13 Jun 2012 22:54:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339628098; bh=cnRnqV/7aHwwPNfsKmrW8vy2F7/cmRySBmAXDkbvf7o=; 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=IUESy2CZ90Nfx/XJEAqX6E8/99kGkxrebE9RafBAeTfl4cIXvyabnsZRMO+MiFSclHeLHckd1w56f3nRGMJfOq93C09MQ00Mb0TmYQj4yBrm061umCVg1xE0iS8XRT1v+ma520CCpwYz3g5FC1hGg1NmTgMjTKd9MpIZnG2qdMQ= 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=cQiNy3pdUn/hSha2f4u7H1hbpEUG5b5s5q4qqF3KYvTO+BTlYk6/6UnpOFR/iHDLFhwur9Ep+Cm+DccG7+ph6lwQvfop1vt04Gm+4uHx1ot5Gz+QCEX5ynzwNDCZ2M3SnOd/cUSZS4VJ2GIxwfCwUlxILMdE+p2V4Od9BEMjsGw=; X-YMail-OSG: SoDdI3UVM1lrf3L24EzCpoweKLqYWlFUZSnH5B4O9mbFrku 8AnpuJTlKS4pYmI4GlVxhSBTZ4A2C66jgvlc7uxmu.Ac1MNiSXiuvCoDd9Dl S43BYvbl7JZvAbXhJioPA0DZskRe52QWrrI3yz_FdoTlekcc7Zewcx5XQH0z wYojHNRRz7JSc9QFzVsttQRyd2TmKlbr7vx1UxvagnsW4kkVHQcOmT.vZvzV mHmzhHpnkS3mtjecW9UwldOFXKfkBah._sVvGvNK_KMdgUdPQkHuqerGD.PB IjX28B3ErM_p3PMGYdsPhHdvzCmVr3Y3MQ2DFXfwX_Tdn0MyvjeMDQFZXGBV 5Dd7UcBcCoo5M4eEh40cQQHhrJPmbytrA2zmpXOu_k6TGM2W3aweC_OwK3sw wiJZHDKhUdB4SwzkFv_OBRfkJ.396oQIz2._VbtjxYmnRom_VSwPk2a1GwR4 xkJEKtrfypy8E52ja8nI7rV0yP_KtsQL0oSJhVEpeYHnu9BZTzr4vmFlP8WY - Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 15:54:58 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> Message-ID: <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 15:54:58 -0700 (PDT) From: William Mills To: Peter Saint-Andre In-Reply-To: <4FD917ED.2050805@stpeter.im> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-1007853197-1339628098=:85328" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery 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 22:55:01 -0000 --1458549034-1007853197-1339628098=:85328 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable As I said, I'm interested specifically in IMAP, SMTP and OAuth endpoints.= =A0 =0A=0A=0AAs a data point, DNS SRV records are not controllable in many = hosted domain models.=0A=0A=0A=0A=0A>________________________________=0A> F= rom: Peter Saint-Andre =0A>To: William Mills =0A>Cc: Paul E. Jones ; 'Cyrus Daboo' <= cyrus@daboo.name>; "apps-discuss@ietf.org" =0A>Sent= : Wednesday, June 13, 2012 3:45 PM=0A>Subject: Re: [apps-discuss] Aggregate= d service discovery=0A> =0A>On 6/13/12 4:17 PM, William Mills wrote:=0A>> I= was just thinking about this topic and found the thread in the=0A>> archiv= e.=A0 I'm interested specifically in the use case of a client=0A>> discover= ing IMAP and SMTP services along with OAuth endpoints.=0A>> =0A>> XMPP, IMA= P and POP all have URI schemes defined, though SMTP does not. =0A>> With th= ings that already have a dedicated scheme for a service type=0A>> would it = make sense to use the "related" link type already defined? =0A>> Then the c= lient looks for "related" links of the scheme they want to=0A>> discover.= =0A>> =0A>> The "related" link type was registered as part of "Atom"=0A>> h= ttp://www.iana.org/go/rfc4287, but it seems to fit.=0A>> =0A>> We still hav= e to deal with SMTP for what I want.=A0 DNS SRV records=0A>> certainly also= work, but I like a one-stop-shop.=0A>=0A>Hi Bill,=0A>=0A>What exactly are = you trying to discover? At least in XMPP, we've been=0A>using DNS SRV recor= ds for many years, and they seem to work just fine=0A>for discovering XMPP = servers and the means for connecting to them. If=0A>you want to discover th= e IM or other accounts associated with an email=0A>address, then WebFinger = seems more appropriate.=0A>=0A>Peter=0A>=0A>=0A>=0A> --1458549034-1007853197-1339628098=:85328 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
As I said, I'm interested specifically in IMAP, SMTP and OAuth endpoints.=  

As a data po= int, DNS SRV records are not controllable in many hosted domain models.
=

From: P= eter Saint-Andre <stpeter@stpeter.im>
To: William Mills <wmills@yahoo-inc.com>
Cc: Paul E. Jones <paulej@packe= tizer.com>; 'Cyrus Daboo' <cyrus@daboo.name>; "apps-discuss@ietf.o= rg" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Aggregated servic= e discovery

=0AOn 6/13/12 4:17 PM, William Mills wro= te:
> I was just thinking about this topic and found the thread in th= e
> archive.  I'm interested specifically in the use case of a c= lient
> discovering IMAP and SMTP services along with OAuth endpoints= .
>
> XMPP, IMAP and POP all have URI schemes defined, though = SMTP does not.
> With things that already have a dedicated scheme fo= r a service type
> would it make sense to use the "related" link type= already defined?
> Then the client looks for "related" links of the= scheme they want to
> discover.
>
> The "related" link = type was registered as part of "Atom"
> http://www.iana.org/go/rfc428= 7, but it seems to fit.
>
> We still have to deal with SMTP fo= r what I want.  DNS SRV records
> certainly also work, but I lik= e a one-stop-shop.

Hi Bill,

What exactly are you trying to di= scover? At least in XMPP, we've been
using DNS SRV records for many years, and they seem to work just f= ine
for discovering XMPP servers and the means for connecting to them. I= f
you want to discover the IM or other accounts associated with an email=
address, then WebFinger seems more appropriate.

Peter


--1458549034-1007853197-1339628098=:85328-- From stpeter@stpeter.im Wed Jun 13 15:58: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 AD5E511E8097 for ; Wed, 13 Jun 2012 15:58: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 lyIYan4ar9H8 for ; Wed, 13 Jun 2012 15:58:01 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2442C21F8589 for ; Wed, 13 Jun 2012 15:58:01 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F3FF940081; Wed, 13 Jun 2012 17:15:13 -0600 (MDT) Message-ID: <4FD91AF7.5050107@stpeter.im> Date: Wed, 13 Jun 2012 16:57:59 -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: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> In-Reply-To: <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 22:58:01 -0000 On 6/13/12 4:54 PM, William Mills wrote: > As I said, I'm interested specifically in IMAP, SMTP and OAuth endpoints. What exactly is an "endpoint"? A client? An account? A server? > As a data point, DNS SRV records are not controllable in many hosted > domain models. At the last XMPP Summit a few months ago, we learned that DNS SRV records are unavailable in whole countries (e.g., Japan). That doesn't mean we should define a replacement for DNS over HTTP. :) Peter -- Peter Saint-Andre https://stpeter.im/ From wmills@yahoo-inc.com Wed Jun 13 16:31: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 37B2B21F84E1 for ; Wed, 13 Jun 2012 16:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.491 X-Spam-Level: X-Spam-Status: No, score=-17.491 tagged_above=-999 required=5 tests=[AWL=0.107, 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 i4b3EGlHgSn4 for ; Wed, 13 Jun 2012 16:31:46 -0700 (PDT) Received: from nm22.bullet.mail.ac4.yahoo.com (nm22.bullet.mail.ac4.yahoo.com [98.139.52.219]) by ietfa.amsl.com (Postfix) with SMTP id 26D4021F84DD for ; Wed, 13 Jun 2012 16:31:46 -0700 (PDT) Received: from [98.139.52.188] by nm22.bullet.mail.ac4.yahoo.com with NNFMP; 13 Jun 2012 23:31:42 -0000 Received: from [98.139.52.144] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 13 Jun 2012 23:31:41 -0000 Received: from [127.0.0.1] by omp1027.mail.ac4.yahoo.com with NNFMP; 13 Jun 2012 23:31:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 796200.39899.bm@omp1027.mail.ac4.yahoo.com Received: (qmail 21542 invoked by uid 60001); 13 Jun 2012 23:31:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339630301; bh=ggujdKH3XPeV1R2TFqkDjwlbfN6BSfuy49rlW8K1Ews=; 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=JCHRvFt45rFXCCBxtoPJmyWnWxV50D9DMKWhZrNjOdmXUH+Yiq+/Uxv7vdH7pB1e3TY7eymSK2jSL48GhNJYrHvP/D2QYmT/l8HkSB0kMPN8w62CYbPtYe5wf3lesN218eG3cTAAhPJCwFvzYEd6wSf2Us4k2TsHAtrgbYKTkMI= 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=Q1qfN1v0psamRA9vIboj7mYvDVhvC2JJfjiDTKR/+an4KK2IcqJzOB8xQJzk659P5Y/pDmT53gCXKzPcMOKKf4eWIxRa/45Mwsp4aFCxOIg9R2wiOClZYseanwOL6SvbhdZTdR1XhnfxkZDXB7XaP5cg+7R1zAD1oYvFmLhJ5FM=; X-YMail-OSG: hD1w9iYVM1mttBAbTpOqQQvwghbAaY7fTuJ1E.IUZsabvTo .GzGsDxOcbmD_SP_jxGFUaNboXKw.D8nc.rZ65ib2sGqKpGlEB5RBKCMbgKh EFECPFvyL9W4T4QX7.Ex0RZnC5KV5tWFvNzlE9.2jqrO0ophu3m0ZbqEELhE C9maBw0xjRkRY_QG4Ocp0SO5z0igMUuMd_UrGd.eSvRWg4HfMSbHI57ZMjJH 244VjMs5S5rCt4q90_0.yHwl0G5WS4OWKQJ_rlu8P15Udy6u.i5qD.hTcNpz xpJxSRR6N3cAvJME1id_9wK3SutI.J0oaqCmZZj2ULzLD.vbFeZWN5AHioey TKzyDeyfz1K1R89yd1ZoxiUlusWvnIKBF2DDhnqYf9cfAM3ykViUbuKQtbCU BwwEsbret7bjx4YcKuW0Yf14nEYw6_ZB0Q5A5Yis036Ixmv4nKyzN5AY7LwO GoCeXKaPDXvNJdmoz2WUA1jO1UccDCgf.8uLhO4Fd0LVhsw-- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 16:31:40 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> Message-ID: <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 16:31:40 -0700 (PDT) From: William Mills To: Peter Saint-Andre In-Reply-To: <4FD91AF7.5050107@stpeter.im> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-2056792573-1339630300=:21499" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery 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 23:31:47 -0000 --1458549034-2056792573-1339630300=:21499 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable In my use case it's a service/server.=0A=0ANot a terribly happy answer to s= ay "DNS SRV records won't work for you, and there is no other solution.".= =A0 By the same token I could ask "Why do we need Webfinger and host meta a= t all if we have DNS SRV records?".=0A=0AIf XMPP uses SRV records for disco= very, that's fine.=A0 IMAP and outbound SMTP services both lack a defined d= iscovery method other than the ubiquitous "service documentation".=A0 Is th= ere a compelling reason to pick DNS over WF for this?=A0 From the app devel= oper point of view I don't want to have N ways to discover M services.=0A= =0A-bill=0A=0A=0A=0A=0A=0A=0A>________________________________=0A> From: Pe= ter Saint-Andre =0A>To: William Mills =0A>Cc: Paul E. Jones ; 'Cyrus Daboo' ; "apps-discuss@ietf.org" =0A>Sent: Wedne= sday, June 13, 2012 3:57 PM=0A>Subject: Re: [apps-discuss] Aggregated servi= ce discovery=0A> =0A>On 6/13/12 4:54 PM, William Mills wrote:=0A>> As I sai= d, I'm interested specifically in IMAP, SMTP and OAuth endpoints. =0A>=0A>W= hat exactly is an "endpoint"? A client? An account? A server?=0A>=0A>> As a= data point, DNS SRV records are not controllable in many hosted=0A>> domai= n models.=0A>=0A>At the last XMPP Summit a few months ago, we learned that = DNS SRV=0A>records are unavailable in whole countries (e.g., Japan). That d= oesn't=0A>mean we should define a replacement for DNS over HTTP. :)=0A>=0A>= Peter=0A>=0A>-- =0A>Peter Saint-Andre=0A>https://stpeter.im/=0A>=0A>=0A>=0A= >=0A>=0A>=0A> --1458549034-2056792573-1339630300=:21499 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
In my use case it's a service/server.

<= /div>
Not a terribly happy answer to say "DNS SRV records won't w= ork for you, and there is no other solution.".  By the same token I co= uld ask "Why do we need Webfinger and host meta at all if we have DNS SRV r= ecords?".

If XMPP uses S= RV records for discovery, that's fine.  IMAP and outbound SMTP service= s both lack a defined discovery method other than the ubiquitous "service d= ocumentation".  Is there a compelling reason to pick DNS over WF for t= his?  From the app developer point of view I don't want to have N ways= to discover M services.

-bill


From: Peter Saint-Andre <stpe= ter@stpeter.im>
To:= William Mills <wmills@yahoo-inc.com>
Cc: Paul E. Jones <paulej@packetizer.com>; 'Cyr= us Daboo' <cyrus@daboo.name>; "apps-discuss@ietf.org" <apps-discus= s@ietf.org>
Sent: = Wednesday, June 13, 2012 3:57 PM
Subject:= Re: [apps-discuss] Aggregated service discovery
=0AOn 6/13/12 4:54 PM, William Mills wrote:
> As I said, I'm interes= ted specifically in IMAP, SMTP and OAuth endpoints.

What exactly is= an "endpoint"? A client? An account? A server?

> As a data point= , DNS SRV records are not controllable in many hosted
> domain models= .

At the last XMPP Summit a few months ago, we learned that DNS SRV<= br>records are unavailable in whole countries (e.g., Japan). That doesn'tmean we should define a replacement for DNS over HTTP. :)

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






<= /blockquote>
--1458549034-2056792573-1339630300=:21499-- From ve7jtb@ve7jtb.com Wed Jun 13 17:14: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 1CF6811E80E2 for ; Wed, 13 Jun 2012 17:14:57 -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 vbPbnSsQHO8S for ; Wed, 13 Jun 2012 17:14:56 -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 F162911E80C2 for ; Wed, 13 Jun 2012 17:14:55 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so801323wgb.13 for ; Wed, 13 Jun 2012 17:14:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=7Hmb8PvvQaBC6K3z38UFfWeirYx6MEVP/TQXXAZYRFI=; b=cGudI8x8I5NBXbS0RtprWjjQZfHxWWp2lJgkyMW2TXD1c65F5gxtt4xH7lEStVUkom aQQ0T8oYm1nJnAmxxhPhCLcqRrRhIG03/+Ltn9zSWeM3FbmlzL1HPnpVhbuXxgxJaQkI LVQYXItqmK+qYS3BkaxsOd9xSUpEsiiUp/67ASJxRVcC8sMb+8nU0LSKJo72WuFcnWi4 V3r/t7OFU8up35P3g0DN/2CuMCrQrJsH3jECFiioC4pmFYnniZdY+r1e/6QDBqIVk2q5 hUwMe2I3PzzskinQjRpSZZVPJJaROdegUTbZ1EC9eghuX/6S4Dj5gSC+PyiNtKIVD8YN Hieg== Received: by 10.180.24.193 with SMTP id w1mr41713355wif.5.1339632894778; Wed, 13 Jun 2012 17:14:54 -0700 (PDT) Received: from [10.143.196.33] ([109.144.251.60]) by mx.google.com with ESMTPS id eb8sm15215392wib.11.2012.06.13.17.14.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jun 2012 17:14:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_5005A17E-3DDC-4C43-98F2-A76597A1811A" From: John Bradley In-Reply-To: <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Thu, 14 Jun 2012 01:14:48 +0100 Message-Id: <3A4C798C-D5E2-4D2C-9E1E-A7D40FB73431@ve7jtb.com> References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnYK4RS5oIC1tjBtFIym8iqhQUs8m6PSw887GOEf0FBuuaHC3zh+C6aD92sXFCqje0wYG8I Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 00:14:57 -0000 --Apple-Mail=_5005A17E-3DDC-4C43-98F2-A76597A1811A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 It is probably worth remembering that WF is about discovering services = for users. hostmeta is about discovering services for domains. One question is if Bob@foo.com and Jane@foo.com can have diffrent OAuth = Authorization servers for there Imap and SMTP services. If not then hostmeta and not WF would be the more appropriate way to = find the OAuth Authorization service required to get a access grant. For Connect we are also pondering the problem of users with hosted = domains that don't have a web server running on the host for the primary = domain, or at-least not one that is likely to provide a WF service. There is not a perfect answer to that question at the moment. John B. On 2012-06-14, at 12:31 AM, William Mills wrote: > In my use case it's a service/server. >=20 > Not a terribly happy answer to say "DNS SRV records won't work for = you, and there is no other solution.". By the same token I could ask = "Why do we need Webfinger and host meta at all if we have DNS SRV = records?". >=20 > If XMPP uses SRV records for discovery, that's fine. IMAP and = outbound SMTP services both lack a defined discovery method other than = the ubiquitous "service documentation". Is there a compelling reason to = pick DNS over WF for this? =46rom the app developer point of view I = don't want to have N ways to discover M services. >=20 > -bill >=20 >=20 > From: Peter Saint-Andre > To: William Mills =20 > Cc: Paul E. Jones ; 'Cyrus Daboo' = ; "apps-discuss@ietf.org" =20 > Sent: Wednesday, June 13, 2012 3:57 PM > Subject: Re: [apps-discuss] Aggregated service discovery >=20 > On 6/13/12 4:54 PM, William Mills wrote: > > As I said, I'm interested specifically in IMAP, SMTP and OAuth = endpoints.=20 >=20 > What exactly is an "endpoint"? A client? An account? A server? >=20 > > As a data point, DNS SRV records are not controllable in many hosted > > domain models. >=20 > At the last XMPP Summit a few months ago, we learned that DNS SRV > records are unavailable in whole countries (e.g., Japan). That doesn't > mean we should define a replacement for DNS over HTTP. :) >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_5005A17E-3DDC-4C43-98F2-A76597A1811A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 It is = probably worth remembering that WF is about discovering services for = users.
hostmeta is about discovering services for = domains.

One question is if Bob@foo.com and Jane@foo.com can have diffrent OAuth = Authorization servers for there Imap and SMTP = services.

If not then hostmeta and not WF would = be the more appropriate way to find the OAuth Authorization service = required to get a access grant.

For Connect we = are also pondering the problem of users with hosted domains that don't = have a web server running on the host for the primary domain, or = at-least not one that is likely to provide a WF = service.

There is not a perfect answer to that = question at the moment.

John = B.
On 2012-06-14, at 12:31 AM, William Mills = wrote:

In my use case it's a = service/server.

Not a = terribly happy answer to say "DNS SRV records won't work for you, and = there is no other solution.".  By the same token I could ask "Why = do we need Webfinger and host meta at all if we have DNS SRV = records?".

If XMPP = uses SRV records for discovery, that's fine.  IMAP and outbound = SMTP services both lack a defined discovery method other than the = ubiquitous "service documentation".  Is there a compelling reason = to pick DNS over WF for this?  =46rom the app developer point of = view I don't want to have N ways to discover M = services.

-bill


=
=
From: = Peter Saint-Andre <stpeter@stpeter.im>
= To: William Mills = <wmills@yahoo-inc.com> =
Cc: Paul E. Jones = <paulej@packetizer.com>; = 'Cyrus Daboo' <cyrus@daboo.name>; "apps-discuss@ietf.org" <apps-discuss@ietf.org>
= Sent: Wednesday, June 13, 2012 3:57 PM
Subject: Re: [apps-discuss] Aggregated service = discovery

On 6/13/12 4:54 PM, William Mills wrote:
> As I said, I'm = interested specifically in IMAP, SMTP and OAuth endpoints.

What = exactly is an "endpoint"? A client? An account? A server?

> As = a data point, DNS SRV records are not controllable in many = hosted
> domain models.

At the last XMPP Summit a few = months ago, we learned that DNS SRV
records are unavailable in whole = countries (e.g., Japan). That doesn't
mean we should define a = replacement for DNS over HTTP. :)

Peter

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






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

= --Apple-Mail=_5005A17E-3DDC-4C43-98F2-A76597A1811A-- From wmills@yahoo-inc.com Wed Jun 13 18:51: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 1EBBA21F843A for ; Wed, 13 Jun 2012 18:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[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 n95mHidlMzLU for ; Wed, 13 Jun 2012 18:51:35 -0700 (PDT) Received: from nm18.bullet.mail.bf1.yahoo.com (nm18.bullet.mail.bf1.yahoo.com [98.139.212.177]) by ietfa.amsl.com (Postfix) with SMTP id A7E8411E80EB for ; Wed, 13 Jun 2012 18:51:34 -0700 (PDT) Received: from [98.139.214.32] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jun 2012 01:51:33 -0000 Received: from [98.139.212.199] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jun 2012 01:51:33 -0000 Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 14 Jun 2012 01:51:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 673863.15957.bm@omp1008.mail.bf1.yahoo.com Received: (qmail 59860 invoked by uid 60001); 14 Jun 2012 01:51:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339638692; bh=asSt0hvEZY/CuyTolGPR88ODB9Hq2J9O2HriGNqu4EA=; 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=OA/HSeiz1VniMJIQfOfZuzmDWHfFkJPFGRDwTDMXtYTNbBQJtvHTal9NPVh4ScWaooQCjxA5FaXue1X20cRDBEyfnz5t7uAEcWY7bbVzNR/tiM6VkhISE2k3yorfqIz/nzHL8Nm9HNzEWDTXXZnNceIFnTR10egaTt2AjKU94qY= 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=lrW7yA/pXw2JrKrfEQoI/L7SnHmY9EOimVibkiFP2rnMeky5dDERluHSOIJMxAEteKM1zoishED9oAP0kVzNY/fTtZJz632fBxtPLq32jialquP0V46bXt7za2Rhj+4x7d+Bl6RwaAU3TOjrQ+kMeUBuXybeFJSzg4vYwAeWdm0=; X-YMail-OSG: tfq9VBwVM1mvnStBSD2euK8QPsl07EYt5.tEmaqwwPwZfA. wh.44HgcOB7mFXMX30PtU86MKgGFEF8NQ7HC9xjzWrBnrJMRoqcTf9WBRkeh WpuUzOgJMBZrR1seO3mTTcpg3OkT77ljnEz4GzqNzaDWpyijiy7_NA3Wl4cf VWsvhqK9l1GfRUQS3Em0n0JfzaosfH6gAaIhI5ccaItDLjAjr_roSFJi_D74 Xqk.5HE5heTVxkTAmf2DGMKtMPHa0wBzdw9tUcZFVAB7iZur6ysPUIoq_lTK ptepGBaQr0wvQ2CqFx3pSMPDJQKNGC8e3rTJMCvzWBe7uhpSxbIkfCD8Fupu _VD_ysJ7mwJwJXi8ApuJHBkSCLibzEiXUS.Omdj46FU3n3eUQYETOF1xXN32 rxqzlsVNAzfP6Jo8FoJjbHOaM3PK2yTfcIhJvj1aTONf8PsTezhsHwcxEqM3 6oAacZD0B_3qFL7D0FyglBg-- Received: from [99.31.212.42] by web31816.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 18:51:32 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <3A4C798C-D5E2-4D2C-9E1E-A7D40FB73431@ve7jtb.com> Message-ID: <1339638692.53675.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 18:51:32 -0700 (PDT) From: William Mills To: John Bradley In-Reply-To: <3A4C798C-D5E2-4D2C-9E1E-A7D40FB73431@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-427776571-1339638692=:53675" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery 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: Thu, 14 Jun 2012 01:51:36 -0000 ---1238014912-427776571-1339638692=:53675 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable An important distinction.=0A=0AIn the end though the same question applies.= =0A=0A=0A=0A=0A>________________________________=0A> From: John Bradley =0A>To: William Mills =0A>Cc: Peter = Saint-Andre ; "apps-discuss@ietf.org" =0A>Sent: Wednesday, June 13, 2012 5:14 PM=0A>Subject: Re: [apps-dis= cuss] Aggregated service discovery=0A> =0A>=0A>It is probably worth remembe= ring that WF is about discovering services for users.=0A>hostmeta is about = discovering services for domains.=0A>=0A>=0A>One question is if Bob@foo.com= and Jane@foo.com can have diffrent OAuth Authorization servers for there I= map and SMTP services.=0A>=0A>=0A>If not then hostmeta and not WF would be = the more appropriate way to find the OAuth Authorization service required t= o get a access grant.=0A>=0A>=0A>For Connect we are also pondering the prob= lem of users with hosted domains that don't have a web server running on th= e host for the primary domain, or at-least not one that is likely to provid= e a WF service.=0A>=0A>=0A>There is not a perfect answer to that question a= t the moment.=0A>=0A>=0A>John B.=0A>On 2012-06-14, at 12:31 AM, William Mil= ls wrote:=0A>=0A>In my use case it's a service/server.=0A>>=0A>>=0A>>Not a = terribly happy answer to say "DNS SRV records won't work for you, and there= is no other solution.".=A0 By the same token I could ask "Why do we need W= ebfinger and host meta at all if we have DNS SRV records?".=0A>>=0A>>=0A>>I= f XMPP uses SRV records for discovery, that's fine.=A0 IMAP and outbound SM= TP services both lack a defined discovery method other than the ubiquitous = "service documentation".=A0 Is there a compelling reason to pick DNS over W= F for this?=A0 From the app developer point of view I don't want to have N = ways to discover M services.=0A>>=0A>>=0A>>-bill=0A>>=0A>>=0A>>=0A>>=0A>>= =0A>>=0A>>>________________________________=0A>>> From: Peter Saint-Andre <= stpeter@stpeter.im>=0A>>>To: William Mills =0A>>>Cc:= Paul E. Jones ; 'Cyrus Daboo' ; "= apps-discuss@ietf.org" =0A>>>Sent: Wednesday, June = 13, 2012 3:57 PM=0A>>>Subject: Re: [apps-discuss] Aggregated service discov= ery=0A>>> =0A>>>On 6/13/12 4:54 PM, William Mills wrote:=0A>>>> As I said, = I'm interested specifically in IMAP, SMTP and OAuth endpoints. =0A>>>=0A>>>= What exactly is an "endpoint"? A client? An account? A server?=0A>>>=0A>>>>= As a data point, DNS SRV records are not controllable in many hosted=0A>>>= > domain models.=0A>>>=0A>>>At the last XMPP Summit a few months ago, we le= arned that DNS SRV=0A>>>records are unavailable in whole countries (e.g., J= apan). That doesn't=0A>>>mean we should define a replacement for DNS over H= TTP. :)=0A>>>=0A>>>Peter=0A>>>=0A>>>-- =0A>>>Peter Saint-Andre=0A>>>https:/= /stpeter.im/=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>_____________________= __________________________=0A>>apps-discuss mailing list=0A>>apps-discuss@i= etf.org=0A>>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>>=0A>=0A>= =0A> ---1238014912-427776571-1339638692=:53675 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
An important distinction.

In the end though the same question applies.

<= blockquote style=3D"border-left: 2px solid rgb(16, 16, 255); margin-left: 5= px; margin-top: 5px; padding-left: 5px;">
= From: John Bradley <ve7jtb@= ve7jtb.com>
To: Wil= liam Mills <wmills@yahoo-inc.com>
Cc: Peter Saint-Andre <stpeter@stpeter.im>; "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Sent: Wednesday, June 13, 2012 5:14 PM Subject: Re: [apps-disc= uss] Aggregated service discovery

=0A
It is probably worth remembering that WF is about discoveri= ng services for users.
hostmeta is about discovering services for domai= ns.

One question is if Bob@f= oo.com and Jane@foo.com can have diffrent= OAuth Authorization servers for there Imap and SMTP services.
If not then hostmeta and not WF would be the more appropriate = way to find the OAuth Authorization service required to get a access grant.=

For Connect we are also pondering the problem of = users with hosted domains that don't have a web server running on the host = for the primary domain, or at-least not one that is likely to provide a WF = service.

There is not a perfect answer to that question at the moment.

John B.
On 2012-06-14, at 12:31 AM, William Mills wrote:

In my use case it's = a service/server.

Not a = terribly happy answer to say "DNS SRV records won't work for you, and there= is no other solution.".  By the same token I could ask "Why do we nee= d Webfinger and host meta at all if we have DNS SRV records?".
=

If XMPP uses SRV records for discove= ry, that's fine.  IMAP and outbound SMTP services both lack a defined = discovery method other than the ubiquitous "service documentation".  I= s there a compelling reason to pick DNS over WF for this?  From the app developer point of view I don't want to have N ways to discover M=0A s= ervices.

-bill


From: Peter Saint-Andre <stpeter@stpeter.im>
To: William Mills <wmills@yahoo-inc.com>
Cc: Paul E. Jones <paulej@packetizer.com<= /a>>; 'Cyrus Daboo' <cyrus@daboo.name= >; "apps-discuss@ietf.org<= /a>" <apps-discuss@ietf.org>
Sent: Wednesday,= June=0A 13, 2012 3:57 PM
Subject:= Re: [apps-discuss] Aggregated service discovery
=0AOn 6/13/12 4:54 PM, William Mills wrote:
> As I said, I'm = interested specifically in IMAP, SMTP and OAuth endpoints.

What exa= ctly is an "endpoint"? A client? An account? A server?

> As a dat= a point, DNS SRV records are not controllable in many hosted
> domain= models.

At the last XMPP Summit a few months ago, we learned that D= NS SRV
records are unavailable in whole countries (e.g., Japan). That do= esn't
mean we should define a replacement for DNS over HTTP. :)

P= eter

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




=

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



---1238014912-427776571-1339638692=:53675-- From yoshiro.yoneya@jprs.co.jp Thu Jun 14 01:27: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 4169721F8599; Thu, 14 Jun 2012 01:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eDhXYfch16i; Thu, 14 Jun 2012 01:27:25 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8404621F85A3; Thu, 14 Jun 2012 01:27:24 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q5E8RJP8003383; Thu, 14 Jun 2012 17:27:21 +0900 X-AuditID: ac120820-b7f406d0000013f6-b3-4fd9a0679e8d Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 67.76.05110.760A9DF4; Thu, 14 Jun 2012 17:27:19 +0900 (JST) Date: Thu, 14 Jun 2012 17:27:16 +0900 From: Yoshiro YONEYA To: apps-discuss@ietf.org, draft-ietf-v6ops-ra-guard-implementation.all@tools.ietf.org Message-Id: <20120614172716.f5ce6631.yoshiro.yoneya@jprs.co.jp> X-Mailer: Sylpheed 3.1.4 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsWyRoiFTzd9wU1/gy/z+SxWv1zBZvG5fSWj xYw/E5ktuto2sziweCxZ8pPJ4+/9d6weXy5/ZgtgjuKySUnNySxLLdK3S+DK2P50OkvBEY6K 2Y9bWRsY37F1MXJySAiYSBzdN58FwhaTuHBvPVCci0NI4DijxK1NM8ASLAKqEifvtILZbAIG Er+W/WYCsUUEIiRe/b3JCGIzCwhKNL1/BVYjLOAm8fjQPFYQm1fAXuL6umfMEAssJJ6ePwHU ywEUF5T4u0MYolVL4uGvWywQtrzE9rdzmCcw8s5CqJqFpGoWkqoFjMyrGGXy09J0i1PzUopz 0w0M9Uoq8/WyCoqK9ZJB9CZGcNhxKOxgnHHK4BCjAAejEg+v7Lkb/kKsiWXFlbmHGCU5mJRE ebvn3vQX4kvKT6nMSCzOiC8qzUktPsQowcGsJMJrPB8ox5uSWFmVWpQPk5LmYFES5z1+doef kEB6YklqdmpqQWoRTFaGg0NJgjcXpFGwKDU9tSItM6cEIc3EwQkynAdoeArY8OKCxNzizHSI /ClGSSlx3laQhABIIqM0D673FaM40AvCvEkgWR5gCoHregU0kAlooObZGyADSxIRUlINjHGP XQVPS4tPCfm75/HunAzfEBnL75IHTh+/kahp62l9ZGWJZ20v+4/Gv0LvdSxvKXMJtC5SnXbn /odnheJJh7QrBQIfZf1fZdFU5W15me2m/wY11/2lv98s+Hn43M+jVfVlj1sqf/wxYfo2v/Kw Fl+J6rQ5jqaRrKuYGPw67kxeaV7Oc57hjBJLcUaioRZzUXEiAMZy+rXeAgAA Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-v6ops-ra-guard-implementation-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: Thu, 14 Jun 2012 08:27:26 -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-ra-guard-implementation-04 Title: Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) Reviewer: Yoshiro Yoneya Review Date: 2012-06-14 IETF Last Call Date: 2012-05-29 IESG Telechat Date: unknown Summary: This draft is ready for publication as a BCP RFC. Major Issues: none Minor Issues: none Nits: - Section 2.2 [Page 6] "A layer-2 device could, however, at least detect that that an ICMPv6 message (or some type) is being sent," -> "A layer-2 device could, however, at least detect that an ICMPv6 message (or some type) is being sent" Regards, -- Yoshiro YONEYA From eran@hueniverse.com Wed Jun 13 09:03: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 02F3D21F8589; Wed, 13 Jun 2012 09:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v6XFVNmB+Um; Wed, 13 Jun 2012 09:03:46 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7B82C21F8582; Wed, 13 Jun 2012 09:03:46 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id Ms3l1j0060Dcg9U01s3lyn; Wed, 13 Jun 2012 09:03:45 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Wed, 13 Jun 2012 09:03:45 -0700 From: Eran Hammer To: William Mills , O Auth WG , "Apps Discuss" Thread-Topic: [OAUTH-WG] OAuth discovery registration. Thread-Index: AQHNSXkSEZ9PqH6dREydEyx3GFnsppb4aOvA Date: Wed, 13 Jun 2012 16:03:45 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201070221@P3PWEX2MB008.ex2.secureserver.net> References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> In-Reply-To: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.163.44.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 14 Jun 2012 08:07:20 -0700 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:03:47 -0000 These are straight link relation registrations, not LRDD (which has no regi= stration process). It is helpful to put these registrations in context and = use LRDD/host-meta as an example of their use, but the actual registration = request is simply for a link relation and nothing else. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of William Mills > Sent: Wednesday, June 13, 2012 8:28 AM > To: O Auth WG; Apps Discuss > Subject: [OAUTH-WG] OAuth discovery registration. >=20 >=20 >=20 > 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.=A0 It's too late in the process to get this int= o the core > OAuth 2 spec, and it doesn't really fit in the WebFinger. Submission info > provided below. >=20 > -bill >=20 > ---------------------------------------------------- >=20 > A new version of I-D, draft-wmills-oauth-lrdd-00.txt has been successfull= y > submitted by William Mills and posted to the IETF repository. >=20 > Filename:=A0=A0=A0 draft-wmills-oauth-lrdd > Revision:=A0=A0=A0 00 > Title:=A0=A0=A0 =A0=A0=A0 LRDD Registry for OAuth 2 > Creation date:=A0=A0=A0 2012-06-13 > WG ID:=A0=A0=A0 =A0=A0=A0 Individual Submission > Number of pages: 10 > URL:=A0 =A0 =A0 =A0 =A0 =A0=A0http://www.ietf.org/internet-drafts/draft-w= mills-oauth-lrdd- > 00.txt > Status:=A0 =A0 =A0 =A0 =A0=A0http://datatracker.ietf.org/doc/draft-wmills= -oauth-lrdd > Htmlized:=A0 =A0 =A0 =A0=A0http://tools.ietf.org/html/submission.filename= =A0}}-00 >=20 >=20 > Abstract: > =A0 Defines link type registrations for the OAuth 2 authentication > =A0 framework. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Jun 13 11:35: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 E7ACC11E809B; Wed, 13 Jun 2012 11:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqwzrJNrqM6w; Wed, 13 Jun 2012 11:35:01 -0700 (PDT) Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id C7ADA11E8088; Wed, 13 Jun 2012 11:35:00 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id Mub01j0080EuLVk01ub0Jp; Wed, 13 Jun 2012 11:35:00 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Wed, 13 Jun 2012 11:35:00 -0700 From: Eran Hammer To: William Mills , Goix Laurent Walter , Peter Saint-Andre Thread-Topic: [OAUTH-WG] R: [apps-discuss] OAuth discovery registration. Thread-Index: AQHNSYPh5+Oe6W1CcUOmcxnfpZl4X5b5BJMA//+OYyA= Date: Wed, 13 Jun 2012 18:34:59 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2010707E7@P3PWEX2MB008.ex2.secureserver.net> References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FD8B646.3080509@stpeter.im> <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> In-Reply-To: <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.163.44.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 14 Jun 2012 08:07:32 -0700 Cc: O Auth WG , Apps Discuss Subject: Re: [apps-discuss] [OAUTH-WG] R: 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 18:35:02 -0000 The registration is a simple process. You write a draft and get the designa= ted expert to review. They can decide to wait until the document is publish= ed/approved or if they think it is likely to be approved, get the registrat= ion request published earlier. They can also reject it with a reason. I would encourage you to contact the link registry list and ask for feedbac= k before making the official request which you can do once the draft is sta= ble. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of William Mills > Sent: Wednesday, June 13, 2012 11:20 AM > To: Goix Laurent Walter; Peter Saint-Andre > Cc: O Auth WG; Apps Discuss > Subject: Re: [OAUTH-WG] R: [apps-discuss] OAuth discovery registration. >=20 > On the informational status, that seemed right, but I honestly don't know > what the correct choice is here.=A0=A0 The actual registration happens vi= a e-mail I > believe, not via this document. >=20 > Thanks for the feedback! >=20 > -bill >=20 >=20 >=20 > ----- Original Message ----- > > From: Goix Laurent Walter > > To: Peter Saint-Andre ; William Mills > > > > Cc: O Auth WG ; Apps Discuss > > Sent: Wednesday, June 13, 2012 9:44 AM > > Subject: R: [apps-discuss] [OAUTH-WG] OAuth discovery registration. > > > >T hank 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 "oauth2-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 updated. > > > > Also, an example and/or use case section could be beneficial, e.g. to > > describe 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.=A0 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 > >> =A0 =A0 This document defines the LRDD [RFC5988] link type registratio= ns > >> for > >> =A0 =A0 the OAuth [I-D.ietf-oauth-v2] authentication framework.=A0 The= se > >> link > >> =A0 =A0 types are used during the endpoint discovery process using Web > >> Host > >> =A0 =A0 Metadata [I-D.hammer-hostmeta] and Webfinger > >> =A0 =A0 [I-D.jones-appsawg-webfinger] by clients needing to discover t= he > >> =A0 =A0 authentication endpoints for a service or site.=A0 It addition= ally > >> =A0 =A0 defines link type registrations for OAuth 1.0a [RFC5849]. > >> > >> NEW > >> =A0 =A0 This document defines the Link-based Resource Descriptor > >> =A0 =A0 Documents (LRDD) [RFC6415] link type registrations for the > >> =A0 =A0 OAuth [I-D.ietf-oauth-v2] authorization framework.=A0 These li= nk > >> =A0 =A0 types are used during the endpoint discovery process using Web > >> =A0 =A0 Host Metadata [RFC6415] and Webfinger > >> =A0 =A0 [I-D.jones-appsawg-webfinger] by clients needing to discover t= he > >> =A0 =A0 authorization, token, and access token endpoints for an OAuth2 > >> =A0 =A0 service or site.=A0 It additionally defines link type registra= tions > >> for OAuth > >> =A0 =A0 1.0a [RFC5849] request initiation endpoints, authorization > >> endpoints, > >> =A0 =A0 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 persone indicate. La diffusione, copia o qualsiasi altra azione > > derivante dalla conoscenza di queste informazioni sono rigorosamente > > vietate. Qualora abbiate ricevuto questo documento per errore siete > > cortesemente pregati di darne immediata comunicazione al mittente e di > > provvedere alla sua distruzione, Grazie. > > > > This e-mail and any attachments is confidential and may contain > > privileged information intended for the addressee(s) only. > > Dissemination, copying, printing or use by anybody else is > > unauthorised. If you are not the intended recipient, please delete > > this message and any attachments and advise the sender by return e-mail= , > Thanks. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Jun 13 11:47: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 0766C11E80B2; Wed, 13 Jun 2012 11:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JfZ2158QWAH; Wed, 13 Jun 2012 11:47:04 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6796911E80B4; Wed, 13 Jun 2012 11:47:04 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id Mun41j0010CJzpC01un4go; Wed, 13 Jun 2012 11:47:04 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Wed, 13 Jun 2012 11:47:03 -0700 From: Eran Hammer To: William Mills , O Auth WG , "Apps Discuss" Thread-Topic: [OAUTH-WG] OAuth discovery registration. Thread-Index: AQHNSXkSEZ9PqH6dREydEyx3GFnsppb4aOvAgAChGoD//4zaMA== Date: Wed, 13 Jun 2012 18:47:02 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201070937@P3PWEX2MB008.ex2.secureserver.net> References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201070221@P3PWEX2MB008.ex2.secureserver.net> <1339612745.81200.YahooMailNeo@web31808.mail.mud.yahoo.com> In-Reply-To: <1339612745.81200.YahooMailNeo@web31808.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.163.44.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 14 Jun 2012 08:07:42 -0700 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 18:47:05 -0000 Probably, unless you focus the document on using these with host-meta. Also= , LRDD is itself just a link relation type so using that instead of host-me= ta is probably more confusing than helpful. I would just register the link = relations to be used with future OAuth discovery via links and give host-me= ta as one example, and maybe Link headers in a 401 response as another exam= ple. EH > -----Original Message----- > From: William Mills [mailto:wmills@yahoo-inc.com] > Sent: Wednesday, June 13, 2012 11:39 AM > To: Eran Hammer; O Auth WG; Apps Discuss > Subject: Re: [OAUTH-WG] OAuth discovery registration. >=20 > Worthwhile to change the document title? >=20 > Examples are easy, can do. >=20 >=20 >=20 > ----- Original Message ----- > > From: Eran Hammer > > To: William Mills ; O Auth WG ; > > Apps Discuss > > Cc: > > Sent: Wednesday, June 13, 2012 9:03 AM > > Subject: RE: [OAUTH-WG] OAuth discovery registration. > > > >T hese are straight link relation registrations, not LRDD (which has no > >registration process). It is helpful to put these registrations in > >context and use LRDD/host-meta as an example of their use, but the > >actual registration request is simply for a link relation and nothing e= lse. > > > > EH > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of William Mills > >> Sent: Wednesday, June 13, 2012 8:28 AM > >> To: O Auth WG; Apps Discuss > >> Subject: [OAUTH-WG] OAuth discovery registration. > >> > >> > >> > >> 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.=A0 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. > >> > >> -bill > >> > >> ---------------------------------------------------- > >> > >> A new version of I-D, draft-wmills-oauth-lrdd-00.txt has been > >> successfully submitted by William Mills and posted to the IETF reposi= tory. > >> > >> Filename:=A0=A0=A0 draft-wmills-oauth-lrdd > >> Revision:=A0=A0=A0 00 > >> Title:=A0=A0=A0 =A0=A0=A0 LRDD Registry for OAuth 2 Creation date: > >> 2012-06-13 WG ID:=A0=A0=A0 =A0=A0=A0 Individual Submission Number of= pages: 10 > >> URL: > > =A0=A0http://www.ietf.org/internet-drafts/draft-wmills-oauth-lrdd- > >> 00.txt > >> Status: > >> http://datatracker.ietf.org/doc/draft-wmills-oauth-lrdd > >> Htmlized:=A0 =A0 =A0 =A0=A0http://tools.ietf.org/html/submission.file= name > >> }}-00 > >> > >> > >> Abstract: > >> =A0 Defines link type registrations for the OAuth 2 authentication > >> =A0 framework. > >> > >> > >> > >> > >> The IETF Secretariat > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > From eve@xmlgrrl.com Wed Jun 13 11:39: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 815C621F8522; Wed, 13 Jun 2012 11:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUm8D3MafEwM; Wed, 13 Jun 2012 11:39:10 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 95C9121F8510; Wed, 13 Jun 2012 11:39:10 -0700 (PDT) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q5DId09c011345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Jun 2012 11:39:01 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Eve Maler In-Reply-To: <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 11:38:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FD8B646.3080509@stpeter.im> <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Thu, 14 Jun 2012 08:07:53 -0700 Cc: Apps Discuss , O Auth WG 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 18:39:11 -0000 Hi Bill-- In incorporating OAuth into several of the UMA flows, we found = a need for the authorization server to provide OAuth-related metadata = along with UMA-specific metadata. Originally it was strictly XRD- and = hostmeta-based, but now uses a JSON format and is more akin to OpenID = Connect's metadata in style:=20 http://docs.kantarainitiative.org/uma/draft-uma-core.html#am-endpoints Do you feel that this new draft is something that ultimately *should* = replace the OAuth-specific parts of the metadata we've spec'd out for = our use case? Note that we went beyond just the two endpoints, also = covering a feature toggle for "dynamic_client_registration_supported" = and lists of "oauth_token_profiles_supported" and = "oauth_grant_types_supported". The purpose in doing this was to provide = a machine-readable mechanism for aiding OAuth-level interop. Thanks, Eve On 13 Jun 2012, at 11:19 AM, William Mills wrote: > On the informational status, that seemed right, but I honestly don't = know what the correct choice is here. The actual registration happens = via e-mail I believe, not via this document. >=20 > Thanks for the feedback! >=20 > -bill >=20 >=20 >=20 > ----- Original Message ----- >> From: Goix Laurent Walter >> To: Peter Saint-Andre ; William Mills = >> Cc: O Auth WG ; Apps Discuss >> Sent: Wednesday, June 13, 2012 9:44 AM >> Subject: R: [apps-discuss] [OAUTH-WG] OAuth discovery registration. >>=20 >> T hank you William for this initiative. >>=20 >> I had similar concerns than Peter on authn vs authz. >>=20 >> Under section 4.1.1 I would suggest to use "oauth2-authorize" instead=20= >> of "oauth2-authenticator", to be consistent with the=20 >> "oauth2-token" pattern and with the concepts of the oauth2 draft. >>=20 >> The header of the pages still reference sasl/gss-api and would need = to be=20 >> updated. >>=20 >> Also, an example and/or use case section could be beneficial, e.g. to = describe=20 >> its usage in an xrd document. Other use cases may be mentioned as = well probably. >>=20 >> I have also noticed that your draft is mentioned as "informational".=20= >> It is indeed your target or only a typo? >>=20 >> Thanks >> walter >>=20 >>> -----Messaggio originale----- >>> Da: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org]=20 >> 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. >>>=20 >>> On 6/13/12 9:27 AM, William Mills wrote: >>>>=20 >>>> 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=20 >> the >>>> process to get this into the core OAuth 2 spec, and it doesn't=20 >> really >>>> fit in the WebFinger. Submission info provided below. >>>=20 >>> Hi Bill, overall this looks good. A few nits: >>>=20 >>> 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]. >>>=20 >>> 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. >>>=20 >>> In Section 4.1.1, you register an "OAuth 2 Authentication=20 >> 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? >>>=20 >>> Also, is the lack of a link type for OAuth2 access token endpoints = an >>> oversight? It seems so. >>>=20 >>> You have "Reference: [[this document]]" but I think you want: >>>=20 >>> Reference: draft-ietf-oauth-v2 >>>=20 >>> and >>>=20 >>> Reference: RFC 5849 >>>=20 >>> You can remove the reference for draft-hammer-hostmeta (RFC 6415 has >>> what you need). >>>=20 >>> Peter >>>=20 >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle persone=20 >> indicate. La diffusione, copia o qualsiasi altra azione derivante = dalla=20 >> conoscenza di queste informazioni sono rigorosamente vietate. Qualora = abbiate=20 >> ricevuto questo documento per errore siete cortesemente pregati di = darne=20 >> immediata comunicazione al mittente e di provvedere alla sua = distruzione,=20 >> Grazie. >>=20 >> This e-mail and any attachments is confidential and may contain = privileged=20 >> information intended for the addressee(s) only. Dissemination, = copying, printing=20 >> or use by anybody else is unauthorised. If you are not the intended = recipient,=20 >> please delete this message and any attachments and advise the sender = by return=20 >> e-mail, Thanks. >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From Paul_Sangster@symantec.com Wed Jun 13 21:09: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 E238311E80B3; Wed, 13 Jun 2012 21:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ-ofcgXiI6F; Wed, 13 Jun 2012 21:09:01 -0700 (PDT) Received: from tus1smtoutpex02.symantec.com (tus1smtoutpex02.symantec.com [216.10.195.242]) by ietfa.amsl.com (Postfix) with ESMTP id D95D811E8073; Wed, 13 Jun 2012 21:09:00 -0700 (PDT) X-AuditID: d80ac3f2-b7fb36d000006edb-f9-4fd963dbb8a3 Received: from ecl1mtahubpin02.ges.symantec.com (ECL1MTAHUBPIN02.ges.symantec.com [10.48.69.202]) by tus1smtoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 98.82.28379.CD369DF4; Thu, 14 Jun 2012 04:09:00 +0000 (GMT) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Sf1Mh-0002dD-JI; Thu, 14 Jun 2012 04:08:59 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Wed, 13 Jun 2012 21:08:59 -0700 From: Paul Sangster To: Alexey Melnikov , "apps-discuss@ietf.org" , "draft-ietf-nea-pt-tls.all@tools.ietf.org" Date: Wed, 13 Jun 2012 21:11:17 -0700 Thread-Topic: [apps-discuss] APPSDIR review of draft-ietf-nea-pt-tls-04 Thread-Index: Ac1JUdVFSXL4cIl6SCmIW/z3GYOE9QAkS6rw Message-ID: <6E79D623502C70419A9EAB18E4D274252B8B06161A@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <4FCD0614.5050902@isode.com> <4FD86FB2.2050002@isode.com> In-Reply-To: <4FD86FB2.2050002@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsXCZeB6SvdO8k1/g019ohYzVhdZrH65gs1i 7sUJ7BbPNs5ncWDxWLLkJ5PHqWZDjy+XP7MFMEdx2aSk5mSWpRbp2yVwZexdu4ytYLJwxddD 61kbGHfydzFyckgImEicm3WLCcIWk7hwbz1bFyMXh5DAO0aJ/SveMEE4rxklzh7awgzhrGKU WDz7EDtIC5uAgcTOI6fYQRIiArsZJR6c/8gGkmAWUJZ4umkO2FwWAVWJlYfvg8WFBdwkvi/p ZQGxRQTcJW683s8MYRtJvL71D8zmFYiS+LW8GaxXSMBV4sXctWBxTgFNiV1bvoPNYQS69fup NUwQu8Qlbj2ZD/WDgMSSPeeZIWxRiZeP/7FC1ItK3GlfzwhRryOxYPcnqDu1JZYtfA21V1Di 5MwnLBMYxWchGTsLScssJC2zkLQsYGRZxShTUlpsWJxbkl9aUpBaYWCkV1yZmwiMwGS95Pzc TYzAKLzBdfjTDsYbSxUPMQpwMCrx8KoAo1OINbEMqPIQowQHs5II7zMFoBBvSmJlVWpRfnxR aU5q8SFGaQ4WJXHeD7u3+gsJpCeWpGanphakFsFkmTg4pRoYPc+5vN0kvo73V1Bg617vIKN1 rExtXKdks7/o3Q9J2XS2Zs7+fkFx7fWG1XnvZjp/MbgidMsrYd1vGZWtV44a65UvmmJc9+Od ZKbmm1DT16yXHa6lWz2+9jBD4fvR7as+/9nz7NWE1+Kf5jNccFq5fOLj+eVN6hq/uRR+Xw4r vv3+Fav3ykrBr0osxRmJhlrMRcWJANJEHki+AgAA X-Mailman-Approved-At: Thu, 14 Jun 2012 08:08:11 -0700 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: Thu, 14 Jun 2012 04:09:02 -0000 > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Sent: Wednesday, June 13, 2012 3:47 AM > To: apps-discuss@ietf.org; draft-ietf-nea-pt-tls.all@tools.ietf.org > Cc: ietf@ietf.org > Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-nea-pt-tls-04 >=20 > 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/ApplicationsAreaDirectora > te > > ). > > > > 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: >=20 > 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? [PS:] The editors will discuss this more and provide a response. >=20 > 2) In the IANA Considerations: >=20 > 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. >=20 > Whom does the last sentence apply to? This registry? Or the IANA PEN > registry being documented by draft-liang-iana-pen? [PS:] I'm assuming your asking about the text at the bottom of section 6.2.= Registry for PT-TLS Message Types immediately below the table that defines= registry values 0 thru 8 for PEN=3D0. It refers to this specific registry= not the PEN registry. From sm@resistor.net Thu Jun 14 08:18: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 78C8E21F86EA for ; Thu, 14 Jun 2012 08:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 NDhXodEzz7Db for ; Thu, 14 Jun 2012 08:18: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 51CF921F86E8 for ; Thu, 14 Jun 2012 08:18:19 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5EFIE8Q019725 for ; Thu, 14 Jun 2012 08:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339687098; i=@resistor.net; bh=S1Y8wZ5aJHZQv48h2U1HdTw3ANCGzioAPr0FJ+jDO2k=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=tqwlch/M8NN3LaNqzjjusWv1FJIHsZNltNILlbRNGmCYlLPjp7UQAxsuCCB/Zsvw+ VW5G/igAAg50l+vk7Gh+iO5ubmT6L/RXX85FkSWH/LnnAp67Ey87V0aiSXgKaxRv1O 0I7zCOBM/5wXMuJnXkOb8Xaw6WVWuJXLRSnvqos4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1339687098; i=@resistor.net; bh=S1Y8wZ5aJHZQv48h2U1HdTw3ANCGzioAPr0FJ+jDO2k=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=HCJcH2Eg++azIPLk4gMfgs8/iEfOgXHvKIx4fyh1WttytGkoNL+dsWbvZqCpg9AbH I5BWBMXy8OJfP4qHC6bRX+0K6Ika0+2iY5DoWTCE0X+KQaqrGj5XrlnAMdkXNORVQD WuHapxCsV/qtBdbNz2ofZQhM0wmWRGfOOOoKR6cM= Message-Id: <6.2.5.6.2.20120614075629.07eb21f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 14 Jun 2012 08:14:25 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: <4FD75939.6060200@dcrocker.net> References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> <01OGGS87OI0Q000058@mauve.mrochek.com> <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> <4FD75939.6060200@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 14 Jun 2012 15:18:21 -0000 At 07:59 12-06-2012, Dave Crocker wrote: > 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. I read Section 6.2 of -01. Murray mentioned that the choice is between Expert Review and First Come, First Served. The draft already populates the sub-registry with entries to cover various use cases. FCFS would provide an easy registration path without having to argue about the quality of a specification. In Section 6.2: "Use: One of "current" (the state keyword is in current use), "deprecated" (the state keyword is in use but not recommended for new implementations), or "historic" (the state keyword is no longer in substantial current use). The draft does not mention anything about how "deprecated" or "historic" are to be handed. If the WG decides for FCFS, for example, how will the "Use" be handled? As a nit I suggest updating the dates and MTA version numbers in the examples. Regards, -sm From superuser@gmail.com Thu Jun 14 11:00: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 066AA21F86BD for ; Thu, 14 Jun 2012 11:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=0.260, 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 PHVCEcweRgQ5 for ; Thu, 14 Jun 2012 11:00:19 -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 2C89621F86B9 for ; Thu, 14 Jun 2012 11:00:18 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2579975lbb.31 for ; Thu, 14 Jun 2012 11:00: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=0Co7NwqTAjW0ZLDI2CQ+OjxNfuaUySyrIBNvzfJMKTM=; b=No/HUv5dWCH6Hales+BQ3IAI6Yitt4sOLlrQSEn8Ebo/GFCHTr9o66rCaDOMbxtwx5 PKwEXDYA5eCTQKVboEHz7XjO1A+TBQNLpy7jIlElRFBGV5D9gHHX7qO2vOToQR4N5B3V v/lAZROQqyH/WPOe75IMWF0M9eJczzJZ/9hvoIG5btjsoV0NySdMBTg2SBplDv6PvvCW Kb1vIkSrSqSQG9Whr4sTWT5yG1Bhe0b4Nnviz3KRRyTO/ZBkcAdq6HlH0OfE1jQb9bBw vVQyjpISkj6CAmd6u8vpy0qgsQKY3aKctBmaolUtRHxC9zURDUfOVSHyPqa9FTGgM1yK gqhg== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr2829239lab.9.1339696813273; Thu, 14 Jun 2012 11:00:13 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 14 Jun 2012 11:00:13 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120614075629.07eb21f0@resistor.net> References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> <01OGGS87OI0Q000058@mauve.mrochek.com> <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> <4FD75939.6060200@dcrocker.net> <6.2.5.6.2.20120614075629.07eb21f0@resistor.net> Date: Thu, 14 Jun 2012 11:00:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=e89a8f22c411a9709604c272783d 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, 14 Jun 2012 18:00:20 -0000 --e89a8f22c411a9709604c272783d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 14, 2012 at 8:14 AM, SM wrote: > In Section 6.2: > > "Use: One of "current" (the state keyword is in current use), > "deprecated" (the state keyword is in use but not recommended for > new implementations), or "historic" (the state keyword is no > longer in substantial current use). > > The draft does not mention anything about how "deprecated" or "historic" > are to be handed. If the WG decides for FCFS, for example, how will the > "Use" be handled? > > Well now that's an interesting question. Can we say something like "FCFS, except IANA should probably check with ADs when they receive requests for status changes"? Has that been done before? -MSK --e89a8f22c411a9709604c272783d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 14, 2012 at 8:14 AM, SM <sm@resistor.net> wrote:
In Section 6.2:

=A0"Use: =A0One of "current" (the state keyword is in curren= t use),
=A0 =A0 =A0"deprecated" (the state keyword is in use but not rec= ommended for
=A0 =A0 =A0new implementations), or "historic" (the state keywor= d is no
=A0 =A0 =A0longer in substantial current use).

The draft does not mention anything about how "deprecated" or &qu= ot;historic" are to be handed. =A0If the WG decides for FCFS, for exam= ple, how will the "Use" be handled?
=A0

Well now that's an interesting question.= =A0 Can we say something like "FCFS, except IANA should probably check= with ADs when they receive requests for status changes"?=A0 Has that = been done before?

-MSK

--e89a8f22c411a9709604c272783d-- From sm@resistor.net Thu Jun 14 11:29: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 18AF021F86BE for ; Thu, 14 Jun 2012 11:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 e-1Qx+gV0AW2 for ; Thu, 14 Jun 2012 11:29:13 -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 6F61321F8681 for ; Thu, 14 Jun 2012 11:29:13 -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 q5EIT6GA004059 for ; Thu, 14 Jun 2012 11:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339698551; i=@resistor.net; bh=Pg5IxTpiyiWlcb10IwhYbV6oSPVjV5lBWDelptiAPjk=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=YXak4XCQW7/otFBX1z3iEXs1LSLPSR932VHoj47EqnbVX5P4/778BQWnXfA+SaTT7 rleOev8s8+zYvfo+7a6b+oNQAgBkWAOkIih0xRhivNzHZ4rYSI2K/vX38icEppVmQS Gz29tr7aWB1Z0zs9RIeX5sykWynYQ5iXeU1NvGMc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1339698551; i=@resistor.net; bh=Pg5IxTpiyiWlcb10IwhYbV6oSPVjV5lBWDelptiAPjk=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=edpgsZjAb+oyAOHdJZziWkanjYdSxo0UnC/+qZY6gnZTYBf4QbwNONRRvsghmPCe7 qapP04FJZMFHhC3Vs+WJkHk6l2lJ1SDBXqvNgTMq6O/xxOM6mjMHCu4bjKWUJwYK39 VW01qNbsmmXQSAC3gW8pXHtqegpJWu8YX6jBQMMY= Message-Id: <6.2.5.6.2.20120614111103.09b6e3b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 14 Jun 2012 11:29:01 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> <01OGGS87OI0Q000058@mauve.mrochek.com> <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> <4FD75939.6060200@dcrocker.net> <6.2.5.6.2.20120614075629.07eb21f0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 14 Jun 2012 18:29:15 -0000 Hi Murray, At 11:00 14-06-2012, Murray S. Kucherawy wrote: >Well now that's an interesting question. Can we say something like >"FCFS, except IANA should probably check with ADs when they receive >requests for status changes"? Has that been done before? I don't recall seeing that before. There is an IESG override for IANA policies. That could be invoked by the ADs to handle such requests. Instead of looking into how to reclassify, I suggest discussing what is considered as deprecated and what is considered as historic. It can be used to assess whether the cost is worthwhile. Regards, -sm From superuser@gmail.com Thu Jun 14 11:41: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 E628A21F8752 for ; Thu, 14 Jun 2012 11:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.354 X-Spam-Level: X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=0.244, 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 xR75PZ75AejN for ; Thu, 14 Jun 2012 11:41:34 -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 1529721F86E4 for ; Thu, 14 Jun 2012 11:41:33 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2610393lbb.31 for ; Thu, 14 Jun 2012 11:41:33 -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=PwzSO0dIEhMIFtU/MnnkVlLSHaxURq10eApX5EdRBKc=; b=PKIJFPkOhtBlC9VgA1rnooyEbV3GJjzgfCnHjAkS4XXACPliBzILuxxkV5xoVKHiU3 ZZAQal4npXHwpDEa3T/U+e+IUU//Y3EHL1oIQVGn1Yj1QgvpNzhmi9wuAUEHyX58WyQR J2AMop+CvDf8oLrnvOvDnvTijKfpQYUK84imc6I+XEkDwkt+spqEP/5XWp0sIULvgA4W EDq9AG7PCgylWmgzo3v+6x6kA1jMNUQunxwZVsYJj8QhMFVptWi1K1Lx+G/sRvStI49r FbxGTt0kKSmFOM+QV10DL+v0eA15uaa/Sfm5Gow2jikSPqAr3zu629jQnUfbK9Jk3cBr pmYg== MIME-Version: 1.0 Received: by 10.112.49.100 with SMTP id t4mr1454764lbn.10.1339699293101; Thu, 14 Jun 2012 11:41:33 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 14 Jun 2012 11:41:33 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120614111103.09b6e3b8@resistor.net> References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> <01OGGS87OI0Q000058@mauve.mrochek.com> <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> <4FD75939.6060200@dcrocker.net> <6.2.5.6.2.20120614075629.07eb21f0@resistor.net> <6.2.5.6.2.20120614111103.09b6e3b8@resistor.net> Date: Thu, 14 Jun 2012 11:41:33 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: multipart/alternative; boundary=bcaec554d63c789dc304c2730c93 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, 14 Jun 2012 18:41:35 -0000 --bcaec554d63c789dc304c2730c93 Content-Type: text/plain; charset=ISO-8859-1 Hi SM, On Thu, Jun 14, 2012 at 11:29 AM, SM wrote: > > At 11:00 14-06-2012, Murray S. Kucherawy wrote: > >> Well now that's an interesting question. Can we say something like >> "FCFS, except IANA should probably check with ADs when they receive >> requests for status changes"? Has that been done before? >> > > > I don't recall seeing that before. There is an IESG override for IANA > policies. That could be invoked by the ADs to handle such requests. > > Instead of looking into how to reclassify, I suggest discussing what is > considered as deprecated and what is considered as historic. It can be > used to assess whether the cost is worthwhile. > > Even if we got rid of one of the two states, the question about moving from "current" to the remaining one is unresolved. Based on what you said, we could do "FCFS" and just encourage IANA to interact with the IESG if they have any doubts at all about the request. The simplest solution is to remove the "Status" column altogether, but I'd prefer to keep it if we can find a way to work within our own IANA procedures. -MSK --bcaec554d63c789dc304c2730c93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi SM,

On Thu, Jun 14, 2012 at 11:29 AM, SM <sm@resistor.net><= /span> wrote:

At 11:00 14-06-2012, Murray S. Kucherawy wrote:
Well now that's an interesting question. =A0Can we say something like &= quot;FCFS, except IANA should probably check with ADs when they receive req= uests for status changes"? =A0Has that been done before?


I don't recall seeing that before. =A0There is an IESG override for IAN= A policies. =A0That could be invoked by the ADs to handle such requests.
Instead of looking into how to reclassify, I suggest discussing what is con= sidered as deprecated and what is considered as historic. =A0It can be used= to assess whether the cost is worthwhile.


Even if we got rid of one of the two states, the question about moving from= "current" to the remaining one is unresolved.

Based on what you said, we could do "FCFS" and just encourage IANA to= =20 interact with the IESG if they have any doubts at all about the request.
The simplest solution is to remove the "Status" column altoge= ther,=20 but I'd prefer to keep it if we can find a way to work within our own= =20 IANA procedures.

-MSK
--bcaec554d63c789dc304c2730c93-- From sm@resistor.net Thu Jun 14 12:25: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 E1E7821F8795 for ; Thu, 14 Jun 2012 12:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 Fkht+O1XhRI2 for ; Thu, 14 Jun 2012 12:25:21 -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 3743421F8792 for ; Thu, 14 Jun 2012 12:25:21 -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 q5EJPGIA014593 for ; Thu, 14 Jun 2012 12:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339701920; i=@resistor.net; bh=KtEjqk6JuiP1UYKFgZEswXkmJWo/ZyMWluXGMRuSg08=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=iFkAqqqPtNB4GiS5BbtwJ/GmPRfx6uh8s4BQkUWGhCbmpdqPbW4mgWq6ohQQh8EgC zyjB0r/Xbpfx66l0k1yFHyj0Kscq9i4hUG3qsLjWfybC09rwIdBdXV67bD6hzMEOb3 5/IGm1lqlqSHu8al9lCPR0xX5SowATmDnAXZrShs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1339701920; i=@resistor.net; bh=KtEjqk6JuiP1UYKFgZEswXkmJWo/ZyMWluXGMRuSg08=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=SjVy8iaFODVvzlk+H/F4iD40KiUsWHcGME7L/7+fldeIfxQkUGxIPAvXOYCq+irZA sCAkZRXIspVt6KODufQtTPC5uRk+zTFXZMxlfev5ksLkfWWItB9lCl4aZBroWhg0oo JDetY1UdttVeQJcOP5aDaULG7h7Z7hweGheZtpuc= Message-Id: <6.2.5.6.2.20120614120158.07f16808@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 14 Jun 2012 12:24:50 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> <01OGGS87OI0Q000058@mauve.mrochek.com> <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> <4FD75939.6060200@dcrocker.net> <6.2.5.6.2.20120614075629.07eb21f0@resistor.net> <6.2.5.6.2.20120614111103.09b6e3b8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 14 Jun 2012 19:25:22 -0000 Hi Murray, At 11:39 14-06-2012, Murray S. Kucherawy wrote: >Based on what you said, we could do "FCFS" and just encourage IANA >to interact with the IESG if they have any doubts at all about the request. In an ideal world, yes. :-) >The simplest solution is to remove the "Status" column altogether, >but I'd prefer to keep it if we can find a way to work within our >own IANA procedures. Expert Review may be easier then. It can be aligned with the Message Header Fields registry. I'd use deprecated instead of deprecated and historic. The ietf-message-headers mailing list can be reused to process the requests. I don't have a strong preference. Regards, -sm From alexey.melnikov@isode.com Thu Jun 14 13:49: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 C58BE21F84E6 for ; Thu, 14 Jun 2012 13:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erPlBXjZizvi for ; Thu, 14 Jun 2012 13:49:45 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 05C7221F8493 for ; Thu, 14 Jun 2012 13:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1339706983; d=isode.com; s=selector; i=@isode.com; bh=M10SsEYN79QfpU9IR4u9SAXkDJOVN8ELJ4TATGD13NI=; 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=ry0ZEvGFdpmXNADix856FlTm29UIcOI0Wm5Di4mhPBUtTnPYbGZW/Rfmvdu6BkuOtJIFP7 K7cCOANqnWHNIAJunZSA2e1LzA+OoLhiQtU6PXmMw2JP/6Sg8O/+aK5Biu0CQbTE43I8Yo cSrISAZbM6RrryFITEQmGFDbZ7RHavU=; Received: from [188.29.2.53] (188.29.2.53.threembb.co.uk [188.29.2.53]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 14 Jun 2012 21:49:43 +0100 References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> <01OGGS87OI0Q000058@mauve.mrochek.com> <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> <4FD75939.6060200@dcrocker.net> <6.2.5.6.2.20120614075629.07eb21f0@resistor.net> In-Reply-To: Message-Id: <5E3FB609-4FDA-45E1-B91C-86CFFA3F1C06@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Thu, 14 Jun 2012 21:49:35 +0100 To: "Murray S. Kucherawy" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-3D36582D-40FA-4D6E-8AE5-D73BBD674162 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, 14 Jun 2012 20:49:45 -0000 --Apple-Mail-3D36582D-40FA-4D6E-8AE5-D73BBD674162 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 14 Jun 2012, at 19:00, "Murray S. Kucherawy" wrote:= > On Thu, Jun 14, 2012 at 8:14 AM, SM wrote: > In Section 6.2: >=20 > "Use: One of "current" (the state keyword is in current use), > "deprecated" (the state keyword is in use but not recommended for > new implementations), or "historic" (the state keyword is no > longer in substantial current use). >=20 > The draft does not mention anything about how "deprecated" or "historic" a= re to be handed. If the WG decides for FCFS, for example, how will the "Use= " be handled? > =20 >=20 > Well now that's an interesting question. Can we say something like "FCFS,= except IANA should probably check with ADs when they receive requests for s= tatus changes"? Has that been done before? I think ADs would prefer for an Expert to deal with this. Really, they don't= have to be experts in SMTP and they already busy as it is. You can restrict the Expert to only be able to do a very small set of tasks (= or be limited in why he/she can reject a registration)= --Apple-Mail-3D36582D-40FA-4D6E-8AE5-D73BBD674162 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
On 14 Jun 2012, at 19:00, "Murray S. Kucherawy" <superuser@gmail.com> wrote:

On Thu, Jun 14, 2012 at 8:14 AM, SM <sm@resistor.net> wrote:
In Section 6.2:

 "Use:  One of "current" (the state keyword is in current use),
     "deprecated" (the state keyword is in use but not recommended for
     new implementations), or "historic" (the state keyword is no
     longer in substantial current use).

The draft does not mention anything about how "deprecated" or "historic" are to be handed.  If the WG decides for FCFS, for example, how will the "Use" be handled?
 

Well now that's an interesting question.  Can we say something like "FCFS, except IANA should probably check with ADs when they receive requests for status changes"?  Has that been done before?

I think ADs would prefer for an Expert to deal with this. Really, they don't have to be experts in SMTP and they already busy as it is.

You can restrict the Expert to only be able to do a very small set of tasks (or be limited in why he/she can reject a registration)
--Apple-Mail-3D36582D-40FA-4D6E-8AE5-D73BBD674162-- From alexey.melnikov@isode.com Thu Jun 14 14:25:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F52521F84A5; Thu, 14 Jun 2012 14:25:15 -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 35yTTfI-HbCM; Thu, 14 Jun 2012 14:25:14 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 77BFC21F8498; Thu, 14 Jun 2012 14:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1339709113; d=isode.com; s=selector; i=@isode.com; bh=81mR9i2F7RG42oI6bOpLQGMiTVTv8elqSyGxOuZDM+Y=; 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=cMMq/gHwhstEPBOJXtyxyq1jneZmbO6joY/ITXEWx5I6GA73qNHl0qCoUQQGPV+SNKJsCf CYPhwSmmKoUcp8GZQfxojj3SuMTUY8TW+sacyemqe0iLcOnzgGE3gD8TIejaT/pwHsIuaZ JuCrHmjjQw20+dPM+/pr9cTemfGSeMo=; Received: from [172.20.10.2] ((unknown) [212.183.128.139]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 14 Jun 2012 22:25:13 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FDA4CFA.7000507@isode.com> Date: Thu, 14 Jun 2012 21:43:38 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Paul Sangster References: <4FCD0614.5050902@isode.com> <4FD86FB2.2050002@isode.com> <6E79D623502C70419A9EAB18E4D274252B8B06161A@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> In-Reply-To: <6E79D623502C70419A9EAB18E4D274252B8B06161A@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-nea-pt-tls.all@tools.ietf.org" , "ietf@ietf.org" , "apps-discuss@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: Thu, 14 Jun 2012 21:25:15 -0000 Hi Paul, On 14/06/2012 05:11, Paul Sangster wrote: >> -----Original Message----- >> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] >> Sent: Wednesday, June 13, 2012 3:47 AM >> To: apps-discuss@ietf.org; draft-ietf-nea-pt-tls.all@tools.ietf.org >> Cc: ietf@ietf.org >> Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-nea-pt-tls-04 >> >> 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/ApplicationsAreaDirectora >> te >>> ). >>> >>> 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? > [PS:] The editors will discuss this more and provide a response. Thanks. >> 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? > [PS:] I'm assuming your asking about the text at the bottom of section 6.2. Registry for PT-TLS Message Types immediately below the table that defines registry values 0 thru 8 for PEN=0. It refers to this specific registry not the PEN registry. Please make this clear in your document. If you want to reserve the value 2^32-1 in the PEN registry, then you need to make this clear in your document as well. From wmills@yahoo-inc.com Thu Jun 14 14: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 7F2EB11E8096 for ; Thu, 14 Jun 2012 14:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 1KPCXxVPSUoT for ; Thu, 14 Jun 2012 14:38:03 -0700 (PDT) Received: from nm11.bullet.mail.bf1.yahoo.com (nm11.bullet.mail.bf1.yahoo.com [98.139.212.170]) by ietfa.amsl.com (Postfix) with SMTP id 9A0B311E8097 for ; Thu, 14 Jun 2012 14:38:02 -0700 (PDT) Received: from [98.139.212.150] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jun 2012 21:38:02 -0000 Received: from [98.139.212.215] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jun 2012 21:38:01 -0000 Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 14 Jun 2012 21:38:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 977321.25751.bm@omp1024.mail.bf1.yahoo.com Received: (qmail 84580 invoked by uid 60001); 14 Jun 2012 21:38:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339709881; bh=0UlzYA7wa1XulHEApabjovB9XMQQi6VsD2jgjOSYy/I=; 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=qIpCh4Fi1YDl8TevJiNktQ9S6GbN/Y59YG+TkIgTOjmOpE1HGOBUJXGFoquzqN63hi5PNrVJlglKJ/WW4BzLqfjPyvOtKrvyAJ64f0Qd+WjmojGT9W+D9isgV6JR2ZO+FIDzWyjFO9xB65luB7ODxEWNTKG9yhUDPulLm/axwdw= 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=B+y8wAKb+ML0Hz+eWMr9dM8gPWUBIbEa7w8/cvbQ0azB22iTSV21es7CazZMtsacusRLS3PCoJ7Rk4jxWoRppIyXv9tvX5wWma/FzIJt8zmxN9FmKPEXmg97sEzsw9iDhCJ9zmOhtbvCKPsxp432N2FVgbpJ54lw0yWISCqG/j8=; X-YMail-OSG: oSJOlE8VM1nyu1PV_kA1TDcqBxoDnLJ1CvqdudSMsgh0bn5 kw8aKh9AtN.fxaJzzWV8y75.6664f0luelj3boJTEhsDD4c5wZfxWXUYvWBF DCwj2eVspE2gX0_Q_yud5YnQYHakALolc1wjRZladwacgMtH8nTtRY7y7X15 ChdJOfk3aftNMyjcZH02RolRvOFKo2GyuAd8GQS5ePY_bOvhkTfGdotEr8nK RRIaGHTXN3ur6dl96WLoQqISBrQH.LE09V79Vs7ZqydqN.8eD5zhFCed1HL2 JYa5lHUPIG4L0m3CnqX8s34Th5X0wS4SLywSTDk_nPqkz8ofIC_lnPfzG_.m 92kAvHPfCnUgmC6Hmrgwi5hhPRQ9x9kqnw_BvzxSKmMf4LpUQf3af7RRizm6 CUALvhELTyEcxxi9zdEA0RAE_7m2fbDJ0xvXqOjtHBL7k5K6cKTABrcUT.kT WylDXWVeMbNOJHgcl.xyIc_qpuXJYYWkWILJbm3VpPLLTqmSgBBhIB_DWywG OyLKdZCXSbbJ.3uu004s7NbgqjJ7M1Q-- Received: from [209.131.62.115] by web31811.mail.mud.yahoo.com via HTTP; Thu, 14 Jun 2012 14:38:00 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> <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: <1339709880.77463.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Thu, 14 Jun 2012 14:38:00 -0700 (PDT) From: William Mills To: Goix Laurent Walter , Eve Maler , Peter Saint-Andre , Eran Hammer- Lahav 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] OAuth discovery registration... -01 draft posed 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: Thu, 14 Jun 2012 21:38:04 -0000 Updated for examples, the editorial issues like replacing link header for l= rdd where it appears, fixing authenticate->authorize.=0A=0AThanks for the f= eedback so far.=0A=0A-bill=0A=0A=0A=0A=0A------------------=0A=0AA new vers= ion of I-D, draft-wmills-oauth-lrdd-01.txt=0Ahas been successfully submitte= d by William Mills and posted to the=0AIETF repository.=0A=0AFilename:=A0= =A0=A0 draft-wmills-oauth-lrdd=0ARevision:=A0=A0=A0 01=0ATitle:=A0=A0=A0 = =A0=A0=A0 Link Type Registry for OAuth 2=0ACreation date:=A0=A0=A0 2012-06-= 14=0AWG ID:=A0=A0=A0 =A0=A0=A0 Individual Submission=0ANumber of pages: 11= =0AURL:=A0 =A0 =A0 =A0 =A0 =A0=A0http://www.ietf.org/internet-drafts/draft-= wmills-oauth-lrdd-01.txt=0AStatus:=A0 =A0 =A0 =A0 =A0=A0http://datatracker.= ietf.org/doc/draft-wmills-oauth-lrdd=0AHtmlized:=A0 =A0 =A0 =A0=A0http://to= ols.ietf.org/html/draft-wmills-oauth-lrdd-01=0ADiff:=A0 =A0 =A0 =A0 =A0 =A0= =A0http://tools.ietf.org/rfcdiff?url2=3Ddraft-wmills-oauth-lrdd-01=0A=0AAbs= tract:=0A=A0 Defines link type registrations for the OAuth 2 authentication= =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 ned.freed@mrochek.com Thu Jun 14 17:26: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 62F9A11E8072 for ; Thu, 14 Jun 2012 17:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 r97pAXINZdTi for ; Thu, 14 Jun 2012 17:26:17 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E12DB11E8083 for ; Thu, 14 Jun 2012 17:26:14 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGOMMCUGHC0036WB@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 14 Jun 2012 17:20:55 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGNDRI25G00006TF@mauve.mrochek.com>; Thu, 14 Jun 2012 17:20:52 -0700 (PDT) Message-id: <01OGOMMBBA460006TF@mauve.mrochek.com> Date: Thu, 14 Jun 2012 17:00:27 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 14 Jun 2012 11:00:13 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> <01OGGS87OI0Q000058@mauve.mrochek.com> <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> <4FD75939.6060200@dcrocker.net> <6.2.5.6.2.20120614075629.07eb21f0@resistor.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, 15 Jun 2012 00:26:17 -0000 > On Thu, Jun 14, 2012 at 8:14 AM, SM wrote: > > In Section 6.2: > > > > "Use: One of "current" (the state keyword is in current use), > > "deprecated" (the state keyword is in use but not recommended for > > new implementations), or "historic" (the state keyword is no > > longer in substantial current use). > > > > The draft does not mention anything about how "deprecated" or "historic" > > are to be handed. If the WG decides for FCFS, for example, how will the > > "Use" be handled? > > > > > Well now that's an interesting question. Can we say something like "FCFS, > except IANA should probably check with ADs when they receive requests for > status changes"? Has that been done before? AFAIK the answer is no, but OTOH IANA has been asked to implement policies of some complexity up to and including the original media types registration process without involving a Designated Expert. That said, it's been my observation that the more you tell IANA to do, the slower the process becomes, especially when what you're telling them to make some sort of assessment. Additionally, and speaking from experience, ADs are very busy people, so don't expect them to handle such queries in a very timely way. I can't help but think you're stirring up quite a pother in order to avoid having a Designated Expert. Ned From dhc@dcrocker.net Thu Jun 14 18:15: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 8CB9E11E809F for ; Thu, 14 Jun 2012 18:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 BQglrtbxQsrk for ; Thu, 14 Jun 2012 18:15:22 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F131711E809A for ; Thu, 14 Jun 2012 18:15:21 -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 q5F1FJKE029225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Jun 2012 18:15:19 -0700 Message-ID: <4FDA8CA3.3020003@dcrocker.net> Date: Thu, 14 Jun 2012 18:15:15 -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: "Murray S. Kucherawy" References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> <01OGGS87OI0Q000058@mauve.mrochek.com> <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> <4FD75939.6060200@dcrocker.net> <6.2.5.6.2.20120614075629.07eb21f0@resistor.net> <6.2.5.6.2.20120614111103.09b6e3b8@resistor.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, 14 Jun 2012 18:15:20 -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, 15 Jun 2012 01:15:22 -0000 On 6/14/2012 11:41 AM, Murray S. Kucherawy wrote: > Based on what you said, we could do "FCFS" and just encourage IANA to > interact with the IESG if they have any doubts at all about the request. This issue goes beyond this specification. In effect, it is a 'security' issue concerning authorization to make changes to an existing IANA entry. I believe we should not be expected to resolve that issue for this specification. On the other hand, I agree it does need resolving. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From eve@xmlgrrl.com Thu Jun 14 11:16: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 4CB8C21F8637; Thu, 14 Jun 2012 11:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.757 X-Spam-Level: * X-Spam-Status: No, score=1.757 tagged_above=-999 required=5 tests=[AWL=-3.049, BAYES_99=3.5, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkznM1rgCL7U; Thu, 14 Jun 2012 11:16:46 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 27B8221F8628; Thu, 14 Jun 2012 11:16:45 -0700 (PDT) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q5EIGhue002955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Jun 2012 11:16:43 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Eve Maler In-Reply-To: <1339613945.46084.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Thu, 14 Jun 2012 11:16:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <54EEB138-ABDA-429F-9B0E-0F42D66F96A7@xmlgrrl.com> References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FD8B646.3080509@stpeter.im> <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> <1339613945.46084.YahooMailNeo@web31813.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Fri, 15 Jun 2012 08:03:32 -0700 Cc: Apps Discuss , O Auth WG 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: Thu, 14 Jun 2012 18:16:47 -0000 FWIW, the reason we ultimately went with JSON was that it removed = stumbling blocks around implementation and sheer spec volume. When we = used straight XRD, we found that we had to put a full worked example in = an appendix so it didn't impede the flow of the spec, and implementers = reported to us that JSON would have been much preferable for producing = and consuming the config data. When we found the OpenID Connect example, = it was a natural fit and so we copied it. (Not trying to open up past "JRD" discussions, just sharing our = experience... If OAuth ultimately absorbs some XRD-formatted hunk of = machine-discoverable config data, we'll leverage it.) Eve On 13 Jun 2012, at 11:59 AM, William Mills wrote: > We certainly overlap, the thing you have that is not in the link type = registrations is dynamic_client_registration_supported. We should be = consistent in naming, and ideally the OAuth related JSON elements from a = JSON format Webfinger request and your UMA stuff shoudl be identical. = My concern with using a JSON list structure for capability lists is how = it would play in the LINK header itself, that seems a bit hairy to put a = JSON list inside a quoted application data value. >=20 > Do we want something like a "capabilities" list which could include = dynamic_client_registration_supported and perhaps others? >=20 > -bill >=20 >=20 >=20 >=20 > ----- Original Message ----- >> From: Eve Maler >> To: William Mills >> Cc: Goix Laurent Walter ; Peter = Saint-Andre ; O Auth WG ; Apps = Discuss >> Sent: Wednesday, June 13, 2012 11:38 AM >> Subject: Re: [OAUTH-WG] [apps-discuss] OAuth discovery registration. >>=20 >> Hi Bill-- In incorporating OAuth into several of the UMA flows, we = found a need=20 >> for the authorization server to provide OAuth-related metadata along = with=20 >> UMA-specific metadata. Originally it was strictly XRD- and = hostmeta-based, but=20 >> now uses a JSON format and is more akin to OpenID Connect's metadata = in=20 >> style:=20 >>=20 >> = http://docs.kantarainitiative.org/uma/draft-uma-core.html#am-endpoints >>=20 >> Do you feel that this new draft is something that ultimately *should* = replace=20 >> the OAuth-specific parts of the metadata we've spec'd out for our use=20= >> case? Note that we went beyond just the two endpoints, also covering = a feature=20 >> toggle for "dynamic_client_registration_supported" and lists of=20 >> "oauth_token_profiles_supported" and=20 >> "oauth_grant_types_supported". The purpose in doing this was to=20 >> provide a machine-readable mechanism for aiding OAuth-level interop. >>=20 >> Thanks, >>=20 >> Eve >>=20 >> On 13 Jun 2012, at 11:19 AM, William Mills wrote: >>=20 >>> On the informational status, that seemed right, but I honestly don't=20= >> know what the correct choice is here. The actual registration = happens via=20 >> e-mail I believe, not via this document. >>>=20 >>> Thanks for the feedback! >>>=20 >>> -bill >>>=20 >>>=20 >>>=20 >>> ----- Original Message ----- >>>> From: Goix Laurent Walter >>>> To: Peter Saint-Andre ; William Mills=20 >> >>>> Cc: O Auth WG ; Apps Discuss=20 >> >>>> Sent: Wednesday, June 13, 2012 9:44 AM >>>> Subject: R: [apps-discuss] [OAUTH-WG] OAuth discovery registration. >>>>=20 >>>> T hank you William for this initiative. >>>>=20 >>>> I had similar concerns than Peter on authn vs authz. >>>>=20 >>>> Under section 4.1.1 I would suggest to use "oauth2-authorize"=20 >> instead=20 >>>> of "oauth2-authenticator", to be consistent with the=20 >>>> "oauth2-token" pattern and with the concepts of the oauth2=20 >> draft. >>>>=20 >>>> The header of the pages still reference sasl/gss-api and would need = to=20 >> be=20 >>>> updated. >>>>=20 >>>> Also, an example and/or use case section could be beneficial, e.g. = to=20 >> describe=20 >>>> its usage in an xrd document. Other use cases may be mentioned as = well=20 >> probably. >>>>=20 >>>> I have also noticed that your draft is mentioned as=20 >> "informational".=20 >>>> It is indeed your target or only a typo? >>>>=20 >>>> Thanks >>>> walter >>>>=20 >>>>> -----Messaggio originale----- >>>>> Da: apps-discuss-bounces@ietf.org=20 >> [mailto:apps-discuss-bounces@ietf.org]=20 >>>> 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=20 >> registration. >>>>>=20 >>>>> On 6/13/12 9:27 AM, William Mills wrote: >>>>>>=20 >>>>>> Since for the OAUTH SASL mechanism I need discovery for clients=20= >> to >>>>>> work, and I had to rip the in-band discovery out of that=20 >> mechanism, >>>>>> and I need it defined somewhere, I've drafted a small doc=20 >> for the >>>>>> registration of link relation types for OAuth. It's too=20 >> late in=20 >>>> the >>>>>> process to get this into the core OAuth 2 spec, and it=20 >> doesn't=20 >>>> really >>>>>> fit in the WebFinger. Submission info provided below. >>>>>=20 >>>>> Hi Bill, overall this looks good. A few nits: >>>>>=20 >>>>> OLD >>>>> This document defines the LRDD [RFC5988] link type=20 >> registrations for >>>>> the OAuth [I-D.ietf-oauth-v2] authentication framework. = These=20 >> link >>>>> types are used during the endpoint discovery process using = Web=20 >> Host >>>>> Metadata [I-D.hammer-hostmeta] and Webfinger >>>>> [I-D.jones-appsawg-webfinger] by clients needing to discover=20= >> the >>>>> authentication endpoints for a service or site. It=20 >> additionally >>>>> defines link type registrations for OAuth 1.0a [RFC5849]. >>>>>=20 >>>>> 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=20= >> the >>>>> authorization, token, and access token endpoints for an = OAuth2 >>>>> service or site. It additionally defines link type=20 >> registrations for >>>>> OAuth >>>>> 1.0a [RFC5849] request initiation endpoints, authorization=20 >> endpoints, >>>>> and token endpoints. >>>>>=20 >>>>> In Section 4.1.1, you register an "OAuth 2 Authentication=20 >>>> Endpoint", >>>>> however draft-ietf-oauth-v2 defines only an authorization = endpoint,=20 >> a >>>>> token endpoint, and an access token endpoint. Whence this >>>>> "authentication endpoint"? Is it just a typo? >>>>>=20 >>>>> Also, is the lack of a link type for OAuth2 access token endpoints=20= >> an >>>>> oversight? It seems so. >>>>>=20 >>>>> You have "Reference: [[this document]]" but I think you=20 >> want: >>>>>=20 >>>>> Reference: draft-ietf-oauth-v2 >>>>>=20 >>>>> and >>>>>=20 >>>>> Reference: RFC 5849 >>>>>=20 >>>>> You can remove the reference for draft-hammer-hostmeta (RFC 6415=20= >> has >>>>> what you need). >>>>>=20 >>>>> Peter >>>>>=20 >>>>> -- >>>>> Peter Saint-Andre >>>>> https://stpeter.im/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> apps-discuss mailing list >>>>> apps-discuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>=20 >>>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle=20 >> persone=20 >>>> indicate. La diffusione, copia o qualsiasi altra azione derivante = dalla=20 >>=20 >>>> conoscenza di queste informazioni sono rigorosamente vietate. = Qualora=20 >> abbiate=20 >>>> ricevuto questo documento per errore siete cortesemente pregati di=20= >> darne=20 >>>> immediata comunicazione al mittente e di provvedere alla sua=20 >> distruzione,=20 >>>> Grazie. >>>>=20 >>>> This e-mail and any attachments is confidential and may contain=20 >> privileged=20 >>>> information intended for the addressee(s) only. Dissemination, = copying,=20 >> printing=20 >>>> or use by anybody else is unauthorised. If you are not the intended=20= >> recipient,=20 >>>> please delete this message and any attachments and advise the = sender by=20 >> return=20 >>>> e-mail, Thanks. >>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >>=20 >> Eve Maler = http://www.xmlgrrl.com/blog >> +1 425 345 6756 http://www.twitter.com/xmlgrrl >>=20 >=20 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From barryleiba.mailing.lists@gmail.com Fri Jun 15 08:10: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 3605E21F8857 for ; Fri, 15 Jun 2012 08:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.84 X-Spam-Level: X-Spam-Status: No, score=-102.84 tagged_above=-999 required=5 tests=[AWL=0.137, 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 1BEBdHbEXxQ4 for ; Fri, 15 Jun 2012 08:10:52 -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 4FCE921F8867 for ; Fri, 15 Jun 2012 08:10:52 -0700 (PDT) Received: by lagv3 with SMTP id v3so2255021lag.31 for ; Fri, 15 Jun 2012 08:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xl3ofYSRxfCSsz+3jQOrGwrt79MPks02gYTR+wEVsxE=; b=zqyOo1DA+zEBFhZmhnavxpDAub0snbHp+h/CXbraW3wJdkdciD0TgqqK2VW3NtYaE0 fKamsd9kJFTeMmpxpdDn64AyVllmY8LAL+wPcSQfGyyws552elfjVqf1pjQkUxjFwQZw Va8keOMRNaNOspEVnPXqktIVylxF9p3MAYpEmgW04kf6lRHqCzxhrwgiKSytCz8OsDI7 lfGhMpjq7ap6FFv6WmFNOnJdzmpybgiDgA/rBpIpbhBE0kW1IgpwHVuXt8tobI2RTwEt 82Ar4D90/SqfmBYAE/prKI0iBN+cD4TNc9gGNG1aV7IkGTsCFUVmo+jh9jXf4ZYiHVme yEtg== MIME-Version: 1.0 Received: by 10.112.42.164 with SMTP id p4mr2737292lbl.54.1339773051156; Fri, 15 Jun 2012 08:10:51 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Fri, 15 Jun 2012 08:10:51 -0700 (PDT) In-Reply-To: References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> <01OGGS87OI0Q000058@mauve.mrochek.com> <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> <4FD75939.6060200@dcrocker.net> <6.2.5.6.2.20120614075629.07eb21f0@resistor.net> Date: Fri, 15 Jun 2012 11:10:51 -0400 X-Google-Sender-Auth: 395RKfZCfHF-IgEZQvOLfVTtWKc Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 15 Jun 2012 15:10:53 -0000 >> The draft does not mention anything about how "deprecated" or "historic" >> are to be handed. =A0If the WG decides for FCFS, for example, how will t= he >> "Use" be handled? > > Well now that's an interesting question.=A0 Can we say something like "FC= FS, > except IANA should probably check with ADs when they receive requests for > status changes"?=A0 Has that been done before? That, in effect, is "Expert Review, and the current App ADs are the designated experts." So: No, let's not do that. If we're worried about who's allowed to modify existing registrations, you can say that in the registry definition: FCFS for new registrations, and existing registrations can be updated by the original requestor or by IESG Approval. Barry From ted.ietf@gmail.com Fri Jun 15 15:25: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 BB40E11E80CE; Fri, 15 Jun 2012 15:25:34 -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_83=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 ONh-rWT7n7kH; Fri, 15 Jun 2012 15:25:34 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09C9321F8593; Fri, 15 Jun 2012 15:25:33 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2213349vbb.31 for ; Fri, 15 Jun 2012 15:25:33 -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:cc:content-type; bh=dkZc24p0nut3WBHXQlC8pv90+3/BnWUIeJjs62L1XGs=; b=S8z1MkyT923fSUrjMNZo5p5o2a6s/ByYaZk3Ph39gio8P8qAOz7hXcsyTLfugj5RpK 5mTGQIu35ni0x05grq4Hv0iXhHebGsbvGpP8alJX2u6Kpio12btxDAw7iN9qSr8qdnt/ N3BAmvoC6/QYM9XSdDRBbBfVjb6V2fqm4ucd0YWYJ/9KGgPrzdOP13gUTnwyQSZDDcdx wMhFZmO71+GZ1Nkj5OPXQvFa23umCNTWyAO8tAqbhgP+LoT4sdNHI+jmie8uWxqfVCSf UhNsXQt779CdapSdOrPYlR5lmksFzD/gGUFAKjXiV6xwL/J8W6lRWZTqoyF0wy7nBhYj 0JyQ== MIME-Version: 1.0 Received: by 10.221.13.77 with SMTP id pl13mr3778745vcb.49.1339799133288; Fri, 15 Jun 2012 15:25:33 -0700 (PDT) Received: by 10.52.37.51 with HTTP; Fri, 15 Jun 2012 15:25:33 -0700 (PDT) Date: Fri, 15 Jun 2012 15:25:33 -0700 Message-ID: From: Ted Hardie To: draft-ietf-idr-rfc4893bis.all@tools.ietf.org, apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: IESG Subject: [apps-discuss] APPs directorate review of draft-ietf-idr-rfc4893bis-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 22:25:34 -0000 Document: draft-ietf-idr-rfc4893bis-06 Title: BGP Support for Four-octet AS Number Space Reviewer:Ted Hardie Review Date:June 15, 2012 Summary:This document is ready for publication on the Standards Track. Major Issues: None seen Minor Issues: None seen Nits: The appendix describing the current document's changes from RFC 4893 currently says: "This document includes several clarifications and editorial changes, and specifies the error handling for the new attributes." This is not terribly useful; since RFC 4893 is being obsoleted by this document (rather than updated), I would suggest that it be removed. If it is kept, it might useful expanded, but I suspect the effort is not worth it. From barryleiba@gmail.com Fri Jun 15 18:06: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 8E22A11E80CE for ; Fri, 15 Jun 2012 18:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.882 X-Spam-Level: X-Spam-Status: No, score=-102.882 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNXn1leQ5FKx for ; Fri, 15 Jun 2012 18:06:31 -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 7600D11E807F for ; Fri, 15 Jun 2012 18:06:31 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2345389qcs.31 for ; Fri, 15 Jun 2012 18:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=M7DCGYOhAOYHQdCogdUFbG/G4FfRA4yqa0xh0KIZbV0=; b=OxcKqlUegAZtTfcpmtIfb843KTqRWCq6YmO+aNnrnMvLidOv47iBPYFOnpBBmv5gbm l6ACi+vHlvOA63mqJ7oddGb4e4rOcpaG4xLDJYeOWVKryDfHFa+qPtVd98STxl7WRg9c ITTuTQwAiawOPDM+OiShZm3viFWNoKhmUoecdLYwNY22JS/L9p3YJqAZengjoBQo0KBt o9m1C0XKNDVJay5HCX9IFKdCG1EF6mLdm6urH/bUW8tOrwvEtwLYzM5LoLhjEK1ezA7K pG+iYOV+YPCTtmHXZzsNxR1/y20vharDKy+d9c1DfZ2Hw9QXI5PpROGtZCaqI8Al06K1 Wong== MIME-Version: 1.0 Received: by 10.224.200.194 with SMTP id ex2mr14719407qab.58.1339808789633; Fri, 15 Jun 2012 18:06:29 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Fri, 15 Jun 2012 18:06:29 -0700 (PDT) Date: Fri, 15 Jun 2012 21:06:29 -0400 X-Google-Sender-Auth: 3l1Qsh1tP4kbzxNFYmXY5RgbJU4 Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Some mailing lists moved from imc.org to ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jun 2012 01:06:32 -0000 A number of IETF-related mailing lists in the Applications Area have for some years been hosted by Paul Hoffman at imc.org. Most of them belonged to working groups at one time, and have remained active since the working groups closed, holding discussions of related activities and technology. Because of that history and current activity, it makes sense to keep the lists, and it also makes sense to re-host them at ietf.org. I discussed this with Paul, and he was also interested in making the switch. The Secretariat has, therefore, moved the lists to ietf.org. By "moved", I mean that the subscribers to the old lists were subscribed to the new ones, *and* the archives were copied over as well -- many thanks to Steve Young for doing his best to clean out the spam and only archive the real stuff. The new lists have the same purpose as the old ones, and Paul has set things up to point people to the new ones when they try to access the old. This should look, to all the users, like a pretty seamless transition, requiring only an update of any email filters to use the new list designations (see below). In addition to thanking Steve for handling the move, I thank Paul Hoffman for having set these up quickly when they were needed, and for hosting them for many years. The lists that were moved are these: imapext@ietf.org, List-ID: (was ietf-imapext@imc.org) Discussion of IMAP extensions ietf-822@ietf.org, List-ID: (was ietf-822@imc.org) Discussion of issues related to Internet Message Format [RFC 822, RFC 2822, RFC 5322] ietf-smtp@ietf.org, List-ID: (was ietf-smtp@imc.org) Discussion of issues related to Simple Mail Transfer Protocol (SMTP) [RFC 821, RFC 2821, RFC 5321] pop3ext@ietf.org, List-ID: (was ietf-pop3ext@imc.org) Discussion of extensions and updates to Post Office Protocol (POP3) xml-mime@ietf.org, List-ID: (was ietf-xml-mime@imc.org) Discussion of XML media types and issues relating to their use in MIME. openpgp@ietf.org, List-ID: (was ietf-openpgp@imc.org) Ongoing discussion of OpenPGP issues. usefor@ietf.org, List-ID: (was ietf-usefor@imc.org) Ongoing discussion of usefor issues. The mailman page for any list is at https://www.ietf.org/mailman/listinfo/LISTNAME --- Barry, Applications AD From ned.freed@mrochek.com Fri Jun 15 23:17: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 8625921F8568 for ; Fri, 15 Jun 2012 23:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 WTm+rY-dYnBO for ; Fri, 15 Jun 2012 23:17:07 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id DCD4B21F8564 for ; Fri, 15 Jun 2012 23:17:06 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGQD8GEP40003SGA@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 15 Jun 2012 23:14:00 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGPLORC04W000058@mauve.mrochek.com>; Fri, 15 Jun 2012 23:13:53 -0700 (PDT) Message-id: <01OGQD8CQZTW000058@mauve.mrochek.com> Date: Fri, 15 Jun 2012 23:13:32 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 15 Jun 2012 11:10:51 -0400" References: <4FD08CA3.6080504@dcrocker.net> <01OGEZDG0T8M000058@mauve.mrochek.com> <4FD29DF5.5010206@dcrocker.net> <01OGGS87OI0Q000058@mauve.mrochek.com> <03a901cd487e$908c37c0$4001a8c0@gateway.2wire.net> <4FD75939.6060200@dcrocker.net> <6.2.5.6.2.20120614075629.07eb21f0@resistor.net> 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: Sat, 16 Jun 2012 06:17:07 -0000 > >> The draft does not mention anything about how "deprecated" or "historic" > >> are to be handed. If the WG decides for FCFS, for example, how will the > >> "Use" be handled? > > > > Well now that's an interesting question. Can we say something like "FCFS, > > except IANA should probably check with ADs when they receive requests for > > status changes"? Has that been done before? > That, in effect, is "Expert Review, and the current App ADs are the > designated experts." > So: No, let's not do that. > If we're worried about who's allowed to modify existing registrations, > you can say that in the registry definition: > FCFS for new registrations, and existing registrations can be updated > by the original requestor or by IESG Approval. That's much better. Ned From cabo@tzi.org Sun Jun 17 13:01: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 512B421F8607; Sun, 17 Jun 2012 13:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.609 X-Spam-Level: X-Spam-Status: No, score=-106.609 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYT4CuGC80TM; Sun, 17 Jun 2012 13:01:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0AC21F84D9; Sun, 17 Jun 2012 13:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q5HK0jD0015418; Sun, 17 Jun 2012 22:00:46 +0200 (CEST) Received: from [192.168.217.117] (p54892585.dip.t-dialin.net [84.137.37.133]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4A020A55; Sun, 17 Jun 2012 22:00:45 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Carsten Bormann Date: Sun, 17 Jun 2012 22:00:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1C6943B9-8860-4331-9129-9D610FC7A661@tzi.org> To: "apps-discuss@ietf.org application-layer protocols" , draft-ietf-6man-rfc3484bis.all@tools.ietf.org X-Mailer: Apple Mail (2.1278) Cc: 6man@ietf.org, The IESG Subject: [apps-discuss] APPSDIR review of draft-ietf-6man-rfc3484bis-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, 17 Jun 2012 20:01:01 -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. Gruesse, Carsten --------------------------------- Document: draft-ietf-6man-rfc3484bis-05 Title: Default Address Selection for Internet Protocol version 6 (IPv6) Reviewer: Carsten Bormann Review Date: 2012-06-17 IETF Last Call Date: 2012-06-01, for 2012-06-15 IESG Telechat Date: 2012-06-21 ** Summary: This document is ready for publication after some editorial fixes, but it could benefit from some additional documentation as specified below. ** (Major:) Three types of address selection are often relevant to applications: -- initiator address selection (source and destination). This appears to be addressed here. -- responder address selection. This is mostly relevant where the responder cannot simply turn around the addresses chosen by the initiator. This may be because of multicast, or because of API deficiencies. -- listening address selection. An application needs to select the addresses to bind to. Experience from the ETSI CoAP plugfest shows that all three types of address selection are likely stumbling blocks when building an IPv6 implementation of a UDP-based protocol. RFC 3484 only seems to address initiator address selection, so it is logical that a -bis follows suit (but then, the security considerations seem to discuss responder address selection). Still, this is a major problem that maybe can be solved in additional documents. I believe the specification needs to be much clearer on who is its = target. The document does not fully indicate which part of a system is supposed = to act on its mandates. It just says The selection rules specified in this document MUST NOT be = construed to override an application or upper-layer's explicit choice = of a legal destination or source address. so there seems to be an assumption some part of the system other than an application or "upper-layer" may or should act on it. It then goes ahead and identifies getaddrinfo() explicitly as a target for destination address selection and "the network layer" for source address selection unless done by the application. Are other parts of a system subject to these mandates? Should an application writer that finds a working getaddrinfo() and a network layer read this document? Should an application layer protocol specification have to reference this document? There is also an assumption that the part of the system responsible for implementing this specification has certain information available to it (e.g., some knowledge is required to detect IPv4-converted addresses as such). This should be made much more explicit. ** (Minor:) Define term "scoped address prefix". (Maybe a section on terms would be useful; this could also be used to expand the many unexplained abbreviations used.) Last paragraph of 5 gives a "MUST be implemented" to Rule 2 only. -> expressio unius est exclusio alterius So clearly there is no MUST for the other rules? ** (Nit:) 2.1, in the paragraph "One effect", clarify that the document at this point hasn't said everything that is needed to derive this. As in: "As will become apparent later, ..." 3.1 could be explicit instead of being posed as a riddle. 5, 6: Saying every single rule twice (once for xA re xB and then for xB re xA) is tiring. From paulej@packetizer.com Sun Jun 17 18:48: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 EF7A721F85C0 for ; Sun, 17 Jun 2012 18:48:18 -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.001, 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 wNo-hNPtkUgc for ; Sun, 17 Jun 2012 18:48:16 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0770821F85C5 for ; Sun, 17 Jun 2012 18:48:15 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5I1m5ri006329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Jun 2012 21:48:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1339984088; bh=pOcQPEVLpH7syymC4lZYWCDE6xSpWltRFIc2UT1X4DQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=e90AqNjzlxI7gRMwH8KP/7O8xCP4v7PKp6ckmmSVMekCrh+KhOOCOn2sD5YxMLcxQ eLPyocuNLHxXNcyFgaJH5sbUP8+SKcUYqnkVzXCEpWt+Zc+fmG9xBxQa2RfuCMIDOI 3iV9ptCfqZOX6TP5iYyFlvq/kwp0ydD5aHGopLeE= From: "Paul E. Jones" To: "'William Mills'" , "'Peter Saint-Andre'" References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> In-Reply-To: <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Sun, 17 Jun 2012 21:48:07 -0400 Message-ID: <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0125_01CD4CD2.E3366B50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNYFRdarpUA3Z9l4mSBSKHTly568wGsYWTHAiB/MPYCgTB6NAGRuS9TAZsphI0CgPvwiZOJzEiA Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 01:48:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0125_01CD4CD2.E3366B50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bill, My apologies for the belated reply. I've been busy this week and got rather behind on email. I do not personally like using SRV records, either. SRV records could work for smaller domains, but I'm not sure that they're the best solution for larger domains. Personally, I would prefer putting users on specific servers or server clusters and SRV records will not differentiate users. To use WebFinger to find one's IMAP, SMTP, or POP server, we could do as I suggested in my email. Now the question is what does one query? Since these three services are email, I'd suggest we query "mailto:paulej@packetizer.com". We could use another URI scheme (e.g., "acct:"), but mailto seems most appropriate given that you're seeking info about mail services. I provided an example earlier that would simply point to a config file with server information. We could do this directly via WebFinger like this: GET /.well-known/host-meta?resource=mailto:paulej@packetizer.com This query would then return something like this: { "subject" : "mailto:paulej@packetizer.com", "links" : [ { "rel" : "smtp-server", "properties" : { "host" : "smtp.packetizer.com", "port" : "587", "login-required" : "yes", "transport" : "starttls" } }, { "rel" : "imap-server", "properties" : { "host" : "imap.packetizer.com", "port" : "993", "transport" : "ssl" } } ] } We would need to standardize the link relation values (smtp-server and imap-server). We would also need to document what the various properties would be. If you would like to create such a configuration document based on WebFinger, I'd be happy to help out. In any case, you can see that WebFinger would serve quite nicely for conveying configuration information given a user's email ID. I'm not sure exactly what you would need for OAuth endpoints, but I would suggest you make that a separate document since it is not mail related. (At least I assume it's not. Even if it were, the mail server information and OAuth information are still different animals.) Paul From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Wednesday, June 13, 2012 7:32 PM To: Peter Saint-Andre Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery In my use case it's a service/server. Not a terribly happy answer to say "DNS SRV records won't work for you, and there is no other solution.". By the same token I could ask "Why do we need Webfinger and host meta at all if we have DNS SRV records?". If XMPP uses SRV records for discovery, that's fine. IMAP and outbound SMTP services both lack a defined discovery method other than the ubiquitous "service documentation". Is there a compelling reason to pick DNS over WF for this? From the app developer point of view I don't want to have N ways to discover M services. -bill _____ From: Peter Saint-Andre To: William Mills Cc: Paul E. Jones ; 'Cyrus Daboo' ; "apps-discuss@ietf.org" Sent: Wednesday, June 13, 2012 3:57 PM Subject: Re: [apps-discuss] Aggregated service discovery On 6/13/12 4:54 PM, William Mills wrote: > As I said, I'm interested specifically in IMAP, SMTP and OAuth endpoints. What exactly is an "endpoint"? A client? An account? A server? > As a data point, DNS SRV records are not controllable in many hosted > domain models. At the last XMPP Summit a few months ago, we learned that DNS SRV records are unavailable in whole countries (e.g., Japan). That doesn't mean we should define a replacement for DNS over HTTP. :) Peter -- Peter Saint-Andre https://stpeter.im/ ------=_NextPart_000_0125_01CD4CD2.E3366B50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bill,

 

My apologies for the belated reply.  I’ve been busy this = week and got rather behind on email.

 

I do not personally like using SRV records, either.  SRV records = could work for smaller domains, but I’m not sure that = they’re the best solution for larger domains.  Personally, I = would prefer putting users on specific servers or server clusters and = SRV records will not differentiate users.

 

To use WebFinger to find one’s IMAP, SMTP, or POP server, we = could do as I suggested in my email.  Now the question is what does = one query?  Since these three services are email, I’d suggest = we query “mailto:paulej@packetizer.com”.  We could use = another URI scheme (e.g., “acct:”), but mailto seems most = appropriate given that you’re seeking info about mail = services.

 

I provided an example earlier that would simply point to a config = file with server information.  We could do this directly via = WebFinger like this:

 

GET = /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com=

 

This query would then return something like = this:

 

{

  "subject" : = "mailto:paulej@packetizer.com",

  "links" :

  [

    {

      "rel" : = "smtp-server",

      = "properties" :

      = {

        = "host" : = "smtp.packetizer.com",

        = "port" : "587",

        = "login-required" : "yes",

        = "transport" : "starttls"

      = }

    },

    {

      "rel" : = "imap-server",

      = "properties" :

      = {

        = "host" : = "imap.packetizer.com",

        = "port" : "993",

        = "transport" : "ssl"

      = }

    }

  ]

}

 

We would need to standardize the link relation values (smtp-server = and imap-server).  We would also need to document what the various = properties would be.  If you would like to create such a = configuration document based on WebFinger, I’d be happy to help = out.  In any case, you can see that WebFinger would serve quite = nicely for conveying configuration information given a user’s = email ID.

 

I’m not sure exactly what you would need for OAuth endpoints, = but I would suggest you make that a separate document since it is not = mail related.  (At least I assume it’s not.  Even if it = were, the mail server information and OAuth information are still = different animals.)

 

Paul

 

From:= = William Mills [mailto:wmills@yahoo-inc.com]
Sent: Wednesday, = June 13, 2012 7:32 PM
To: Peter Saint-Andre
Cc: Paul = E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org
Subject: Re: = [apps-discuss] Aggregated service = discovery

 

In my = use case it's a service/server.

 

Not a = terribly happy answer to say "DNS SRV records won't work for you, = and there is no other solution.".  By the same token I could = ask "Why do we need Webfinger and host meta at all if we have DNS = SRV records?".

 

If XMPP = uses SRV records for discovery, that's fine.  IMAP and outbound = SMTP services both lack a defined discovery method other than the = ubiquitous "service documentation".  Is there a = compelling reason to pick DNS over WF for this?  From the app = developer point of view I don't want to have N ways to discover M = services.

 

-bill

 

 

<= hr size=3D1 width=3D"100%" align=3Dcenter>

F= rom: = Peter Saint-Andre <stpeter@stpeter.im>
To: William Mills <wmills@yahoo-inc.com> =
Cc: Paul E. Jones <paulej@packetizer.com>; = 'Cyrus Daboo' <cyrus@daboo.name>; "apps-discuss@ietf.org" = <apps-discuss@ietf.org> =
Sent: Wednesday, June 13, 2012 3:57 PM
Subject: Re: = [apps-discuss] Aggregated service discovery


On 6/13/12 4:54 PM, William Mills = wrote:
> As I said, I'm interested specifically in IMAP, SMTP and = OAuth endpoints.

What exactly is an "endpoint"? A = client? An account? A server?

> As a data point, DNS SRV = records are not controllable in many hosted
> domain = models.

At the last XMPP Summit a few months ago, we learned that = DNS SRV
records are unavailable in whole countries (e.g., Japan). = That doesn't
mean we should define a replacement for DNS over HTTP. = :)

Peter

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





------=_NextPart_000_0125_01CD4CD2.E3366B50-- From internet-drafts@ietf.org Sun Jun 17 22:09: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 303E721F8589; Sun, 17 Jun 2012 22:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 30NnzgP-yrYb; Sun, 17 Jun 2012 22:09:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442EF21F855A; Sun, 17 Jun 2012 22:09:25 -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: <20120618050925.30416.34929.idtracker@ietfa.amsl.com> Date: Sun, 17 Jun 2012 22:09:25 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-jones-appsawg-webfinger-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 05:09:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-jones-appsawg-webfinger-06.txt Pages : 24 Date : 2012-06-17 Abstract: This specification defines the WebFinger protocol. WebFinger may be used to discover information about people on the Internet, such as a person's personal profile address, identity service, telephone number, or preferred avatar. WebFinger may also be used to learn information about objects on the network, such as the amount of toner in a printer or the physical location of a server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jones-appsawg-webfinger There's also a htmlized version available at: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-jones-appsawg-webfinger-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paulej@packetizer.com Sun Jun 17 22: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 877A021F8589 for ; Sun, 17 Jun 2012 22:28:44 -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 1cevkrt8Zyxn for ; Sun, 17 Jun 2012 22:28:43 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C441B21F8587 for ; Sun, 17 Jun 2012 22:28:43 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5I5SgqS012472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 18 Jun 2012 01:28:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1339997323; bh=+4ZoPsCmWZNtxX22SfXi+VOLKjy58IIE+J63h/d3Jew=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZX6G+3Nnt4iMRIf8qPWnPJ+F/jG3k1FAle3qsLJZ6jBNfAP+5poeJNofATo2yq0OR 25BxQsR0lvFvejGoqzWD/IrMHNFRu851y/xQF8jtjVy3Hz/842brEr6KTImPRjSeSV uRFh4qcKrXU1YYtoVlGagPFaJDjezV7smGlXt3wI= From: "Paul E. Jones" To: References: <20120618050925.30416.34929.idtracker@ietfa.amsl.com> In-Reply-To: <20120618050925.30416.34929.idtracker@ietfa.amsl.com> Date: Mon, 18 Jun 2012 01:28:44 -0400 Message-ID: <016a01cd4d13$3b1b1380$b1513a80$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJi9pBpzQapvsw8ynyUFChe2wVLbZXUNChA Content-Language: en-us Subject: [apps-discuss] FW: I-D Action: draft-jones-appsawg-webfinger-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 05:28:44 -0000 Folks, I posted a new version of the WebFinger draft, taking into consideration some of the feedback received, some of the off-line exchanges I've had with Mike and few others, contributed text from Peter, etc. I tried to capture the significant changes in the change log at the end of the document. Please have a look at this revised draft and we'll try to move it forward. I have also sent a request to the email address specified for URI scheme review to try to move registration of "acct" along. I hope that will not take long, and I would hope it would not considering the specific and narrow scope of "acct". Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: Monday, June 18, 2012 1:09 AM > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > Subject: [apps-discuss] I-D Action: draft-jones-appsawg-webfinger-06.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group Working > Group of the IETF. > > Title : WebFinger > Author(s) : Paul E. Jones > Gonzalo Salgueiro > Joseph Smarr > Filename : draft-jones-appsawg-webfinger-06.txt > Pages : 24 > Date : 2012-06-17 > > Abstract: > This specification defines the WebFinger protocol. WebFinger may be > used to discover information about people on the Internet, such as a > person's personal profile address, identity service, telephone > number, or preferred avatar. WebFinger may also be used to learn > information about objects on the network, such as the amount of toner > in a printer or the physical location of a server. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-jones-appsawg-webfinger > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-jones-appsawg-webfinger-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From derhoermi@gmx.net Sun Jun 17 22:51: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 B8C0C21F8462 for ; Sun, 17 Jun 2012 22:51:52 -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 5Tzq6tOlF8Wg for ; Sun, 17 Jun 2012 22:51:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 355A421F845F for ; Sun, 17 Jun 2012 22:51:51 -0700 (PDT) Received: (qmail invoked by alias); 18 Jun 2012 05:51:49 -0000 Received: from dslb-094-222-147-091.pools.arcor-ip.net (EHLO HIVE) [94.222.147.91] by mail.gmx.net (mp037) with SMTP; 18 Jun 2012 07:51:49 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+UxvcWGDaU6n6s+zfbbBGJKt4ArxI2G2+yHjHwry bNjiR84ESAgN+l From: Bjoern Hoehrmann To: "Paul E. Jones" Date: Mon, 18 Jun 2012 07:51:54 +0200 Message-ID: References: <20120618050925.30416.34929.idtracker@ietfa.amsl.com> <016a01cd4d13$3b1b1380$b1513a80$@packetizer.com> In-Reply-To: <016a01cd4d13$3b1b1380$b1513a80$@packetizer.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: I-D Action: draft-jones-appsawg-webfinger-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 05:51:53 -0000 * Paul E. Jones wrote: >I have also sent a request to the email address specified for URI scheme >review to try to move registration of "acct" along. I hope that will not >take long, and I would hope it would not considering the specific and narrow >scope of "acct". http://www.ietf.org/mail-archive/web/uri-review/current/msg01605.html if anyone wants to follow along. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From wwwrun@rfc-editor.org Sun Jun 17 23:26: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 4304811E80C6; Sun, 17 Jun 2012 23:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.84 X-Spam-Level: X-Spam-Status: No, score=-101.84 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoLdLwx6nGkP; Sun, 17 Jun 2012 23:26:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C5F1F11E80C4; Sun, 17 Jun 2012 23:26:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8206872E042; Sun, 17 Jun 2012 23:26:22 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120618062622.8206872E042@rfc-editor.org> Date: Sun, 17 Jun 2012 23:26:22 -0700 (PDT) Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 6647 on Email Greylisting: An Applicability Statement for 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: Mon, 18 Jun 2012 06:26:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6647 Title: Email Greylisting: An Applicability Statement for SMTP Author: M. Kucherawy, D. Crocker Status: Standards Track Stream: IETF Date: June 2012 Mailbox: superuser@gmail.com, dcrocker@bbiw.net Pages: 17 Characters: 38097 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-appsawg-greylisting-09.txt URL: http://www.rfc-editor.org/rfc/rfc6647.txt This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. [STANDARDS-TRACK] This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From perpetual-tripper@wwelves.org Mon Jun 18 00: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 8DCEB21F84B3 for ; Mon, 18 Jun 2012 00:57:29 -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 v6colve-c2VV for ; Mon, 18 Jun 2012 00:57:29 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id DCFF421F84A6 for ; Mon, 18 Jun 2012 00:57:28 -0700 (PDT) X-Originating-IP: 217.70.178.139 Received: from mfilter10-d.gandi.net (mfilter10-d.gandi.net [217.70.178.139]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 4E33717209D; Mon, 18 Jun 2012 09:57:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter10-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter10-d.gandi.net (mfilter10-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id UUYygRsSxGIe; Mon, 18 Jun 2012 09:57:15 +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 relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 791971720C9; Mon, 18 Jun 2012 09:57:15 +0200 (CEST) Content-Type: text/plain; charset=UTF-8 From: elf Pavlik To: Paul E. Jones In-reply-to: <016a01cd4d13$3b1b1380$b1513a80$@packetizer.com> References: <20120618050925.30416.34929.idtracker@ietfa.amsl.com> <016a01cd4d13$3b1b1380$b1513a80$@packetizer.com> Date: Mon, 18 Jun 2012 07:57:13 +0000 Message-Id: <1340005251-sup-8958@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss Subject: Re: [apps-discuss] FW: I-D Action: draft-jones-appsawg-webfinger-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 07:57:29 -0000 Hi Paul, Excerpts from Paul E. Jones's message of 2012-06-18 05:28:44 +0000: > Folks, >=20 > I posted a new version of the WebFinger draft, taking into consideratio= n > some of the feedback received, some of the off-line exchanges I've had = with > Mike and few others, contributed text from Peter, etc. I tried to capt= ure > the significant changes in the change log at the end of the document. >=20 > Please have a look at this revised draft and we'll try to move it forwa= rd. >=20 > I have also sent a request to the email address specified for URI schem= e > review to try to move registration of "acct" along. I hope that will n= ot > take long, and I would hope it would not considering the specific and n= arrow > scope of "acct". >=20 > Paul We have discussed at some point strategy for marking in my XRD/JRD profil= e that I've *moved to* another webfinger address. Do I understand correct= ly that section: '7. The "acct" Link Relation' explains how we can do it? I see it quite important that people can 'lightheaded' create accounts so= mewhere just to 'give it a try' than take more time to choose providers f= or their accounts, including using domain names they have control over, a= nd than migrate leaving old webfinger just pointing to new one :) Cheers! ~ elf Pavlik ~ From internet-drafts@ietf.org Mon Jun 18 06:50: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 18FF321F860F; Mon, 18 Jun 2012 06:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, 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 QTjjOjwU2eaF; Mon, 18 Jun 2012 06:50:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D34C21F8638; Mon, 18 Jun 2012 06:50:57 -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: <20120618135057.6443.82211.idtracker@ietfa.amsl.com> Date: Mon, 18 Jun 2012 06:50:57 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 13:50:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Forwarded HTTP Extension Author(s) : Andreas Petersson Martin Nilsson Filename : draft-ietf-appsawg-http-forwarded-04.txt Pages : 15 Date : 2012-06-18 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-http-forwarded-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paulej@packetizer.com Mon Jun 18 08:13: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 E53D321F870E for ; Mon, 18 Jun 2012 08:13:52 -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 esonYarOiXct for ; Mon, 18 Jun 2012 08:13:51 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 618B321F8710 for ; Mon, 18 Jun 2012 08:13:51 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5IFDoQ3029104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Jun 2012 11:13:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340032430; bh=5S8yCzsjK4vP/YltcjVRcWXg+1iRAI1HLgtTsZxVLpY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=lLRrZa/sNHBUpNEKQnJOQOfG1SbAz1MFoOnotXaQSDh/kZQMmqVBhfgysLWgvS2u8 QPEKDvX0e3jlH642PneYHEjZo1Oz+FamTOcrE2uNcuNFaG/BXRcZ8Y1Eo93Sy0ZqZj CgyJiB5bRXHpmv4q5LeFzjlFemzw2ZPgrJjYOh0M= From: "Paul E. Jones" To: "'elf Pavlik'" References: <20120618050925.30416.34929.idtracker@ietfa.amsl.com> <016a01cd4d13$3b1b1380$b1513a80$@packetizer.com> <1340005251-sup-8958@heahdk.net> In-Reply-To: <1340005251-sup-8958@heahdk.net> Date: Mon, 18 Jun 2012 11:13:53 -0400 Message-ID: <01e301cd4d64$f948d260$ebda7720$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJi9pBpzQapvsw8ynyUFChe2wVLbQGC2oIFAVtN7M2VvdH0gA== Content-Language: en-us Cc: 'apps-discuss' Subject: Re: [apps-discuss] FW: I-D Action: draft-jones-appsawg-webfinger-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 15:13:53 -0000 Elf, The intent is that the "acct" link relation would be a means of allowing = one account to incorporate link relations from a different account URI. = So, let's suppose I have an account acct:paulej@packetizer.com and I = also have an account that holds pictures on flickr.com. Within my = packetizer.com account, I could include a reference to my flickr.com = account, like this: I could include the particular link relations that Flickr might = advertise from within my packetizer.com account. However, that requires = me to ensure I keep those references up-to-date. A reference like the = above helps simplify my life. I added two new paragraphs following the first paragraph in that section = to make it clearer in the -07 draft: =3D=3D=3D 7.1. Purpose for the =E2=80=9Cacct=E2=80=9D Link Relation Users of some services might have an =E2=80=9Cacct=E2=80=9D URI that = looks significantly different from his or her email address, perhaps = using an entirely different domain name. It is also possible for a user = have multiple accounts that a user wants to advertise and that a = WebFinger client may want to query. To address both of these needs, = this specification defines the =E2=80=9Cacct=E2=80=9D link relation. The "acct" link relation allows a WebFinger server to reference one or = more other user account URIs from within a user account. The "acct" = link relation is intended to allow a client to incorporate additional = link relations by reference to produce a complete set of link relations = for a user. Any newly discovered link relations found by querying the = referenced account should be merged into the resource descriptor = document at the point where the "acct" link relation was inserted. Note that the "acct" link relation does not replace the use of standard = HTTP 3xx response codes to indicate the new temporary or permanent = location of a user account. If a user account is moved to a different = location, then a 3xx response code SHOULD be used. ... =3D=3D=3D Do those additional paragraphs help? As for creating accounts here and there just to give WebFinger a try, I = would hope users don't try to hold on to those. That would be messy for = a computer or human to deal with. :-) Paul > -----Original Message----- > From: elf Pavlik [mailto:perpetual-tripper@wwelves.org] > Sent: Monday, June 18, 2012 3:57 AM > To: Paul E. Jones > Cc: apps-discuss > Subject: Re: [apps-discuss] FW: I-D Action: = draft-jones-appsawg-webfinger- > 06.txt >=20 > Hi Paul, >=20 > Excerpts from Paul E. Jones's message of 2012-06-18 05:28:44 +0000: > > Folks, > > > > I posted a new version of the WebFinger draft, taking into > > consideration some of the feedback received, some of the off-line > > exchanges I've had with Mike and few others, contributed text from > > Peter, etc. I tried to capture the significant changes in the = change > log at the end of the document. > > > > Please have a look at this revised draft and we'll try to move it > forward. > > > > I have also sent a request to the email address specified for URI > > scheme review to try to move registration of "acct" along. I hope > > that will not take long, and I would hope it would not considering = the > > specific and narrow scope of "acct". > > > > Paul >=20 > We have discussed at some point strategy for marking in my XRD/JRD = profile > that I've *moved to* another webfinger address. Do I understand = correctly > that section: '7. The "acct" Link Relation' explains how we can do it? >=20 > I see it quite important that people can 'lightheaded' create accounts > somewhere just to 'give it a try' than take more time to choose = providers > for their accounts, including using domain names they have control = over, > and than migrate leaving old webfinger just pointing to new one :) >=20 > Cheers! > ~ elf Pavlik ~ From perpetual-tripper@wwelves.org Mon Jun 18 09:05: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 CDD5A21F86DF for ; Mon, 18 Jun 2012 09:05:07 -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 wagsciBQcPYS for ; Mon, 18 Jun 2012 09:05:06 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id B153221F86F7 for ; Mon, 18 Jun 2012 09:05:05 -0700 (PDT) X-Originating-IP: 217.70.178.133 Received: from mfilter3-d.gandi.net (mfilter3-d.gandi.net [217.70.178.133]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id A9CA5172090; Mon, 18 Jun 2012 18:04:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter3-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter3-d.gandi.net (mfilter3-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id QFe7Y3Z-fy2P; Mon, 18 Jun 2012 18:04:50 +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 relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 20A3E1720A5; Mon, 18 Jun 2012 18:04:49 +0200 (CEST) Content-Type: text/plain; charset=UTF-8 From: elf Pavlik To: Paul E. Jones In-reply-to: <01e301cd4d64$f948d260$ebda7720$@packetizer.com> References: <20120618050925.30416.34929.idtracker@ietfa.amsl.com> <016a01cd4d13$3b1b1380$b1513a80$@packetizer.com> <1340005251-sup-8958@heahdk.net> <01e301cd4d64$f948d260$ebda7720$@packetizer.com> Date: Mon, 18 Jun 2012 16:04:48 +0000 Message-Id: <1340035392-sup-1090@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss Subject: Re: [apps-discuss] FW: I-D Action: draft-jones-appsawg-webfinger-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 16:05:07 -0000 Hi Paul, Excerpts from Paul E. Jones's message of 2012-06-18 15:13:53 +0000: > Elf, >=20 > The intent is that the "acct" link relation would be a means of allowin= g one account to incorporate link relations from a different account URI.= So, let's suppose I have an account acct:paulej@packetizer.com and I al= so have an account that holds pictures on flickr.com. Within my packetiz= er.com account, I could include a reference to my flickr.com account, lik= e this: > >=20 > I could include the particular link relations that Flickr might adverti= se from within my packetizer.com account. However, that requires me to e= nsure I keep those references up-to-date. A reference like the above hel= ps simplify my life. >=20 > I added two new paragraphs following the first paragraph in that sectio= n to make it clearer in the -07 draft: >=20 > =3D=3D=3D > 7.1. Purpose for the =E2=80=9Cacct=E2=80=9D Link Relation >=20 > Users of some services might have an =E2=80=9Cacct=E2=80=9D URI that lo= oks significantly different from his or her email address, perhaps using = an entirely different domain name. It is also possible for a user have m= ultiple accounts that a user wants to advertise and that a WebFinger clie= nt may want to query. To address both of these needs, this specification= defines the =E2=80=9Cacct=E2=80=9D link relation. >=20 > The "acct" link relation allows a WebFinger server to reference one or = more other user account URIs from within a user account. The "acct" link= relation is intended to allow a client to incorporate additional link re= lations by reference to produce a complete set of link relations for a us= er. Any newly discovered link relations found by querying the referenced= account should be merged into the resource descriptor document at the po= int where the "acct" link relation was inserted. >=20 > Note that the "acct" link relation does not replace the use of standard= HTTP 3xx response codes to indicate the new temporary or permanent locat= ion of a user account. If a user account is moved to a different locatio= n, then a 3xx response code SHOULD be used. >=20 > ... > =3D=3D=3D >=20 > Do those additional paragraphs help? That helped me with clarifying it, thank you! :) ~ elf Pavlik ~ From wmills@yahoo-inc.com Mon Jun 18 10:36: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 AC21E21F86D5 for ; Mon, 18 Jun 2012 10:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.525 X-Spam-Level: X-Spam-Status: No, score=-17.525 tagged_above=-999 required=5 tests=[AWL=0.073, 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 cZDEDkR2UN5G for ; Mon, 18 Jun 2012 10:36:29 -0700 (PDT) Received: from nm24-vm0.bullet.mail.sp2.yahoo.com (nm24-vm0.bullet.mail.sp2.yahoo.com [98.139.91.226]) by ietfa.amsl.com (Postfix) with SMTP id 2DE7C21F86D4 for ; Mon, 18 Jun 2012 10:36:28 -0700 (PDT) Received: from [72.30.22.78] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 18 Jun 2012 17:36:28 -0000 Received: from [98.139.91.44] by tm12.bullet.mail.sp2.yahoo.com with NNFMP; 18 Jun 2012 17:36:28 -0000 Received: from [127.0.0.1] by omp1044.mail.sp2.yahoo.com with NNFMP; 18 Jun 2012 17:36:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 864529.38865.bm@omp1044.mail.sp2.yahoo.com Received: (qmail 7697 invoked by uid 60001); 18 Jun 2012 17:36:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1340040988; bh=sj3MPSO+6VouIL60DcxXS5HTQ4Jwlg8/vH+Smfir2gQ=; 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=XKzMe4smVjUYcMvMaRKIJYRE4hPos5nZsEnpoTrAVaxl46SwHtGPDVpeUTSl5+xl6jklLrRtKyHJUq/ZnK61R0ySN0hWm8FuE0DwMgIdN0ufzohn1J7pEhHWbkzLLM1IIecQzChvwIyYREUqbFAqgNyIVM/Am2DWvOcWJ/cOEjk= 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=e7GGS+i/+DfU33+dcIkiUka9zpMG6h3vrK0jxLdaCaH9RMGyvBWECQY/BlOhyR4ur3PZcjMFESMB6SI2qB52fFF5ZHjmHrFrGDBes2gENStS3VpRerswZENoizV2UKkDuz7eSwSVx18hSTqgfdEzw3blsTJa8GRRrpOkd1jGJRo=; X-YMail-OSG: DPbl6aEVM1mJ8U_1yvkhJvJwlZ_UQ4ijcB5ULknnJhi1oTg CsGb.QucXqjzb50QZvbXq0DHIGNCKf7.gdYlRFU9kL_JJjNJeMswYfb_S1Sy UjFnBfrbx3lZEGy4KLXsG3DqsCzvxhyu1gLjuwF52Dlr2sZp1K3PpjzGylQ4 4IrZay0gRySanAuPreG8K6SM_I1mj7Ps0C1.EdOUC0ZWfA3dpAgjx7XpqaGX LvOoab1uYQ8quDjz1AlEa1hmMCKvCV3inQ.ffy5hLSS0q4..V4lduED1KqA5 BcX7ox4X7u2vCLwKMx6CaNajF0m7TnF6GAfdU4rCljDQpe3Ni1feqOEmRh1z x5J3ZrYCxegC0gynMg8707So6DU92vAraW4g_Adeauzz10T2nN7ZpNiKsNul hYXsRq5aPe2PkX7e1Sl605JrCbKouaGvKbvcacnlVSN60eghFwC9hc9BVs6w dWvd_5p.W5F_BItXrQHtb9UU0YZB54O4N7BJ3WC6ayyh5UrFizqPJyary9Dp _LLq5qz_1_P1w.Jd2_c75a.o8HX0k.ye2a_yBSylZeg-- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Mon, 18 Jun 2012 10:36:27 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> Message-ID: <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Mon, 18 Jun 2012 10:36:27 -0700 (PDT) From: William Mills To: "Paul E. Jones" , 'Peter Saint-Andre' In-Reply-To: <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-117279552-1340040987=:3036" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery 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, 18 Jun 2012 17:36:30 -0000 --1458549034-117279552-1340040987=:3036 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul, =0A=0A=0AThanks for the reply on this.=C2=A0 I do already have a sepa= rate doc for registering the OAuth specific relations, http://tools.ietf.or= g/id/draft-wmills-oauth-lrdd-01.html=0A=0A=0AI don't think I like the thoug= ht of having to register a new link type for every service, but that might = be the right way.=C2=A0 IMAP already has a URI defined for example so if we= use a more general link relation then the URI scheme details the type.=C2= =A0 The tradeoff is whether you can look for a specific link-type or if you= have to scan list elements for the URI type you need.=0A=0A-bill=0A=0A=0A= =0A=0A=0A>________________________________=0A> From: Paul E. Jones =0A>To: 'William Mills' ; 'Peter Saint= -Andre' =0A>Cc: 'Cyrus Daboo' ; apps= -discuss@ietf.org =0A>Sent: Sunday, June 17, 2012 6:48 PM=0A>Subject: RE: [= apps-discuss] Aggregated service discovery=0A> =0A>=0A>Bill,=0A>=C2=A0=0A>M= y apologies for the belated reply.=C2=A0 I=E2=80=99ve been busy this week a= nd got rather behind on email.=0A>=C2=A0=0A>I do not personally like using = SRV records, either.=C2=A0 SRV records could work for smaller domains, but = I=E2=80=99m not sure that they=E2=80=99re the best solution for larger doma= ins.=C2=A0 Personally, I would prefer putting users on specific servers or = server clusters and SRV records will not differentiate users. =0A>=C2=A0=0A= >To use WebFinger to find one=E2=80=99s IMAP, SMTP, or POP server, we could= do as I suggested in my email.=C2=A0 Now the question is what does one que= ry?=C2=A0 Since these three services are email, I=E2=80=99d suggest we quer= y =E2=80=9Cmailto:paulej@packetizer.com=E2=80=9D.=C2=A0 We could use anothe= r URI scheme (e.g., =E2=80=9Cacct:=E2=80=9D), but mailto seems most appropr= iate given that you=E2=80=99re seeking info about mail services.=0A>=C2=A0= =0A>I provided an example earlier that would simply point to a config file = with server information.=C2=A0 We could do this directly via WebFinger like= this:=0A>=C2=A0=0A>GET /.well-known/host-meta?resource=3Dmailto:paulej@pac= ketizer.com=0A>=C2=A0=0A>This query would then return something like this:= =0A>=C2=A0=0A>{=0A>=C2=A0 "subject" : "mailto:paulej@packetizer.com",=0A>= =C2=A0 "links" :=0A>=C2=A0 [=0A>=C2=A0=C2=A0=C2=A0 {=0A>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 "rel" : "smtp-server",=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "prop= erties" :=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=0A>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "host" : "smtp.packetizer.com",=0A>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "port" : "587",=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "login-required" : "yes",=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "transport" : "starttls"=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=0A>=C2= =A0=C2=A0=C2=A0 },=0A>=C2=A0=C2=A0=C2=A0 {=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 "rel" : "imap-server",=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "properties" := =0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "host" : "imap.packetizer.com",=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 "port" : "993",=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "transport" : "ssl"=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=0A>=C2=A0=C2=A0=C2= =A0 }=0A>=C2=A0 ]=0A>}=0A>=C2=A0=0A>We would need to standardize the link r= elation values (smtp-server and imap-server).=C2=A0 We would also need to d= ocument what the various properties would be.=C2=A0 If you would like to cr= eate such a configuration document based on WebFinger, I=E2=80=99d be happy= to help out.=C2=A0 In any case, you can see that WebFinger would serve qui= te nicely for conveying configuration information given a user=E2=80=99s em= ail ID.=0A>=C2=A0=0A>I=E2=80=99m not sure exactly what you would need for O= Auth endpoints, but I would suggest you make that a separate document since= it is not mail related.=C2=A0 (At least I assume it=E2=80=99s not.=C2=A0 E= ven if it were, the mail server information and OAuth information are still= different animals.)=0A>=C2=A0=0A>Paul=0A>=C2=A0=0A>From:William Mills [mai= lto:wmills@yahoo-inc.com] =0A>Sent: Wednesday, June 13, 2012 7:32 PM=0A>To:= Peter Saint-Andre=0A>Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.o= rg=0A>Subject: Re: [apps-discuss] Aggregated service discovery=0A>=C2=A0=0A= >In my use case it's a service/server.=0A>=C2=A0=0A>Not a terribly happy an= swer to say "DNS SRV records won't work for you, and there is no other solu= tion.".=C2=A0 By the same token I could ask "Why do we need Webfinger and h= ost meta at all if we have DNS SRV records?".=0A>=C2=A0=0A>If XMPP uses SRV= records for discovery, that's fine.=C2=A0 IMAP and outbound SMTP services = both lack a defined discovery method other than the ubiquitous "service doc= umentation".=C2=A0 Is there a compelling reason to pick DNS over WF for thi= s?=C2=A0 From the app developer point of view I don't want to have N ways t= o discover M services.=0A>=C2=A0=0A>-bill=0A>=C2=A0=0A>=C2=A0=0A>>=0A>>____= ____________________________=0A>>=0A>>From:Peter Saint-Andre =0A>>To: William Mills =0A>>Cc: Paul E. Jones = ; 'Cyrus Daboo' ; "apps-discuss@ie= tf.org" =0A>>Sent: Wednesday, June 13, 2012 3:57 PM= =0A>>Subject: Re: [apps-discuss] Aggregated service discovery=0A>>=0A>>On 6= /13/12 4:54 PM, William Mills wrote:=0A>>> As I said, I'm interested specif= ically in IMAP, SMTP and OAuth endpoints. =0A>>=0A>>What exactly is an "end= point"? A client? An account? A server?=0A>>=0A>>> As a data point, DNS SRV= records are not controllable in many hosted=0A>>> domain models.=0A>>=0A>>= At the last XMPP Summit a few months ago, we learned that DNS SRV=0A>>recor= ds are unavailable in whole countries (e.g., Japan). That doesn't=0A>>mean = we should define a replacement for DNS over HTTP. :)=0A>>=0A>>Peter=0A>>=0A= >>-- =0A>>Peter Saint-Andre=0A>>https://stpeter.im/=0A>>=0A>>=0A>>=0A>>=0A>= >=0A>>=0A>=0A> --1458549034-117279552-1340040987=:3036 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Paul,

Thanks for = the reply on this.  I do already have a separate doc for registering t= he OAuth specific relations, http://tools.ietf.org/id/draft-wmills-oauth-lr= dd-01.html

I don't t= hink I like the thought of having to register a new link type for every ser= vice, but that might be the right way.  IMAP already has a URI defined= for example so if we use a more general link relation then the URI scheme = details the type.  The tradeoff is whether you can look for a specific= link-type or if you have to scan list elements for the URI type you need.<= /span>

-bill


From: Paul E. Jones <paulej@packetize= r.com>
To: 'William= Mills' <wmills@yahoo-inc.com>; 'Peter Saint-Andre' <stpeter@stpet= er.im>
Cc: 'Cyrus D= aboo' <cyrus@daboo.name>; apps-discuss@ietf.org
Sent: Sunday, June 17, 2012 6:48 PM
= Subject: RE: [apps-discuss= ] Aggregated service discovery

=0A
Bill,
 
My apologies for the belated reply.  I=E2=80=99ve been busy= this week and got rather behind on email.
 
I do not personally like using SRV records, either.  = SRV records could work for smaller domains, but I=E2=80=99m not sure that t= hey=E2=80=99re the best solution for larger domains.  Personally, I would prefer putting users on specific= servers or server clusters and SRV records will not differentiate users. <= /span>
 
To use WebFinger to find o= ne=E2=80=99s IMAP, SMTP, or POP server, we could do as I suggested in my em= ail.  Now the question is what does one query?  Since these three= services are email, I=E2=80=99d suggest we query =E2=80=9Cmailto:paulej@pa= cketizer.com=E2=80=9D.  We could use another URI scheme (e.g., =E2=80= =9Cacct:=E2=80=9D), but mailto seems most appropriate given that you=E2=80= =99re seeking info about mail services.
 
I provided an example earlier tha= t would simply point to a config file with server information.  We cou= ld do this directly via WebFinger like this:
 
GET /.well-known/host-meta?resource=3Dmailto:paulej@pac= ketizer.com
&n= bsp;
This query w= ould then return something like this:
 
{
  "subject" : = "mailto:paulej@packetizer.com",
  "links" :
  [
    {
      "rel" : "smtp-ser= ver",
 &nbs= p;    "properties" :
      {
      &n= bsp; "host" : "sm= tp.packetizer.com",
<= span style=3D"font-size:10.0pt;font-family:"Courier New";color:#1= F497D;">        "port" : "587",
        "login-required" : "yes",
   =      "transport" : "starttls"
      }
    },
   = {
      "rel" : "imap-ser= ver",
 &nbs= p;    "properties" :
      {
      &n= bsp; "host" : "im= ap.packetizer.com",
<= span style=3D"font-size:10.0pt;font-family:"Courier New";color:#1= F497D;">        "port" : "993",
        "transport" : "ssl"
    =   }
 &= nbsp;  }
&n= bsp; ]
}<= /div>
 
We would need to standardize the link relation values (smtp-server and i= map-server).  We would also need to document what the various properti= es would be.  If you would like to create such a configuration documen= t based on WebFinger, I=E2=80=99d be happy to help out.  In any case, = you can see that WebFinger would serve quite nicely for conveying configura= tion information given a user=E2=80=99s email ID.
 
I=E2=80=99m not sure exactly what you would need fo= r OAuth endpoints, but I would suggest you make that a separate document si= nce it is not mail related.  (At least I assume it=E2=80=99s not. = ; Even if it were, the mail server information and OAuth information are still different animals.)
 
=
Paul
 
From: William Mills [mailto:wmi= lls@yahoo-inc.com]
Sent: Wednesday, June 13, 2012 7:32 PM
= To: Peter Saint-Andre
Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.= org
Subject: Re: [apps-discuss] Aggregated service discovery
 
In my use case it's a service/server.
 
Not a terribly happy answer to say "DNS SRV records won't = work for you, and there is no other solution.".  By the same token I c= ould ask "Why do we need Webfinger and host meta at all if we have DNS SRV records?".
 
If XMPP uses= SRV records for discovery, that's fine.  IMAP and outbound SMTP servi= ces both lack a defined discovery method other than the ubiquitous "service= documentation".  Is there a compelling reason to pick DNS over WF for= this?  From the app developer point of view I don't want to have N wa= ys to discover M services.
 
<= div>
 
 
From: Peter Saint-Andre <stpeter@stpeter.im>
To: William Mills <wmills@yahoo-inc.com>
Cc: Paul E. Jones <paulej@packe= tizer.com>; 'Cyrus Daboo' <cyrus@= daboo.name>; "apps-discuss= @ietf.org" <apps-discuss@ietf.org>
Sent: Wedne= sday, June 13, 2012 3:57 PM
Subject: Re: [apps-discuss] Aggregate= d service discovery
<= div class=3D"yiv1454295026MsoNormal" style=3D"margin-bottom:12.0pt;backgrou= nd:white;">
On 6/13/12 4:54 PM, William Mil= ls wrote:
> As I said, I'm interested specifically in IMAP, SMTP and = OAuth endpoints.

What exactly is an "endpoint"? A client? An accoun= t? A server?

> As a data point, DNS SRV records are not controlla= ble in many hosted
> domain models.

At the last XMPP Summit a = few months ago, we learned that DNS SRV
records are unavailable in whole= countries (e.g., Japan). That doesn't
mean we should define a replaceme= nt for DNS over HTTP. :)

Peter

--
Peter Saint-Andre
https://st= peter.im/





=


--1458549034-117279552-1340040987=:3036-- From paulej@packetizer.com Mon Jun 18 11:23: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 5660921F84F0 for ; Mon, 18 Jun 2012 11:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZjejUQTcfwA for ; Mon, 18 Jun 2012 11:22:59 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7263921F84E7 for ; Mon, 18 Jun 2012 11:22:59 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5IIMuHF002805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Jun 2012 14:22:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340043777; bh=s5lei3NN3dmXwFzTPAcnbniOfQ8PSLRY43B+Z/vSa8I=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=FF0MAhXE4LbEp70aSGhcFQIifVaoAWtbecmACHRL6CIxLyn4h/bAf1sEsjYEeXC1Z nf4U2aSunjr11UQCaHOUeXsm8+lT2fKprDxQohSrL0d+U7G52D5LV7SiLc2LEhvPaQ lVbFN83ysWxIh1hLRGhXdZh6gpCqsN7le1M/4cVw= From: "Paul E. Jones" To: "'William Mills'" , "'Peter Saint-Andre'" References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> In-Reply-To: <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Mon, 18 Jun 2012 14:22:59 -0400 Message-ID: <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0229_01CD4D5D.DD3DE210" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNYFRdarpUA3Z9l4mSBSKHTly568wGsYWTHAiB/MPYCgTB6NAGRuS9TAZsphI0CgPvwiQHAzgIyAdRbPCqTbklo8A== Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 18:23:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0229_01CD4D5D.DD3DE210 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bill, =20 In the referenced draft below, I assume the = =E2=80=9Cgrant-types=E2=80=9D and =E2=80=9Ctoken-types=E2=80=9D should = be contained inside a =E2=80=9Cproperties=E2=80=9D? That is, I think = you want this: =20 { "subject" : "acct:carol@example.com", "links" : [ { "rel" : "oauth2-athorize", "href" : "http://login.example.com/oauth2/authorize" }, { "rel" : "oauth2-token", "href" : "https://login.example.com/oauth2/token", "properties" : { "grant-types" : "code password", "token-types" : "bearer" } } ] } =20 For auto-provisioning of email clients (which I understand was your = goal), we can either define one link relation that points to a separate = configuration document of some sort, or we define multiple link = relations. My previous example showed the single link relation and the = email below shows use of multiple. Both have pros and cons, but I tend = to favor using multiple link relations, since this allows one to = introduce new stuff without changing the one mail configuration file. = Also, it reduces the number of queries a mail client has to make to get = config information. =20 You indicate that IMAP already has a defined URI. Where is that = defined? I could not find it in the IANA link relations registry, so I = assume it=E2=80=99s really a URI defined in a spec somewhere. In any = case, we could use URIs for these things (rather than defining single = token link relation values and registering them). I have no preference, = but I would like an agreed approach to provisioning. I hate configuring = all the stuff manually on email clients. :-) =20 Paul =20 From: William Mills [mailto:wmills@yahoo-inc.com]=20 Sent: Monday, June 18, 2012 1:36 PM To: Paul E. Jones; 'Peter Saint-Andre' Cc: 'Cyrus Daboo'; apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery =20 Paul,=20 =20 Thanks for the reply on this. I do already have a separate doc for = registering the OAuth specific relations, = http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html =20 I don't think I like the thought of having to register a new link type = for every service, but that might be the right way. IMAP already has a = URI defined for example so if we use a more general link relation then = the URI scheme details the type. The tradeoff is whether you can look = for a specific link-type or if you have to scan list elements for the = URI type you need. =20 -bill =20 =20 _____ =20 From: Paul E. Jones To: 'William Mills' ; 'Peter Saint-Andre' = =20 Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org=20 Sent: Sunday, June 17, 2012 6:48 PM Subject: RE: [apps-discuss] Aggregated service discovery =20 Bill, =20 My apologies for the belated reply. I=E2=80=99ve been busy this week = and got rather behind on email. =20 I do not personally like using SRV records, either. SRV records could = work for smaller domains, but I=E2=80=99m not sure that they=E2=80=99re = the best solution for larger domains. Personally, I would prefer = putting users on specific servers or server clusters and SRV records = will not differentiate users.=20 =20 To use WebFinger to find one=E2=80=99s IMAP, SMTP, or POP server, we = could do as I suggested in my email. Now the question is what does one = query? Since these three services are email, I=E2=80=99d suggest we = query =E2=80=9Cmailto:paulej@packetizer.com=E2=80=9D. We could use = another URI scheme (e.g., =E2=80=9Cacct:=E2=80=9D), but mailto seems = most appropriate given that you=E2=80=99re seeking info about mail = services. =20 I provided an example earlier that would simply point to a config file = with server information. We could do this directly via WebFinger like = this: =20 GET /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com =20 This query would then return something like this: =20 { "subject" : "mailto:paulej@packetizer.com", "links" : [ { "rel" : "smtp-server", "properties" : { "host" : "smtp.packetizer.com ", "port" : "587", "login-required" : "yes", "transport" : "starttls" } }, { "rel" : "imap-server", "properties" : { "host" : "imap.packetizer.com ", "port" : "993", "transport" : "ssl" } } ] } =20 We would need to standardize the link relation values (smtp-server and = imap-server). We would also need to document what the various = properties would be. If you would like to create such a configuration = document based on WebFinger, I=E2=80=99d be happy to help out. In any = case, you can see that WebFinger would serve quite nicely for conveying = configuration information given a user=E2=80=99s email ID. =20 I=E2=80=99m not sure exactly what you would need for OAuth endpoints, = but I would suggest you make that a separate document since it is not = mail related. (At least I assume it=E2=80=99s not. Even if it were, = the mail server information and OAuth information are still different = animals.) =20 Paul =20 From: William Mills [mailto:wmills@yahoo-inc.com]=20 Sent: Wednesday, June 13, 2012 7:32 PM To: Peter Saint-Andre Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery =20 In my use case it's a service/server. =20 Not a terribly happy answer to say "DNS SRV records won't work for you, = and there is no other solution.". By the same token I could ask "Why do = we need Webfinger and host meta at all if we have DNS SRV records?". =20 If XMPP uses SRV records for discovery, that's fine. IMAP and outbound = SMTP services both lack a defined discovery method other than the = ubiquitous "service documentation". Is there a compelling reason to = pick DNS over WF for this? From the app developer point of view I don't = want to have N ways to discover M services. =20 -bill =20 =20 _____ =20 From: Peter Saint-Andre To: William Mills =20 Cc: Paul E. Jones ; 'Cyrus Daboo' = ; "apps-discuss@ietf.org" =20 Sent: Wednesday, June 13, 2012 3:57 PM Subject: Re: [apps-discuss] Aggregated service discovery On 6/13/12 4:54 PM, William Mills wrote: > As I said, I'm interested specifically in IMAP, SMTP and OAuth = endpoints.=20 What exactly is an "endpoint"? A client? An account? A server? > As a data point, DNS SRV records are not controllable in many hosted > domain models. At the last XMPP Summit a few months ago, we learned that DNS SRV records are unavailable in whole countries (e.g., Japan). That doesn't mean we should define a replacement for DNS over HTTP. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ =20 ------=_NextPart_000_0229_01CD4D5D.DD3DE210 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Bill,

 

In the referenced draft below, I assume the = =E2=80=9Cgrant-types=E2=80=9D and =E2=80=9Ctoken-types=E2=80=9D should = be contained inside a =E2=80=9Cproperties=E2=80=9D?=C2=A0 That is, I = think you want this:

 

{

=C2=A0 "subject" : = "acct:carol@example.com",

=C2=A0 "links" :

=C2=A0 [

=C2=A0=C2=A0=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : = "oauth2-athorize",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "href" : = "http://login.example.com/oauth2/authorize"

=C2=A0=C2=A0=C2=A0 },

=C2=A0=C2=A0=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : = "oauth2-token",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "href" : = "https://login.example.com/oauth2/token",

=

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"properties" = :

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = {

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"grant-types" : = "code password",

=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"token-types" : = "bearer"

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = }

=C2=A0=C2=A0=C2=A0 }

=C2=A0 ]

}

 

For auto-provisioning of email clients (which I understand was your = goal), we can either define one link relation that points to a separate = configuration document of some sort, or we define multiple link = relations.=C2=A0 My previous example showed the single link relation and = the email below shows use of multiple.=C2=A0 Both have pros and cons, = but I tend to favor using multiple link relations, since this allows one = to introduce new stuff without changing the one mail configuration = file.=C2=A0 Also, it reduces the number of queries a mail client has to = make to get config information.

 

You indicate that IMAP already has a defined URI.=C2=A0 Where is that = defined?=C2=A0 I could not find it in the IANA link relations registry, = so I assume it=E2=80=99s really a URI defined in a spec somewhere.=C2=A0 = In any case, we could use URIs for these things (rather than defining = single token link relation values and registering them).=C2=A0 I have no = preference, but I would like an agreed approach to provisioning.=C2=A0 I = hate configuring all the stuff manually on email clients. = :-)

 

Paul

 

From:= = William Mills [mailto:wmills@yahoo-inc.com]
Sent: Monday, = June 18, 2012 1:36 PM
To: Paul E. Jones; 'Peter = Saint-Andre'
Cc: 'Cyrus Daboo'; = apps-discuss@ietf.org
Subject: Re: [apps-discuss] Aggregated = service discovery

 

Paul, =

 

Thanks = for the reply on this.  I do already have a separate doc for = registering the OAuth specific relations, http://= tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html

 

I don't = think I like the thought of having to register a new link type for every = service, but that might be the right way.  IMAP already has a URI = defined for example so if we use a more general link relation then the = URI scheme details the type.  The tradeoff is whether you can look = for a specific link-type or if you have to scan list elements for the = URI type you need.

 

-bill

 

 

<= hr size=3D1 width=3D"100%" align=3Dcenter>

F= rom: = Paul E. Jones <paulej@packetizer.com>
To: 'William Mills' <wmills@yahoo-inc.com>; = 'Peter Saint-Andre' <stpeter@stpeter.im> =
Cc: 'Cyrus Daboo' <cyrus@daboo.name>; apps-discuss@ietf.org =
Sent: Sunday, June 17, 2012 6:48 PM
Subject: RE: = [apps-discuss] Aggregated service discovery

 

Bill,

 

My apologies for the belated reply.  I=E2=80=99ve been busy this = week and got rather behind on email.

 

I do not personally like using SRV records, either.  SRV records = could work for smaller domains, but I=E2=80=99m not sure that = they=E2=80=99re the best solution for larger domains.  Personally, = I would prefer putting users on specific servers or server clusters and = SRV records will not differentiate users.

 

To use WebFinger to find one=E2=80=99s IMAP, SMTP, or POP server, we = could do as I suggested in my email.  Now the question is what does = one query?  Since these three services are email, I=E2=80=99d = suggest we query =E2=80=9Cmailto:paulej@packetizer.com=E2= =80=9D.  We could use another URI scheme (e.g., = =E2=80=9Cacct:=E2=80=9D), but mailto seems most appropriate given that = you=E2=80=99re seeking info about mail services.

 

I provided an example earlier that would simply point to a config file = with server information.  We could do this directly via WebFinger = like this:

 

GET = /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com

 

This query would then return something like this:

 

{

  "subject" : "mailto:paulej@packetizer.com&qu= ot;,

  "links" :

  [

    {

      = "rel" : "smtp-server",

      = "properties" :

      {

        = "host" : "smtp.packetizer.com",

        = "port" : "587",

        = "login-required" : "yes",

        = "transport" : "starttls"

      }

    },

    {

      = "rel" : "imap-server",

      = "properties" :

      {

        = "host" : "imap.packetizer.com",

        = "port" : "993",

        = "transport" : "ssl"

      }

    }

  ]

}

 

We would need to standardize the link relation values (smtp-server and = imap-server).  We would also need to document what the various = properties would be.  If you would like to create such a = configuration document based on WebFinger, I=E2=80=99d be happy to help = out.  In any case, you can see that WebFinger would serve quite = nicely for conveying configuration information given a user=E2=80=99s = email ID.

 

I=E2=80=99m not sure exactly what you would need for OAuth endpoints, = but I would suggest you make that a separate document since it is not = mail related.  (At least I assume it=E2=80=99s not.  Even if = it were, the mail server information and OAuth information are still = different animals.)

 

Paul

 

F= rom: = William Mills [mailto:wmills@yahoo-inc.co= m]
Sent: Wednesday, June 13, 2012 7:32 PM
To: = Peter Saint-Andre
Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] Aggregated service discovery

 

In my = use case it's a service/server.

 

Not a = terribly happy answer to say "DNS SRV records won't work for you, = and there is no other solution.".  By the same token I could = ask "Why do we need Webfinger and host meta at all if we have DNS = SRV records?".

 

If XMPP = uses SRV records for discovery, that's fine.  IMAP and outbound = SMTP services both lack a defined discovery method other than the = ubiquitous "service documentation".  Is there a = compelling reason to pick DNS over WF for this?  From the app = developer point of view I don't want to have N ways to discover M = services.

 

-bill

 

 

<= hr size=3D1 width=3D"100%" align=3Dcenter>

F= rom: = Peter Saint-Andre <stpeter@stpeter.im>
To: William Mills = <wmills@yahoo-inc.com>
Cc: Paul E. = Jones <paulej@packetizer.com>; 'Cyrus Daboo' <cyrus@daboo.name>; "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Sent: = Wednesday, June 13, 2012 3:57 PM
Subject: Re: [apps-discuss] = Aggregated service discovery


On 6/13/12 4:54 PM, William Mills = wrote:
> As I said, I'm interested specifically in IMAP, SMTP and = OAuth endpoints.

What exactly is an "endpoint"? A = client? An account? A server?

> As a data point, DNS SRV = records are not controllable in many hosted
> domain = models.

At the last XMPP Summit a few months ago, we learned that = DNS SRV
records are unavailable in whole countries (e.g., Japan). = That doesn't
mean we should define a replacement for DNS over HTTP. = :)

Peter

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




<= /span>

 

------=_NextPart_000_0229_01CD4D5D.DD3DE210-- From ve7jtb@ve7jtb.com Mon Jun 18 11:36: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 81D6121F85A4 for ; Mon, 18 Jun 2012 11:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 3L0QlRAB5xdk for ; Mon, 18 Jun 2012 11:36:47 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAAF21F85AD for ; Mon, 18 Jun 2012 11:36:47 -0700 (PDT) Received: by yenq13 with SMTP id q13so4473965yen.31 for ; Mon, 18 Jun 2012 11:36:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=lCQT1NfKLxyVYmOgb3Wbtm51E0+W9EGNNiwFkb7mHdM=; b=hMgLIYoUTtq81A2XAQ8HEhPO1jeYOT6WIZlWmmThjPhzKGLC8BgVNllaz4XK43i6UZ jCmU/vzca/JSF+/om3qVza2jnqXpmsnZgrfywJK6HsPxDcaYO1uIz8nyLWBpHFFXjG+y yqJ0yujRnb/Wils+QknBtYOFk9rO7+dWtfhwh8+fL2rnbNHWiaVhA+trqTcF9dPEdA/v C7WXkkU+HNMsVGtCcaHL/KdKdY9cf/IK9OoYshyf8o6IxVRvngNlmIXvRCboFB5l6IAC nNFvhWRNMOeCey6xyk3eG+IxhlPw64kuPm4OlCndzU0s0IBttouB8xhyaZK4MJWzc9IP euaQ== Received: by 10.236.109.225 with SMTP id s61mr19974705yhg.5.1340044607033; Mon, 18 Jun 2012 11:36:47 -0700 (PDT) Received: from [192.168.1.213] (190-20-29-46.baf.movistar.cl. [190.20.29.46]) by mx.google.com with ESMTPS id y10sm67591722yha.4.2012.06.18.11.36.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jun 2012 11:36:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_98023D2C-26DC-49EE-B85F-193F41ADD55C"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> Date: Mon, 18 Jun 2012 14:36:22 -0400 Message-Id: References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmShXzwmbs3cdyWOBrGp03ySmTfZmGdljvFJnphbGPsWPFl/gDw3pOyzAlKT1ygKZqJQ7r0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 18:36:49 -0000 --Apple-Mail=_98023D2C-26DC-49EE-B85F-193F41ADD55C Content-Type: multipart/alternative; boundary="Apple-Mail=_6712A44E-5C69-432E-814C-71894D19A36E" --Apple-Mail=_6712A44E-5C69-432E-814C-71894D19A36E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 A user is likely to have a number of OAuth authorization services for = different things. =20 I suspect that the best way to organize it is to describe the services = the user has: openID Connect imap portable contacts etc and let the service describe how it is authenticated and where the = endpoints are. For Connect there is a single relation for the Connect issuer and that = is then discovered to get the endpoint and other configuration = information. =20 Given that user identifiers may point to services in other domains it is = best to leave it up to the service to describe itself rather than = relying on individual user information to be correct. John B. On 2012-06-18, at 2:22 PM, Paul E. Jones wrote: > Bill, > =20 > In the referenced draft below, I assume the =93grant-types=94 and = =93token-types=94 should be contained inside a =93properties=94? That = is, I think you want this: > =20 > { > "subject" : "acct:carol@example.com", > "links" : > [ > { > "rel" : "oauth2-athorize", > "href" : "http://login.example.com/oauth2/authorize" > }, > { > "rel" : "oauth2-token", > "href" : "https://login.example.com/oauth2/token", > "properties" : > { > "grant-types" : "code password", > "token-types" : "bearer" > } > } > ] > } > =20 > For auto-provisioning of email clients (which I understand was your = goal), we can either define one link relation that points to a separate = configuration document of some sort, or we define multiple link = relations. My previous example showed the single link relation and the = email below shows use of multiple. Both have pros and cons, but I tend = to favor using multiple link relations, since this allows one to = introduce new stuff without changing the one mail configuration file. = Also, it reduces the number of queries a mail client has to make to get = config information. > =20 > You indicate that IMAP already has a defined URI. Where is that = defined? I could not find it in the IANA link relations registry, so I = assume it=92s really a URI defined in a spec somewhere. In any case, we = could use URIs for these things (rather than defining single token link = relation values and registering them). I have no preference, but I = would like an agreed approach to provisioning. I hate configuring all = the stuff manually on email clients. :-) > =20 > Paul > =20 > From: William Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Monday, June 18, 2012 1:36 PM > To: Paul E. Jones; 'Peter Saint-Andre' > Cc: 'Cyrus Daboo'; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Aggregated service discovery > =20 > Paul, > =20 > Thanks for the reply on this. I do already have a separate doc for = registering the OAuth specific = relations,http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html > =20 > I don't think I like the thought of having to register a new link type = for every service, but that might be the right way. IMAP already has a = URI defined for example so if we use a more general link relation then = the URI scheme details the type. The tradeoff is whether you can look = for a specific link-type or if you have to scan list elements for the = URI type you need. > =20 > -bill > =20 > =20 > From: Paul E. Jones > To: 'William Mills' ; 'Peter Saint-Andre' = =20 > Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org=20 > Sent: Sunday, June 17, 2012 6:48 PM > Subject: RE: [apps-discuss] Aggregated service discovery > =20 > Bill, > =20 > My apologies for the belated reply. I=92ve been busy this week and = got rather behind on email. > =20 > I do not personally like using SRV records, either. SRV records could = work for smaller domains, but I=92m not sure that they=92re the best = solution for larger domains. Personally, I would prefer putting users = on specific servers or server clusters and SRV records will not = differentiate users. > =20 > To use WebFinger to find one=92s IMAP, SMTP, or POP server, we could = do as I suggested in my email. Now the question is what does one query? = Since these three services are email, I=92d suggest we query = =93mailto:paulej@packetizer.com=94. We could use another URI scheme = (e.g., =93acct:=94), but mailto seems most appropriate given that you=92re= seeking info about mail services. > =20 > I provided an example earlier that would simply point to a config file = with server information. We could do this directly via WebFinger like = this: > =20 > GET /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com > =20 > This query would then return something like this: > =20 > { > "subject" : "mailto:paulej@packetizer.com", > "links" : > [ > { > "rel" : "smtp-server", > "properties" : > { > "host" : "smtp.packetizer.com", > "port" : "587", > "login-required" : "yes", > "transport" : "starttls" > } > }, > { > "rel" : "imap-server", > "properties" : > { > "host" : "imap.packetizer.com", > "port" : "993", > "transport" : "ssl" > } > } > ] > } > =20 > We would need to standardize the link relation values (smtp-server and = imap-server). We would also need to document what the various = properties would be. If you would like to create such a configuration = document based on WebFinger, I=92d be happy to help out. In any case, = you can see that WebFinger would serve quite nicely for conveying = configuration information given a user=92s email ID. > =20 > I=92m not sure exactly what you would need for OAuth endpoints, but I = would suggest you make that a separate document since it is not mail = related. (At least I assume it=92s not. Even if it were, the mail = server information and OAuth information are still different animals.) > =20 > Paul > =20 > From: William Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Wednesday, June 13, 2012 7:32 PM > To: Peter Saint-Andre > Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Aggregated service discovery > =20 > In my use case it's a service/server. > =20 > Not a terribly happy answer to say "DNS SRV records won't work for = you, and there is no other solution.". By the same token I could ask = "Why do we need Webfinger and host meta at all if we have DNS SRV = records?". > =20 > If XMPP uses SRV records for discovery, that's fine. IMAP and = outbound SMTP services both lack a defined discovery method other than = the ubiquitous "service documentation". Is there a compelling reason to = pick DNS over WF for this? =46rom the app developer point of view I = don't want to have N ways to discover M services. > =20 > -bill > =20 > =20 > From: Peter Saint-Andre > To: William Mills =20 > Cc: Paul E. Jones ; 'Cyrus Daboo' = ; "apps-discuss@ietf.org" =20 > Sent: Wednesday, June 13, 2012 3:57 PM > Subject: Re: [apps-discuss] Aggregated service discovery >=20 > On 6/13/12 4:54 PM, William Mills wrote: > > As I said, I'm interested specifically in IMAP, SMTP and OAuth = endpoints.=20 >=20 > What exactly is an "endpoint"? A client? An account? A server? >=20 > > As a data point, DNS SRV records are not controllable in many hosted > > domain models. >=20 > At the last XMPP Summit a few months ago, we learned that DNS SRV > records are unavailable in whole countries (e.g., Japan). That doesn't > mean we should define a replacement for DNS over HTTP. :) >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 >=20 >=20 > =20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_6712A44E-5C69-432E-814C-71894D19A36E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 A user is likely to have a number of OAuth = authorization services for different things.  

I = suspect that the best way to organize it is to describe the services the = user has:
openID Connect
imap
portable = contacts
etc

and let the service = describe how it is authenticated and where the endpoints = are.

For Connect there is a single relation for = the Connect issuer and that is then discovered to get the endpoint and = other configuration information.  
Given that user = identifiers may point to services in other domains it is best to leave = it up to the service to describe itself rather than relying on = individual user information to be correct.

John = B.

On 2012-06-18, at 2:22 PM, Paul E. Jones = wrote:

In = the referenced draft below, I assume the =93grant-types=94 and = =93token-types=94 should be contained inside a =93properties=94?  = That is, I think you want this:
  "subject" = : "acct:carol@example.com",
  "links" = :
  = [
      "rel" : = "oauth2-athorize",
    = },
      "rel" : = "oauth2-token",
   =      "token-types" : = "bearer"
    = }
  = ]
For = auto-provisioning of email clients (which I understand was your goal), = we can either define one link relation that points to a separate = configuration document of some sort, or we define multiple link = relations.  My previous example showed the single link relation and = the email below shows use of multiple.  Both have pros and cons, = but I tend to favor using multiple link relations, since this allows one = to introduce new stuff without changing the one mail configuration = file.  Also, it reduces the number of queries a mail client has to = make to get config information.
You = indicate that IMAP already has a defined URI.  Where is that = defined?  I could not find it in the IANA link relations registry, = so I assume it=92s really a URI defined in a spec somewhere.  In = any case, we could use URIs for these things (rather than defining = single token link relation values and registering them).  I have no = preference, but I would like an agreed approach to provisioning.  I = hate configuring all the stuff manually on email clients. = :-)
 William = Mills [mailto:wmills@yahoo-inc.com] 
Sent: Monday, June 18, 2012 1:36 = PM
To: Paul = E. Jones; 'Peter Saint-Andre'
Cc: 'Cyrus Daboo'; apps-discuss@ietf.org
Subj= ect: Re: = [apps-discuss] Aggregated service = discovery
From: Paul E. Jones = < 'William Mills' <wmills@yahoo-inc.com>; 'Peter = Saint-Andre' <stpeter@stpeter.im> 
Cc: 'Cyrus Daboo' <cyrus@daboo.name>; apps-discuss@ietf.org 
Sent: Sunday, June 17, 2012 6:48 = PM
Subject: RE: [apps-discuss] = Aggregated service discovery 
Bill, My apologies for the belated reply.  I=92ve been busy = this week and got rather behind on email.
 I do not personally like using SRV records, either.  = SRV records could work for smaller domains, but I=92m not sure that = they=92re the best solution for larger domains.  Personally, I = would prefer putting users on specific servers or server clusters and = SRV records will not differentiate users.
 To use WebFinger to find one=92s IMAP, SMTP, or POP server, = we could do as I suggested in my email.  Now the question is what = does one query?  Since these three services are email, I=92d = suggest we query =93
 We would need to standardize the link relation values = (smtp-server and imap-server).  We would also need to document what = the various properties would be.  If you would like to create such = a configuration document based on WebFinger, I=92d be happy to help = out.  In any case, you can see that WebFinger would serve quite = nicely for conveying configuration information given a user=92s email = ID. I=92m not sure exactly what you would need for OAuth = endpoints, but I would suggest you make that a separate document since = it is not mail related.  (At least I assume it=92s not.  Even = if it were, the mail server information and OAuth information are still = different animals.) Paul 
From: William Mills [mailto:wmills@yahoo-inc.com] 
Sent: Wednesday, June 13, 2012 = 7:32 PM
To: Peter = Saint-Andre
Cc: Paul E. Jones; 'Cyrus = Daboo';  Re: [apps-discuss] = Aggregated service discoveryIn my use case it's a = service/server. Not a terribly happy answer to say "DNS SRV records = won't work for you, and there is no other solution.".  By the same = token I could ask "Why do we need Webfinger and host meta at all if we = have DNS SRV records?". If XMPP uses SRV records for discovery, that's = fine.  IMAP and outbound SMTP services both lack a defined = discovery method other than the ubiquitous "service = documentation".  Is there a compelling reason to pick DNS over WF = for this?  =46rom the app developer point of view I don't want to = have N ways to discover M services. -bill 
From: Peter Saint-Andre = < William Mills <wmills@yahoo-inc.com> 
Cc: Paul E. Jones <paulej@packetizer.com>; = 'Cyrus Daboo' < 
Sent: Wednesday, June 13, 2012 = 3:57 PM
Subject: Re: [apps-discuss] = Aggregated service discovery
On 6/13/12 4:54 PM, William Mills = wrote:
> As I said, I'm interested specifically in IMAP, SMTP and = OAuth endpoints. 

What exactly is an = "endpoint"? A client? An account? A server?

> As a data point, = DNS SRV records are not controllable in many hosted
> domain = models.

At the last XMPP Summit a few months ago, we learned that = DNS SRV
records are unavailable in whole countries (e.g., Japan). = That doesn't
mean we should define a replacement for DNS over HTTP. = :)

Peter

-- 
Peter Saint-Andre
apps-discuss@ietf.org
https:/= /www.ietf.org/mailman/listinfo/apps-discuss

= --Apple-Mail=_6712A44E-5C69-432E-814C-71894D19A36E-- --Apple-Mail=_98023D2C-26DC-49EE-B85F-193F41ADD55C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYx ODE4MzYyMlowIwYJKoZIhvcNAQkEMRYEFOPEQ8dIV59HuNuoqUAOIPfBBelqMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACFXZuB3jUQLJSTrQZl0zr5kYGbd3i/baGjQVhbPbMVLE1jxp+iYIW7HQpbbvgVe84nzLKn5Ytc4 8BBZ63pSJv3PCl0SSxYexxnmqmbRf8KVgBA0I+oDrQwDcVSIglLbSFrms2UD67Mu3ih7S9MDjmru WN9HJnSSpIe5uxY7YYygh2HlekOKOO4xnu2GpGykh+yoaiE0jXpQSu9DbBGJ7zstl7IJu5zhCg2A gZuFputLNQYPgdMmh4K6f0NlmLvKcKu7HaLs/DgO+rtgyiRc12uuVMKNLYghn45tjPJ0qeb4fvEq tJdjT+6gpDPDu1Z1tOvu+hLMQb1Pn1fDz2XVtokAAAAAAAA= --Apple-Mail=_98023D2C-26DC-49EE-B85F-193F41ADD55C-- From wmills@yahoo-inc.com Mon Jun 18 12:15: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 2272421F86F5 for ; Mon, 18 Jun 2012 12:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.528 X-Spam-Level: X-Spam-Status: No, score=-17.528 tagged_above=-999 required=5 tests=[AWL=0.070, 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 oRPbqWAA5OoP for ; Mon, 18 Jun 2012 12:15:26 -0700 (PDT) Received: from nm24-vm0.bullet.mail.sp2.yahoo.com (nm24-vm0.bullet.mail.sp2.yahoo.com [98.139.91.226]) by ietfa.amsl.com (Postfix) with SMTP id 71E3421F86EE for ; Mon, 18 Jun 2012 12:15:26 -0700 (PDT) Received: from [98.139.91.62] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 18 Jun 2012 19:15:24 -0000 Received: from [98.139.91.56] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 18 Jun 2012 19:15:24 -0000 Received: from [127.0.0.1] by omp1056.mail.sp2.yahoo.com with NNFMP; 18 Jun 2012 19:15:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 734066.71256.bm@omp1056.mail.sp2.yahoo.com Received: (qmail 34653 invoked by uid 60001); 18 Jun 2012 19:15:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1340046923; bh=WcuiGZltiMrl3bZLfadfVjXKMXrrOmQkAxHU9so9drc=; 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=QbU0QpVZS12OG6/3z3ikkeNOGJtat+C0/8cCDEs9bgdKD5WnzR5JIVa5NPjr3liMFb8S4wsxD0bcXdoHbkcYv7tDH53TO7qNLwmabTg5h2DecZbFiCJpN+/qCzvzzbNKbm6d5qLM1jTxjv2wdwlrbNh8NVcDE40l35nmj/fITo4= 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=mUrlpHB3Cq2A07w2mU+qjJByBS4ztrNyBvEtCPKmUEd0JLFpRfK/qfQZd1Wsrm6TAAPHXm1OII18XPvuha4FPFfgVBB/d712YwqRLjnyXmlxD+xH1WqwU7ldjtqmLjVGAMCO3cN7d1GuFGbFKvfgGCbTnDdFoBWFMmeRoafH6i4=; X-YMail-OSG: VZNs4UYVM1mb_w23M1Fr.3EOSPgjKNt78dvjZTVNis0wmpt H9nCS3iELezzW8s34IE2YtkEioh_TT7CHngWX1qTwv0.WJBBqlCYsSFBmpGu 67o9Q8wM6iB6HCCETP5snj4WYiRhIJatSjob6IU7iAWZFgSQJSkqa0A8hbya Gj_Jjj45MmqyxeJe1g4NL.EmCpWMq4MDnQfudPxyqNZTbNy1o16wgBsgYraR oqBiuA8qLbw5J7B_Z6.HatpWEEEH2fnZD5WrRkKhn8A2fV4Sj9TPNtkMRrgq ovPvSld_N216c1hTck7fd8Wrs_Bnod6V7X.XhhZD02bnjWifRc3DXU1MsJcI nj6HGQM55Cd8jeZvfEf6E06.D5Hp2fB6OOop_1uXFujb.pvtEV2qmx_q1Zoh sQoApgJQDTesaukda4uYK6irQ3CSMPDANsUKioO97quQzW1RvdutrS_0dgwR 5Y8338XO.FcPcNXMSh0ZXV_wVa5ALQTpsFwEoUpZZp5oqCyBHMvVZafn6prQ PNq8eDG0z1HbC7vvWz.yY6me88w9IKvhVrPEjyZCe6zoRiN6XcffQToZYAUz .jJBCa87J8RPPxLB77VzQNF2ZxztYkN66IPYqgX_eb7eL.os30vrZSXHKir4 hAmpvB50KqGgZTqbVv3pV5LQNaFyE_pP6oTbtI7CDX5BiAuFEbvnetkofKqI Wk9wJmUtwd5skoQ.3UCc- Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Mon, 18 Jun 2012 12:15:23 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> Message-ID: <1340046923.34140.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Mon, 18 Jun 2012 12:15:23 -0700 (PDT) From: William Mills To: "Paul E. Jones" , 'Peter Saint-Andre' In-Reply-To: <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-175639555-1340046923=:34140" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery 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, 18 Jun 2012 19:15:28 -0000 ---1055047407-175639555-1340046923=:34140 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ah, I missed that nuance, that declared application data goes in "propertie= s".=0A=0AThe "imap" scheme is listed in http://www.iana.org/assignments/uri= -schemes.html and defined in http://www.rfc-editor.org/rfc/rfc5092.txt=0A= =0AI've been inquiring about the "related" link relation type, which seems = semantically what we want at first glance.=C2=A0 It's not clear to me that = you can define a link relation that does not have a uri?=C2=A0 That has onl= y application data?=C2=A0 I don't think it's right to extend link relations= to be an arbitrary data container, but requiring a URI scheme is going to = be a lot of work for some things.=C2=A0 SMTP is the hard one right now, a h= ack for that might be a new relation and just put the postmaster mailto: li= nk in the URI spot.=C2=A0 =0A=0A=0AI'm not inclined to try to encode arbitr= ary flags like login-required, I'd probably go as far as a well known servi= ce name and leave it there.=0A=0A-bill=0A=0A=0A=0A=0A>_____________________= ___________=0A> From: Paul E. Jones =0A>To: 'William= Mills' ; 'Peter Saint-Andre' = =0A>Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org =0A>Sent: M= onday, June 18, 2012 11:22 AM=0A>Subject: RE: [apps-discuss] Aggregated ser= vice discovery=0A> =0A>=0A>Bill,=0A>=C2=A0=0A>In the referenced draft below= , I assume the =E2=80=9Cgrant-types=E2=80=9D and =E2=80=9Ctoken-types=E2=80= =9D should be contained inside a =E2=80=9Cproperties=E2=80=9D?=C2=A0 That i= s, I think you want this:=0A>=C2=A0=0A>{=0A>=C2=A0 "subject" : "acct:carol@= example.com",=0A>=C2=A0 "links" :=0A>=C2=A0 [=0A>=C2=A0=C2=A0=C2=A0 {=0A>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : "oauth2-athorize",=0A>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "href" : "http://login.example.com/oauth2/authorize"=0A>= =C2=A0=C2=A0=C2=A0 },=0A>=C2=A0=C2=A0=C2=A0 {=0A>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "rel" : "oauth2-token",=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "href" : "= https://login.example.com/oauth2/token",=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"= properties" :=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=0A>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0"grant-types" : "code password",=0A>=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0"token-types" : "bearer"=0A>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 }=0A>=C2=A0=C2=A0=C2=A0 }=0A>=C2=A0 ]=0A>}=0A>=C2=A0=0A>For au= to-provisioning of email clients (which I understand was your goal), we can= either define one link relation that points to a separate configuration do= cument of some sort, or we define multiple link relations.=C2=A0 My previou= s example showed the single link relation and the email below shows use of = multiple.=C2=A0 Both have pros and cons, but I tend to favor using multiple= link relations, since this allows one to introduce new stuff without chang= ing the one mail configuration file.=C2=A0 Also, it reduces the number of q= ueries a mail client has to make to get config information.=0A>=C2=A0=0A>Yo= u indicate that IMAP already has a defined URI.=C2=A0 Where is that defined= ?=C2=A0 I could not find it in the IANA link relations registry, so I assum= e it=E2=80=99s really a URI defined in a spec somewhere.=C2=A0 In any case,= we could use URIs for these things (rather than defining single token link= relation values and registering them).=C2=A0 I have no preference, but I w= ould like an agreed approach to provisioning.=C2=A0 I hate configuring all = the stuff manually on email clients. :-)=0A>=C2=A0=0A>Paul=0A>=C2=A0=0A>Fro= m:William Mills [mailto:wmills@yahoo-inc.com] =0A>Sent: Monday, June 18, 20= 12 1:36 PM=0A>To: Paul E. Jones; 'Peter Saint-Andre'=0A>Cc: 'Cyrus Daboo'; = apps-discuss@ietf.org=0A>Subject: Re: [apps-discuss] Aggregated service dis= covery=0A>=C2=A0=0A>Paul, =0A>=C2=A0=0A>Thanks for the reply on this.=C2=A0= I do already have a separate doc for registering the OAuth specific relati= ons, http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html=0A>=C2=A0=0A>= I don't think I like the thought of having to register a new link type for = every service, but that might be the right way.=C2=A0 IMAP already has a UR= I defined for example so if we use a more general link relation then the UR= I scheme details the type.=C2=A0 The tradeoff is whether you can look for a= specific link-type or if you have to scan list elements for the URI type y= ou need.=0A>=C2=A0=0A>-bill=0A>=C2=A0=0A>=C2=A0=0A>>=0A>>__________________= ______________=0A>>=0A>>From:Paul E. Jones =0A>>To: = 'William Mills' ; 'Peter Saint-Andre' =0A>>Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org =0A>= >Sent: Sunday, June 17, 2012 6:48 PM=0A>>Subject: RE: [apps-discuss] Aggreg= ated service discovery=0A>>=C2=A0=0A>>Bill,=0A>>=C2=A0=0A>>My apologies for= the belated reply.=C2=A0 I=E2=80=99ve been busy this week and got rather b= ehind on email.=0A>>=C2=A0=0A>>I do not personally like using SRV records, = either.=C2=A0 SRV records could work for smaller domains, but I=E2=80=99m n= ot sure that they=E2=80=99re the best solution for larger domains.=C2=A0 Pe= rsonally, I would prefer putting users on specific servers or server cluste= rs and SRV records will not differentiate users. =0A>>=C2=A0=0A>>To use Web= Finger to find one=E2=80=99s IMAP, SMTP, or POP server, we could do as I su= ggested in my email.=C2=A0 Now the question is what does one query?=C2=A0 S= ince these three services are email, I=E2=80=99d suggest we query =E2=80=9C= mailto:paulej@packetizer.com=E2=80=9D.=C2=A0 We could use another URI schem= e (e.g., =E2=80=9Cacct:=E2=80=9D), but mailto seems most appropriate given = that you=E2=80=99re seeking info about mail services.=0A>>=C2=A0=0A>>I prov= ided an example earlier that would simply point to a config file with serve= r information.=C2=A0 We could do this directly via WebFinger like this:=0A>= >=C2=A0=0A>>GET /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.= com=0A>>=C2=A0=0A>>This query would then return something like this:=0A>>= =C2=A0=0A>>{=0A>>=C2=A0 "subject" : "mailto:paulej@packetizer.com",=0A>>=C2= =A0 "links" :=0A>>=C2=A0 [=0A>>=C2=A0=C2=A0=C2=A0 {=0A>>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 "rel" : "smtp-server",=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "pro= perties" :=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=0A>>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "host" : "smtp.packetizer.com",=0A>>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 "port" : "587",=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "login-required" : "yes",=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "transport" : "starttls"=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= }=0A>>=C2=A0=C2=A0=C2=A0 },=0A>>=C2=A0=C2=A0=C2=A0 {=0A>>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "rel" : "imap-server",=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "= properties" :=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=0A>>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 "host" : "imap.packetizer.com",=0A>>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "port" : "993",=0A>>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "transport" : "ssl"=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }= =0A>>=C2=A0=C2=A0=C2=A0 }=0A>>=C2=A0 ]=0A>>}=0A>>=C2=A0=0A>>We would need t= o standardize the link relation values (smtp-server and imap-server).=C2=A0= We would also need to document what the various properties would be.=C2=A0= If you would like to create such a configuration document based on WebFing= er, I=E2=80=99d be happy to help out.=C2=A0 In any case, you can see that W= ebFinger would serve quite nicely for conveying configuration information g= iven a user=E2=80=99s email ID.=0A>>=C2=A0=0A>>I=E2=80=99m not sure exactly= what you would need for OAuth endpoints, but I would suggest you make that= a separate document since it is not mail related.=C2=A0 (At least I assume= it=E2=80=99s not.=C2=A0 Even if it were, the mail server information and O= Auth information are still different animals.)=0A>>=C2=A0=0A>>Paul=0A>>=C2= =A0=0A>>From:William Mills [mailto:wmills@yahoo-inc.com] =0A>>Sent: Wednesd= ay, June 13, 2012 7:32 PM=0A>>To: Peter Saint-Andre=0A>>Cc: Paul E. Jones; = 'Cyrus Daboo'; apps-discuss@ietf.org=0A>>Subject: Re: [apps-discuss] Aggreg= ated service discovery=0A>>=C2=A0=0A>>In my use case it's a service/server.= =0A>>=C2=A0=0A>>Not a terribly happy answer to say "DNS SRV records won't w= ork for you, and there is no other solution.".=C2=A0 By the same token I co= uld ask "Why do we need Webfinger and host meta at all if we have DNS SRV r= ecords?".=0A>>=C2=A0=0A>>If XMPP uses SRV records for discovery, that's fin= e.=C2=A0 IMAP and outbound SMTP services both lack a defined discovery meth= od other than the ubiquitous "service documentation".=C2=A0 Is there a comp= elling reason to pick DNS over WF for this?=C2=A0 From the app developer po= int of view I don't want to have N ways to discover M services.=0A>>=C2=A0= =0A>>-bill=0A>>=C2=A0=0A>>=C2=A0=0A>>>=0A>>>_______________________________= _=0A>>>=0A>>>From:Peter Saint-Andre =0A>>>To: William M= ills =0A>>>Cc: Paul E. Jones = ; 'Cyrus Daboo' ; "apps-discuss@ietf.org" =0A>>>Sent: Wednesday, June 13, 2012 3:57 PM=0A>>>Subject: Re: [ap= ps-discuss] Aggregated service discovery=0A>>>=0A>>>On 6/13/12 4:54 PM, Wil= liam Mills wrote:=0A>>>> As I said, I'm interested specifically in IMAP, SM= TP and OAuth endpoints. =0A>>>=0A>>>What exactly is an "endpoint"? A client= ? An account? A server?=0A>>>=0A>>>> As a data point, DNS SRV records are n= ot controllable in many hosted=0A>>>> domain models.=0A>>>=0A>>>At the last= XMPP Summit a few months ago, we learned that DNS SRV=0A>>>records are una= vailable in whole countries (e.g., Japan). That doesn't=0A>>>mean we should= define a replacement for DNS over HTTP. :)=0A>>>=0A>>>Peter=0A>>>=0A>>>-- = =0A>>>Peter Saint-Andre=0A>>>https://stpeter.im/=0A>>>=0A>>>=0A>>>=0A>>>=0A= >>>=0A>>=C2=A0=0A>=0A> ---1055047407-175639555-1340046923=:34140 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ah, I missed that nuance, that declared application data goes in "propert= ies".

The "imap" scheme = is listed in http://www.iana.org/assignments/uri-schemes.html and defined i= n http://www.rfc-editor.org/rfc/rfc5092.txt

I've been inquiring about the "related" link relation t= ype, which seems semantically what we want at first glance.  It's not = clear to me that you can define a link relation that does not have a uri?&n= bsp; That has only application data?  I don't think it's right to exte= nd link relations to be an arbitrary data container, but requiring a URI sc= heme is going to be a lot of work for some things.  SMTP is the hard o= ne right now, a hack for that might be a new relation and just put the postmaster mailto: link in the URI spot. 

<= span>
I'm not inclined to try to encode arbitrary fl= ags like login-required, I'd probably go as far as a well known service nam= e and leave it there.

-b= ill

From: Paul E. Jones <paulej@packetizer.com>
To: 'William Mills' <wmills@yahoo-inc.com>= ;; 'Peter Saint-Andre' <stpeter@stpeter.im>
Cc: 'Cyrus Daboo' <cyrus@daboo.name>; apps-discuss= @ietf.org
Sent: Monda= y, June 18, 2012 11:22 AM
Subject= : RE: [apps-discuss] Aggregated service discovery
=0A
=
Bill,
 
In = the referenced draft below, I assume the =E2=80=9Cgrant-types=E2=80=9D and = =E2=80=9Ctoken-types=E2=80=9D should be contained inside a =E2=80=9Cpropert= ies=E2=80=9D?  That is, I think you want this:
 
{
  "subject" : "acct:carol@example.com",
  "links" :
  [
    {
      "rel" : "oau= th2-athorize",
&= nbsp;     "href" : "http://login.example.com/oauth2/authorize"
    },
    {
      "r= el" : "oauth2-token",
      "href" : "https://login.example.com/oa= uth2/token",
&= nbsp;    "properties" :
      {=
  &n= bsp;    "grant-types" : "code password",
      = ;  "token-types" : "bearer"
      }
    }
  ]
}
 
For= auto-provisioning of email clients (which I understand was your goal), we = can either define one link relation that points to a separate configuration= document of some sort, or we define multiple link relations.  My prev= ious example showed the single link relation and the email below shows use = of multiple.  Both have pros and cons, but I tend to favor using multi= ple link relations, since this allows one to introduce new stuff without ch= anging the one mail configuration file.  Also, it reduces the number o= f queries a mail client has to make to get config information.
<= div class=3D"yiv1250163441MsoNormal">  
You indicate that IMAP already has a de= fined URI.  Where is that defined?  I could not find it in the IA= NA link relations registry, so I assume it=E2=80=99s really a URI defined i= n a spec somewhere.  In any case, we could use URIs for these things (= rather than defining single token link relation values and registering them= ).  I have no preference, but I would like an agreed approach to provi= sioning.  I hate configuring all the stuff manually on email clients. = :-)
 
Paul
 
=
From: William Mills [mailto:wmills@= yahoo-inc.com]
Sent: Monday, June 18, 2012 1:36 PM
To:= Paul E. Jones; 'Peter Saint-Andre'
Cc: 'Cyrus Daboo'; apps-discu= ss@ietf.org
Subject: Re: [apps-discuss] Aggregated service discov= ery
 
Paul,
 
=
Thanks for the reply on this.  I do already have a separate doc for= registering the OAuth specific relations, http://tools.ietf.org/id/draft-w= mills-oauth-lrdd-01.html
 
 
-bill=
 
 
From: Paul E. Jones <paulej@packetizer.com>
= To: 'William Mills' <wmills@= yahoo-inc.com>; 'Peter Saint-Andre' <stpeter@stpeter.im>
Cc: 'Cyrus Daboo' <cyrus@daboo.name>; apps-discuss@ietf.org
Sent: Sunday, June = 17, 2012 6:48 PM
Subject: RE: [apps-discuss] Aggregated service d= iscovery
 
Bill,
 <= /div>
My apologies for the belated reply.  I=E2=80=99ve been = busy this week and got rather behind on email.
 
I d= o not personally like using SRV records, either.  SRV records could wo= rk for smaller domains, but I=E2=80=99m not sure that they=E2=80=99re the b= est solution for larger domains.  Personally, I would prefer putting u= sers on specific servers or server clusters and SRV records will not differ= entiate users.
=
&= nbsp;
To use WebF= inger to find one=E2=80=99s IMAP, SMTP, or POP server, we could do as I sug= gested in my email.  Now the question is what does one query?  Since these three services are emai= l, I=E2=80=99d suggest we query =E2=80=9Cmailto:paulej@packetizer.com=E2=80=9D.  We could use anoth= er URI scheme (e.g., =E2=80=9Cacct:=E2=80=9D), but mailto seems most approp= riate given that you=E2=80=99re seeking info about mail services.
 
I provided an example earlier that= would simply point to a config file with server information.  We coul= d do this directly via WebFinger like this:
 
GET /.well-known/host-meta?resource= =3Dmailto:paulej@packetizer.com<= /div>
 
This query would then return something like this:
 
{=
  "links" :
  [
    {
      "rel" : "smtp-server",
   &= nbsp;  "properties" :
  &= nbsp;   {
<= div>
        "host" : "smtp.packetizer.co= m",
 &n= bsp;      "port" : "587",
      &= nbsp; "login-required" : "yes",<= /div>
        "transport" : "s= tarttls"
 &= nbsp;    }
<= /div>
    },<= /div>
&n= bsp;   {
 = ;     "rel" : "imap-server",
      "properties= " :
 &nbs= p;    {
&n= bsp;       "host" : "imap.packetizer.com"= ,
  &n= bsp;     "port" : "993",
        "tr= ansport" : "ssl"
      }
    }
  ]
}
=
 
We would need to standardize= the link relation values (smtp-server and imap-server).  We would als= o need to document what the various properties would be.  If you would= like to create such a configuration document based on WebFinger, I=E2=80= =99d be happy to help out.  In any case, you can see that WebFinger wo= uld serve quite nicely for conveying configuration information given a user= =E2=80=99s email ID.
=
 
I=E2=80=99m not sure exactly what you would need for OAuth endpoints, bu= t I would suggest you make that a separate document since it is not mail re= lated.  (At least I assume it=E2=80=99s not.  Even if it were, th= e mail server information and OAuth information are still different animals= .)
 <= span style=3D"color:black;">
Paul
 
From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Wednesday, June 13, 2012 7:32 PM
To: Peter Saint-An= dre
Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org
Subj= ect: Re: [apps-discuss] Aggregated service discovery
&= nbsp;
In my use case it's a service/server.<= /span>
 <= /span>
Not a t= erribly happy answer to say "DNS SRV records won't work for you, and there is no other solution.".=   By the same token I could ask "Why do we need Webfinger and host met= a at all if we have DNS SRV records?".<= /span>
 <= /span>
If XMPP uses SRV records for discovery, tha= t's fine.  IMAP and outbound SMTP services both lack a defined discove= ry method other than the ubiquitous "service documentation".  Is there= a compelling reason to pick DNS over WF for this?  From the app devel= oper point of view I don't want to have N ways to discover M services.
 
-bill
 
=
 


= ---1055047407-175639555-1340046923=:34140-- From wmills@yahoo-inc.com Mon Jun 18 12:19: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 EB3F411E8098 for ; Mon, 18 Jun 2012 12:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.531 X-Spam-Level: X-Spam-Status: No, score=-17.531 tagged_above=-999 required=5 tests=[AWL=0.067, 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 j0qXgGDOkkAq for ; Mon, 18 Jun 2012 12:19:16 -0700 (PDT) Received: from nm1.bullet.mail.sp2.yahoo.com (nm1.bullet.mail.sp2.yahoo.com [98.139.91.71]) by ietfa.amsl.com (Postfix) with SMTP id 4054D11E8072 for ; Mon, 18 Jun 2012 12:19:16 -0700 (PDT) Received: from [72.30.22.79] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 18 Jun 2012 19:19:16 -0000 Received: from [98.139.91.39] by tm13.bullet.mail.sp2.yahoo.com with NNFMP; 18 Jun 2012 19:19:16 -0000 Received: from [127.0.0.1] by omp1039.mail.sp2.yahoo.com with NNFMP; 18 Jun 2012 19:19:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 65634.52645.bm@omp1039.mail.sp2.yahoo.com Received: (qmail 74958 invoked by uid 60001); 18 Jun 2012 19:19:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1340047154; bh=OLSuzhSeJSoDZWFiReOLJIyuzk6DPe41ZyLaxT2v3Cg=; 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=XskCiVsmMDcG26vmzxiqUUusNbOiBLmDXqDXNXOUQg4Prq4SovhbX+mX/wd6NuIunubvdtqy/8JpPzsrrJmQUL7vO0GQWVyOxMyo5BVZBcRyIWTR9sz/DsWmLfCObhO91nJ9NF+CsZKwKtQ37nM+R8pX/6nPOs/iJ8j/8yPsEsY= 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=GFEhnH3w9Xf5nYkUeflMkS5pLO+RUlGqILWs0GICjb0tWyXXrDqhnKmTPoExPPEtjv4rQhFO0QuoLcCbHtG2MBARCSOt5uqzQycuxMDd1Y7Ew+z5bPue3DKYPKRCz6M8pnQbcoaUXPxYB6Rd65tW9duOGjsjtJDlsOpwP3GTyng=; X-YMail-OSG: oZ7IcM8VM1ko7ARMXNsw9ElqQj7u0pTMhKvMkr.qYp2ISrx S5tYLhnb9zeu4C4X2o7wTYFsFtdWJVTbXpErl3mvYsunMvoRlmhrCl9sf0L8 NmhKgU2q4lKk8KcRDi6lbscFwbBHBChaCNPZEM07XPGC60GBfW_6Egp0d8Ig SQF9kByMp_KvjFOtHlEb_mRCxtVyQYw5bJUHjQQSRvHha.A1ZjHTP2POzTXT CzUNNK3l_gTon_PNWVBKKYu8UBRafs04J2D8LVqug6429f8_rN2WK5Z3NUN7 hu2BPfv10nWBK3IzWCg4WyTD6ngKYlJ4_62ShFH7apZrxP5Yu4KRC3kYwrE5 tDjrxbyt0M_Kp4BuNcycIEpnwhU2aH2rfU_Rqj3TSKQK32Z8yUtsxb6ZkI.Q UJTJXKP1H6lvoOGATYrgPYtYIReoVUdCHu4NcxTOkkVxsJPFBT8HSfwKwSno AIOZGDR4LGxybhyxB9hsreaUVI78XdUCwR69GFs2zRbBxlXOapyQIM0BERIq Ybek6vjBAGEnP3bCdvPOTca.M3Py97buaRD_UsADW09ncPxg- Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Mon, 18 Jun 2012 12:19:14 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> Message-ID: <1340047154.69599.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Mon, 18 Jun 2012 12:19:14 -0700 (PDT) From: William Mills To: John Bradley , "Paul E. Jones" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1502656925-316022621-1340047154=:69599" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery 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, 18 Jun 2012 19:19:18 -0000 --1502656925-316022621-1340047154=:69599 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Unfortunately we came to the conclusion that letting a service endpoint def= ine it's authenticators is probably wrong, this was in the context of disco= very for SASL mechanisms.=C2=A0 The core problem is when the client support= s the password grant if it then trusts the service endpoint to tell it who = to give the username password pair then it's vulnerable.=0A=0A=0A=0A>______= __________________________=0A> From: John Bradley =0A>To= : Paul E. Jones =0A>Cc: 'William Mills' ; 'Peter Saint-Andre' ; apps-discuss@ietf.or= g =0A>Sent: Monday, June 18, 2012 11:36 AM=0A>Subject: Re: [apps-discuss] A= ggregated service discovery=0A> =0A>=0A>A user is likely to have a number o= f OAuth authorization services for different things. =C2=A0=0A>=0A>=0A>I su= spect that the best way to organize it is to describe the services the user= has:=0A>openID Connect=0A>imap=0A>portable contacts=0A>etc=0A>=0A>=0A>and = let the service describe how it is authenticated and where the endpoints ar= e.=0A>=0A>=0A>For Connect there is a single relation for the Connect issuer= and that is then discovered to get the endpoint and other configuration in= formation. =C2=A0=0A>Given that user identifiers may point to services in o= ther domains it is best to leave it up to the service to describe itself ra= ther than relying on individual user information to be correct.=0A>=0A>=0A>= John B.=0A>=0A>=0A>On 2012-06-18, at 2:22 PM, Paul E. Jones wrote:=0A>=0A>B= ill,=0A>>=C2=A0=0A>>In the referenced draft below, I assume the =E2=80=9Cgr= ant-types=E2=80=9D and =E2=80=9Ctoken-types=E2=80=9D should be contained in= side a =E2=80=9Cproperties=E2=80=9D?=C2=A0 That is, I think you want this:= =0A>>=C2=A0=0A>>{=0A>>=C2=A0 "subject" : "acct:carol@example.com",=0A>>=C2= =A0 "links" :=0A>>=C2=A0 [=0A>>=C2=A0=C2=A0=C2=A0 {=0A>>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 "rel" : "oauth2-athorize",=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = "href" : "http://login.example.com/oauth2/authorize"=0A>>=C2=A0=C2=A0=C2=A0= },=0A>>=C2=A0=C2=A0=C2=A0 {=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : "oa= uth2-token",=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "href" : "https://login.exa= mple.com/oauth2/token",=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"properties" :=0A= >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0"grant-types" : "code password",=0A>>=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0"token-types" : "bearer"=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }= =0A>>=C2=A0=C2=A0=C2=A0 }=0A>>=C2=A0 ]=0A>>}=0A>>=C2=A0=0A>>For auto-provis= ioning of email clients (which I understand was your goal), we can either d= efine one link relation that points to a separate configuration document of= some sort, or we define multiple link relations.=C2=A0 My previous example= showed the single link relation and the email below shows use of multiple.= =C2=A0 Both have pros and cons, but I tend to favor using multiple link rel= ations, since this allows one to introduce new stuff without changing the o= ne mail configuration file.=C2=A0 Also, it reduces the number of queries a = mail client has to make to get config information.=0A>>=C2=A0=0A>>You indic= ate that IMAP already has a defined URI.=C2=A0 Where is that defined?=C2=A0= I could not find it in the IANA link relations registry, so I assume it=E2= =80=99s really a URI defined in a spec somewhere.=C2=A0 In any case, we cou= ld use URIs for these things (rather than defining single token link relati= on values and registering them).=C2=A0 I have no preference, but I would li= ke an agreed approach to provisioning.=C2=A0 I hate configuring all the stu= ff manually on email clients. :-)=0A>>=C2=A0=0A>>Paul=0A>>=C2=A0=0A>>From:= =C2=A0William Mills [mailto:wmills@yahoo-inc.com]=C2=A0=0A>>Sent:=C2=A0Mond= ay, June 18, 2012 1:36 PM=0A>>To:=C2=A0Paul E. Jones; 'Peter Saint-Andre'= =0A>>Cc:=C2=A0'Cyrus Daboo'; apps-discuss@ietf.org=0A>>Subject:=C2=A0Re: [a= pps-discuss] Aggregated service discovery=0A>>=C2=A0=0A>>Paul,=0A>>=C2=A0= =0A>>Thanks for the reply on this.=C2=A0 I do already have a separate doc f= or registering the OAuth specific relations,http://tools.ietf.org/id/draft-= wmills-oauth-lrdd-01.html=0A>>=C2=A0=0A>>I don't think I like the thought o= f having to register a new link type for every service, but that might be t= he right way.=C2=A0 IMAP already has a URI defined for example so if we use= a more general link relation then the URI scheme details the type.=C2=A0 T= he tradeoff is whether you can look for a specific link-type or if you have= to scan list elements for the URI type you need.=0A>>=C2=A0=0A>>-bill=0A>>= =C2=A0=0A>>=C2=A0=0A>>>=0A>>>________________________________=0A>>>=0A>>>Fr= om:=C2=A0Paul E. Jones =0A>>>To:=C2=A0'William Mills= ' ; 'Peter Saint-Andre' =C2=A0=0A= >>>Cc:=C2=A0'Cyrus Daboo' ;=C2=A0apps-discuss@ietf.org=C2= =A0=0A>>>Sent:=C2=A0Sunday, June 17, 2012 6:48 PM=0A>>>Subject:=C2=A0RE: [a= pps-discuss] Aggregated service discovery=0A>>>=C2=A0=0A>>>Bill,=0A>>>=C2= =A0=0A>>>My apologies for the belated reply.=C2=A0 I=E2=80=99ve been busy t= his week and got rather behind on email.=0A>>>=C2=A0=0A>>>I do not personal= ly like using SRV records, either.=C2=A0 SRV records could work for smaller= domains, but I=E2=80=99m not sure that they=E2=80=99re the best solution f= or larger domains.=C2=A0 Personally, I would prefer putting users on specif= ic servers or server clusters and SRV records will not differentiate users.= =0A>>>=C2=A0=0A>>>To use WebFinger to find one=E2=80=99s IMAP, SMTP, or POP= server, we could do as I suggested in my email.=C2=A0 Now the question is = what does one query?=C2=A0 Since these three services are email, I=E2=80=99= d suggest we query =E2=80=9Cmailto:paulej@packetizer.com=E2=80=9D.=C2=A0 We= could use another URI scheme (e.g., =E2=80=9Cacct:=E2=80=9D), but mailto s= eems most appropriate given that you=E2=80=99re seeking info about mail ser= vices.=0A>>>=C2=A0=0A>>>I provided an example earlier that would simply poi= nt to a config file with server information.=C2=A0 We could do this directl= y via WebFinger like this:=0A>>>=C2=A0=0A>>>GET /.well-known/host-meta?reso= urce=3Dmailto:paulej@packetizer.com=0A>>>=C2=A0=0A>>>This query would then = return something like this:=0A>>>=C2=A0=0A>>>{=0A>>>=C2=A0 "subject" : "mai= lto:paulej@packetizer.com",=0A>>>=C2=A0 "links" :=0A>>>=C2=A0 [=0A>>>=C2=A0= =C2=A0=C2=A0 {=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : "smtp-server",= =0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "properties" :=0A>>>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 {=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "host" : "sm= tp.packetizer.com",=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "port" = : "587",=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "login-required" := "yes",=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "transport" : "star= ttls"=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=0A>>>=C2=A0=C2=A0=C2=A0 },=0A>>= >=C2=A0=C2=A0=C2=A0 {=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : "imap-ser= ver",=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "properties" :=0A>>>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 {=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "host"= : "imap.packetizer.com",=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "= port" : "993",=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "transport" = : "ssl"=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=0A>>>=C2=A0=C2=A0=C2=A0 }=0A>= >>=C2=A0 ]=0A>>>}=0A>>>=C2=A0=0A>>>We would need to standardize the link re= lation values (smtp-server and imap-server).=C2=A0 We would also need to do= cument what the various properties would be.=C2=A0 If you would like to cre= ate such a configuration document based on WebFinger, I=E2=80=99d be happy = to help out.=C2=A0 In any case, you can see that WebFinger would serve quit= e nicely for conveying configuration information given a user=E2=80=99s ema= il ID.=0A>>>=C2=A0=0A>>>I=E2=80=99m not sure exactly what you would need fo= r OAuth endpoints, but I would suggest you make that a separate document si= nce it is not mail related.=C2=A0 (At least I assume it=E2=80=99s not.=C2= =A0 Even if it were, the mail server information and OAuth information are = still different animals.)=0A>>>=C2=A0=0A>>>Paul=0A>>>=C2=A0=0A>>>From:=C2= =A0William Mills=C2=A0[mailto:wmills@yahoo-inc.com]=C2=A0=0A>>>Sent:=C2=A0W= ednesday, June 13, 2012 7:32 PM=0A>>>To:=C2=A0Peter Saint-Andre=0A>>>Cc:=C2= =A0Paul E. Jones; 'Cyrus Daboo';=C2=A0apps-discuss@ietf.org=0A>>>Subject:= =C2=A0Re: [apps-discuss] Aggregated service discovery=0A>>>=C2=A0=0A>>>In m= y use case it's a service/server.=0A>>>=C2=A0=0A>>>Not a terribly happy ans= wer to say "DNS SRV records won't work for you, and there is no other solut= ion.".=C2=A0 By the same token I could ask "Why do we need Webfinger and ho= st meta at all if we have DNS SRV records?".=0A>>>=C2=A0=0A>>>If XMPP uses = SRV records for discovery, that's fine.=C2=A0 IMAP and outbound SMTP servic= es both lack a defined discovery method other than the ubiquitous "service = documentation".=C2=A0 Is there a compelling reason to pick DNS over WF for = this?=C2=A0 From the app developer point of view I don't want to have N way= s to discover M services.=0A>>>=C2=A0=0A>>>-bill=0A>>>=C2=A0=0A>>>=C2=A0=0A= >>>>=0A>>>>________________________________=0A>>>>=0A>>>>From:=C2=A0Peter S= aint-Andre =0A>>>>To:=C2=A0William Mills =C2=A0=0A>>>>Cc:=C2=A0Paul E. Jones ; 'Cyrus= Daboo' ; "apps-discuss@ietf.org" = =C2=A0=0A>>>>Sent:=C2=A0Wednesday, June 13, 2012 3:57 PM=0A>>>>Subject:=C2= =A0Re: [apps-discuss] Aggregated service discovery=0A>>>>=0A>>>>On 6/13/12 = 4:54 PM, William Mills wrote:=0A>>>>> As I said, I'm interested specificall= y in IMAP, SMTP and OAuth endpoints.=C2=A0=0A>>>>=0A>>>>What exactly is an = "endpoint"? A client? An account? A server?=0A>>>>=0A>>>>> As a data point,= DNS SRV records are not controllable in many hosted=0A>>>>> domain models.= =0A>>>>=0A>>>>At the last XMPP Summit a few months ago, we learned that DNS= SRV=0A>>>>records are unavailable in whole countries (e.g., Japan). That d= oesn't=0A>>>>mean we should define a replacement for DNS over HTTP. :)=0A>>= >>=0A>>>>Peter=0A>>>>=0A>>>>--=C2=A0=0A>>>>Peter Saint-Andre=0A>>>>https://= stpeter.im/=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>=C2=A0=0A______________= _________________________________=0A>>apps-discuss mailing list=0A>>apps-di= scuss@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>= =0A>=0A> --1502656925-316022621-1340047154=:69599 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Unfortunately we came to the conclusion that letting a service endpoint d= efine it's authenticators is probably wrong, this was in the context of dis= covery for SASL mechanisms.  The core problem is when the client suppo= rts the password grant if it then trusts the service endpoint to tell it wh= o to give the username password pair then it's vulnerable.

<= hr size=3D"1"> From: John = Bradley <ve7jtb@ve7jtb.com>
To: Paul E. Jones <paulej@packetizer.com>
Cc: 'William Mills' <wmills@yahoo-inc.com= >; 'Peter Saint-Andre' <stpeter@stpeter.im>; apps-discuss@ietf.org=
Sent: Monday, June 1= 8, 2012 11:36 AM
Subject:<= /b> Re: [apps-discuss] Aggregated service discovery

= =0A
A user is likely to have a number o= f OAuth authorization services for different things.  

<= div>I suspect that the best way to organize it is to describe the services = the user has:
openID Connect
imap
portable co= ntacts
etc

and let the service describe = how it is authenticated and where the endpoints are.

For Connect there is a single relation for the Connect issuer and that i= s then discovered to get the endpoint and other configuration information. =  
Given that user identifiers may point to services in other= domains it is best to leave it up to the service to describe itself rather= than relying on individual user information to be correct.

<= /div>
John B.

On 2012-06-18, at 2:22 PM, Paul E= . Jones wrote:

Bill,
 
In the referenced draf= t below, I assume the =E2=80=9Cgrant-types=E2=80=9D and =E2=80=9Ctoken-type= s=E2=80=9D should be contained inside a =E2=80=9Cproperties=E2=80=9D? = That is, I think you want this:
 
{
  "subject" : "acct:carol@example.com",
  "links" :
  [
    {
      "rel" : "oauth2-athorize",
    &nbs= p; "href" : "= http://login.example.com/oauth2/authorize"
    },
    {
      "re= l" : "oauth2-token",
     &nb= sp;  "token-types" : "bearer"
For auto-provisionin= g of email clients (which I understand was your goal), we can either define= one link relation that points to a separate configuration document of some= sort, or we define multiple link relations.  My previous example show= ed the single link relation and the email below shows use of multiple. = ; Both have pros and cons, but I tend to favor using multiple link relation= s, since this allows one to introduce new stuff without changing the one ma= il configuration file.  Also, it reduces the number of queries a mail client has to make to get config information.
Paul,
=  
Thanks for the reply on this.  I do already have a = separate doc for registering the OAuth specific relations,http://tools.ie= tf.org/id/draft-wmills-oauth-lrdd-01.html
 
I don't th= ink I like the thought of having to register a new link type for every serv= ice, but that might be the right way.  IMAP already has a URI defined = for example so if we use a more general link relation then the URI scheme d= etails the type.  The tradeoff is whether you can look for a specific = link-type or if you have to scan list elements for the URI type you need.
 
-bill
 
 
From: = Paul E. Jones <paulej@packetizer.com>
To: 'Wi= lliam Mills' <wmills@yahoo-inc.com>; 'Peter Saint-Andre' <s= tpeter@stpeter.im> 
Cc: 'Cyrus Daboo' <cyrus@daboo.name>; apps-d= iscuss@ietf.org 
Sent:=  Sunday, Jun= e 17, 2012 6:48 PM
Subject: RE: [apps-discuss] Aggregated service discovery
=  
Bill,
&= nbsp;
My apol= ogies for the belated reply.  I=E2=80=99ve been busy this week and got= rather behind on email.
 
I= do not personally like using SRV records, either.  SRV records could = work for smaller domains, but I=E2=80=99m not sure that they=E2=80=99re the= best solution for larger domains.  Personally, I would prefer putting= users on specific servers or server clusters and SRV records will not diff= erentiate users.
 
T= o use WebFinger to find one=E2=80=99s IMAP, SMTP, or POP server, we could d= o as I suggested in my email.  Now the question is what does one query= ?  Since these three services are email, I=E2=80=99d suggest we query = =E2=80=9Cmailto:paulej@packetizer.com=E2=80=9D.  We= could use another URI scheme (e.g., =E2=80=9Cacct:=E2=80=9D), but mailto s= eems most appropriate given that you=E2=80=99re seeking info about mail ser= vices.
&= nbsp;
I provi= ded an example earlier that would simply point to a config file with server= information.  We could do this directly via WebFinger like this:
 
GET /.well-known/host-meta?r= esource=3Dmailto:paulej@packetizer.com<= /span>
 =
This query would then return something like this:
 
{
  "= links" :
  [=
  &nbs= p; {
      "r= el" : "smtp-server",
=
      "properties" :
      {
    &nbs= p;   "host" : "sm= tp.packetizer.com",
        "port" : "587",
 = ;       "login-required" : "yes",
    &nbs= p;   "transport" : "starttls"=
      }
    },=
    {
      "rel" := "imap-server",
=
 = ;     "properties" :
      {
     &nbs= p;  "host" : "imap.packetizer.com",
        "port" : "99= 3",
  = ;      "transport" : "ssl"
 = ;     }
    }<= /div>
  ]
}
 
We would need to stand= ardize the link relation values (smtp-server and imap-server).  We wou= ld also need to document what the various properties would be.  If you= would like to create such a configuration document based on WebFinger, I=E2=80= =99d be happy to help out.  In any case, you can see that WebFinger wo= uld serve quite nicely for conveying configuration information given a user= =E2=80=99s email ID.
=
 
<= div style=3D"margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:= 0.0001pt;font-size:12pt;font-family:serif;background-color:white;">
 
Paul=
 
From:=  William Mills [mailto:wmills@yahoo-inc.com] 
Sent: Wednesday, June 13, 20= 12 7:32 PM
To:=  Peter Saint-Andre
Cc: Paul E. Jones; 'Cyrus Daboo'; apps-di= scuss@ietf.org
Subject: Re: [apps-discuss] Aggregated service discovery
 
 
Not a terribly h= appy answer to say "DNS SRV records won't work for you, and there is no oth= er solution.".  By the same token I could ask "Why do we need Webfinge= r and host meta at all if we have DNS SRV records?".
 
If XMPP uses SRV records for discovery, that's fine.&nb= sp; IMAP and outbound SMTP services both lack a defined discovery method ot= her than the ubiquitous "service documentation".  Is there a compellin= g reason to pick DNS over WF for this?  From the app developer point o= f view I don't want to have N ways to discover M services.
 
-bill
 
 
From: Peter Saint-Andre <stpeter@stpeter.im>
To: William Mills &l= t;wmills@yahoo-inc.com> 
Cc: Paul E. Jones <paulej@= packetizer.com>; 'Cyrus Daboo' <cyrus@daboo.name>; "<= a rel=3D"nofollow" ymailto=3D"mailto:apps-discuss@ietf.org" target=3D"_blan= k" href=3D"mailto:apps-discuss@ietf.org" style=3D"color:blue;text-decoration:underline;">apps-discuss@ietf.org"= <apps-discuss@ietf.org> 
Sent: Wednesday, June 13, 2012 3:57 PM=
Subject: = ;Re: [apps-discuss] Aggregated service discovery

On 6/13/12 4:54 P= M, William Mills wrote:
> As I said, I'm interested specifically in I= MAP, SMTP and OAuth endpoints. =

What exactly is an "endpoint"? A client? An account? A server?
<= br>> As a data point, DNS SRV records are not controllable in many hoste= d
> domain models.

At the last XMPP Summit a few months ago, w= e learned that DNS SRV
records are unavailable in whole countries (e.g.,= Japan). That doesn't
mean we should define a replacement for DNS over H= TTP. :)

Peter

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




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


 --1502656925-316022621-1340047154=:69599-- From paulej@packetizer.com Mon Jun 18 13:16: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 179DD21F8549 for ; Mon, 18 Jun 2012 13:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJloOXgkA5Xt for ; Mon, 18 Jun 2012 13:16:44 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB6421F852C for ; Mon, 18 Jun 2012 13:16:44 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5IKGfkx005859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Jun 2012 16:16:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340050603; bh=kCWOCB/dEKUmFQqy8Ue/8uSZlPiRkykYhxK6w2vO49c=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Y7byUtRS7f2f44xvCLJbsGuotXi3O3dJevcxxb80gJxAwF2i4VOAdODTOUj83qJj9 CfkfJBUbTCBzFFfqDdfi7jLb1FFHggkECe91ujulYEvK7AE3MivQFxk4CasSHcmqRI AjSgSWZ/WOv7Cho/uljozg3qdLEGNc28RLDhacrI= From: "Paul E. Jones" To: "'William Mills'" , "'Peter Saint-Andre'" References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> <1340046923.34140.YahooMailNeo@web31806.mail.mud.yahoo.com> In-Reply-To: <1340046923.34140.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Mon, 18 Jun 2012 16:16:45 -0400 Message-ID: <027001cd4d8f$48e260f0$daa722d0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0271_01CD4D6D.C1D554D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNYFRdarpUA3Z9l4mSBSKHTly568wGsYWTHAiB/MPYCgTB6NAGRuS9TAZsphI0CgPvwiQHAzgIyAdRbPCoCdcjfHwDj9hFfk1OXYhA= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 20:16:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0271_01CD4D6D.C1D554D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bill, =20 Ah, I was confused. I thought you were speaking of an IMAP link = relation. You did same URI scheme. =20 It is possible to have a link relation with no URI. At least that is = valid per the XRD spec. The href is listed as optional: http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.link =20 In any case, one could return an IMAP URI or one could just return = properties. The choice is ours, but I do tend to think we would not = want a URI scheme for POP3, IMAP, SMTP, etc. It seems like overkill.=20 =20 This is why I preferred returning the mail configuration info using the = =E2=80=9Cmailto=E2=80=9D URI scheme. This is an example where I would = prefer it over =E2=80=9Caccount=E2=80=9D since =E2=80=9Cmailto=E2=80=9D = would refer to a specific email address. With that address, one could = then discover the mail server configuration data as I showed it below. = I=E2=80=99d expect this to be populated by the email provider, not the = user. =20 If we want to use the href field, then we could just use WebFinger to = point to the email config document as I had initially proposed. That = was something like this: =20 { "subject" : "mailto:paulej@packetizer.com", "links" : [ { "rel" : "config-email", "href" : = "http://www.packetizer.com.com/config/email/?user=3Dpaulej" } ] } =20 So the client would first query the WebFinger server to get the above = link relation (=E2=80=9Cconfig-email=E2=80=9D or whatever) and then = perform a second query to get the actual configuration parameters. The = document containing the configuration parameters would be in whatever = format we want to define. =20 There are pros and cons with each approach. I have no strong preference = either way, but as I said, I=E2=80=99d love to see agreement on some = universally agreed approach :) =20 Paul =20 From: William Mills [mailto:wmills@yahoo-inc.com]=20 Sent: Monday, June 18, 2012 3:15 PM To: Paul E. Jones; 'Peter Saint-Andre' Cc: 'Cyrus Daboo'; apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery =20 Ah, I missed that nuance, that declared application data goes in = "properties". =20 The "imap" scheme is listed in = http://www.iana.org/assignments/uri-schemes.html and defined in = http://www.rfc-editor.org/rfc/rfc5092.txt =20 I've been inquiring about the "related" link relation type, which seems = semantically what we want at first glance. It's not clear to me that = you can define a link relation that does not have a uri? That has only = application data? I don't think it's right to extend link relations to = be an arbitrary data container, but requiring a URI scheme is going to = be a lot of work for some things. SMTP is the hard one right now, a = hack for that might be a new relation and just put the postmaster = mailto: link in the URI spot. =20 =20 I'm not inclined to try to encode arbitrary flags like login-required, = I'd probably go as far as a well known service name and leave it there. =20 -bill =20 _____ =20 From: Paul E. Jones To: 'William Mills' ; 'Peter Saint-Andre' = =20 Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org=20 Sent: Monday, June 18, 2012 11:22 AM Subject: RE: [apps-discuss] Aggregated service discovery =20 Bill, =20 In the referenced draft below, I assume the = =E2=80=9Cgrant-types=E2=80=9D and =E2=80=9Ctoken-types=E2=80=9D should = be contained inside a =E2=80=9Cproperties=E2=80=9D? That is, I think = you want this: =20 { "subject" : "acct:carol@example.com", "links" : [ { "rel" : "oauth2-athorize", "href" : "http://login.example.com/oauth2/authorize" }, { "rel" : "oauth2-token", "href" : "https://login.example.com/oauth2/token", "properties" : { "grant-types" : "code password", "token-types" : "bearer" } } ] } =20 For auto-provisioning of email clients (which I understand was your = goal), we can either define one link relation that points to a separate = configuration document of some sort, or we define multiple link = relations. My previous example showed the single link relation and the = email below shows use of multiple. Both have pros and cons, but I tend = to favor using multiple link relations, since this allows one to = introduce new stuff without changing the one mail configuration file. = Also, it reduces the number of queries a mail client has to make to get = config information. =20 You indicate that IMAP already has a defined URI. Where is that = defined? I could not find it in the IANA link relations registry, so I = assume it=E2=80=99s really a URI defined in a spec somewhere. In any = case, we could use URIs for these things (rather than defining single = token link relation values and registering them). I have no preference, = but I would like an agreed approach to provisioning. I hate configuring = all the stuff manually on email clients. :-) =20 Paul =20 From: William Mills [mailto:wmills@yahoo-inc.com]=20 Sent: Monday, June 18, 2012 1:36 PM To: Paul E. Jones; 'Peter Saint-Andre' Cc: 'Cyrus Daboo'; apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery =20 Paul,=20 =20 Thanks for the reply on this. I do already have a separate doc for = registering the OAuth specific relations, = http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html =20 I don't think I like the thought of having to register a new link type = for every service, but that might be the right way. IMAP already has a = URI defined for example so if we use a more general link relation then = the URI scheme details the type. The tradeoff is whether you can look = for a specific link-type or if you have to scan list elements for the = URI type you need. =20 -bill =20 =20 _____ =20 From: Paul E. Jones To: 'William Mills' ; 'Peter Saint-Andre' = =20 Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org=20 Sent: Sunday, June 17, 2012 6:48 PM Subject: RE: [apps-discuss] Aggregated service discovery =20 Bill, =20 My apologies for the belated reply. I=E2=80=99ve been busy this week = and got rather behind on email. =20 I do not personally like using SRV records, either. SRV records could = work for smaller domains, but I=E2=80=99m not sure that they=E2=80=99re = the best solution for larger domains. Personally, I would prefer = putting users on specific servers or server clusters and SRV records = will not differentiate users.=20 =20 To use WebFinger to find one=E2=80=99s IMAP, SMTP, or POP server, we = could do as I suggested in my email. Now the question is what does one = query? Since these three services are email, I=E2=80=99d suggest we = query =E2=80=9Cmailto:paulej@packetizer.com=E2=80=9D. We could use = another URI scheme (e.g., =E2=80=9Cacct:=E2=80=9D), but mailto seems = most appropriate given that you=E2=80=99re seeking info about mail = services. =20 I provided an example earlier that would simply point to a config file = with server information. We could do this directly via WebFinger like = this: =20 GET /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com =20 This query would then return something like this: =20 { "subject" : "mailto:paulej@packetizer.com", "links" : [ { "rel" : "smtp-server", "properties" : { "host" : "smtp.packetizer.com ", "port" : "587", "login-required" : "yes", "transport" : "starttls" } }, { "rel" : "imap-server", "properties" : { "host" : "imap.packetizer.com ", "port" : "993", "transport" : "ssl" } } ] } =20 We would need to standardize the link relation values (smtp-server and = imap-server). We would also need to document what the various = properties would be. If you would like to create such a configuration = document based on WebFinger, I=E2=80=99d be happy to help out. In any = case, you can see that WebFinger would serve quite nicely for conveying = configuration information given a user=E2=80=99s email ID. =20 I=E2=80=99m not sure exactly what you would need for OAuth endpoints, = but I would suggest you make that a separate document since it is not = mail related. (At least I assume it=E2=80=99s not. Even if it were, = the mail server information and OAuth information are still different = animals.) =20 Paul =20 From: William Mills [mailto:wmills@yahoo-inc.com]=20 Sent: Wednesday, June 13, 2012 7:32 PM To: Peter Saint-Andre Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery =20 In my use case it's a service/server. =20 Not a terribly happy answer to say "DNS SRV records won't work for you, = and there is no other solution.". By the same token I could ask "Why do = we need Webfinger and host meta at all if we have DNS SRV records?". =20 If XMPP uses SRV records for discovery, that's fine. IMAP and outbound = SMTP services both lack a defined discovery method other than the = ubiquitous "service documentation". Is there a compelling reason to = pick DNS over WF for this? From the app developer point of view I don't = want to have N ways to discover M services. =20 -bill =20 =20 _____ =20 From: Peter Saint-Andre To: William Mills =20 Cc: Paul E. Jones ; 'Cyrus Daboo' = ; "apps-discuss@ietf.org" =20 Sent: Wednesday, June 13, 2012 3:57 PM Subject: Re: [apps-discuss] Aggregated service discovery On 6/13/12 4:54 PM, William Mills wrote: > As I said, I'm interested specifically in IMAP, SMTP and OAuth = endpoints.=20 What exactly is an "endpoint"? A client? An account? A server? > As a data point, DNS SRV records are not controllable in many hosted > domain models. At the last XMPP Summit a few months ago, we learned that DNS SRV records are unavailable in whole countries (e.g., Japan). That doesn't mean we should define a replacement for DNS over HTTP. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ =20 =20 ------=_NextPart_000_0271_01CD4D6D.C1D554D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Bill,

 

Ah, I was confused.=C2=A0 I thought you were speaking of an IMAP link = relation.=C2=A0 You did same URI scheme.

 

It is possible to have a link relation with no URI.=C2=A0 At least = that is valid per the XRD spec.=C2=A0 The href is listed as = optional:

http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.link

 

In any case, one could return an IMAP URI or one could just return = properties.=C2=A0 The choice is ours, but I do tend to think we would = not want a URI scheme for POP3, IMAP, SMTP, etc.=C2=A0 It seems like = overkill.

 

This is why I preferred returning the mail configuration info using = the =E2=80=9Cmailto=E2=80=9D URI scheme.=C2=A0 This is an example where = I would prefer it over =E2=80=9Caccount=E2=80=9D since = =E2=80=9Cmailto=E2=80=9D would refer to=C2=A0 a specific email = address.=C2=A0 With that address, one could then discover the mail = server configuration data as I showed it below.=C2=A0 I=E2=80=99d expect = this to be populated by the email provider, not the = user.

 

If we want to use the href field, then we could just use WebFinger to = point to the email config document as I had initially proposed.=C2=A0 = That was something like this:

 

{

=C2=A0 "subject" : = "mailto:paulej@packetizer.com",

=C2=A0 "links" :

=C2=A0 [

=C2=A0=C2=A0=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : = "config-email",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "href" : = "http://www.packetizer.com.com/config/email/?user=3Dpaulej"

=C2=A0=C2=A0=C2=A0 }

=C2=A0 ]

}

 

So the client would first query the WebFinger server to get the above = link relation (=E2=80=9Cconfig-email=E2=80=9D or whatever) and then = perform a second query to get the actual configuration parameters.=C2=A0 = The document containing the configuration parameters would be in = whatever format we want to define.

 

There are pros and cons with each approach.=C2=A0 I have no strong = preference either way, but as I said, I=E2=80=99d love to see agreement = on some universally agreed approach :)

 

Paul

 

From:= = William Mills [mailto:wmills@yahoo-inc.com]
Sent: Monday, = June 18, 2012 3:15 PM
To: Paul E. Jones; 'Peter = Saint-Andre'
Cc: 'Cyrus Daboo'; = apps-discuss@ietf.org
Subject: Re: [apps-discuss] Aggregated = service discovery

 

Ah, I = missed that nuance, that declared application data goes in = "properties".

 

 

I've = been inquiring about the "related" link relation type, which = seems semantically what we want at first glance.  It's not clear to = me that you can define a link relation that does not have a uri?  = That has only application data?  I don't think it's right to extend = link relations to be an arbitrary data container, but requiring a URI = scheme is going to be a lot of work for some things.  SMTP is the = hard one right now, a hack for that might be a new relation and just put = the postmaster mailto: link in the URI spot.  =

 

I'm not = inclined to try to encode arbitrary flags like login-required, I'd = probably go as far as a well known service name and leave it = there.

 

-bill

 

<= hr size=3D1 width=3D"100%" align=3Dcenter>

F= rom: = Paul E. Jones <paulej@packetizer.com>
To: 'William Mills' <wmills@yahoo-inc.com>; = 'Peter Saint-Andre' <stpeter@stpeter.im> =
Cc: 'Cyrus Daboo' <cyrus@daboo.name>; apps-discuss@ietf.org =
Sent: Monday, June 18, 2012 11:22 AM
Subject: RE: = [apps-discuss] Aggregated service discovery

 

Bill,

 

In the referenced draft below, I assume the = =E2=80=9Cgrant-types=E2=80=9D and =E2=80=9Ctoken-types=E2=80=9D should = be contained inside a =E2=80=9Cproperties=E2=80=9D?  That is, I = think you want this:

 

{

  "subject" : = "acct:carol@example.com",

  "links" :

  [

    {

      "rel" : = "oauth2-athorize",

    },

    {

      "rel" : = "oauth2-token",

     "properties" = :

      {

       "grant= -types" : "code password",

   =      "token-types" : = "bearer"

      }

    }

  ]

}

 

For auto-provisioning of email clients (which I understand was your = goal), we can either define one link relation that points to a separate = configuration document of some sort, or we define multiple link = relations.  My previous example showed the single link relation and = the email below shows use of multiple.  Both have pros and cons, = but I tend to favor using multiple link relations, since this allows one = to introduce new stuff without changing the one mail configuration = file.  Also, it reduces the number of queries a mail client has to = make to get config information.

 

You indicate that IMAP already has a defined URI.  Where is that = defined?  I could not find it in the IANA link relations registry, = so I assume it=E2=80=99s really a URI defined in a spec somewhere.  = In any case, we could use URIs for these things (rather than defining = single token link relation values and registering them).  I have no = preference, but I would like an agreed approach to provisioning.  I = hate configuring all the stuff manually on email clients. = :-)

 

Paul

 

F= rom: = William Mills [mailto:wmills@yahoo-inc.co= m]
Sent: Monday, June 18, 2012 1:36 PM
To: Paul = E. Jones; 'Peter Saint-Andre'
Cc: 'Cyrus Daboo'; apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] Aggregated service discovery

 

Paul, =

 

Thanks = for the reply on this.  I do already have a separate doc for = registering the OAuth specific relations, http://= tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html

 

I don't = think I like the thought of having to register a new link type for every = service, but that might be the right way.  IMAP already has a URI = defined for example so if we use a more general link relation then the = URI scheme details the type.  The tradeoff is whether you can look = for a specific link-type or if you have to scan list elements for the = URI type you need.

 

-bill

 

 

<= hr size=3D1 width=3D"100%" align=3Dcenter>

F= rom: = Paul E. Jones <paulej@packetizer.com>
To: 'William = Mills' <wmills@yahoo-inc.com>; 'Peter Saint-Andre' = <stpeter@stpeter.im>
Cc: 'Cyrus = Daboo' <cyrus@daboo.name>; apps-discuss@ietf.org
Sent: Sunday, = June 17, 2012 6:48 PM
Subject: RE: [apps-discuss] Aggregated = service discovery

 

Bill,

 

My apologies for the belated reply.  I=E2=80=99ve been busy this = week and got rather behind on email.

 

I do not personally like using SRV records, either.  SRV records = could work for smaller domains, but I=E2=80=99m not sure that = they=E2=80=99re the best solution for larger domains.  Personally, = I would prefer putting users on specific servers or server clusters and = SRV records will not differentiate users.

 

To use WebFinger to find one=E2=80=99s IMAP, SMTP, or POP server, we = could do as I suggested in my email.  Now the question is what does = one query?  Since these three services are email, I=E2=80=99d = suggest we query =E2=80=9Cmailto:paulej@packetizer.com=E2=80=9D.  We = could use another URI scheme (e.g., =E2=80=9Cacct:=E2=80=9D), but mailto = seems most appropriate given that you=E2=80=99re seeking info about mail = services.

 

I provided an example earlier that would simply point to a config file = with server information.  We could do this directly via WebFinger = like this:

 

GET = /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com

 

This query would then return something like this:

 

{

  "links" = :

  [

    {

      = "rel" : "smtp-server",

      = "properties" :

      {

        = "host" : "smtp.packetizer.com",

        = "port" : "587",

        = "login-required" : "yes",

        = "transport" : "starttls"

      }

    },

    {

      = "rel" : "imap-server",

      = "properties" :

      {

        = "host" : "imap.packetizer.com",

        = "port" : "993",

        = "transport" : "ssl"

      }

    }

  ]

}

 

We would need to standardize the link relation values (smtp-server and = imap-server).  We would also need to document what the various = properties would be.  If you would like to create such a = configuration document based on WebFinger, I=E2=80=99d be happy to help = out.  In any case, you can see that WebFinger would serve quite = nicely for conveying configuration information given a user=E2=80=99s = email ID.

 

I=E2=80=99m not sure exactly what you would need for OAuth endpoints, = but I would suggest you make that a separate document since it is not = mail related.  (At least I assume it=E2=80=99s not.  Even if = it were, the mail server information and OAuth information are still = different animals.)

 

Paul

 

F= rom: = William Mills [mailto:wmills@yahoo-inc.com]
Sent: = Wednesday, June 13, 2012 7:32 PM
To: Peter = Saint-Andre
Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org
Subject: Re: = [apps-discuss] Aggregated service discovery

=

 

<= div>

In my = use case it's a service/server.

<= div>

 

<= div>

Not a = terribly happy answer to say "DNS SRV records won't work for you, = and there is no other solution.".  By the same token I could = ask "Why do we need Webfinger and host meta at all if we have DNS = SRV records?".

<= div>

 

<= div>

If XMPP = uses SRV records for discovery, that's fine.  IMAP and outbound = SMTP services both lack a defined discovery method other than the = ubiquitous "service documentation".  Is there a = compelling reason to pick DNS over WF for this?  From the app = developer point of view I don't want to have N ways to discover M = services.

<= div>

 

<= div>

-bill

<= div>

 

 

<= hr size=3D1 width=3D"100%" align=3Dcenter>

F= rom: = Peter Saint-Andre <stpeter@stpeter.im>
To: William Mills = <wmills@yahoo-inc.com>
Cc: Paul E. = Jones <paulej@packetizer.com>; 'Cyrus Daboo' <cyrus@daboo.name>; "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Sent: = Wednesday, June 13, 2012 3:57 PM
Subject: Re: [apps-discuss] = Aggregated service discovery


On 6/13/12 4:54 PM, William Mills = wrote:
> As I said, I'm interested specifically in IMAP, SMTP and = OAuth endpoints.

What exactly is an "endpoint"? A = client? An account? A server?

> As a data point, DNS SRV = records are not controllable in many hosted
> domain = models.

At the last XMPP Summit a few months ago, we learned that = DNS SRV
records are unavailable in whole countries (e.g., Japan). = That doesn't
mean we should define a replacement for DNS over HTTP. = :)

Peter

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



=

 

 

------=_NextPart_000_0271_01CD4D6D.C1D554D0-- From ve7jtb@ve7jtb.com Mon Jun 18 13:19:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DCB21F8570 for ; Mon, 18 Jun 2012 13:19:22 -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 pBob9V5ZEYVl for ; Mon, 18 Jun 2012 13:19:21 -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 AEBE221F856D for ; Mon, 18 Jun 2012 13:19:20 -0700 (PDT) Received: by ggnc4 with SMTP id c4so4477939ggn.31 for ; Mon, 18 Jun 2012 13:19:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=s7ILXvTL5qcl5MSQBnKhWuTgnM4Z03yy/ArJeO5G9kI=; b=C49O2syhwgTSGtYvMkgxf9j8xuUVNBD+RzaCR6wbIi+EBytCZkXeuG42MX/zhYZzEn 5MZst/uP+hNG43C5GhOeAtJbiiaqJmsg+xx/Sk8UZri/QHODPfy32bi73Dq66V+GLqVd erhhxVqwcSfo82mvtK5nbU4RHVNr9UH77oIBHQAoOjckuHDw/AJdLzRWLnUPQdwk79H+ 7FpT85jKwu1LTIBJU5gEVFeEHifMPlQ5hnBNH7T3sy588aTsntFJmf2LbNUvKBdFp/sE QQqeFpdX3w5QZkKIGZrD/HYl1wTZydUHnHoCtjp2R5zglqOLiHZCv6W5touYIfEXCvTT Gq1g== Received: by 10.236.190.6 with SMTP id d6mr19560950yhn.16.1340050759847; Mon, 18 Jun 2012 13:19:19 -0700 (PDT) Received: from [192.168.1.213] (190-20-29-46.baf.movistar.cl. [190.20.29.46]) by mx.google.com with ESMTPS id a64sm68705401yhe.11.2012.06.18.13.19.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jun 2012 13:19:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_39FEC628-0BD5-4285-A37D-112E73554ECC"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <1340047154.69599.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Mon, 18 Jun 2012 16:19:08 -0400 Message-Id: <24783551-C1B8-456B-8E94-9BF59A3CAC75@ve7jtb.com> References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> <1340047154.69599.YahooMailNeo@web31803.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk06sYPG2bWGdaUEr9LA2X9zxUxdOxRI8jyH6TdsOFm9ZGhVlhxH3B/Gk2zWKtkOQNFod9w Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 20:19:22 -0000 --Apple-Mail=_39FEC628-0BD5-4285-A37D-112E73554ECC Content-Type: multipart/alternative; boundary="Apple-Mail=_C0A35206-9E3E-4997-89CD-6EABDA051AA3" --Apple-Mail=_C0A35206-9E3E-4997-89CD-6EABDA051AA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 That is not what I am saying. I am saying that the user's discovery document has a link relation to = the providers decryption of the service. That is different from the = imap endpoint providing the link relation. If you can trust the user's information to provide the Oauth endpoint = why can't you trust the user's information to link to the description of = the service. As I have pointed out before you probably don't want per user = configuration for things like imap, the simplest thing is to describe = the service in host-meta and forget the extra user discovery steps and = maintenance. John B. On 2012-06-18, at 3:19 PM, William Mills wrote: > Unfortunately we came to the conclusion that letting a service = endpoint define it's authenticators is probably wrong, this was in the = context of discovery for SASL mechanisms. The core problem is when the = client supports the password grant if it then trusts the service = endpoint to tell it who to give the username password pair then it's = vulnerable. >=20 > From: John Bradley > To: Paul E. Jones =20 > Cc: 'William Mills' ; 'Peter Saint-Andre' = ; apps-discuss@ietf.org=20 > Sent: Monday, June 18, 2012 11:36 AM > Subject: Re: [apps-discuss] Aggregated service discovery >=20 > A user is likely to have a number of OAuth authorization services for = different things. =20 >=20 > I suspect that the best way to organize it is to describe the services = the user has: > openID Connect > imap > portable contacts > etc >=20 > and let the service describe how it is authenticated and where the = endpoints are. >=20 > For Connect there is a single relation for the Connect issuer and that = is then discovered to get the endpoint and other configuration = information. =20 > Given that user identifiers may point to services in other domains it = is best to leave it up to the service to describe itself rather than = relying on individual user information to be correct. >=20 > John B. >=20 > On 2012-06-18, at 2:22 PM, Paul E. Jones wrote: >=20 >> Bill, >> =20 >> In the referenced draft below, I assume the =93grant-types=94 and = =93token-types=94 should be contained inside a =93properties=94? That = is, I think you want this: >> =20 >> { >> "subject" : "acct:carol@example.com", >> "links" : >> [ >> { >> "rel" : "oauth2-athorize", >> "href" : "http://login.example.com/oauth2/authorize" >> }, >> { >> "rel" : "oauth2-token", >> "href" : "https://login.example.com/oauth2/token", >> "properties" : >> { >> "grant-types" : "code password", >> "token-types" : "bearer" >> } >> } >> ] >> } >> =20 >> For auto-provisioning of email clients (which I understand was your = goal), we can either define one link relation that points to a separate = configuration document of some sort, or we define multiple link = relations. My previous example showed the single link relation and the = email below shows use of multiple. Both have pros and cons, but I tend = to favor using multiple link relations, since this allows one to = introduce new stuff without changing the one mail configuration file. = Also, it reduces the number of queries a mail client has to make to get = config information. >> =20 >> You indicate that IMAP already has a defined URI. Where is that = defined? I could not find it in the IANA link relations registry, so I = assume it=92s really a URI defined in a spec somewhere. In any case, we = could use URIs for these things (rather than defining single token link = relation values and registering them). I have no preference, but I = would like an agreed approach to provisioning. I hate configuring all = the stuff manually on email clients. :-) >> =20 >> Paul >> =20 >> From: William Mills [mailto:wmills@yahoo-inc.com]=20 >> Sent: Monday, June 18, 2012 1:36 PM >> To: Paul E. Jones; 'Peter Saint-Andre' >> Cc: 'Cyrus Daboo'; apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Aggregated service discovery >> =20 >> Paul, >> =20 >> Thanks for the reply on this. I do already have a separate doc for = registering the OAuth specific = relations,http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html >> =20 >> I don't think I like the thought of having to register a new link = type for every service, but that might be the right way. IMAP already = has a URI defined for example so if we use a more general link relation = then the URI scheme details the type. The tradeoff is whether you can = look for a specific link-type or if you have to scan list elements for = the URI type you need. >> =20 >> -bill >> =20 >> =20 >> From: Paul E. Jones >> To: 'William Mills' ; 'Peter Saint-Andre' = =20 >> Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org=20 >> Sent: Sunday, June 17, 2012 6:48 PM >> Subject: RE: [apps-discuss] Aggregated service discovery >> =20 >> Bill, >> =20 >> My apologies for the belated reply. I=92ve been busy this week and = got rather behind on email. >> =20 >> I do not personally like using SRV records, either. SRV records = could work for smaller domains, but I=92m not sure that they=92re the = best solution for larger domains. Personally, I would prefer putting = users on specific servers or server clusters and SRV records will not = differentiate users. >> =20 >> To use WebFinger to find one=92s IMAP, SMTP, or POP server, we could = do as I suggested in my email. Now the question is what does one query? = Since these three services are email, I=92d suggest we query = =93mailto:paulej@packetizer.com=94. We could use another URI scheme = (e.g., =93acct:=94), but mailto seems most appropriate given that you=92re= seeking info about mail services. >> =20 >> I provided an example earlier that would simply point to a config = file with server information. We could do this directly via WebFinger = like this: >> =20 >> GET /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com >> =20 >> This query would then return something like this: >> =20 >> { >> "subject" : "mailto:paulej@packetizer.com", >> "links" : >> [ >> { >> "rel" : "smtp-server", >> "properties" : >> { >> "host" : "smtp.packetizer.com", >> "port" : "587", >> "login-required" : "yes", >> "transport" : "starttls" >> } >> }, >> { >> "rel" : "imap-server", >> "properties" : >> { >> "host" : "imap.packetizer.com", >> "port" : "993", >> "transport" : "ssl" >> } >> } >> ] >> } >> =20 >> We would need to standardize the link relation values (smtp-server = and imap-server). We would also need to document what the various = properties would be. If you would like to create such a configuration = document based on WebFinger, I=92d be happy to help out. In any case, = you can see that WebFinger would serve quite nicely for conveying = configuration information given a user=92s email ID. >> =20 >> I=92m not sure exactly what you would need for OAuth endpoints, but I = would suggest you make that a separate document since it is not mail = related. (At least I assume it=92s not. Even if it were, the mail = server information and OAuth information are still different animals.) >> =20 >> Paul >> =20 >> From: William Mills [mailto:wmills@yahoo-inc.com]=20 >> Sent: Wednesday, June 13, 2012 7:32 PM >> To: Peter Saint-Andre >> Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Aggregated service discovery >> =20 >> In my use case it's a service/server. >> =20 >> Not a terribly happy answer to say "DNS SRV records won't work for = you, and there is no other solution.". By the same token I could ask = "Why do we need Webfinger and host meta at all if we have DNS SRV = records?". >> =20 >> If XMPP uses SRV records for discovery, that's fine. IMAP and = outbound SMTP services both lack a defined discovery method other than = the ubiquitous "service documentation". Is there a compelling reason to = pick DNS over WF for this? =46rom the app developer point of view I = don't want to have N ways to discover M services. >> =20 >> -bill >> =20 >> =20 >> From: Peter Saint-Andre >> To: William Mills =20 >> Cc: Paul E. Jones ; 'Cyrus Daboo' = ; "apps-discuss@ietf.org" =20 >> Sent: Wednesday, June 13, 2012 3:57 PM >> Subject: Re: [apps-discuss] Aggregated service discovery >>=20 >> On 6/13/12 4:54 PM, William Mills wrote: >> > As I said, I'm interested specifically in IMAP, SMTP and OAuth = endpoints.=20 >>=20 >> What exactly is an "endpoint"? A client? An account? A server? >>=20 >> > As a data point, DNS SRV records are not controllable in many = hosted >> > domain models. >>=20 >> At the last XMPP Summit a few months ago, we learned that DNS SRV >> records are unavailable in whole countries (e.g., Japan). That = doesn't >> mean we should define a replacement for DNS over HTTP. :) >>=20 >> Peter >>=20 >> --=20 >> Peter Saint-Andre >> https://stpeter.im/ >>=20 >>=20 >>=20 >>=20 >> =20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 >=20 --Apple-Mail=_C0A35206-9E3E-4997-89CD-6EABDA051AA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 That = is not what I am saying.

I am saying that the user's = discovery document has a link relation to the providers decryption of = the service.   That is different from the imap endpoint providing = the link relation.

If you can trust the user's = information to provide the Oauth endpoint why can't you trust the user's = information to link to the description of the = service.

As I have pointed out before you = probably don't want per user configuration for things like imap, =  the simplest thing is to describe the service in host-meta and = forget the extra user discovery steps and = maintenance.

John B.

On = 2012-06-18, at 3:19 PM, William Mills wrote:

Unfortunately we came to the = conclusion that letting a service endpoint define it's authenticators is = probably wrong, this was in the context of discovery for SASL = mechanisms.  The core problem is when the client supports the = password grant if it then trusts the service endpoint to tell it who to = give the username password pair then it's = vulnerable.

=
=
From: = John Bradley <ve7jtb@ve7jtb.com>
= To: Paul E. Jones = <paulej@packetizer.com>=
Cc: 'William = Mills' <wmills@yahoo-inc.com>; = 'Peter Saint-Andre' <stpeter@stpeter.im>; apps-discuss@ietf.org
= Sent: Monday, June 18, = 2012 11:36 AM
Subject: Re: [apps-discuss] Aggregated service = discovery

A user is likely to have a number = of OAuth authorization services for different things. =  

I suspect that the best way to organize it is = to describe the services the user has:
openID = Connect
imap
portable = contacts
etc

and let the service = describe how it is authenticated and where the endpoints = are.

For Connect there is a single relation for = the Connect issuer and that is then discovered to get the endpoint and = other configuration information.  
Given that user = identifiers may point to services in other domains it is best to leave = it up to the service to describe itself rather than relying on = individual user information to be correct.

John = B.

On 2012-06-18, at 2:22 PM, Paul E. Jones = wrote:

Bill,
 
In the referenced draft below, I assume the =93grant-types=94 = and =93token-types=94 should be contained inside a =93properties=94? = That is, I think you want this:
 
{
  "subject" : "acct:carol@example.com",
  "links" :
  [
    {
      "rel" : = "oauth2-athorize",
    },
    {
      "rel" : = "oauth2-token",
     "properties" :
      {
       "grant-types" : "code = password",
        "token-types" : = "bearer"
      }
    }
  ]
}
 
For auto-provisioning of email clients (which I understand = was your goal), we can either define one link relation that points to a = separate configuration document of some sort, or we define multiple link = relations.  My previous example showed the single link relation and = the email below shows use of multiple.  Both have pros and cons, = but I tend to favor using multiple link relations, since this allows one = to introduce new stuff without changing the one mail configuration = file.  Also, it reduces the number of queries a mail client has to make to get config information.
 
You indicate that IMAP already has a defined URI.  Where = is that defined?  I could not find it in the IANA link relations = registry, so I assume it=92s really a URI defined in a spec = somewhere.  In any case, we could use URIs for these things (rather = than defining single token link relation values and registering = them).  I have no preference, but I would like an agreed approach = to provisioning.  I hate configuring all the stuff manually on = email clients. :-)
 
Paul
 
From: William Mills = [mailto:wmills@yahoo-inc.com] 
Sent:=  Monday, = June 18, 2012 1:36 PM
To: Paul E. Jones; = 'Peter Saint-Andre'
Cc: 'Cyrus Daboo'; = apps-discuss@ietf.org
Subj= ect: Re: = [apps-discuss] Aggregated service discovery
 
Paul,
 
Thanks = for the reply on this.  I do already have a separate doc for = registering the OAuth specific relations,http://tools.ietf.org/id/d= raft-wmills-oauth-lrdd-01.html
=  
I don't = think I like the thought of having to register a new link type for every = service, but that might be the right way.  IMAP already has a URI = defined for example so if we use a more general link relation then the = URI scheme details the type.  The tradeoff is whether you can look = for a specific link-type or if you have to scan list elements for the = URI type you need.
=  
-bill
=  
=  
From: Paul E. Jones = <paulej@packetizer.com&= gt;
To: 'William = Mills' <wmills@yahoo-inc.com&g= t;; 'Peter Saint-Andre' <stpeter@stpeter.im>=  
Cc: 'Cyrus = Daboo' <cyrus@daboo.name>;<= span class=3D"yiv1198500501Apple-converted-space"> apps-discuss@ietf.org<= span = class=3D"yiv1198500501Apple-converted-space"> 
Sent:=  Sunday, = June 17, 2012 6:48 PM
Subject: RE: = [apps-discuss] Aggregated service discovery
 
Bill,
 
My apologies for the belated reply.  I=92ve been busy this = week and got rather behind on email.
 
I do not personally like using SRV records, either.  SRV = records could work for smaller domains, but I=92m not sure that they=92re = the best solution for larger domains.  Personally, I would prefer = putting users on specific servers or server clusters and SRV records = will not differentiate users.
 
To use WebFinger to find one=92s IMAP, SMTP, or POP server, we = could do as I suggested in my email.  Now the question is what does = one query?  Since these three services are email, I=92d suggest we = query =93mailto:paulej@packetizer.c= om=94.  We could use another URI scheme (e.g., =93acct:=94), = but mailto seems most appropriate given that you=92re seeking info about = mail services.
 
I provided an example earlier that would simply point to a config = file with server information.  We could do this directly via = WebFinger like this:
 
GET = /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com
 
This query would then return something like this:
 
{
  "links" :
  [
    {
   =    "rel" : "smtp-server",
      "properties" :
      {
        "host" : "smtp.packetizer.com",<= /span>
        "port" : = "587",
        "login-required" : = "yes",
        "transport" : = "starttls"
      }
    },
    {
   =    "rel" : "imap-server",
      "properties" :
      {
        "host" : "imap.packetizer.com",<= /span>
        "port" : = "993",
        "transport" : = "ssl"
      }
    }
  ]
}
 
We would need to standardize the link relation values = (smtp-server and imap-server).  We would also need to document what = the various properties would be.  If you would like to create such a configuration document based on WebFinger, I=92d = be happy to help out.  In any case, you can see that WebFinger = would serve quite nicely for conveying configuration information given a = user=92s email ID.
 
I=92m not sure exactly what you would need for OAuth endpoints, = but I would suggest you make that a separate document since it is not = mail related.  (At least I assume it=92s not.  Even if it were, the mail server information = and OAuth information are still different animals.)
 
Paul
 
From: William Mills [mailto:wmills@yahoo-inc.c= om] 
Sent:=  Wednesday,= June 13, 2012 7:32 PM
To: Peter = Saint-Andre
Cc: Paul E. Jones; = 'Cyrus Daboo'; apps-discuss@ietf.org<= br>Subject: Re: [apps-discuss] Aggregated service discovery
 
In my = use case it's a service/server.
 
Not a = terribly happy answer to say "DNS SRV records won't work for you, and = there is no other solution.".  By the same token I could ask "Why = do we need Webfinger and host meta at all if we have DNS SRV = records?".
 
If XMPP uses SRV records for discovery, that's = fine.  IMAP and outbound SMTP services both lack a defined = discovery method other than the ubiquitous "service = documentation".  Is there a compelling reason to pick DNS over WF = for this?  =46rom the app developer point of view I don't want to = have N ways to discover M services.
 
-bill
 
 
From: Peter = Saint-Andre <stpeter@stpeter.im>=
To: William Mills = <wmills@yahoo-inc.com&g= t; 
Cc: Paul E. = Jones <paulej@packetizer.com&= gt;; 'Cyrus Daboo' <cyrus@daboo.name>; = "apps-discuss@ietf.org"= <apps-discuss@ietf.org&= gt; 
Sent:=  Wednesday,= June 13, 2012 3:57 PM
Subject: Re: = [apps-discuss] Aggregated service discovery

On 6/13/12 4:54 PM, William Mills = wrote:
> As I said, I'm interested specifically in IMAP, SMTP and = OAuth endpoints. 

What = exactly is an "endpoint"? A client? An account? A server?

> As = a data point, DNS SRV records are not controllable in many = hosted
> domain models.

At the last XMPP Summit a few = months ago, we learned that DNS SRV
records are unavailable in whole = countries (e.g., Japan). That doesn't
mean we should define a = replacement for DNS over HTTP. :)

Peter

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



<= /div>
=  
= _______________________________________________
apps-discuss mailing = list
apps-discuss@ietf.org
https://www.ie= tf.org/mailman/listinfo/apps-discuss


=

= --Apple-Mail=_C0A35206-9E3E-4997-89CD-6EABDA051AA3-- --Apple-Mail=_39FEC628-0BD5-4285-A37D-112E73554ECC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYx ODIwMTkwOVowIwYJKoZIhvcNAQkEMRYEFJp+0RrlA4Z7xFsas/s7UV+FHfeQMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACBl1QXeOpmoGaKEbwGs/Q/2K1H0SW4yYbL2BfQJynjEtsSwEbcB424poCGwb97A7FLqs5lSb5Gv R8D6KhieYTXcoOKgD+rEZa2EdkIsS0C5zKJWlauFiNxV9XGNZKxflBKaMzUcK7AiacVrfR4/Yeas FzefJkQ6ylb2ih68Lu4cISeymTALgbeO8PBOnvsfu2r4XI9Vr2humb2Kbt9g4mzkF5tgXSFZZ8u3 jFEbbo9qm+Qk+ROTtHdupUtfKqFkLDFbKQ3Q75jj0+1AGQY+63eoVSjtbT4NKlKBmc2SuyG6vZ64 V3JnQwwNaTvEt1DffxGdrlvuXBlC797c8ZSF8XoAAAAAAAA= --Apple-Mail=_39FEC628-0BD5-4285-A37D-112E73554ECC-- From wmills@yahoo-inc.com Mon Jun 18 13:36:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BD711E80A4 for ; Mon, 18 Jun 2012 13:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.534 X-Spam-Level: X-Spam-Status: No, score=-17.534 tagged_above=-999 required=5 tests=[AWL=0.064, 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 j32wmkrk2dkA for ; Mon, 18 Jun 2012 13:36:02 -0700 (PDT) Received: from nm29-vm0.bullet.mail.ac4.yahoo.com (nm29-vm0.bullet.mail.ac4.yahoo.com [98.139.52.248]) by ietfa.amsl.com (Postfix) with SMTP id 3B93411E8095 for ; Mon, 18 Jun 2012 13:36:02 -0700 (PDT) Received: from [98.139.52.195] by nm29.bullet.mail.ac4.yahoo.com with NNFMP; 18 Jun 2012 20:35:58 -0000 Received: from [98.139.52.142] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 18 Jun 2012 20:35:58 -0000 Received: from [127.0.0.1] by omp1025.mail.ac4.yahoo.com with NNFMP; 18 Jun 2012 20:35:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 35266.47077.bm@omp1025.mail.ac4.yahoo.com Received: (qmail 16743 invoked by uid 60001); 18 Jun 2012 20:35:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1340051757; bh=NIqraT61RVV/Y563pQXiq/5ZG422yC74CBckFmnsDoA=; 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=dgdknYTEtgOpVxVlo84oFePIOtlU7CwuT6saUb3eT/ktNtaVjhz8s3zT/kH5S4RQCW+io4Ir3pMkVE6LJFwNQlzGsK4llDHysRhGPjOIH4VRFqUF6KtCMDHzRahszpEKDpPkWPqI/+78YoCTYcaLI21U2kKeHiNHFLz5lIh16Pk= 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=Ypj4qlABWtsUU0aB6qThF+f3nPHqggEJNe6gcCEkguIB6i9bCQH5IWyNFT0m/bb1UhBnCw4181bRU/b1NJBkRztHB7/flPc1Gd+0Db6o/Z/s5QvnA0RPT7fIZ4oZ81E6Hn+2+k3/cWz0h2mymL94ZnfP36doAIasiHVx8aHRP/U=; X-YMail-OSG: LdaLwowVM1l9p_pyyCsaUSXR62ONm9t2M6E1Mz0Vx2J0dx. 5fLam1eLXtgIWT_jHuYXElW56Tm_KLgcFUd0CBaDnXmkLDoF5x0MhY5GVKpH Zzw97uyd_d6HY3MHme_r0OWkOqJk9L08ok.neQ2dJzPQV9hbm8LxQdRTdEjG dbw41zhfL5wU0a5dT7oj3mS4NaKJxjHTz4WANxlZrLXKh4sU8HZHbcZRxOrh abic9WZVEC.JO.gP2J8w0XELAUne6Ftn6681nVy_kAMhqjA1FcQC3Kxg2FaR 6Mvv8wA5XrObIVuzQh.XWDYCOJ4rqDUsVCGKCLsKXEYSviLRukx42E15QraQ RVkesjQ58lwSjiyBsDu3N3Bpv_sY4YQUPJzUkOJr7dhvITwrGKOsLWYXX4AW DpWa9wBUD9z1xKuTAEBoYvRRnompYkb9Gr22jbPkMKZ9Uwutlvc740Dv_p7l nVJNlOxUQZiS.fBVeXngbGWdBgvoaaZfbe8eZrQLblDDZ9tCBMX.wSCFIebr a0XQCEqUJ46XTVh6aySLF8pvykrtD6edRSsueonFgmcSwgA-- Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Mon, 18 Jun 2012 13:35:57 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> <1340047154.69599.YahooMailNeo@web31803.mail.mud.yahoo.com> <24783551-C1B8-456B-8E94-9BF59A3CAC75@ve7jtb.com> Message-ID: <1340051757.92228.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Mon, 18 Jun 2012 13:35:57 -0700 (PDT) From: William Mills To: John Bradley In-Reply-To: <24783551-C1B8-456B-8E94-9BF59A3CAC75@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1502656925-674596147-1340051757=:92228" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery 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, 18 Jun 2012 20:36:04 -0000 --1502656925-674596147-1340051757=:92228 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I believe you meant description where you wrote decryption...=0A=0AIMAP lik= ely is advertized with host-meta, however I do have a use case where premiu= m users may get a different DOS guarantee and might be handled on a differe= nt set of servers, and therefor a per-user return would be appropriate.=0A= =0A=0A=0A=0A>________________________________=0A> From: John Bradley =0A>To: William Mills =0A>Cc: Paul E. J= ones ; 'Peter Saint-Andre' ; "ap= ps-discuss@ietf.org" =0A>Sent: Monday, June 18, 201= 2 1:19 PM=0A>Subject: Re: [apps-discuss] Aggregated service discovery=0A> = =0A>=0A>That is not what I am saying.=0A>=0A>=0A>I am saying that the user'= s discovery document has a link relation to the providers decryption of the= service. =C2=A0 That is different from the imap endpoint providing the lin= k relation.=0A>=0A>=0A>If you can trust the user's information to provide t= he Oauth endpoint why can't you trust the user's information to link to the= description of the service.=0A>=0A>=0A>As I have pointed out before you pr= obably don't want per user configuration for things like imap, =C2=A0the si= mplest thing is to describe the service in host-meta and forget the extra u= ser discovery steps and maintenance.=0A>=0A>=0A>John B.=0A>=0A>=0A>On 2012-= 06-18, at 3:19 PM, William Mills wrote:=0A>=0A>Unfortunately we came to the= conclusion that letting a service endpoint define it's authenticators is p= robably wrong, this was in the context of discovery for SASL mechanisms.=C2= =A0 The core problem is when the client supports the password grant if it t= hen trusts the service endpoint to tell it who to give the username passwor= d pair then it's vulnerable.=0A>>=0A>>=0A>>=0A>>>__________________________= ______=0A>>> From: John Bradley =0A>>>To: Paul E. Jones = =0A>>>Cc: 'William Mills' ; '= Peter Saint-Andre' ; apps-discuss@ietf.org =0A>>>Sent: = Monday, June 18, 2012 11:36 AM=0A>>>Subject: Re: [apps-discuss] Aggregated = service discovery=0A>>> =0A>>>=0A>>>A user is likely to have a number of OA= uth authorization services for different things. =C2=A0=0A>>>=0A>>>=0A>>>I = suspect that the best way to organize it is to describe the services the us= er has:=0A>>>openID Connect=0A>>>imap=0A>>>portable contacts=0A>>>etc=0A>>>= =0A>>>=0A>>>and let the service describe how it is authenticated and where = the endpoints are.=0A>>>=0A>>>=0A>>>For Connect there is a single relation = for the Connect issuer and that is then discovered to get the endpoint and = other configuration information. =C2=A0=0A>>>Given that user identifiers ma= y point to services in other domains it is best to leave it up to the servi= ce to describe itself rather than relying on individual user information to= be correct.=0A>>>=0A>>>=0A>>>John B.=0A>>>=0A>>>=0A>>>On 2012-06-18, at 2:= 22 PM, Paul E. Jones wrote:=0A>>>=0A>>>Bill,=0A>>>>=C2=A0=0A>>>>In the refe= renced draft below, I assume the =E2=80=9Cgrant-types=E2=80=9D and =E2=80= =9Ctoken-types=E2=80=9D should be contained inside a =E2=80=9Cproperties=E2= =80=9D?=C2=A0 That is, I think you want this:=0A>>>>=C2=A0=0A>>>>{=0A>>>>= =C2=A0 "subject" : "acct:carol@example.com",=0A>>>>=C2=A0 "links" :=0A>>>>= =C2=A0 [=0A>>>>=C2=A0=C2=A0=C2=A0 {=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "r= el" : "oauth2-athorize",=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "href" : "htt= p://login.example.com/oauth2/authorize"=0A>>>>=C2=A0=C2=A0=C2=A0 },=0A>>>>= =C2=A0=C2=A0=C2=A0 {=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : "oauth2-t= oken",=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "href" : "https://login.example= .com/oauth2/token",=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"properties" :=0A>>= >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0"grant-types" : "code password",=0A>>>>=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0"token-types" : "bearer"=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 }=0A>>>>=C2=A0=C2=A0=C2=A0 }=0A>>>>=C2=A0 ]=0A>>>>}=0A>>>>=C2=A0=0A>= >>>For auto-provisioning of email clients (which I understand was your goal= ), we can either define one link relation that points to a separate configu= ration document of some sort, or we define multiple link relations.=C2=A0 M= y previous example showed the single link relation and the email below show= s use of multiple.=C2=A0 Both have pros and cons, but I tend to favor using= multiple link relations, since this allows one to introduce new stuff with= out changing the one mail configuration file.=C2=A0 Also, it reduces the nu= mber of queries a mail client has to make to get config information.=0A>>>>= =C2=A0=0A>>>>You indicate that IMAP already has a defined URI.=C2=A0 Where = is that defined?=C2=A0 I could not find it in the IANA link relations regis= try, so I assume it=E2=80=99s really a URI defined in a spec somewhere.=C2= =A0 In any case, we could use URIs for these things (rather than defining s= ingle token link relation values and registering them).=C2=A0 I have no pre= ference, but I would like an agreed approach to provisioning.=C2=A0 I hate = configuring all the stuff manually on email clients. :-)=0A>>>>=C2=A0=0A>>>= >Paul=0A>>>>=C2=A0=0A>>>>From:=C2=A0William Mills [mailto:wmills@yahoo-inc.= com]=C2=A0=0A>>>>Sent:=C2=A0Monday, June 18, 2012 1:36 PM=0A>>>>To:=C2=A0Pa= ul E. Jones; 'Peter Saint-Andre'=0A>>>>Cc:=C2=A0'Cyrus Daboo'; apps-discuss= @ietf.org=0A>>>>Subject:=C2=A0Re: [apps-discuss] Aggregated service discove= ry=0A>>>>=C2=A0=0A>>>>Paul,=0A>>>>=C2=A0=0A>>>>Thanks for the reply on this= .=C2=A0 I do already have a separate doc for registering the OAuth specific= relations,http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html=0A>>>>= =C2=A0=0A>>>>I don't think I like the thought of having to register a new l= ink type for every service, but that might be the right way.=C2=A0 IMAP alr= eady has a URI defined for example so if we use a more general link relatio= n then the URI scheme details the type.=C2=A0 The tradeoff is whether you c= an look for a specific link-type or if you have to scan list elements for t= he URI type you need.=0A>>>>=C2=A0=0A>>>>-bill=0A>>>>=C2=A0=0A>>>>=C2=A0=0A= >>>>>=0A>>>>>________________________________=0A>>>>>=0A>>>>>From:=C2=A0Pau= l E. Jones =0A>>>>>To:=C2=A0'William Mills' ; 'Peter Saint-Andre' =C2=A0=0A>>>>>Cc:= =C2=A0'Cyrus Daboo' ;=C2=A0apps-discuss@ietf.org=C2=A0=0A= >>>>>Sent:=C2=A0Sunday, June 17, 2012 6:48 PM=0A>>>>>Subject:=C2=A0RE: [app= s-discuss] Aggregated service discovery=0A>>>>>=C2=A0=0A>>>>>Bill,=0A>>>>>= =C2=A0=0A>>>>>My apologies for the belated reply.=C2=A0 I=E2=80=99ve been b= usy this week and got rather behind on email.=0A>>>>>=C2=A0=0A>>>>>I do not= personally like using SRV records, either.=C2=A0 SRV records could work fo= r smaller domains, but I=E2=80=99m not sure that they=E2=80=99re the best s= olution for larger domains.=C2=A0 Personally, I would prefer putting users = on specific servers or server clusters and SRV records will not differentia= te users.=0A>>>>>=C2=A0=0A>>>>>To use WebFinger to find one=E2=80=99s IMAP,= SMTP, or POP server, we could do as I suggested in my email.=C2=A0 Now the= question is what does one query?=C2=A0 Since these three services are emai= l, I=E2=80=99d suggest we query =E2=80=9Cmailto:paulej@packetizer.com=E2=80= =9D.=C2=A0 We could use another URI scheme (e.g., =E2=80=9Cacct:=E2=80=9D),= but mailto seems most appropriate given that you=E2=80=99re seeking info a= bout mail services.=0A>>>>>=C2=A0=0A>>>>>I provided an example earlier that= would simply point to a config file with server information.=C2=A0 We coul= d do this directly via WebFinger like this:=0A>>>>>=C2=A0=0A>>>>>GET /.well= -known/host-meta?resource=3Dmailto:paulej@packetizer.com=0A>>>>>=C2=A0=0A>>= >>>This query would then return something like this:=0A>>>>>=C2=A0=0A>>>>>{= =0A>>>>>=C2=A0 "subject" : "mailto:paulej@packetizer.com",=0A>>>>>=C2=A0 "l= inks" :=0A>>>>>=C2=A0 [=0A>>>>>=C2=A0=C2=A0=C2=A0 {=0A>>>>>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "rel" : "smtp-server",=0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 "properties" :=0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=0A>>>>>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "host" : "smtp.packetizer.com",=0A>>>>>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "port" : "587",=0A>>>>>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "login-required" : "yes",=0A>>>>>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "transport" : "starttls"=0A>>>>>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 }=0A>>>>>=C2=A0=C2=A0=C2=A0 },=0A>>>>>=C2=A0=C2=A0= =C2=A0 {=0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : "imap-server",=0A>>>= >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "properties" :=0A>>>>>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 {=0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "host" : "= imap.packetizer.com",=0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "po= rt" : "993",=0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "transport" = : "ssl"=0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=0A>>>>>=C2=A0=C2=A0=C2=A0 }= =0A>>>>>=C2=A0 ]=0A>>>>>}=0A>>>>>=C2=A0=0A>>>>>We would need to standardize= the link relation values (smtp-server and imap-server).=C2=A0 We would als= o need to document what the various properties would be.=C2=A0 If you would= like to create such a configuration document based on WebFinger, I=E2=80= =99d be happy to help out.=C2=A0 In any case, you can see that WebFinger wo= uld serve quite nicely for conveying configuration information given a user= =E2=80=99s email ID.=0A>>>>>=C2=A0=0A>>>>>I=E2=80=99m not sure exactly what= you would need for OAuth endpoints, but I would suggest you make that a se= parate document since it is not mail related.=C2=A0 (At least I assume it= =E2=80=99s not.=C2=A0 Even if it were, the mail server information and OAut= h information are still different animals.)=0A>>>>>=C2=A0=0A>>>>>Paul=0A>>>= >>=C2=A0=0A>>>>>From:=C2=A0William Mills=C2=A0[mailto:wmills@yahoo-inc.com]= =C2=A0=0A>>>>>Sent:=C2=A0Wednesday, June 13, 2012 7:32 PM=0A>>>>>To:=C2=A0P= eter Saint-Andre=0A>>>>>Cc:=C2=A0Paul E. Jones; 'Cyrus Daboo';=C2=A0apps-di= scuss@ietf.org=0A>>>>>Subject:=C2=A0Re: [apps-discuss] Aggregated service d= iscovery=0A>>>>>=C2=A0=0A>>>>>In my use case it's a service/server.=0A>>>>>= =C2=A0=0A>>>>>Not a terribly happy answer to say "DNS SRV records won't wor= k for you, and there is no other solution.".=C2=A0 By the same token I coul= d ask "Why do we need Webfinger and host meta at all if we have DNS SRV rec= ords?".=0A>>>>>=C2=A0=0A>>>>>If XMPP uses SRV records for discovery, that's= fine.=C2=A0 IMAP and outbound SMTP services both lack a defined discovery = method other than the ubiquitous "service documentation".=C2=A0 Is there a = compelling reason to pick DNS over WF for this?=C2=A0 From the app develope= r point of view I don't want to have N ways to discover M services.=0A>>>>>= =C2=A0=0A>>>>>-bill=0A>>>>>=C2=A0=0A>>>>>=C2=A0=0A>>>>>>=0A>>>>>>__________= ______________________=0A>>>>>>=0A>>>>>>From:=C2=A0Peter Saint-Andre =0A>>>>>>To:=C2=A0William Mills =C2=A0= =0A>>>>>>Cc:=C2=A0Paul E. Jones ; 'Cyrus Daboo' ; "apps-discuss@ietf.org" =C2=A0=0A>>>= >>>Sent:=C2=A0Wednesday, June 13, 2012 3:57 PM=0A>>>>>>Subject:=C2=A0Re: [a= pps-discuss] Aggregated service discovery=0A>>>>>>=0A>>>>>>On 6/13/12 4:54 = PM, William Mills wrote:=0A>>>>>>> As I said, I'm interested specifically i= n IMAP, SMTP and OAuth=0A endpoints.=C2=A0=0A>>>>>>=0A>>>>>>What exactly is= an "endpoint"? A client? An account? A server?=0A>>>>>>=0A>>>>>>> As a dat= a point, DNS SRV records are not controllable in many hosted=0A>>>>>>> doma= in models.=0A>>>>>>=0A>>>>>>At the last XMPP Summit a few months ago, we le= arned that DNS SRV=0A>>>>>>records are unavailable in whole countries (e.g.= , Japan). That doesn't=0A>>>>>>mean we should define a replacement for DNS = over HTTP. :)=0A>>>>>>=0A>>>>>>Peter=0A>>>>>>=0A>>>>>>--=C2=A0=0A>>>>>>Pete= r Saint-Andre=0A>>>>>>https://stpeter.im/=0A>>>>>>=0A>>>>>>=0A>>>>>>=0A>>>>= >>=0A>>>>>>=0A>>>>>=C2=A0=0A_______________________________________________= =0A>>>>apps-discuss mailing list=0A>>>>apps-discuss@ietf.org=0A>>>>https://= www.ietf.org/mailman/listinfo/apps-discuss=0A>>>=0A>>>=0A>>>=0A>=0A>=0A> --1502656925-674596147-1340051757=:92228 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I be= lieve you meant description where you wrote decryption...

IMAP likely is advertized with host-meta, however I do have a use c= ase where premium users may get a different DOS guarantee and might be hand= led on a different set of servers, and therefor a per-user return would be = appropriate.

=
From: John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: Paul E. Jones <paulej@pa= cketizer.com>; 'Peter Saint-Andre' <stpeter@stpeter.im>; "apps-dis= cuss@ietf.org" <apps-discuss@ietf.org>
Sent: Monday, June 18, 2012 1:19 PM
Subject: Re: [apps-discuss] Aggregate= d service discovery

=0A
That is not what I am saying.

I am saying that the use= r's discovery document has a link relation to the providers decryption of t= he service.   That is different from the imap endpoint providing the l= ink relation.

If you can trust the user's informat= ion to provide the Oauth endpoint why can't you trust the user's informatio= n to link to the description of the service.

As I = have pointed out before you probably don't want per user configuration for = things like imap,  the simplest thing is to describe the service in ho= st-meta and forget the extra user discovery steps and maintenance.

John B.

On 2012-06-18, at 3:19 PM,= William Mills wrote:

Unfortunately we= came to the conclusion that letting a service endpoint define it's authent= icators is probably wrong, this was in the context of discovery for SASL me= chanisms.  The core problem is when the client supports the password g= rant if it then trusts the service endpoint to tell it who to give the user= name password pair then it's vulnerable.

=
From: John Bradley=0A <ve7jtb@ve7jtb.com>
To: Paul E. Jones <paulej@packetizer.com>
Cc: 'William Mills' <wmills@yahoo-inc.com>; 'Peter Saint-Andre' <stpeter@stpeter.im>; apps-discuss@ietf.org
Sent: Monday, June 18, 2012 11:36 AM
Subject: Re: [apps-discuss] Aggrega= ted service discovery

=0A
<= base>
A user is likely to have a number of OAuth authorization services= for different things.  

I suspect that the best wa= y to organize it is to describe the services the user has:
openID= Connect
imap
portable contacts
etc

and let the service describe how it is authenticated and wh= ere the endpoints are.

For Connect there is a sing= le relation for the Connect issuer and that is then discovered to get the e= ndpoint and other configuration information.  
Given that us= er identifiers may point to services in other domains it is best to leave i= t up to the service to describe itself rather than relying on individual us= er information to be correct.

John B.
On 2012-06-18, at 2:22 PM, Paul E. Jones wrote:

Bill,
 
In the referenced draf= t below, I assume the =E2=80=9Cgrant-types=E2=80=9D and =E2=80=9Ctoken-type= s=E2=80=9D should be contained inside a =E2=80=9Cproperties=E2=80=9D? = That is, I think you want this:
 
{
  "subject" : "acct:carol@example.com",
  "links" :
  [
    {
      "rel" : "oauth2-athorize",
    &nbs= p; "href" : "= http://login.example.com/oauth2/authorize"
    },
    {=
   =    "rel" : "oauth2-token",
     "properties" :
      {<= /span>
  &= nbsp;    "grant-types" : "code password",
<= div style=3D"margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:= 0.0001pt;font-size:12pt;font-family:serif;">     &= nbsp;  "token-types" : "bearer"
     = ; }
 &n= bsp;  }
  ]
}<= /span>
 
For auto-provisionin= g of email clients (which I understand was your goal), we can either define= one link relation that points to a separate configuration document of some= sort, or we define multiple link relations.  My previous example show= ed the single link relation and the email below shows use of multiple. = ; Both have pros and cons, but I tend to favor using multiple link relation= s, since this allows one to introduce new stuff without changing the one ma= il configuration file.  Also, it reduces the number of queries a mail= =0A client has to make to get config information.
 
You indicate that IMAP alrea= dy has a defined URI.  Where is that defined?  I could not find i= t in the IANA link relations registry, so I assume it=E2=80=99s really a UR= I defined in a spec somewhere.  In any case, we could use URIs for the= se things (rather than defining single token link relation values and regis= tering them).  I have no preference, but I would like an agreed approa= ch to provisioning.  I hate configuring all the stuff manually on emai= l clients.=0A :-)
=  
Paul
 
= From: William Mills [m= ailto:wmills@yahoo-inc.com] 
Sent: Monday, June 18, 2012 1:36 PM
To: Paul E. Jones; 'Peter = Saint-Andre'
Cc: 'Cyrus Daboo'; <= a rel=3D"nofollow" ymailto=3D"mailto:apps-discuss@ietf.org" target=3D"_blan= k" href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org
Su= bject: R= e: [apps-discuss] Aggregated service discovery
 
Paul,
= =0A &= nbsp;
Thanks for the reply on this.  I do already have a se= parate doc for registering the OAuth specific relations,http://tools.ietf= .org/id/draft-wmills-oauth-lrdd-01.html
 
=
I don't th= ink I like the thought of having to register a new link type for every serv= ice, but that might be the right way.  IMAP already has a URI defined = for example so if we use a more general link relation then the URI scheme d= etails the type.  The tradeoff is whether you can look for a specific = link-type or if you have to scan list elements for the URI type you need.
 
-bill
 
 
From: = Paul E. Jones <paulej@packetizer.com>
To: 'Wi= lliam Mills' <wmills@yahoo-inc.com>; 'Peter Saint-Andre' <s= tpeter@stpeter.im> 
Cc: 'Cyrus Daboo' <cyrus@daboo.name>; apps-d= iscuss@ietf.org 
Sent:=  Sunday, Jun= e 17, 2012 6:48 PM
Subject: RE: [apps-discuss] Aggregated service discovery
=  
Bill,
&= nbsp;
My apol= ogies for the belated reply.  I=E2=80=99ve been busy this week and got= rather behind on email.
 
I= do not personally like using SRV records, either.  SRV records could = work for smaller domains, but I=E2=80=99m not sure that they=E2=80=99re the= best solution for larger domains.  Personally, I would prefer putting= users on specific servers or server clusters and SRV records will not diff= erentiate users.
 
T= o use WebFinger to find one=E2=80=99s IMAP, SMTP, or POP server, we could d= o as I suggested in my email.  Now the question is what does one query= ?  Since these three services are email, I=E2=80=99d suggest we query = =E2=80=9Cmailto:paulej@packetizer.com=E2=80=9D.  We= could use another URI scheme (e.g., =E2=80=9Cacct:=E2=80=9D), but mailto s= eems most appropriate given that you=E2=80=99re seeking info about mail ser= vices.
&= nbsp;
I provi= ded an example earlier that would simply point to a config file with server= information.  We could do this directly via WebFinger like this:
 
GET /.well-known/host-meta?r= esource=3Dmailto:paulej@packetizer.com<= /span>
 =
This query would then return something like this:
 
{
  "= links" :
  [=
  &nbs= p;=0A {
    &nbs= p; "rel" : "smtp-server",
<= /div>
      "properties" :
      {
    &nbs= p;   "host" : "sm= tp.packetizer.com",
        "port" : "587",
 = ;       "login-required" : "yes",
    &nbs= p;   "transport" : "starttls"=
      }
    },=
    {
      "rel" := "imap-server",
=
 = ;     "properties" :
      {
     &nbs= p;  "host" : "imap.packetizer.com",
        "port" : "99= 3",
  = ;      "transport" : "ssl"
 = ;     }
    }<= /div>
  ]
}
 
We would need to stand= ardize the link relation values (smtp-server and imap-server).  We wou= ld also need to document what the various properties would be.  If you= would=0A like to create such a configuration document based on WebFinger, = I=E2=80=99d be happy to help out.  In any case, you can see that WebFi= nger would serve quite nicely for conveying configuration information given= a user=E2=80=99s email ID.
 
<= span style=3D"font-size:11pt;font-family:Arial, sans-serif;color:rgb(31, 73= , 125);">I=E2=80=99m not sure exactly what you would need for OAuth endpoin= ts, but I would suggest you make that a separate document since it is not m= ail related.  (At least I=0A assume it=E2=80=99s not.  Even if it= were, the mail server information and OAuth information are still differen= t animals.)
&= nbsp;
Paul
 
From: William=0A Mills [mailto:wmills@yahoo-inc.com] 
Sent: Wednesday, June 13, 2012 7:32 PM
To: Peter Sai= nt-Andre
Cc:&n= bsp;Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org
Subject: Re:=0A [apps-discuss] Aggregated service discovery
&nbs= p;
In my use case it's a service/server.
 
Not a terribly h= appy answer to say "DNS SRV records won't work for you, and there is no oth= er solution.".  By the same token I could ask "Why do we need Webfinge= r and host meta at all if we have DNS SRV records?".
 
If XMPP uses SRV records for discovery, that's= fine.  IMAP and outbound SMTP services both lack a defined discovery = method other than the ubiquitous "service documentation".  Is there a = compelling reason to pick DNS over WF for this?  From the app develope= r point of view I don't want to have N ways to discover M services.<= span style=3D"color:black;">
 
-bill
 
 
From: Peter Saint-Andre <stpeter@stpeter.im>
To: William Mills &l= t;wmills@yahoo-inc.com> 
Cc: Paul E. Jones <paulej@= packetizer.com>; 'Cyrus Daboo' <cyrus@daboo.name>; "<= a rel=3D"nofollow" ymailto=3D"mailto:apps-discuss@ietf.org" target=3D"_blan= k" href=3D"mailto:apps-discuss@ietf.org" style=3D"color:blue;text-decoration:underline;">apps-discuss@ietf.org"= <apps-discuss@ietf.org> 
Sent: Wednesday, June 13, 2012 3:57 PM=
Subject: = ;Re: [apps-discuss] Aggregated service discovery

On 6/13/12 4:54 P= M, William Mills wrote:
> As I said, I'm interested specifically in I= MAP, SMTP and OAuth=0A endpoints. 

What exactly is an "endpoint"? A client? An a= ccount? A server?

> As a data point, DNS SRV records are not cont= rollable in many hosted
> domain models.

At the last XMPP Summ= it a few months ago, we learned that DNS SRV
records are unavailable in = whole countries (e.g., Japan). That doesn't
mean we should define a repl= acement for DNS over HTTP. :)

Peter

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




<= /span>
 
=
_______________________________________________
apps-= discuss mailing list
apps-disc= uss@ietf.org
https://www.ietf.org/mailman/lis= tinfo/apps-discuss






= --1502656925-674596147-1340051757=:92228-- From ve7jtb@ve7jtb.com Mon Jun 18 13:42: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 B6C2F11E80BD for ; Mon, 18 Jun 2012 13:42:45 -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 FfiPWUWAxgYp for ; Mon, 18 Jun 2012 13:42:42 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E54911E80B3 for ; Mon, 18 Jun 2012 13:42:36 -0700 (PDT) Received: by yenq13 with SMTP id q13so4605117yen.31 for ; Mon, 18 Jun 2012 13:42:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Hzsv7/FTLasQ/GeeXaxBL6Y2uwFSuE5B1r9shVEc4VQ=; b=Nnjy0zMlQEFbuRTsHwFDVFOmACXhWsSPNi1bMjH/dI12xtAGyaMfVLXfHRsOLn0zId bKr/QWfq6pAtjBqcUU4tYayriVcYie7vtEGElMbYckc9JNrHvgTpBnLcy1Pg0fFGQUrK LyLMKhWHeDO5/oKmRU/kMGszTPcK8pvbMxHOoaq5l3H7NKSq0U0VMxfI3pkWkcpEdqK4 rwEevqkiS3LLncdFkXV/XNsPTh5p9/moITOrIxcHuRFmKQeqqOxBSEdljCTuqcsMfeXX U77YHoK82SXkv1M/C+OFwB+xSFibZdL/MwdASVV4JtGQSiNxnma/qYe80IR4bfRlafYQ Swkg== Received: by 10.236.136.8 with SMTP id v8mr20150965yhi.101.1340052156292; Mon, 18 Jun 2012 13:42:36 -0700 (PDT) Received: from [192.168.1.213] (190-20-29-46.baf.movistar.cl. [190.20.29.46]) by mx.google.com with ESMTPS id w61sm68972159yhi.5.2012.06.18.13.42.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jun 2012 13:42:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_EEEC95CD-110E-4B7F-A770-AFB14AF2238F"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <1340051757.92228.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Mon, 18 Jun 2012 16:42:12 -0400 Message-Id: <3E2D94E4-C8E3-4AF2-A0F0-0C2BCB5B0AA5@ve7jtb.com> References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> <1340047154.69599.YahooMailNeo@web31803.mail.mud.yahoo.com> <24783551-C1B8-456B-8E94-9BF59A3CAC75@ve7jtb.com> <1340051757.92228.YahooMailNeo@web31803.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlAL/XUTWebyz6WZ0a/ONjnU1VLF+YOet6HzfWnfNLfyg3RCh3SxANxMebmTUFLqiMSn9Pj Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 20:42:46 -0000 --Apple-Mail=_EEEC95CD-110E-4B7F-A770-AFB14AF2238F Content-Type: multipart/alternative; boundary="Apple-Mail=_A817EB8A-5ABD-401B-BAA8-4AF67DCBB8A9" --Apple-Mail=_A817EB8A-5ABD-401B-BAA8-4AF67DCBB8A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 OK but you are talking about the OAuth authorization service for IMAP, = do you intend to run different ones for different users? If you are that's fine. However listing the service configuration in = the users XRD rather than pointing to it from the XRD is probably not a = good design. Listing a generic OAuth 2.0 authorization service in the users XRD is = interesting, but probably not specific enough. John B. On 2012-06-18, at 4:35 PM, William Mills wrote: > I believe you meant description where you wrote decryption... >=20 > IMAP likely is advertized with host-meta, however I do have a use case = where premium users may get a different DOS guarantee and might be = handled on a different set of servers, and therefor a per-user return = would be appropriate. >=20 > From: John Bradley > To: William Mills =20 > Cc: Paul E. Jones ; 'Peter Saint-Andre' = ; "apps-discuss@ietf.org" =20 > Sent: Monday, June 18, 2012 1:19 PM > Subject: Re: [apps-discuss] Aggregated service discovery >=20 > That is not what I am saying. >=20 > I am saying that the user's discovery document has a link relation to = the providers decryption of the service. That is different from the = imap endpoint providing the link relation. >=20 > If you can trust the user's information to provide the Oauth endpoint = why can't you trust the user's information to link to the description of = the service. >=20 > As I have pointed out before you probably don't want per user = configuration for things like imap, the simplest thing is to describe = the service in host-meta and forget the extra user discovery steps and = maintenance. >=20 > John B. >=20 > On 2012-06-18, at 3:19 PM, William Mills wrote: >=20 >> Unfortunately we came to the conclusion that letting a service = endpoint define it's authenticators is probably wrong, this was in the = context of discovery for SASL mechanisms. The core problem is when the = client supports the password grant if it then trusts the service = endpoint to tell it who to give the username password pair then it's = vulnerable. >>=20 >> From: John Bradley >> To: Paul E. Jones =20 >> Cc: 'William Mills' ; 'Peter Saint-Andre' = ; apps-discuss@ietf.org=20 >> Sent: Monday, June 18, 2012 11:36 AM >> Subject: Re: [apps-discuss] Aggregated service discovery >>=20 >> A user is likely to have a number of OAuth authorization services for = different things. =20 >>=20 >> I suspect that the best way to organize it is to describe the = services the user has: >> openID Connect >> imap >> portable contacts >> etc >>=20 >> and let the service describe how it is authenticated and where the = endpoints are. >>=20 >> For Connect there is a single relation for the Connect issuer and = that is then discovered to get the endpoint and other configuration = information. =20 >> Given that user identifiers may point to services in other domains it = is best to leave it up to the service to describe itself rather than = relying on individual user information to be correct. >>=20 >> John B. >>=20 >> On 2012-06-18, at 2:22 PM, Paul E. Jones wrote: >>=20 >>> Bill, >>> =20 >>> In the referenced draft below, I assume the =93grant-types=94 and = =93token-types=94 should be contained inside a =93properties=94? That = is, I think you want this: >>> =20 >>> { >>> "subject" : "acct:carol@example.com", >>> "links" : >>> [ >>> { >>> "rel" : "oauth2-athorize", >>> "href" : "http://login.example.com/oauth2/authorize" >>> }, >>> { >>> "rel" : "oauth2-token", >>> "href" : "https://login.example.com/oauth2/token", >>> "properties" : >>> { >>> "grant-types" : "code password", >>> "token-types" : "bearer" >>> } >>> } >>> ] >>> } >>> =20 >>> For auto-provisioning of email clients (which I understand was your = goal), we can either define one link relation that points to a separate = configuration document of some sort, or we define multiple link = relations. My previous example showed the single link relation and the = email below shows use of multiple. Both have pros and cons, but I tend = to favor using multiple link relations, since this allows one to = introduce new stuff without changing the one mail configuration file. = Also, it reduces the number of queries a mail client has to make to get = config information. >>> =20 >>> You indicate that IMAP already has a defined URI. Where is that = defined? I could not find it in the IANA link relations registry, so I = assume it=92s really a URI defined in a spec somewhere. In any case, we = could use URIs for these things (rather than defining single token link = relation values and registering them). I have no preference, but I = would like an agreed approach to provisioning. I hate configuring all = the stuff manually on email clients. :-) >>> =20 >>> Paul >>> =20 >>> From: William Mills [mailto:wmills@yahoo-inc.com]=20 >>> Sent: Monday, June 18, 2012 1:36 PM >>> To: Paul E. Jones; 'Peter Saint-Andre' >>> Cc: 'Cyrus Daboo'; apps-discuss@ietf.org >>> Subject: Re: [apps-discuss] Aggregated service discovery >>> =20 >>> Paul, >>> =20 >>> Thanks for the reply on this. I do already have a separate doc for = registering the OAuth specific = relations,http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html >>> =20 >>> I don't think I like the thought of having to register a new link = type for every service, but that might be the right way. IMAP already = has a URI defined for example so if we use a more general link relation = then the URI scheme details the type. The tradeoff is whether you can = look for a specific link-type or if you have to scan list elements for = the URI type you need. >>> =20 >>> -bill >>> =20 >>> =20 >>> From: Paul E. Jones >>> To: 'William Mills' ; 'Peter Saint-Andre' = =20 >>> Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org=20 >>> Sent: Sunday, June 17, 2012 6:48 PM >>> Subject: RE: [apps-discuss] Aggregated service discovery >>> =20 >>> Bill, >>> =20 >>> My apologies for the belated reply. I=92ve been busy this week and = got rather behind on email. >>> =20 >>> I do not personally like using SRV records, either. SRV records = could work for smaller domains, but I=92m not sure that they=92re the = best solution for larger domains. Personally, I would prefer putting = users on specific servers or server clusters and SRV records will not = differentiate users. >>> =20 >>> To use WebFinger to find one=92s IMAP, SMTP, or POP server, we could = do as I suggested in my email. Now the question is what does one query? = Since these three services are email, I=92d suggest we query = =93mailto:paulej@packetizer.com=94. We could use another URI scheme = (e.g., =93acct:=94), but mailto seems most appropriate given that you=92re= seeking info about mail services. >>> =20 >>> I provided an example earlier that would simply point to a config = file with server information. We could do this directly via WebFinger = like this: >>> =20 >>> GET /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com >>> =20 >>> This query would then return something like this: >>> =20 >>> { >>> "subject" : "mailto:paulej@packetizer.com", >>> "links" : >>> [ >>> { >>> "rel" : "smtp-server", >>> "properties" : >>> { >>> "host" : "smtp.packetizer.com", >>> "port" : "587", >>> "login-required" : "yes", >>> "transport" : "starttls" >>> } >>> }, >>> { >>> "rel" : "imap-server", >>> "properties" : >>> { >>> "host" : "imap.packetizer.com", >>> "port" : "993", >>> "transport" : "ssl" >>> } >>> } >>> ] >>> } >>> =20 >>> We would need to standardize the link relation values (smtp-server = and imap-server). We would also need to document what the various = properties would be. If you would like to create such a configuration = document based on WebFinger, I=92d be happy to help out. In any case, = you can see that WebFinger would serve quite nicely for conveying = configuration information given a user=92s email ID. >>> =20 >>> I=92m not sure exactly what you would need for OAuth endpoints, but = I would suggest you make that a separate document since it is not mail = related. (At least I assume it=92s not. Even if it were, the mail = server information and OAuth information are still different animals.) >>> =20 >>> Paul >>> =20 >>> From: William Mills [mailto:wmills@yahoo-inc.com]=20 >>> Sent: Wednesday, June 13, 2012 7:32 PM >>> To: Peter Saint-Andre >>> Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org >>> Subject: Re: [apps-discuss] Aggregated service discovery >>> =20 >>> In my use case it's a service/server. >>> =20 >>> Not a terribly happy answer to say "DNS SRV records won't work for = you, and there is no other solution.". By the same token I could ask = "Why do we need Webfinger and host meta at all if we have DNS SRV = records?". >>> =20 >>> If XMPP uses SRV records for discovery, that's fine. IMAP and = outbound SMTP services both lack a defined discovery method other than = the ubiquitous "service documentation". Is there a compelling reason to = pick DNS over WF for this? =46rom the app developer point of view I = don't want to have N ways to discover M services. >>> =20 >>> -bill >>> =20 >>> =20 >>> From: Peter Saint-Andre >>> To: William Mills =20 >>> Cc: Paul E. Jones ; 'Cyrus Daboo' = ; "apps-discuss@ietf.org" =20 >>> Sent: Wednesday, June 13, 2012 3:57 PM >>> Subject: Re: [apps-discuss] Aggregated service discovery >>>=20 >>> On 6/13/12 4:54 PM, William Mills wrote: >>> > As I said, I'm interested specifically in IMAP, SMTP and OAuth = endpoints.=20 >>>=20 >>> What exactly is an "endpoint"? A client? An account? A server? >>>=20 >>> > As a data point, DNS SRV records are not controllable in many = hosted >>> > domain models. >>>=20 >>> At the last XMPP Summit a few months ago, we learned that DNS SRV >>> records are unavailable in whole countries (e.g., Japan). That = doesn't >>> mean we should define a replacement for DNS over HTTP. :) >>>=20 >>> Peter >>>=20 >>> --=20 >>> Peter Saint-Andre >>> https://stpeter.im/ >>>=20 >>>=20 >>>=20 >>>=20 >>> =20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_A817EB8A-5ABD-401B-BAA8-4AF67DCBB8A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 OK = but you are talking about the OAuth authorization service for IMAP, =  do you intend to run different ones for different = users?

If you are that's fine.   However listing = the service configuration in the users XRD rather than pointing to it = from the XRD is probably not a good = design.

Listing a generic OAuth 2.0 = authorization service in the users XRD is interesting, but probably not = specific enough.

John B.
On = 2012-06-18, at 4:35 PM, William Mills wrote:

I believe = you meant description where you wrote = decryption...

IMAP likely is advertized with = host-meta, however I do have a use case where premium users may get a = different DOS guarantee and might be handled on a different set of = servers, and therefor a per-user return would be = appropriate.

From: John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills@yahoo-inc.com> =
Cc: Paul E. Jones = <paulej@packetizer.com>; = 'Peter Saint-Andre' <stpeter@stpeter.im>; "apps-discuss@ietf.org" <apps-discuss@ietf.org>
= Sent: Monday, June 18, = 2012 1:19 PM
Subject: Re: [apps-discuss] Aggregated service = discovery

That is not what I am = saying.

I am saying that the user's discovery = document has a link relation to the providers decryption of the service. =   That is different from the imap endpoint providing the link = relation.

If you can trust the user's = information to provide the Oauth endpoint why can't you trust the user's = information to link to the description of the = service.

As I have pointed out before you = probably don't want per user configuration for things like imap, =  the simplest thing is to describe the service in host-meta and = forget the extra user discovery steps and = maintenance.

John B.

On = 2012-06-18, at 3:19 PM, William Mills wrote:

Unfortunately = we came to the conclusion that letting a service endpoint define it's = authenticators is probably wrong, this was in the context of discovery = for SASL mechanisms.  The core problem is when the client supports = the password grant if it then trusts the service endpoint to tell it who = to give the username password pair then it's = vulnerable.

From: John Bradley <ve7jtb@ve7jtb.com>
To: Paul E. Jones <paulej@packetizer.com> =
Cc: 'William Mills' = <wmills@yahoo-inc.com>; = 'Peter Saint-Andre' <stpeter@stpeter.im>; apps-discuss@ietf.org
= Sent: Monday, June 18, = 2012 11:36 AM
Subject:= Re: [apps-discuss] Aggregated service discovery

A user is likely to have a number = of OAuth authorization services for different things. =  

I suspect that the best way to organize it is = to describe the services the user has:
openID = Connect
imap
portable = contacts
etc

and let the service = describe how it is authenticated and where the endpoints = are.

For Connect there is a single relation for = the Connect issuer and that is then discovered to get the endpoint and = other configuration information.  
Given that user = identifiers may point to services in other domains it is best to leave = it up to the service to describe itself rather than relying on = individual user information to be correct.

John = B.

On 2012-06-18, at 2:22 PM, Paul E. Jones = wrote:

Bill,
 
In the referenced draft below, I assume the =93grant-types=94 = and =93token-types=94 should be contained inside a =93properties=94? = That is, I think you want this:
 
{
  "subject" : "acct:carol@example.com",
  "links" :
  [
    {
      "rel" : = "oauth2-athorize",
    },
    {
      "rel" : = "oauth2-token",
     "properties" :
      {
       "grant-types" : "code = password",
        "token-types" : = "bearer"
      }
    }
  ]
}
 
For auto-provisioning of email clients (which I understand = was your goal), we can either define one link relation that points to a = separate configuration document of some sort, or we define multiple link = relations.  My previous example showed the single link relation and = the email below shows use of multiple.  Both have pros and cons, = but I tend to favor using multiple link relations, since this allows one = to introduce new stuff without changing the one mail configuration = file.  Also, it reduces the number of queries a mail client has to make to get config information.
 
You indicate that IMAP already has a defined URI.  Where = is that defined?  I could not find it in the IANA link relations = registry, so I assume it=92s really a URI defined in a spec = somewhere.  In any case, we could use URIs for these things (rather = than defining single token link relation values and registering = them).  I have no preference, but I would like an agreed approach = to provisioning.  I hate configuring all the stuff manually on = email clients. :-)
 
Paul
 
From: William Mills = [mailto:wmills@yahoo-inc.com] 
Sent:=  Monday, = June 18, 2012 1:36 PM
To: Paul E. Jones; = 'Peter Saint-Andre'
Cc: 'Cyrus Daboo'; = apps-discuss@ietf.org
Subj= ect: Re: = [apps-discuss] Aggregated service discovery
 
Paul,
 
Thanks = for the reply on this.  I do already have a separate doc for = registering the OAuth specific relations,http://tools.ietf.org/id/d= raft-wmills-oauth-lrdd-01.html
=  
I don't = think I like the thought of having to register a new link type for every = service, but that might be the right way.  IMAP already has a URI = defined for example so if we use a more general link relation then the = URI scheme details the type.  The tradeoff is whether you can look = for a specific link-type or if you have to scan list elements for the = URI type you need.
=  
-bill
=  
=  
From: Paul E. Jones = <paulej@packetizer.com&= gt;
To: 'William = Mills' <wmills@yahoo-inc.com&g= t;; 'Peter Saint-Andre' <stpeter@stpeter.im>=  
Cc: 'Cyrus = Daboo' <cyrus@daboo.name>;<= span class=3D"yiv1035727011Apple-converted-space"> apps-discuss@ietf.org<= span = class=3D"yiv1035727011Apple-converted-space"> 
Sent:=  Sunday, = June 17, 2012 6:48 PM
Subject: RE: = [apps-discuss] Aggregated service discovery
 
Bill,
 
My apologies for the belated reply.  I=92ve been busy this = week and got rather behind on email.
 
I do not personally like using SRV records, either.  SRV = records could work for smaller domains, but I=92m not sure that they=92re = the best solution for larger domains.  Personally, I would prefer = putting users on specific servers or server clusters and SRV records = will not differentiate users.
 
To use WebFinger to find one=92s IMAP, SMTP, or POP server, we = could do as I suggested in my email.  Now the question is what does = one query?  Since these three services are email, I=92d suggest we = query =93mailto:paulej@packetizer.c= om=94.  We could use another URI scheme (e.g., =93acct:=94), = but mailto seems most appropriate given that you=92re seeking info about = mail services.
 
I provided an example earlier that would simply point to a config = file with server information.  We could do this directly via = WebFinger like this:
 
GET = /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com
 
This query would then return something like this:
 
{
  "links" :
  [
    {
   =    "rel" : "smtp-server",
      "properties" :
      {
        "host" : "smtp.packetizer.com",<= /span>
        "port" : = "587",
        "login-required" : = "yes",
        "transport" : = "starttls"
      }
    },
    {
   =    "rel" : "imap-server",
      "properties" :
      {
        "host" : "imap.packetizer.com",<= /span>
        "port" : = "993",
        "transport" : = "ssl"
      }
    }
  ]
}
 
We would need to standardize the link relation values = (smtp-server and imap-server).  We would also need to document what = the various properties would be.  If you would like to create such a configuration document based on WebFinger, I=92d = be happy to help out.  In any case, you can see that WebFinger = would serve quite nicely for conveying configuration information given a = user=92s email ID.
 
I=92m not sure exactly what you would need for OAuth endpoints, = but I would suggest you make that a separate document since it is not = mail related.  (At least I assume it=92s not.  Even if it were, the mail server information = and OAuth information are still different animals.)
 
Paul
 
From: William Mills [mailto:wmills@yahoo-inc.c= om] 
Sent:=  Wednesday,= June 13, 2012 7:32 PM
To: Peter = Saint-Andre
Cc: Paul E. Jones; = 'Cyrus Daboo'; apps-discuss@ietf.org<= br>Subject: Re: [apps-discuss] Aggregated service discovery
 
In my = use case it's a service/server.
 
Not a = terribly happy answer to say "DNS SRV records won't work for you, and = there is no other solution.".  By the same token I could ask "Why = do we need Webfinger and host meta at all if we have DNS SRV = records?".
 
If XMPP uses SRV records for discovery, that's = fine.  IMAP and outbound SMTP services both lack a defined = discovery method other than the ubiquitous "service = documentation".  Is there a compelling reason to pick DNS over WF = for this?  =46rom the app developer point of view I don't want to = have N ways to discover M services.
 
-bill
 
 
From: Peter = Saint-Andre <stpeter@stpeter.im>=
To: William Mills = <wmills@yahoo-inc.com&g= t; 
Cc: Paul E. = Jones <paulej@packetizer.com&= gt;; 'Cyrus Daboo' <cyrus@daboo.name>; = "apps-discuss@ietf.org"= <apps-discuss@ietf.org&= gt; 
Sent:=  Wednesday,= June 13, 2012 3:57 PM
Subject: Re: = [apps-discuss] Aggregated service discovery

On 6/13/12 4:54 PM, William Mills = wrote:
> As I said, I'm interested specifically in IMAP, SMTP and = OAuth endpoints. 

What = exactly is an "endpoint"? A client? An account? A server?

> As = a data point, DNS SRV records are not controllable in many = hosted
> domain models.

At the last XMPP Summit a few = months ago, we learned that DNS SRV
records are unavailable in whole = countries (e.g., Japan). That doesn't
mean we should define a = replacement for DNS over HTTP. :)

Peter

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



<= /div>
=  
= _______________________________________________
apps-discuss mailing = list
apps-discuss@ietf.org
https://www.ie= tf.org/mailman/listinfo/apps-discuss


=



=
=

= --Apple-Mail=_A817EB8A-5ABD-401B-BAA8-4AF67DCBB8A9-- --Apple-Mail=_EEEC95CD-110E-4B7F-A770-AFB14AF2238F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYx ODIwNDIxM1owIwYJKoZIhvcNAQkEMRYEFMXQQyP5PZz66GtzW/EJxJUZbi63MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ABoKDmCmEuVOURWL08ii+1fz+S58Y8K6lAclZPz5wrfnTjLf/59oTMM4dje6s9wfYhRgE/Lk7rCp 1GwyyT45tYhGC2//D2yiJdYgQMfkEAltNyYkJSgciztLkhHQPTGr//7RKjm4nH9Se8Mek0/jO+GE bB7QXKiE1JS/4uc4QTGrfH6MUhZLswSEf/anI1q7FA09epeCRPu7hkgUpwmw5l6BTBcgxmAuuDr5 ay/AhYGd1p5GP6uZeZ7vBVGABO/SZO6vP7W9uPz+PtHdXhlSOrD31m2S1GS9eMDHQpOu5HcIlwgL U1by0Vu4xrIQc0YDZa4PtC0S+/ADH51tXnaf5T8AAAAAAAA= --Apple-Mail=_EEEC95CD-110E-4B7F-A770-AFB14AF2238F-- From wmills@yahoo-inc.com Mon Jun 18 13:56: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 1C39821F85F3 for ; Mon, 18 Jun 2012 13:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.536 X-Spam-Level: X-Spam-Status: No, score=-17.536 tagged_above=-999 required=5 tests=[AWL=0.062, 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 aFTI2RNC5Rxm for ; Mon, 18 Jun 2012 13:56:49 -0700 (PDT) Received: from nm28-vm1.bullet.mail.ne1.yahoo.com (nm28-vm1.bullet.mail.ne1.yahoo.com [98.138.91.35]) by ietfa.amsl.com (Postfix) with SMTP id EBB7421F85FB for ; Mon, 18 Jun 2012 13:56:48 -0700 (PDT) Received: from [98.138.90.55] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jun 2012 20:56:45 -0000 Received: from [98.138.89.171] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jun 2012 20:56:45 -0000 Received: from [127.0.0.1] by omp1027.mail.ne1.yahoo.com with NNFMP; 18 Jun 2012 20:56:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 148424.8059.bm@omp1027.mail.ne1.yahoo.com Received: (qmail 68287 invoked by uid 60001); 18 Jun 2012 20:56:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1340053004; bh=0rWXWYagcpX+8jwSK+ReqksEQ+YPBQXkrGrSHlL0Phc=; 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=FMoB2GpuvwB+ckzjPMuSxuc4Dn8cmpPT7x5AMaE5dGoOY1bH2b16pVqJkYKPTRlqm+7RINm50+3hgb//es9nTofuK+FUuOkS9kHLbTowc2JuMrcf7mP7SjsI0gp1UIOTv1TzdJ6om9Sjyf9dXQH+oIwSnyTNzPoIGjTn0AvzPB4= 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=KGxJcvng2/7/iY/u5kZ8TRs9ngkZG+7fB/9zdkY3T8cFq9qSJx7PUI6Whm40TLuf8Nd7jyEiXdVu2iupzrCsJaH9x0KWpsZ4hCi7Wg8qnI5q5/cI8FUkiuyQzmtGH9Z3UZTrhMjJbj3wo7OfEupVUu/EdTAoSaWA+49jFDCJlHY=; X-YMail-OSG: RzwVk5MVM1li99dnxDCMx3AgWtNPEg.6MI4ipSJAse21C3Y nQp2NHCWrAr4Rgg5LJEiWxIhosk.QPB3rFPqKixuVn7AO4eCsTUIBupeTuys gyOawf1.C5utqlAGcEUzeGNVYuplPra9MPAxFd09pdxiWUvi6I3yNQnDPn3x y5s7K4pKPh5m8ZjwZY1SPYoNOATLTGqzERtJXUi1epgk8KbuF5u4SgZ4jUOb R3tEYSDtZK0VTrJdxZLJun.B3kq7fLiVhebhd7HD5o9aOWWIpcA0pSNeV3Zg E4ctm.5Yx6Q.oo9pbZVpshWt1hnt1DotHPppugtBCodpQYu1afoPRDX51tKa KqEqAwm7j7cXeqXsuhUZU97NdhktYQTtPURdBQANLDTC3ti6HaK8pUsj1iNz KPqjRmNl4p2BBheAK8_Znl6JrY4YG1fwwTfcM6S1Ut.7Zn8k_oLUYVPF8.9R ZXXfgcrKW_x0Dbdpww4mO.6brgQ9FnrHO7TjdMZwmBlSfrNdxYCdfIGfntNz hDfjsOFeAx0P5lc3zqmAs2sGR0qJkCWf5YOI1CA01rKMVmfMnUMInEk8HWB_ KAOSn7Frj1a.0IvVujLUfkg8l2bHAP.W6sgK2MdFN4oAfA1bxwHXbarvpduy 7LEp3byzSZJCboSx6WW03_SWfOv4FYeSV_xERVDxjLLYACRQdiMWjEzFG2ow PPl5JgfCOxaWObpqM8PSzsL1LyVZHoG1KQSnhy6vnsCvx21ZsCvJorDtQzHo jivC2y6mE2C_T7d0DduQMdYbscN.079ChfX4HxuheVrX6HXD7YD.jyobPsef C1G2_31DWb_RR65FVPAhUGMHMBMFpl25D57HN26P_PRFbkNr1sm35JTPhUZH a4zL7S34N1E5ar9E- Received: from [209.131.62.115] by web31805.mail.mud.yahoo.com via HTTP; Mon, 18 Jun 2012 13:56:44 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> <1340046923.34140.YahooMailNeo@web31806.mail.mud.yahoo.com> <027001cd4d8f$48e260f0$daa722d0$@packetizer.com> Message-ID: <1340053004.56116.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Mon, 18 Jun 2012 13:56:44 -0700 (PDT) From: William Mills To: "Paul E. Jones" , 'Peter Saint-Andre' In-Reply-To: <027001cd4d8f$48e260f0$daa722d0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-286670863-1340053004=:56116" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery 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, 18 Jun 2012 20:56:55 -0000 ---551393103-286670863-1340053004=:56116 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable What data elements does a generic service description need?=C2=A0 =0A=0A=0A= =C2=A0=C2=A0=C2=A0 name:=C2=A0 a service name form http://www.iana.org/assi= gnments/service-names-port-numbers/service-names-port-numbers.xml=0A=C2=A0= =C2=A0=C2=A0 host:=C2=A0 hostname=0A=0A=C2=A0=C2=A0=C2=A0 port:=C2=A0 a por= t number=0A=0AIs the name here sufficient to convey protocol and such thing= s as SSL?=C2=A0 I think so, if we are using well known services.=0A=0A=C2= =A0=C2=A0=C2=A0 =0A=0A=0A=0A=0A>________________________________=0A> From: = Paul E. Jones =0A>To: 'William Mills' ; 'Peter Saint-Andre' =0A>Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org =0A>Sent: Monday, June 18, 2012 1:1= 6 PM=0A>Subject: RE: [apps-discuss] Aggregated service discovery=0A> =0A>= =0A>Bill,=0A>=C2=A0=0A>Ah, I was confused.=C2=A0 I thought you were speakin= g of an IMAP link relation.=C2=A0 You did same URI scheme.=0A>=C2=A0=0A>It = is possible to have a link relation with no URI.=C2=A0 At least that is val= id per the XRD spec.=C2=A0 The href is listed as optional:=0A>http://docs.o= asis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.link=0A>=C2=A0=0A>In any ca= se, one could return an IMAP URI or one could just return properties.=C2=A0= The choice is ours, but I do tend to think we would not want a URI scheme = for POP3, IMAP, SMTP, etc.=C2=A0 It seems like overkill. =0A>=C2=A0=0A>This= is why I preferred returning the mail configuration info using the =E2=80= =9Cmailto=E2=80=9D URI scheme.=C2=A0 This is an example where I would prefe= r it over =E2=80=9Caccount=E2=80=9D since =E2=80=9Cmailto=E2=80=9D would re= fer to=C2=A0 a specific email address.=C2=A0 With that address, one could t= hen discover the mail server configuration data as I showed it below.=C2=A0= I=E2=80=99d expect this to be populated by the email provider, not the use= r.=0A>=C2=A0=0A>If we want to use the href field, then we could just use We= bFinger to point to the email config document as I had initially proposed.= =C2=A0 That was something like this:=0A>=C2=A0=0A>{=0A>=C2=A0 "subject" : "= mailto:paulej@packetizer.com",=0A>=C2=A0 "links" :=0A>=C2=A0 [=0A>=C2=A0=C2= =A0=C2=A0 {=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : "config-email",=0A>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "href" : "http://www.packetizer.com.com/conf= ig/email/?user=3Dpaulej"=0A>=C2=A0=C2=A0=C2=A0 }=0A>=C2=A0 ]=0A>}=0A>=C2=A0= =0A>So the client would first query the WebFinger server to get the above l= ink relation (=E2=80=9Cconfig-email=E2=80=9D or whatever) and then perform = a second query to get the actual configuration parameters.=C2=A0 The docume= nt containing the configuration parameters would be in whatever format we w= ant to define.=0A>=C2=A0=0A>There are pros and cons with each approach.=C2= =A0 I have no strong preference either way, but as I said, I=E2=80=99d love= to see agreement on some universally agreed approach :)=0A>=C2=A0=0A>Paul= =0A>=C2=A0=0A>From:William Mills [mailto:wmills@yahoo-inc.com] =0A>Sent: Mo= nday, June 18, 2012 3:15 PM=0A>To: Paul E. Jones; 'Peter Saint-Andre'=0A>Cc= : 'Cyrus Daboo'; apps-discuss@ietf.org=0A>Subject: Re: [apps-discuss] Aggre= gated service discovery=0A>=C2=A0=0A>Ah, I missed that nuance, that declare= d application data goes in "properties".=0A>=C2=A0=0A>The "imap" scheme is = listed in http://www.iana.org/assignments/uri-schemes.html and defined in h= ttp://www.rfc-editor.org/rfc/rfc5092.txt=0A>=C2=A0=0A>I've been inquiring a= bout the "related" link relation type, which seems semantically what we wan= t at first glance.=C2=A0 It's not clear to me that you can define a link re= lation that does not have a uri?=C2=A0 That has only application data?=C2= =A0 I don't think it's right to extend link relations to be an arbitrary da= ta container, but requiring a URI scheme is going to be a lot of work for s= ome things.=C2=A0 SMTP is the hard one right now, a hack for that might be = a new relation and just put the postmaster mailto: link in the URI spot.=C2= =A0 =0A>=C2=A0=0A>I'm not inclined to try to encode arbitrary flags like lo= gin-required, I'd probably go as far as a well known service name and leave= it there.=0A>=C2=A0=0A>-bill=0A>=C2=A0=0A>>=0A>>__________________________= ______=0A>>=0A>>From:Paul E. Jones =0A>>To: 'William= Mills' ; 'Peter Saint-Andre' = =0A>>Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org =0A>>Sent:= Monday, June 18, 2012 11:22 AM=0A>>Subject: RE: [apps-discuss] Aggregated = service discovery=0A>>=C2=A0=0A>>Bill,=0A>>=C2=A0=0A>>In the referenced dra= ft below, I assume the =E2=80=9Cgrant-types=E2=80=9D and =E2=80=9Ctoken-typ= es=E2=80=9D should be contained inside a =E2=80=9Cproperties=E2=80=9D?=C2= =A0 That is, I think you want this:=0A>>=C2=A0=0A>>{=0A>>=C2=A0 "subject" := "acct:carol@example.com",=0A>>=C2=A0 "links" :=0A>>=C2=A0 [=0A>>=C2=A0=C2= =A0=C2=A0 {=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : "oauth2-athorize",= =0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "href" : "http://login.example.com/oaut= h2/authorize"=0A>>=C2=A0=C2=A0=C2=A0 },=0A>>=C2=A0=C2=A0=C2=A0 {=0A>>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 "rel" : "oauth2-token",=0A>>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "href" : "https://login.example.com/oauth2/token",=0A>>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0"properties" :=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=0A= >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"grant-types" : "code password"= ,=0A>>=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"token-types" : "bearer"= =0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=0A>>=C2=A0=C2=A0=C2=A0 }=0A>>=C2=A0 ]= =0A>>}=0A>>=C2=A0=0A>>For auto-provisioning of email clients (which I under= stand was your goal), we can either define one link relation that points to= a separate configuration document of some sort, or we define multiple link= relations.=C2=A0 My previous example showed the single link relation and t= he email below shows use of multiple.=C2=A0 Both have pros and cons, but I = tend to favor using multiple link relations, since this allows one to intro= duce new stuff without changing the one mail configuration file.=C2=A0 Also= , it reduces the number of queries a mail client has to make to get config = information.=0A>>=C2=A0=0A>>You indicate that IMAP already has a defined UR= I.=C2=A0 Where is that defined?=C2=A0 I could not find it in the IANA link = relations registry, so I assume it=E2=80=99s really a URI defined in a spec= somewhere.=C2=A0 In any case, we could use URIs for these things (rather t= han defining single token link relation values and registering them).=C2=A0= I have no preference, but I would like an agreed approach to provisioning.= =C2=A0 I hate configuring all the stuff manually on email clients. :-)=0A>>= =C2=A0=0A>>Paul=0A>>=C2=A0=0A>>From:William Mills [mailto:wmills@yahoo-inc.= com] =0A>>Sent: Monday, June 18, 2012 1:36 PM=0A>>To: Paul E. Jones; 'Peter= Saint-Andre'=0A>>Cc: 'Cyrus Daboo'; apps-discuss@ietf.org=0A>>Subject: Re:= [apps-discuss] Aggregated service discovery=0A>>=C2=A0=0A>>Paul, =0A>>=C2= =A0=0A>>Thanks for the reply on this.=C2=A0 I do already have a separate do= c for registering the OAuth specific relations, http://tools.ietf.org/id/dr= aft-wmills-oauth-lrdd-01.html=0A>>=C2=A0=0A>>I don't think I like the thoug= ht of having to register a new link type for every service, but that might = be the right way.=C2=A0 IMAP already has a URI defined for example so if we= use a more general link relation then the URI scheme details the type.=C2= =A0 The tradeoff is whether you can look for a specific link-type or if you= have to scan list elements for the URI type you need.=0A>>=C2=A0=0A>>-bill= =0A>>=C2=A0=0A>>=C2=A0=0A>>>=0A>>>________________________________=0A>>>=0A= >>>From:Paul E. Jones =0A>>>To: 'William Mills' ; 'Peter Saint-Andre' =0A>>>Cc: 'Cyr= us Daboo' ; apps-discuss@ietf.org =0A>>>Sent: Sunday, Jun= e 17, 2012 6:48 PM=0A>>>Subject: RE: [apps-discuss] Aggregated service disc= overy=0A>>>=C2=A0=0A>>>Bill,=0A>>>=C2=A0=0A>>>My apologies for the belated = reply.=C2=A0 I=E2=80=99ve been busy this week and got rather behind on emai= l.=0A>>>=C2=A0=0A>>>I do not personally like using SRV records, either.=C2= =A0 SRV records could work for smaller domains, but I=E2=80=99m not sure th= at they=E2=80=99re the best solution for larger domains.=C2=A0 Personally, = I would prefer putting users on specific servers or server clusters and SRV= records will not differentiate users. =0A>>>=C2=A0=0A>>>To use WebFinger t= o find one=E2=80=99s IMAP, SMTP, or POP server, we could do as I suggested = in my email.=C2=A0 Now the question is what does one query?=C2=A0 Since the= se three services are email, I=E2=80=99d suggest we query =E2=80=9Cmailto:p= aulej@packetizer.com=E2=80=9D.=C2=A0 We could use another URI scheme (e.g.,= =E2=80=9Cacct:=E2=80=9D), but mailto seems most appropriate given that you= =E2=80=99re seeking info about mail services.=0A>>>=C2=A0=0A>>>I provided a= n example earlier that would simply point to a config file with server info= rmation.=C2=A0 We could do this directly via WebFinger like this:=0A>>>=C2= =A0=0A>>>GET /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com= =0A>>>=C2=A0=0A>>>This query would then return something like this:=0A>>>= =C2=A0=0A>>>{=0A>>>=C2=A0 "subject" : "mailto:paulej@packetizer.com",=0A>>>= =C2=A0 "links" :=0A>>>=C2=A0 [=0A>>>=C2=A0=C2=A0=C2=A0 {=0A>>>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "rel" : "smtp-server",=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 "properties" :=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=0A>>>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "host" : "smtp.packetizer.com",=0A>>>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "port" : "587",=0A>>>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 "login-required" : "yes",=0A>>>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 "transport" : "starttls"=0A>>>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 }=0A>>>=C2=A0=C2=A0=C2=A0 },=0A>>>=C2=A0=C2=A0=C2=A0 {=0A>>= >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : "imap-server",=0A>>>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "properties" :=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=0A>>>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "host" : "imap.packetizer.com",= =0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "port" : "993",=0A>>>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "transport" : "ssl"=0A>>>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 }=0A>>>=C2=A0=C2=A0=C2=A0 }=0A>>>=C2=A0 ]=0A>>>}=0A>>= >=C2=A0=0A>>>We would need to standardize the link relation values (smtp-se= rver and imap-server).=C2=A0 We would also need to document what the variou= s properties would be.=C2=A0 If you would like to create such a configurati= on document based on WebFinger, I=E2=80=99d be happy to help out.=C2=A0 In = any case, you can see that WebFinger would serve quite nicely for conveying= configuration information given a user=E2=80=99s email ID.=0A>>>=C2=A0=0A>= >>I=E2=80=99m not sure exactly what you would need for OAuth endpoints, but= I would suggest you make that a separate document since it is not mail rel= ated.=C2=A0 (At least I assume it=E2=80=99s not.=C2=A0 Even if it were, the= mail server information and OAuth information are still different animals.= )=0A>>>=C2=A0=0A>>>Paul=0A>>>=C2=A0=0A>>>From:William Mills [mailto:wmills@= yahoo-inc.com] =0A>>>Sent: Wednesday, June 13, 2012 7:32 PM=0A>>>To: Peter = Saint-Andre=0A>>>Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org=0A= >>>Subject: Re: [apps-discuss] Aggregated service discovery=0A>>>=C2=A0=0A>= >>In my use case it's a service/server.=0A>>>=C2=A0=0A>>>Not a terribly hap= py answer to say "DNS SRV records won't work for you, and there is no other= solution.".=C2=A0 By the same token I could ask "Why do we need Webfinger = and host meta at all if we have DNS SRV records?".=0A>>>=C2=A0=0A>>>If XMPP= uses SRV records for discovery, that's fine.=C2=A0 IMAP and outbound SMTP = services both lack a defined discovery method other than the ubiquitous "se= rvice documentation".=C2=A0 Is there a compelling reason to pick DNS over W= F for this?=C2=A0 From the app developer point of view I don't want to have= N ways to discover M services.=0A>>>=C2=A0=0A>>>-bill=0A>>>=C2=A0=0A>>>=C2= =A0=0A>>>>=0A>>>>________________________________=0A>>>>=0A>>>>From:Peter S= aint-Andre =0A>>>>To: William Mills =0A>>>>Cc: Paul E. Jones ; 'Cyrus Daboo' ; "apps-discuss@ietf.org" =0A>>>>Sent: W= ednesday, June 13, 2012 3:57 PM=0A>>>>Subject: Re: [apps-discuss] Aggregate= d service discovery=0A>>>>=0A>>>>On 6/13/12 4:54 PM, William Mills wrote:= =0A>>>>> As I said, I'm interested specifically in IMAP, SMTP and OAuth end= points. =0A>>>>=0A>>>>What exactly is an "endpoint"? A client? An account? = A server?=0A>>>>=0A>>>>> As a data point, DNS SRV records are not controlla= ble in many hosted=0A>>>>> domain models.=0A>>>>=0A>>>>At the last XMPP Sum= mit a few months ago, we learned that DNS SRV=0A>>>>records are unavailable= in whole countries (e.g., Japan). That doesn't=0A>>>>mean we should define= a replacement for DNS over HTTP. :)=0A>>>>=0A>>>>Peter=0A>>>>=0A>>>>-- =0A= >>>>Peter Saint-Andre=0A>>>>https://stpeter.im/=0A>>>>=0A>>>>=0A>>>>=0A>>>>= =0A>>>=C2=A0=0A>>=C2=A0=0A>=0A> ---551393103-286670863-1340053004=:56116 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
What data elements does a generic service description need? 

    name:&= nbsp; a service name form http://www.iana.org/assignments/service-names-por= t-numbers/service-names-port-numbers.xml
    host:  hostname
  =   port:  a port number

Is the name= here sufficient to convey protocol and such things as SSL?  I think s= o, if we are using well known services.
   

From: Paul E. Jones <paulej@packetize= r.com>
To: 'William= Mills' <wmills@yahoo-inc.com>; 'Peter Saint-Andre' <stpeter@stpet= er.im>
Cc: 'Cyrus D= aboo' <cyrus@daboo.name>; apps-discuss@ietf.org
Sent: Monday, June 18, 2012 1:16 PM
= Subject: RE: [apps-discuss= ] Aggregated service discovery

Bill,
 
Ah, I was confused.  I t= hought you were speaking of an IMAP link relation.  You did same URI s= cheme.
 
It is possible to hav= e a link relation with no URI.  At least that is valid per the XRD spe= c.  The href is listed as optional:
http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.link
 
In any case, one could return= an IMAP URI or one could just return properties.  The choice is ours,= but I do tend to think we would not want a URI scheme for POP3, IMAP, SMTP= , etc.  It seems like overkill.
 
This is why I preferred returning the mail configuration info using the = =E2=80=9Cmailto=E2=80=9D URI scheme.  This is an example where I would= prefer it over =E2=80=9Caccount=E2=80=9D since =E2=80=9Cmailto=E2=80=9D wo= uld refer to  a specific email address.  With that address, one c= ould then discover the mail server configuration data as I showed it below.=   I=E2=80=99d expect this to be populated by the email provider, not t= he user.
 
If we want to use t= he href field, then we could just use WebFinger to point to the email confi= g document as I had initially proposed.  That was something like this:=
 
{
  "subject" : "mailto:paulej@packetizer.com",<= /div>
  "links" :<= /div>
  [
    {
      "rel" : "config-e= mail",
 &nbs= p;    "href" : "http://www.packetizer.com.com/config/email/?= user=3Dpaulej"
&n= bsp;   }
}
 
So the client would first query the WebFinger server to get the above li= nk relation (=E2=80=9Cconfig-email=E2=80=9D or whatever) and then perform a= second query to get the actual configuration parameters.  The documen= t containing the configuration parameters would be in whatever format we wa= nt to define.
&n= bsp;
There are pro= s and cons with each approach.  I have no strong preference either way= , but as I said, I=E2=80=99d love to see agreement on some universally agre= ed approach :)
&n= bsp;
Paul
 
From: William Mills [mailto:wmills@yahoo= -inc.com]
Sent: Monday, June 18, 2012 3:15 PM
To: Paul= E. Jones; 'Peter Saint-Andre'
Cc: 'Cyrus Daboo'; apps-discuss@ie= tf.org
Subject: Re: [apps-discuss] Aggregated service discovery
 
Ah, I m= issed that nuance, that declared application data goes in "properties".
 
I've been inquiring about the "related" link = relation type, which seems semantically what we want at first glance. = It's not clear to me that you can define a link relation that does not hav= e a uri?  That has only application data?  I don't think it's rig= ht to extend link relations to be an arbitrary data container, but requirin= g a URI scheme is going to be a lot of work for some things.  SMTP is = the hard one right now, a hack for that might be a new relation and just pu= t the postmaster mailto: link in the URI spot. 
 
I'm not inclined to try to encode arbitrary f= lags like login-required, I'd probably go as far as a well known service na= me and leave it there.
 
<= div class=3D"yiv990624892MsoNormal" style=3D"background:white;">-bil= l
 
From: Paul E. Jones <paulej@packetizer.com>
To: 'William Mills' <<= a rel=3D"nofollow" ymailto=3D"mailto:wmills@yahoo-inc.com" target=3D"_blank= " href=3D"mailto:wmills@yahoo-inc.com">wmills@yahoo-inc.com>; 'Peter= Saint-Andre' <stpeter@stpeter.im>
Cc: 'Cyrus Daboo' <cyrus@daboo.name&g= t;; apps-discuss@ietf.org Sent: Monday, June 18, 2012 11:22 AM
Subject: RE: [apps-d= iscuss] Aggregated service discovery
 
Bill,
 
In the r= eferenced draft below, I assume the =E2=80=9Cgrant-types=E2=80=9D and =E2= =80=9Ctoken-types=E2=80=9D should be contained inside a =E2=80=9Cproperties= =E2=80=9D?  That is, I think you want this:
 
{
  "subject" : "acct:carol@exampl= e.com",
  "l= inks" :
  [<= /span>
   = ; {
      "rel" : "oauth2-athorize",
    }= ,
  &nb= sp; {
    &nbs= p; "rel" : "oauth2-token",
=
      "href" : "https://login= .example.com/oauth2/token",<= /div>
     "properties" :
      {
   &nb= sp;   "grant-types" : "code password",
       &= nbsp;"token-types" : "bearer"
      }
    }<= span style=3D"color:black;">
  ]
}
 
<= /div>
= For auto-provisioning of email clients (which I understand was your goal= ), we can either define one link relation that points to a separate configu= ration document of some sort, or we define multiple link relations.  M= y previous example showed the single link relation and the email below show= s use of multiple.  Both have pros and cons, but I tend to favor using= multiple link relations, since this allows one to introduce new stuff with= out changing the one mail configuration file.  Also, it reduces the nu= mber of queries a mail client has to make to get config information.=
 
You indicate that IMAP already has a d= efined URI.  Where is that defined?  I could not find it in the I= ANA link relations registry, so I assume it=E2=80=99s really a URI defined = in a spec somewhere.  In any case, we could use URIs for these things = (rather than defining single token link relation values and registering the= m).  I have no preference, but I would like an agreed approach to prov= isioning.  I hate configuring all the stuff manually on email clients.= :-)
 
Paul
 
=
From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: = Monday, June 18, 2012 1:36 PM
To: Paul E. Jones; 'Peter Saint-Andre'
Cc: 'Cyrus D= aboo'; apps-discuss@ietf.org=
Subject: Re: [apps-discuss] Aggregated service discovery<= span style=3D"color:black;">
 
Paul,
 
Thanks for the reply on this.  I d= o already have a separate doc for registering the OAuth specific relations,= http://tools.ietf.org/id/draft-wmills-oauth-l= rdd-01.html
 
=
= I don't think I like the thought of having to register a new link ty= pe for every service, but that might be the right way.  IMAP already h= as a URI defined for example so if we use a more general link relation then the URI scheme = details the type.  The tradeoff is whether you can look for a specific= link-type or if you have to scan list elements for the URI type you need.<= /span>
 
-bill
 
 
From: Paul E. Jones <paulej@packetizer.com>
= To: 'William Mills' <wmills@= yahoo-inc.com>; 'Peter Saint-Andre' <stpeter@stpeter.im>
Cc: 'Cyrus Daboo' <cyrus@daboo.name>; apps-discuss@ietf.org
Sent: Sunday, June = 17, 2012 6:48 PM
Subject: RE: [apps-discuss] Aggregated service d= iscovery
<= div class=3D"yiv990624892MsoNormal" style=3D"background:white;"> 
<= div>
Bill,
 
My apologies for the belated reply.  I=E2=80=99ve been= busy this week and got rather behind on email.
 
=
I do not personally like using SRV records, either.  SRV records co= uld work for smaller domains, but I=E2=80=99m not sure that they=E2=80=99re= the best solution for larger domains.  Personally, I would prefer put= ting users on specific servers or server clusters and SRV records will not = differentiate users.
 
To use WebFinger to find one=E2=80=99s IMAP, SMTP, or POP server, we cou= ld do as I suggested in my email.  Now the question is what does one q= uery?  Since these three services are email, I=E2=80=99d suggest we qu= ery =E2=80=9Cmailto:paulej@packet= izer.com=E2=80=9D.  We could use another URI scheme (e.g., =E2=80= =9Cacct:=E2=80=9D), but mailto seems most appropriate given that you=E2=80= =99re seeking info about mail services.=
 =
I provided an example earlier that would simply point to a config file w= ith server information.  We could do this directly via WebFinger like = this:
&= nbsp;
= GET /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com
 
This query would t= hen return something like this:<= /div>
 <= /div>
{
  "links" :
<= /div>
  [
    {
 =      "rel" : "smtp-server",
      "properties" :
   = ;   {
        "host" : "smtp.packeti= zer.com",
<= div>
 = ;       "port" : "587",
    &nb= sp;   "login-required" : "yes",
      &nb= sp; "transport" : "starttls"
      }
    },=
 = ;   {
    &nbs= p; "rel" : "imap-server",
<= /div>
      "properties" :
 &n= bsp;    {
        "host" : "ima= p.packetizer.com",
        "port" : "993",=
   = ;     "transport" : "ssl"
      }
 &n= bsp;  }
  ]
}<= /span>
 <= /span>
We woul= d need to standardize the link relation values (smtp-server and imap-server= ).  We would also need to document what the various properties would b= e.  If you would like to create such a configuration document based on= WebFinger, I=E2=80=99d be happy to help out.  In any case, you can se= e that WebFinger would serve quite nicely for conveying configuration information given a user=E2= =80=99s email ID.
 
I=E2=80=99m not sure exactly what you would need for OAuth endpo= ints, but I would suggest you make that a separate document since it is not= mail related.  (At least I assume it=E2=80=99s not.  Even if it = were, the mail server information and OAuth information are still different= animals.)
 
=
Paul
 
From: William Mills [= mailto:wmills@yahoo-inc.com]
Sent: Wednesday, June 13, 2012 = 7:32 PM
To: Peter Saint-Andre
Cc: Paul E. Jones; 'Cyrus= Daboo'; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Aggregated service discovery=
<= div>
 
 
From: Peter Saint-An= dre <stpeter@stpeter.im>
<= b>To: William Mills <wmills@= yahoo-inc.com>
Cc: Paul E. Jones <paulej@packetizer.com>; 'Cyrus Daboo' <cyrus@daboo.name>; "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Sent: Wednesd= ay, June 13, 2012 3:57 PM
Subject: Re: [apps-discuss] Aggregated = service discovery

On 6/13/12 4:54 PM, Wil= liam Mills wrote:
> As I said, I'm interested specifically in IMAP, S= MTP and OAuth endpoints.

What exactly is an "endpoint"? A client? A= n account? A server?

> As a data point, DNS SRV records are not c= ontrollable in many hosted
> domain models.

At the last XMPP S= ummit a few months ago, we learned that DNS SRV
records are unavailable in whole countries= (e.g., Japan). That doesn't
mean we should define a replacement for DNS= over HTTP. :)

Peter

--
Peter Saint-Andre
https://stpeter.im/<= /a>



=
 

---551393103-286670863-1340053004=:56116-- From paulej@packetizer.com Mon Jun 18 14:43: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 C8E5511E80CE for ; Mon, 18 Jun 2012 14:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clNr1RugN0XG for ; Mon, 18 Jun 2012 14:43:44 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DD7B411E80CC for ; Mon, 18 Jun 2012 14:43:43 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5ILheb7008252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Jun 2012 17:43:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340055821; bh=ajc5GgKHjcmAm/oBsGgehxuJGE8JulbHGcOk5ttuJ5A=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=JhBUZaB6e+ba3KmFsot/eWciG9vp3/9w4yhd6ZJOFFvBeaZgMbPa14cbhRd2jS3DL kpqT2ljNRmJwJEE9O3EQD1BWrqb/lyGtc7UZjG0pOxjDBx0msh9ZbMiUPLKZD0pLo1 fIAcRI3EGzrRZIvfBWpqBEUi9tq06hWnlVGLGztA= From: "Paul E. Jones" To: "'William Mills'" , "'Peter Saint-Andre'" References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> <1340046923.34140.YahooMailNeo@web31806.mail.mud.yahoo.com> <027001cd4d8f$48e260f0$daa722d0$@packetizer.com> <1340053004.56116.YahooMailNeo@web31805.mail.mud.yahoo.com> In-Reply-To: <1340053004.56116.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Mon, 18 Jun 2012 17:43:43 -0400 Message-ID: <02bd01cd4d9b$6f651ea0$4e2f5be0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02BE_01CD4D79.E8599920" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNYFRdarpUA3Z9l4mSBSKHTly568wGsYWTHAiB/MPYCgTB6NAGRuS9TAZsphI0CgPvwiQHAzgIyAdRbPCoCdcjfHwDj9hFfAcntoUICMTf0e5Mz1alw Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 21:43:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02BE_01CD4D79.E8599920 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bill, =20 It=E2=80=99s hard to make everything generic. For IMAP, for example, = one should be able to specify the use of SSL, TLS, or no security. = It=E2=80=99s also important to specify the root folder path. There may = be other options, but I=E2=80=99m not an IMAP guru. Those are just = options I=E2=80=99ve had to configure personally. =20 For other services, the transports might vary from TCP to UDP, too. = So, for a generic service I think indicating a transport, transport = security option. Things like the folder path are specific to IMAP and = would have no meaning to, say, SMTP. =20 For SMTP, one would need to indicate whether logging in is required or = not. =20 So, I think any service that would be specified would have: Hostname Port Transport Transport-Security (Perhaps the transport and transport security = could be combined?) Protocol specific parameters (IMAP root folder path, SMTP login = requirements) =20 The =E2=80=9Cservice name=E2=80=9D could be assumed given the value of = the link relation. And it=E2=80=99s those protocol-specific = parameters that are a challenge to make generic, but they are important. =20 Paul =20 From: William Mills [mailto:wmills@yahoo-inc.com]=20 Sent: Monday, June 18, 2012 4:57 PM To: Paul E. Jones; 'Peter Saint-Andre' Cc: 'Cyrus Daboo'; apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery =20 What data elements does a generic service description need? =20 =20 name: a service name form = http://www.iana.org/assignments/service-names-port-numbers/service-names-= port-numbers.xml host: hostname port: a port number =20 Is the name here sufficient to convey protocol and such things as SSL? = I think so, if we are using well known services. =20 =20 _____ =20 From: Paul E. Jones To: 'William Mills' ; 'Peter Saint-Andre' = =20 Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org=20 Sent: Monday, June 18, 2012 1:16 PM Subject: RE: [apps-discuss] Aggregated service discovery =20 Bill, =20 Ah, I was confused. I thought you were speaking of an IMAP link = relation. You did same URI scheme. =20 It is possible to have a link relation with no URI. At least that is = valid per the XRD spec. The href is listed as optional: http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html#element.link =20 In any case, one could return an IMAP URI or one could just return = properties. The choice is ours, but I do tend to think we would not = want a URI scheme for POP3, IMAP, SMTP, etc. It seems like overkill.=20 =20 This is why I preferred returning the mail configuration info using the = =E2=80=9Cmailto=E2=80=9D URI scheme. This is an example where I would = prefer it over =E2=80=9Caccount=E2=80=9D since =E2=80=9Cmailto=E2=80=9D = would refer to a specific email address. With that address, one could = then discover the mail server configuration data as I showed it below. = I=E2=80=99d expect this to be populated by the email provider, not the = user. =20 If we want to use the href field, then we could just use WebFinger to = point to the email config document as I had initially proposed. That = was something like this: =20 { "subject" : "mailto:paulej@packetizer.com", "links" : [ { "rel" : "config-email", "href" : = "http://www.packetizer.com.com/config/email/?user=3Dpaulej" } ] } =20 So the client would first query the WebFinger server to get the above = link relation (=E2=80=9Cconfig-email=E2=80=9D or whatever) and then = perform a second query to get the actual configuration parameters. The = document containing the configuration parameters would be in whatever = format we want to define. =20 There are pros and cons with each approach. I have no strong preference = either way, but as I said, I=E2=80=99d love to see agreement on some = universally agreed approach :) =20 Paul =20 From: William Mills [mailto:wmills@yahoo-inc.com]=20 Sent: Monday, June 18, 2012 3:15 PM To: Paul E. Jones; 'Peter Saint-Andre' Cc: 'Cyrus Daboo'; apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery =20 Ah, I missed that nuance, that declared application data goes in = "properties". =20 The "imap" scheme is listed in = http://www.iana.org/assignments/uri-schemes.html and defined in = http://www.rfc-editor.org/rfc/rfc5092.txt =20 I've been inquiring about the "related" link relation type, which seems = semantically what we want at first glance. It's not clear to me that = you can define a link relation that does not have a uri? That has only = application data? I don't think it's right to extend link relations to = be an arbitrary data container, but requiring a URI scheme is going to = be a lot of work for some things. SMTP is the hard one right now, a = hack for that might be a new relation and just put the postmaster = mailto: link in the URI spot. =20 =20 I'm not inclined to try to encode arbitrary flags like login-required, = I'd probably go as far as a well known service name and leave it there. =20 -bill =20 _____ =20 From: Paul E. Jones To: 'William Mills' ; 'Peter Saint-Andre' = =20 Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org=20 Sent: Monday, June 18, 2012 11:22 AM Subject: RE: [apps-discuss] Aggregated service discovery =20 Bill, =20 In the referenced draft below, I assume the = =E2=80=9Cgrant-types=E2=80=9D and =E2=80=9Ctoken-types=E2=80=9D should = be contained inside a =E2=80=9Cproperties=E2=80=9D? That is, I think = you want this: =20 { "subject" : "acct:carol@example.com", "links" : [ { "rel" : "oauth2-athorize", "href" : "http://login.example.com/oauth2/authorize" }, { "rel" : "oauth2-token", "href" : "https://login.example.com/oauth2/token", "properties" : { "grant-types" : "code password", "token-types" : "bearer" } } ] } =20 For auto-provisioning of email clients (which I understand was your = goal), we can either define one link relation that points to a separate = configuration document of some sort, or we define multiple link = relations. My previous example showed the single link relation and the = email below shows use of multiple. Both have pros and cons, but I tend = to favor using multiple link relations, since this allows one to = introduce new stuff without changing the one mail configuration file. = Also, it reduces the number of queries a mail client has to make to get = config information. =20 You indicate that IMAP already has a defined URI. Where is that = defined? I could not find it in the IANA link relations registry, so I = assume it=E2=80=99s really a URI defined in a spec somewhere. In any = case, we could use URIs for these things (rather than defining single = token link relation values and registering them). I have no preference, = but I would like an agreed approach to provisioning. I hate configuring = all the stuff manually on email clients. :-) =20 Paul =20 From: William Mills [mailto:wmills@yahoo-inc.com]=20 Sent: Monday, June 18, 2012 1:36 PM To: Paul E. Jones; 'Peter Saint-Andre' Cc: 'Cyrus Daboo'; apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery =20 Paul,=20 =20 Thanks for the reply on this. I do already have a separate doc for = registering the OAuth specific relations, = http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html =20 I don't think I like the thought of having to register a new link type = for every service, but that might be the right way. IMAP already has a = URI defined for example so if we use a more general link relation then = the URI scheme details the type. The tradeoff is whether you can look = for a specific link-type or if you have to scan list elements for the = URI type you need. =20 -bill =20 =20 _____ =20 From: Paul E. Jones To: 'William Mills' ; 'Peter Saint-Andre' = =20 Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org=20 Sent: Sunday, June 17, 2012 6:48 PM Subject: RE: [apps-discuss] Aggregated service discovery =20 Bill, =20 My apologies for the belated reply. I=E2=80=99ve been busy this week = and got rather behind on email. =20 I do not personally like using SRV records, either. SRV records could = work for smaller domains, but I=E2=80=99m not sure that they=E2=80=99re = the best solution for larger domains. Personally, I would prefer = putting users on specific servers or server clusters and SRV records = will not differentiate users.=20 =20 To use WebFinger to find one=E2=80=99s IMAP, SMTP, or POP server, we = could do as I suggested in my email. Now the question is what does one = query? Since these three services are email, I=E2=80=99d suggest we = query =E2=80=9Cmailto:paulej@packetizer.com=E2=80=9D. We could use = another URI scheme (e.g., =E2=80=9Cacct:=E2=80=9D), but mailto seems = most appropriate given that you=E2=80=99re seeking info about mail = services. =20 I provided an example earlier that would simply point to a config file = with server information. We could do this directly via WebFinger like = this: =20 GET /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com =20 This query would then return something like this: =20 { "subject" : "mailto:paulej@packetizer.com", "links" : [ { "rel" : "smtp-server", "properties" : { "host" : "smtp.packetizer.com ", "port" : "587", "login-required" : "yes", "transport" : "starttls" } }, { "rel" : "imap-server", "properties" : { "host" : "imap.packetizer.com ", "port" : "993", "transport" : "ssl" } } ] } =20 We would need to standardize the link relation values (smtp-server and = imap-server). We would also need to document what the various = properties would be. If you would like to create such a configuration = document based on WebFinger, I=E2=80=99d be happy to help out. In any = case, you can see that WebFinger would serve quite nicely for conveying = configuration information given a user=E2=80=99s email ID. =20 I=E2=80=99m not sure exactly what you would need for OAuth endpoints, = but I would suggest you make that a separate document since it is not = mail related. (At least I assume it=E2=80=99s not. Even if it were, = the mail server information and OAuth information are still different = animals.) =20 Paul =20 From: William Mills [mailto:wmills@yahoo-inc.com]=20 Sent: Wednesday, June 13, 2012 7:32 PM To: Peter Saint-Andre Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery =20 In my use case it's a service/server. =20 Not a terribly happy answer to say "DNS SRV records won't work for you, = and there is no other solution.". By the same token I could ask "Why do = we need Webfinger and host meta at all if we have DNS SRV records?". =20 If XMPP uses SRV records for discovery, that's fine. IMAP and outbound = SMTP services both lack a defined discovery method other than the = ubiquitous "service documentation". Is there a compelling reason to = pick DNS over WF for this? From the app developer point of view I don't = want to have N ways to discover M services. =20 -bill =20 =20 _____ =20 From: Peter Saint-Andre To: William Mills =20 Cc: Paul E. Jones ; 'Cyrus Daboo' = ; "apps-discuss@ietf.org" =20 Sent: Wednesday, June 13, 2012 3:57 PM Subject: Re: [apps-discuss] Aggregated service discovery On 6/13/12 4:54 PM, William Mills wrote: > As I said, I'm interested specifically in IMAP, SMTP and OAuth = endpoints.=20 What exactly is an "endpoint"? A client? An account? A server? > As a data point, DNS SRV records are not controllable in many hosted > domain models. At the last XMPP Summit a few months ago, we learned that DNS SRV records are unavailable in whole countries (e.g., Japan). That doesn't mean we should define a replacement for DNS over HTTP. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ =20 =20 =20 ------=_NextPart_000_02BE_01CD4D79.E8599920 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Bill,

 

It=E2=80=99s hard to make everything generic.=C2=A0 For IMAP, for = example, one should be able to specify the use of SSL, TLS, or no = security.=C2=A0 It=E2=80=99s also important to specify the root folder = path.=C2=A0 There may be other options, but I=E2=80=99m not an IMAP = guru.=C2=A0 Those are just options I=E2=80=99ve had to configure = personally.

 

For other services, the transports might vary from TCP to UDP, = too.=C2=A0=C2=A0 So, for a generic service I think indicating a = transport, transport security option.=C2=A0 Things like the folder path = are specific to IMAP and would have no meaning to, say, = SMTP.

 

For SMTP, one would need to indicate whether logging in is required = or not.

 

So, I think any service that would be specified would = have:

=C2=A0=C2=A0 Hostname

=C2=A0=C2=A0 Port

=C2=A0=C2=A0 Transport

=C2=A0=C2=A0 Transport-Security=C2=A0 (Perhaps the transport and = transport security could be combined?)

=C2=A0=C2=A0 Protocol specific parameters (IMAP root folder path, = SMTP login requirements)

 

The =E2=80=9Cservice name=E2=80=9D could be assumed given the value = of the link relation.=C2=A0=C2=A0 =C2=A0And it=E2=80=99s those = protocol-specific parameters that are a challenge to make generic, but = they are important.

 

Paul

 

From:= = William Mills [mailto:wmills@yahoo-inc.com]
Sent: Monday, = June 18, 2012 4:57 PM
To: Paul E. Jones; 'Peter = Saint-Andre'
Cc: 'Cyrus Daboo'; = apps-discuss@ietf.org
Subject: Re: [apps-discuss] Aggregated = service discovery

 

What = data elements does a generic service description need?  =

 

    host:  = hostname

    port:  a port = number

 

Is the = name here sufficient to convey protocol and such things as SSL?  I = think so, if we are using well known services.

   

 

<= hr size=3D1 width=3D"100%" align=3Dcenter>

F= rom: = Paul E. Jones <paulej@packetizer.com>
To: 'William Mills' <wmills@yahoo-inc.com>; = 'Peter Saint-Andre' <stpeter@stpeter.im> =
Cc: 'Cyrus Daboo' <cyrus@daboo.name>; apps-discuss@ietf.org =
Sent: Monday, June 18, 2012 1:16 PM
Subject: RE: = [apps-discuss] Aggregated service discovery

 

Bill,

 

Ah, I was confused.  I thought you were speaking of an IMAP link = relation.  You did same URI scheme.

 

It is possible to have a link relation with no URI.  At least that = is valid per the XRD spec.  The href is listed as = optional:

 

In any case, one could return an IMAP URI or one could just return = properties.  The choice is ours, but I do tend to think we would = not want a URI scheme for POP3, IMAP, SMTP, etc.  It seems like = overkill.

 

This is why I preferred returning the mail configuration info using the = =E2=80=9Cmailto=E2=80=9D URI scheme.  This is an example where I = would prefer it over =E2=80=9Caccount=E2=80=9D since = =E2=80=9Cmailto=E2=80=9D would refer to  a specific email = address.  With that address, one could then discover the mail = server configuration data as I showed it below.  I=E2=80=99d expect = this to be populated by the email provider, not the user.

 

If we want to use the href field, then we could just use WebFinger to = point to the email config document as I had initially proposed.  = That was something like this:

 

{

  "subject" : "mailto:paulej@packetizer.com&qu= ot;,

  "links" :

  [

    {

      = "rel" : "config-email",

    }

  ]

}

 

So the client would first query the WebFinger server to get the above = link relation (=E2=80=9Cconfig-email=E2=80=9D or whatever) and then = perform a second query to get the actual configuration parameters.  = The document containing the configuration parameters would be in = whatever format we want to define.

 

There are pros and cons with each approach.  I have no strong = preference either way, but as I said, I=E2=80=99d love to see agreement = on some universally agreed approach :)

 

Paul

 

F= rom: = William Mills [mailto:wmills@yahoo-inc.co= m]
Sent: Monday, June 18, 2012 3:15 PM
To: Paul = E. Jones; 'Peter Saint-Andre'
Cc: 'Cyrus Daboo'; apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] Aggregated service discovery

 

Ah, I = missed that nuance, that declared application data goes in = "properties".

 

 

I've = been inquiring about the "related" link relation type, which = seems semantically what we want at first glance.  It's not clear to = me that you can define a link relation that does not have a uri?  = That has only application data?  I don't think it's right to extend = link relations to be an arbitrary data container, but requiring a URI = scheme is going to be a lot of work for some things.  SMTP is the = hard one right now, a hack for that might be a new relation and just put = the postmaster mailto: link in the URI spot. 

 

I'm not = inclined to try to encode arbitrary flags like login-required, I'd = probably go as far as a well known service name and leave it = there.

 

-bill

 

<= hr size=3D1 width=3D"100%" align=3Dcenter>

F= rom: = Paul E. Jones <paulej@packetizer.com>
To: 'William = Mills' <wmills@yahoo-inc.com>; 'Peter Saint-Andre' = <stpeter@stpeter.im>
Cc: 'Cyrus = Daboo' <cyrus@daboo.name>; apps-discuss@ietf.org
Sent: Monday, = June 18, 2012 11:22 AM
Subject: RE: [apps-discuss] Aggregated = service discovery

 

Bill,

 

In the referenced draft below, I assume the = =E2=80=9Cgrant-types=E2=80=9D and =E2=80=9Ctoken-types=E2=80=9D should = be contained inside a =E2=80=9Cproperties=E2=80=9D?  That is, I = think you want this:

 

{

  "subject" : = "acct:carol@example.com",

  "links" :

  [

    {

      "rel" : = "oauth2-athorize",

    },

    {

      "rel" : = "oauth2-token",

     "properties" = :

      {

       "grant= -types" : "code password",

   =      "token-types" : = "bearer"

      }

    }

  ]

}

 

For auto-provisioning of email clients (which I understand was your = goal), we can either define one link relation that points to a separate = configuration document of some sort, or we define multiple link = relations.  My previous example showed the single link relation and = the email below shows use of multiple.  Both have pros and cons, = but I tend to favor using multiple link relations, since this allows one = to introduce new stuff without changing the one mail configuration = file.  Also, it reduces the number of queries a mail client has to = make to get config information.

 

You indicate that IMAP already has a defined URI.  Where is that = defined?  I could not find it in the IANA link relations registry, = so I assume it=E2=80=99s really a URI defined in a spec somewhere.  = In any case, we could use URIs for these things (rather than defining = single token link relation values and registering them).  I have no = preference, but I would like an agreed approach to provisioning.  I = hate configuring all the stuff manually on email clients. = :-)

 

Paul

 

F= rom: = William Mills [mailto:wmills@yahoo-inc.com]
Sent: = Monday, June 18, 2012 1:36 PM
To: Paul E. Jones; 'Peter = Saint-Andre'
Cc: 'Cyrus Daboo'; apps-discuss@ietf.org
Subject: Re: = [apps-discuss] Aggregated service discovery

=

 

<= div>

Paul, =

<= div>

 

<= div>

Thanks = for the reply on this.  I do already have a separate doc for = registering the OAuth specific relations, http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.htm= l

<= div>

 

<= div>

I don't = think I like the thought of having to register a new link type for every = service, but that might be the right way.  IMAP already has a URI = defined for example so if we use a more general link relation then the = URI scheme details the type.  The tradeoff is whether you can look = for a specific link-type or if you have to scan list elements for the = URI type you need.

<= div>

 

<= div>

-bill

<= div>

 

 

<= hr size=3D1 width=3D"100%" align=3Dcenter>

F= rom: = Paul E. Jones <paulej@packetizer.com>
To: 'William = Mills' <wmills@yahoo-inc.com>; 'Peter Saint-Andre' = <stpeter@stpeter.im>
Cc: 'Cyrus = Daboo' <cyrus@daboo.name>; apps-discuss@ietf.org
Sent: Sunday, = June 17, 2012 6:48 PM
Subject: RE: [apps-discuss] Aggregated = service discovery

<= p class=3DMsoNormal style=3D'background:white'> 

Bill,

<= div>

 

<= div>

My apologies for the belated reply.  I=E2=80=99ve been busy this = week and got rather behind on email.

<= div>

 

<= div>

I do not personally like using SRV records, either.  SRV records = could work for smaller domains, but I=E2=80=99m not sure that = they=E2=80=99re the best solution for larger domains.  Personally, = I would prefer putting users on specific servers or server clusters and = SRV records will not differentiate users.

<= div>

 

<= div>

To use WebFinger to find one=E2=80=99s IMAP, SMTP, or POP server, we = could do as I suggested in my email.  Now the question is what does = one query?  Since these three services are email, I=E2=80=99d = suggest we query =E2=80=9Cmailto:paulej@packetizer.com=E2=80=9D.  We = could use another URI scheme (e.g., =E2=80=9Cacct:=E2=80=9D), but mailto = seems most appropriate given that you=E2=80=99re seeking info about mail = services.

<= div>

 

<= div>

I provided an example earlier that would simply point to a config file = with server information.  We could do this directly via WebFinger = like this:

<= div>

 

<= div>

GET = /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com

<= div>

 

<= div>

This query would then return something like this:

<= div>

 

<= div>

{

<= div>

  "subject" : "mailto:paulej@packetizer.com",

<= div>

  "links" = :

<= div>

  [

<= div>

    {

<= div>

      = "rel" : "smtp-server",

<= div>

      = "properties" :

<= div>

      {

<= div>

        = "host" : "smtp.packetizer.com",

<= div>

        = "port" : "587",

<= div>

        = "login-required" : "yes",

<= div>

        = "transport" : "starttls"

<= div>

      = }

<= div>

    },

<= div>

    {

<= div>

      = "rel" : "imap-server",

<= div>

      = "properties" :

<= div>

      {

<= div>

        = "host" : "imap.packetizer.com",

<= div>

        = "port" : "993",

<= div>

        = "transport" : "ssl"

<= div>

      }

<= div>

    }

<= div>

  ]

<= div>

}

<= div>

 

<= div>

We would need to standardize the link relation values (smtp-server and = imap-server).  We would also need to document what the various = properties would be.  If you would like to create such a = configuration document based on WebFinger, I=E2=80=99d be happy to help = out.  In any case, you can see that WebFinger would serve quite = nicely for conveying configuration information given a user=E2=80=99s = email ID.

<= div>

 

<= div>

I=E2=80=99m not sure exactly what you would need for OAuth endpoints, = but I would suggest you make that a separate document since it is not = mail related.  (At least I assume it=E2=80=99s not.  Even if = it were, the mail server information and OAuth information are still = different animals.)

<= div>

 

<= div>

Paul

<= div>

 

F= rom: = William Mills [mailto:wmills@yahoo-inc.com]
Sent: = Wednesday, June 13, 2012 7:32 PM
To: Peter = Saint-Andre
Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org
Subject: Re: = [apps-discuss] Aggregated service discovery

 

=

In my = use case it's a service/server.

=

 

=

Not a = terribly happy answer to say "DNS SRV records won't work for you, = and there is no other solution.".  By the same token I could = ask "Why do we need Webfinger and host meta at all if we have DNS = SRV records?".

=

 

=

If XMPP = uses SRV records for discovery, that's fine.  IMAP and outbound = SMTP services both lack a defined discovery method other than the = ubiquitous "service documentation".  Is there a = compelling reason to pick DNS over WF for this?  From the app = developer point of view I don't want to have N ways to discover M = services.

=

 

=

-bill

=

 

=

 

<= div>
<= hr size=3D1 width=3D"100%" align=3Dcenter>

F= rom: = Peter Saint-Andre <stpeter@stpeter.im>
To: William Mills = <wmills@yahoo-inc.com>
Cc: Paul E. = Jones <paulej@packetizer.com>; 'Cyrus Daboo' <cyrus@daboo.name>; "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Sent: = Wednesday, June 13, 2012 3:57 PM
Subject: Re: [apps-discuss] = Aggregated service discovery


On 6/13/12 4:54 PM, William Mills = wrote:
> As I said, I'm interested specifically in IMAP, SMTP and = OAuth endpoints.

What exactly is an "endpoint"? A = client? An account? A server?

> As a data point, DNS SRV = records are not controllable in many hosted
> domain = models.

At the last XMPP Summit a few months ago, we learned that = DNS SRV
records are unavailable in whole countries (e.g., Japan). = That doesn't
mean we should define a replacement for DNS over HTTP. = :)

Peter

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


 

 

 

------=_NextPart_000_02BE_01CD4D79.E8599920-- From cyrus@daboo.name Mon Jun 18 15:08: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 C1BAD11E80F6 for ; Mon, 18 Jun 2012 15:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBd8niRowjf1 for ; Mon, 18 Jun 2012 15:08:06 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4023211E80C1 for ; Mon, 18 Jun 2012 15:08:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 61DC529A26DB; Mon, 18 Jun 2012 18:08:05 -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 sbz4l9zJQxHa; Mon, 18 Jun 2012 18:08:04 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 7EDD629A26C8; Mon, 18 Jun 2012 18:08:03 -0400 (EDT) Date: Mon, 18 Jun 2012 18:08:00 -0400 From: Cyrus Daboo To: "Paul E. Jones" , 'William Mills' , 'Peter Saint-Andre' Message-ID: <9D8ACECA51A33EADF323F71B@caldav.corp.apple.com> In-Reply-To: <02bd01cd4d9b$6f651ea0$4e2f5be0$@packetizer.com> References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> <1340046923.34140.YahooMailNeo@web31806.mail.mud.yahoo.com> <027001cd4d8f$48e260f0$daa722d0$@packetizer.com> <1340053004.56116.YahooMailNeo@web31805.mail.mud.yahoo.com> <02bd01cd4d9b$6f651ea0$4e2f5be0$@packetizer.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=934 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 22:08:07 -0000 Hi Paul, --On June 18, 2012 5:43:43 PM -0400 "Paul E. Jones" = wrote: > So, I think any service that would be specified would have: > > =C2=A0=C2=A0 Hostname > > =C2=A0=C2=A0 Port > > =C2=A0=C2=A0 Transport > > =C2=A0=C2=A0 Transport-Security=C2=A0 (Perhaps the transport and = transport security > could be combined?) > > =C2=A0=C2=A0 Protocol specific parameters (IMAP root folder path, SMTP = login > requirements) > > Andrew and I are working on a draft that has pretty much that set of=20 attributes per service. We did include details on authentication - (e.g.=20 mechanism, user id to use etc). Some other features are needed, such as=20 priority (e.g., whether IMAP is preferred over POP). Our draft will start=20 out with an XML schema and its own .well-known resource - that was pretty=20 much our original design before we started the wider discussions here - but = obviously that is all open to change (i.e. JSON, host-meta or whatever). --=20 Cyrus Daboo From paulej@packetizer.com Mon Jun 18 16:43: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 59A9311E80F7 for ; Mon, 18 Jun 2012 16:43:01 -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 u9Cy5tsXgjIo for ; Mon, 18 Jun 2012 16:43:00 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6648821F847F for ; Mon, 18 Jun 2012 16:42:58 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5INgtCj012134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Jun 2012 19:42:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340062976; bh=yWXAedYlXERdNmKyjW7gRXsSIscbtuVxwYry7l8v8jo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=JxzJ072HuNgriSvLWW4MmbkfT+b1aCyU2Y0JyrFiVXXaySSEyBbPnYNuHwhBlIZVF cAqagLcfi62V8rPDmVz1e1b1Jq9zkcytMWbAyyW+ka7Gm5aqh8CLdJih4SHIfls4+n u1Os9+xMj7M7CkxQqWBZ6izIcRsIV9G6Rt/ox6HI= From: "Paul E. Jones" To: "'Cyrus Daboo'" , "'William Mills'" , "'Peter Saint-Andre'" References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> <1340046923.34140.YahooMailNeo@web31806.mail.mud.yahoo.com> <027001cd4d8f$48e260f0$daa722d0$@packetizer.com> <1340053004.56116.YahooMailNeo@web31805.mail.mud.yahoo.com> <02bd01cd4d9b$6f651ea0$4e2f5be0$@packetizer.com> <9D8ACECA51A33EADF323F71B@caldav.corp.apple.com> In-Reply-To: <9D8ACECA51A33EADF323F71B@caldav.corp.apple.com> Date: Mon, 18 Jun 2012 19:42:59 -0400 Message-ID: <02d301cd4dac$18878260$49968720$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNYFRdarpUA3Z9l4mSBSKHTly568wGsYWTHAiB/MPYCgTB6NAGRuS9TAZsphI0CgPvwiQHAzgIyAdRbPCoCdcjfHwDj9hFfAcntoUICMTf0ewHVZ8SWASo++uKTG/zIgA== Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 23:43:01 -0000 Cyrus, > > So, I think any service that would be specified would have: > > > > Hostname > > > > Port > > > > Transport > > > > Transport-Security (Perhaps the transport and transport security > > could be combined?) > > > > Protocol specific parameters (IMAP root folder path, SMTP login > > requirements) > > > > >=20 > Andrew and I are working on a draft that has pretty much that set of > attributes per service. We did include details on authentication - = (e.g. > mechanism, user id to use etc). Some other features are needed, such = as > priority (e.g., whether IMAP is preferred over POP). Our draft will = start > out with an XML schema and its own .well-known resource - that was = pretty > much our original design before we started the wider discussions here = - > but obviously that is all open to change (i.e. JSON, host-meta or > whatever). WebFinger is about discovering resources, and you are defining the = resource. What you are apparently already working on is in line with = the approach I suggested at the outset: use WebFinger with an address = like mailto:paulej@packetizer.com to discover a link relation of type = "config-email" (or whatever) that points to this XML document you're = defining. That XML document can contain all of the information = necessary to provision a mail client. I look forward to seeing it and would be happy to lend a hand. Paul From laurentwalter.goix@telecomitalia.it Tue Jun 19 07:34: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 1317221F853A for ; Tue, 19 Jun 2012 07:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.069 X-Spam-Level: X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBgg2o16rwWV for ; Tue, 19 Jun 2012 07:34:04 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC7221F852A for ; Tue, 19 Jun 2012 07:34:03 -0700 (PDT) Content-Type: multipart/mixed; boundary="_61c1216b-ef6e-43c5-af2d-fd3cb3393eef_" Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 19 Jun 2012 16:34:02 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Tue, 19 Jun 2012 16:34:01 +0200 From: Goix Laurent Walter To: John Bradley , William Mills Date: Tue, 19 Jun 2012 16:33:59 +0200 Thread-Topic: [apps-discuss] Aggregated service discovery Thread-Index: Ac1NkvX3I1Ov3uNNTTKY1r7WNOR4MgAlUt6g Message-ID: References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> <1340047154.69599.YahooMailNeo@web31803.mail.mud.yahoo.com> <24783551-C1B8-456B-8E94-9BF59A3CAC75@ve7jtb.com> <1340051757.92228.YahooMailNeo@web31803.mail.mud.yahoo.com> <3E2D94E4-C8E3-4AF2-A0F0-0C2BCB5B0AA5@ve7jtb.com> In-Reply-To: <3E2D94E4-C8E3-4AF2-A0F0-0C2BCB5B0AA5@ve7jtb.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] R: Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 14:34:11 -0000 --_61c1216b-ef6e-43c5-af2d-fd3cb3393eef_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A11C866FGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A11C866FGRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I also believe the the oauth related links could typically stay in the host= -meta rather than the user's xrd/jrd. The draft should not mandate its usag= e into one or the other imho and it will be up to service providers to incl= ude these links into host-meta (if this can be generalized) or user descrip= tors. Is that your suggestion john? walter Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Pe= r conto di John Bradley Inviato: luned=EC 18 giugno 2012 22.42 A: William Mills Cc: apps-discuss@ietf.org Oggetto: Re: [apps-discuss] Aggregated service discovery OK but you are talking about the OAuth authorization service for IMAP, do = you intend to run different ones for different users? If you are that's fine. However listing the service configuration in the = users XRD rather than pointing to it from the XRD is probably not a good de= sign. Listing a generic OAuth 2.0 authorization service in the users XRD is inter= esting, but probably not specific enough. John B. On 2012-06-18, at 4:35 PM, William Mills wrote: I believe you meant description where you wrote decryption... IMAP likely is advertized with host-meta, however I do have a use case wher= e premium users may get a different DOS guarantee and might be handled on a= different set of servers, and therefor a per-user return would be appropri= ate. ________________________________ From: John Bradley > To: William Mills > Cc: Paul E. Jones >; 'P= eter Saint-Andre' >; "apps-di= scuss@ietf.org" > Sent: Monday, June 18, 2012 1:19 PM Subject: Re: [apps-discuss] Aggregated service discovery That is not what I am saying. I am saying that the user's discovery document has a link relation to the p= roviders decryption of the service. That is different from the imap endpo= int providing the link relation. If you can trust the user's information to provide the Oauth endpoint why c= an't you trust the user's information to link to the description of the ser= vice. As I have pointed out before you probably don't want per user configuration= for things like imap, the simplest thing is to describe the service in ho= st-meta and forget the extra user discovery steps and maintenance. John B. On 2012-06-18, at 3:19 PM, William Mills wrote: Unfortunately we came to the conclusion that letting a service endpoint def= ine it's authenticators is probably wrong, this was in the context of disco= very for SASL mechanisms. The core problem is when the client supports the= password grant if it then trusts the service endpoint to tell it who to gi= ve the username password pair then it's vulnerable. ________________________________ From: John Bradley > To: Paul E. Jones > Cc: 'William Mills' >; 'P= eter Saint-Andre' >; apps-dis= cuss@ietf.org Sent: Monday, June 18, 2012 11:36 AM Subject: Re: [apps-discuss] Aggregated service discovery A user is likely to have a number of OAuth authorization services for diffe= rent things. I suspect that the best way to organize it is to describe the services the = user has: openID Connect imap portable contacts etc and let the service describe how it is authenticated and where the endpoint= s are. For Connect there is a single relation for the Connect issuer and that is t= hen discovered to get the endpoint and other configuration information. Given that user identifiers may point to services in other domains it is be= st to leave it up to the service to describe itself rather than relying on = individual user information to be correct. John B. On 2012-06-18, at 2:22 PM, Paul E. Jones wrote: Bill, In the referenced draft below, I assume the "grant-types" and "token-types"= should be contained inside a "properties"? That is, I think you want this= : { "subject" : "acct:carol@example.com", "links" : [ { "rel" : "oauth2-athorize", "href" : "http://login.example.com/oauth2/authorize" }, { "rel" : "oauth2-token", "href" : "https://login.example.com/oauth2/token", "properties" : { "grant-types" : "code password", "token-types" : "bearer" } } ] } For auto-provisioning of email clients (which I understand was your goal), = we can either define one link relation that points to a separate configurat= ion document of some sort, or we define multiple link relations. My previo= us example showed the single link relation and the email below shows use of= multiple. Both have pros and cons, but I tend to favor using multiple lin= k relations, since this allows one to introduce new stuff without changing = the one mail configuration file. Also, it reduces the number of queries a = mail client has to make to get config information. You indicate that IMAP already has a defined URI. Where is that defined? = I could not find it in the IANA link relations registry, so I assume it's r= eally a URI defined in a spec somewhere. In any case, we could use URIs fo= r these things (rather than defining single token link relation values and = registering them). I have no preference, but I would like an agreed approa= ch to provisioning. I hate configuring all the stuff manually on email cli= ents. :-) Paul From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Monday, June 18, 2012 1:36 PM To: Paul E. Jones; 'Peter Saint-Andre' Cc: 'Cyrus Daboo'; apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery Paul, Thanks for the reply on this. I do already have a separate doc for registe= ring the OAuth specific relations,http://tools.ietf.org/id/draft-wmills-oau= th-lrdd-01.html I don't think I like the thought of having to register a new link type for = every service, but that might be the right way. IMAP already has a URI def= ined for example so if we use a more general link relation then the URI sch= eme details the type. The tradeoff is whether you can look for a specific = link-type or if you have to scan list elements for the URI type you need. -bill ________________________________ From: Paul E. Jones > To: 'William Mills' >; 'P= eter Saint-Andre' > Cc: 'Cyrus Daboo' >; apps-discuss= @ietf.org Sent: Sunday, June 17, 2012 6:48 PM Subject: RE: [apps-discuss] Aggregated service discovery Bill, My apologies for the belated reply. I've been busy this week and got rathe= r behind on email. I do not personally like using SRV records, either. SRV records could work= for smaller domains, but I'm not sure that they're the best solution for l= arger domains. Personally, I would prefer putting users on specific server= s or server clusters and SRV records will not differentiate users. To use WebFinger to find one's IMAP, SMTP, or POP server, we could do as I = suggested in my email. Now the question is what does one query? Since the= se three services are email, I'd suggest we query "mailto:paulej@packetizer= .com". We could use another URI scheme (e.g., "acct:"), but mailto seems m= ost appropriate given that you're seeking info about mail services. I provided an example earlier that would simply point to a config file with= server information. We could do this directly via WebFinger like this: GET /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com This query would then return something like this: { "subject" : "mailto:paulej@packetizer.com", "links" : [ { "rel" : "smtp-server", "properties" : { "host" : "smtp.packetizer.com", "port" : "587", "login-required" : "yes", "transport" : "starttls" } }, { "rel" : "imap-server", "properties" : { "host" : "imap.packetizer.com", "port" : "993", "transport" : "ssl" } } ] } We would need to standardize the link relation values (smtp-server and imap= -server). We would also need to document what the various properties would= be. If you would like to create such a configuration document based on We= bFinger, I'd be happy to help out. In any case, you can see that WebFinger= would serve quite nicely for conveying configuration information given a u= ser's email ID. I'm not sure exactly what you would need for OAuth endpoints, but I would s= uggest you make that a separate document since it is not mail related. (At= least I assume it's not. Even if it were, the mail server information and= OAuth information are still different animals.) Paul From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Wednesday, June 13, 2012 7:32 PM To: Peter Saint-Andre Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org Subject: Re: [apps-discuss] Aggregated service discovery In my use case it's a service/server. Not a terribly happy answer to say "DNS SRV records won't work for you, and= there is no other solution.". By the same token I could ask "Why do we ne= ed Webfinger and host meta at all if we have DNS SRV records?". If XMPP uses SRV records for discovery, that's fine. IMAP and outbound SMT= P services both lack a defined discovery method other than the ubiquitous "= service documentation". Is there a compelling reason to pick DNS over WF f= or this? From the app developer point of view I don't want to have N ways = to discover M services. -bill ________________________________ From: Peter Saint-Andre > To: William Mills > Cc: Paul E. Jones >; 'C= yrus Daboo' >; "apps-discuss@ietf= .org" > Sent: Wednesday, June 13, 2012 3:57 PM Subject: Re: [apps-discuss] Aggregated service discovery On 6/13/12 4:54 PM, William Mills wrote: > As I said, I'm interested specifically in IMAP, SMTP and OAuth endpoints. What exactly is an "endpoint"? A client? An account? A server? > As a data point, DNS SRV records are not controllable in many hosted > domain models. At the last XMPP Summit a few months ago, we learned that DNS SRV records are unavailable in whole countries (e.g., Japan). That doesn't mean we should define a replacement for DNS over HTTP. :) Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE53A11C866FGRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I also believe the the oauth related links could typically s= tay in the host-meta rather than the user’s xrd/jrd. The draft should= not mandate its usage into one or the other imho and it will be up to service provider= s to include these links into host-meta (if this can be generalized) or use= r descriptors.

 

Is that your suggestion john?

walter

 

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounce= s@ietf.org] Per conto di John Bradley
Inviato: luned=EC 18 giugno 2012 22.42
A: William Mills
Cc: apps-discuss@ietf.org
Oggetto: Re: [apps-discuss] Aggregated service discovery<= /span>

 

OK but you are talking about the OAuth authorization= service for IMAP,  do you intend to run different ones for different = users?

 

If you are that's fine.   However listing the s= ervice configuration in the users XRD rather than pointing to it from the X= RD is probably not a good design.

 

Listing a generic OAuth 2.0 authorization service in= the users XRD is interesting, but probably not specific enough.=

 

John B.

On 2012-06-18, at 4:35 PM, William Mills wrote:=



I believe you meant descri= ption where you wrote decryption...

 

IMAP likely is advertized = with host-meta, however I do have a use case where premium users may get a = different DOS guarantee and might be handled on a different set of servers, and therefor a per-user return would be app= ropriate.

 

From: John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills= @yahoo-inc.com>
Cc: Paul E. Jones <paule= j@packetizer.com>; 'Peter Saint-Andre' <stpeter@stpeter.im>; "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Sent: Monday, June 18, 2012 1:19 PM
Subject: Re: [apps-discuss] Aggregated service discovery

 

That is not what I am saying.

 

I am saying that the user's discovery document has a link relation to th= e providers decryption of the service.   That is different from the im= ap endpoint providing the link relation.

 

If you can trust the user's information to provide the Oauth endpoint wh= y can't you trust the user's information to link to the description of the = service.

 

As I have pointed out before you probably don't want per user configurat= ion for things like imap,  the simplest thing is to describe the servi= ce in host-meta and forget the extra user discovery steps and maintenance.

 

John B.

 

On 2012-06-18, at 3:19 PM, William Mills wrote:



Unfortunately we came to t= he conclusion that letting a service endpoint define it's authenticators is= probably wrong, this was in the context of discovery for SASL mechanisms.  The core problem is when the clien= t supports the password grant if it then trusts the service endpoint to tel= l it who to give the username password pair then it's vulnerable.

 

From: John Bradley <ve7jtb@ve7jtb.com>
To: Paul E. Jones <paulej@packetizer.com>
Cc: 'William Mills' <wmills@yahoo-inc.com>; 'Peter Saint-Andre' <stpeter@stpeter.im>= ; apps-discuss@iet= f.org
Sent: Monday, June 18, 2012 11:36 AM
Subject: Re: [apps-discuss] Aggregated service discovery

 

A user is likely to have a number of OAuth authorization services for di= fferent things.  

 

I suspect that the best way to organize it is to describe the services t= he user has:

openID Connect

imap

portable contacts

etc

 

and let the service describe how it is authenticated and where the endpo= ints are.

 

For Connect there is a single relation for the Connect issuer and that i= s then discovered to get the endpoint and other configuration information. =  

Given that user identifiers may point to services in other domains it is= best to leave it up to the service to describe itself rather than relying = on individual user information to be correct.

 

John B.

 

On 2012-06-18, at 2:22 PM, Paul E. Jones wrote:



=

{

  "subj= ect" : "acct:carol@example.com",

  "link= s" :

  [

   = ; {

   = ;   "rel" : "oauth2-athorize",

   = ; },

   = ; {

   = ;   "rel" : "oauth2-token",

   = ;   "href" : "https://login.example.com/oauth2/token= ",=

   &= nbsp; "properties" :

   = ;   {

   = ;    "grant-types" : "code password"= ;,

   &nbs= p;    "token-types" : "bearer"

   = ;   }

   = ; }

  ]

}

<= /p>

From:&= nbsp;William Mills [mailto:wmills@yahoo-inc.com] 
Sent: Monday, June 18, 2012 1:36 PM
To: P= aul E. Jones; 'Peter Saint-Andre'
Cc: '= Cyrus Daboo'; apps-discuss@iet= f.org
Subject: Re: [apps-discuss] Aggregated service discovery

 

Paul,

 

Thanks for the repl= y on this.  I do already have a separate doc for registering the OAuth= specific relations,http://tools.ietf.org/id/draft-wmills-oauth= -lrdd-01.html

 

I don't think I lik= e the thought of having to register a new link type for every service, but = that might be the right way.  IMAP already has a URI defined for example so if we use a more general link rel= ation then the URI scheme details the type.  The tradeoff is whether y= ou can look for a specific link-type or if you have to scan list elements f= or the URI type you need.=

 

-bill

 

 

From:&n= bsp;Paul E. Jones <pa= ulej@packetizer.com>
To: '= William Mills' <wmills@yahoo-inc.com>; 'Peter Saint-Andre' <stpeter@stpeter.im> 
Cc: '= Cyrus Daboo' <cyru= s@daboo.name>;&nb= sp;apps-d= iscuss@ietf.org = ;
Sent: Sunday, June 17, 2012 6:48 PM
Subject: RE: [apps-discuss] Aggregated service discovery

 

= Bill,

=  <= /p>

= My apologies for the belated reply.  I’ve been busy this week an= d got rather behind on email.

=  <= /p>

= I do not personally like using SRV records, either.  SRV records could= work for smaller domains, but I’m not sure that they’re the best solution for larger domains.  Personally, I wo= uld prefer putting users on specific servers or server clusters and SRV rec= ords will not differentiate users.

=  <= /p>

= To use WebFinger to find one’s IMAP, SMTP, or POP server, we could do= as I suggested in my email.  Now the question is what does one query?  Since these three services are email, I’d= suggest we query “mailto:paulej@packetizer.com”.  We could use anothe= r URI scheme (e.g., “acct:”), but mailto seems most appropriate given that you’re seeking info about mail services.

=  <= /p>

= I provided an example earlier that would simply point to a config file with= server information.  We could do this directly via WebFinger like this:=

=  <= /p>

GET /.well-known/= host-meta?resource=3Dmailto:paulej@packetizer.com

=  <= /p>

= This query would then return something like this:

=  <= /p>

{

  "subj= ect" : "mailto:paulej@packetizer.com",

  "link= s" :

  [

   = ; {

      "rel" : "= smtp-server",

   = ;   "properties" :

   = ;   {

   = ;     "host" : "smtp.packetizer.com",

   = ;     "port" : "587",

   = ;     "login-required" : "yes",

   = ;     "transport" : "starttls"

   = ;   }

   = ; },

   = ; {

      "rel" : "= imap-server",

   = ;   "properties" :

   = ;   {

   = ;     "host" : "imap.packetizer.com",

   = ;     "port" : "993",

   = ;     "transport" : "ssl"

   = ;   }

   = ; }

  ]

}

=  <= /p>

= We would need to standardize the link relation values (smtp-server and imap= -server).  We would also need to document what the various properties would be.  If you would like to create such a = configuration document based on WebFinger, I’d be happy to help out.&= nbsp; In any case, you can see that WebFinger would serve quite nicely for = conveying configuration information given a user’s email ID.

=  <= /p>

= I’m not sure exactly what you would need for OAuth endpoints, but I w= ould suggest you make that a separate document since it is not mail related.  (At least I assume it’s not.  Eve= n if it were, the mail server information and OAuth information are still d= ifferent animals.)

=  <= /p>

= Paul

&n= bsp;

From:&n= bsp;William Mills [mailto:wmill= s@yahoo-inc.com]&nbs= p;
Sent: Wednesday, June 13, 2012 7:32 PM
To: P= eter Saint-Andre
Cc: P= aul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org
Subject: Re: [apps-discuss] Aggregated service discovery

 

In my use case it's= a service/server.

 

Not a terribly happ= y answer to say "DNS SRV records won't work for you, and there is no o= ther solution.".  By the same token I could ask "Why do we need Webfinger and host meta at all if we have D= NS SRV records?".

 

If XMPP uses SRV re= cords for discovery, that's fine.  IMAP and outbound SMTP services bot= h lack a defined discovery method other than the ubiquitous "service documentation".  Is there a co= mpelling reason to pick DNS over WF for this?  From the app developer = point of view I don't want to have N ways to discover M services.

 

-bill

 

 

From:&n= bsp;Peter Saint-Andre <st= peter@stpeter.im>
To: W= illiam Mills <= wmills@yahoo-inc.com> 
Cc: P= aul E. Jones <paulej@packetizer.com>; 'Cyrus Daboo' <cyrus@daboo.name>; "apps-discuss@ietf.org"= ; <apps-discus= s@ietf.org> =
Sent: Wednesday, June 13, 2012 3:57 PM
Subject: Re: [apps-discuss] Aggregated service discovery


On 6/13/12 4:54 PM, William Mills wrote:
> As I said, I'm interested specifically in IMAP, SMTP and OAuth endpoin= ts. 

What exactly is an "endpoint"? A client? An account? A server?
> As a data point, DNS SRV records are not controllable in many hosted > domain models.

At the last XMPP Summit a few months ago, we learned that DNS SRV
records are unavailable in whole countries (e.g., Japan). That doesn't
mean we should define a replacement for DNS over HTTP. :)

Peter

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


 

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

 

 

 

 

 

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

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

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

--_000_A09A9E0A4B9C654E8672D1DC003633AE53A11C866FGRFMBX704BA02_-- --_61c1216b-ef6e-43c5-af2d-fd3cb3393eef_ 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= --_61c1216b-ef6e-43c5-af2d-fd3cb3393eef_-- From ve7jtb@ve7jtb.com Tue Jun 19 08:30: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 674E611E808F for ; Tue, 19 Jun 2012 08:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SMRjpJivDkrN for ; Tue, 19 Jun 2012 08:30:52 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7072C21F8518 for ; Tue, 19 Jun 2012 08:30:52 -0700 (PDT) Received: by yenq13 with SMTP id q13so5367427yen.31 for ; Tue, 19 Jun 2012 08:30:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=hXXcuJ3HyZMnRdPLp3VhXQ+6UCl2gI6/R5g4ruWMU5Y=; b=OUJZkzx41DgwOMdjLK+CM5qosbbdgV0v9gYkHj2XsFNjckDy6fXDswYjeX0yW2U4vB 5T7buwD8MdSc9QXym/5t912O/vqbmE8LZgjZBw4mu5pLvZN/WtrLBs/fv7YADAGwuyJF BgluOmz3Z0wdmlLDL28uaQXCsMtSMsYCLf4qMRE6F5zTIn2T8p6YqHmdvCBt9B7kqVXL nMntamQnjBF+PasPxDp9/lXNIYKhyBZMgHrw2tCq8RVsjEDHrLPH9E0OhwG01K89kjO0 XRmTtTlQ5aH4Hko22fniI55m6XUZLlzOUy/a7Mddlc3aL1dSK/SxHIwmTCgyMtNnsoEQ 5Syg== Received: by 10.236.152.97 with SMTP id c61mr23350531yhk.130.1340119851667; Tue, 19 Jun 2012 08:30:51 -0700 (PDT) Received: from [192.168.1.213] (190-20-33-245.baf.movistar.cl. [190.20.33.245]) by mx.google.com with ESMTPS id c12sm35476622ann.15.2012.06.19.08.30.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jun 2012 08:30:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_69EDF29C-6322-4A9D-AFED-439E84F6FA86"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Tue, 19 Jun 2012 11:30:35 -0400 Message-Id: <9748187C-3224-4C70-869C-63D982A920D3@ve7jtb.com> References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> <1340047154.69599.YahooMailNeo@web31803.mail.mud.yahoo.com> <24783551-C1B8-456B-8E94-9BF59A3CAC75@ve7jtb.com> <1340051757.92228.YahooMailNeo@web31803.mail.mud.yahoo.com> <3E2D94E4-C8E3-4AF2-A0F0-0C2BCB5B0AA5@ve7jtb.com> To: Goix Laurent Walter X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQn0kvmo0foRpH/kH9jDnmazw5y7NVRStxrM3QIUxpaq2244DPLwiUVoMWlv0xbDSpZOMNGl Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 15:30:55 -0000 --Apple-Mail=_69EDF29C-6322-4A9D-AFED-439E84F6FA86 Content-Type: multipart/alternative; boundary="Apple-Mail=_A8907D4B-9249-48F7-BF10-4EDB340E69C1" --Apple-Mail=_A8907D4B-9249-48F7-BF10-4EDB340E69C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes, I wouldn't preclude putting config info into the users XRD. =20 It is mostly the protocols that use WF for discovery that should be = specifying the lookup pattern. For Connect you would discover the issuer link relation in the user XRD = and then follow that to get the configuration for the IdP. Allowing a user XRD to define the OAuth endpoint URI and signing keys = would open all sorts of interesting attacks. =20 For Connect we don't assume that the IdP/Issuer controls the user's WF. = I think that is consistent with the overall WF approach. Putting service config directly in a XRD/JRD is supported, however if = those config settings have security implications, that probably limits = them to XRD/JRD that are under the control of the service. When we did XRD several years ago the format was intended to be generic = and allow the protocols using them to define the higher level semantics. For things like IMAP you need to consider that as an enterprise I may be = foo.com but host key email with Google or Yahoo etc.=20 My MTA is going to need to discover me based on my enterprise email but = use the service provider IMAP/SMTP and perhaps my enterprise SSO/OAuth = Authorization service or Mail Service provider SSO/OAuth Authorization = service for getting an access token. There is also the problem of what to do if the enterprise is not hosting = a web server on a host with the same name as the domain(not uncommon, at = least not on a trusted host). This is something WF doesn't yet support but I suspect is important to = Bill's use case and also important to Connect. You probably need to have enough flexibility to accommodate the various = use cases. =20 John B. On 2012-06-19, at 10:33 AM, Goix Laurent Walter wrote: > I also believe the the oauth related links could typically stay in the = host-meta rather than the user=92s xrd/jrd. The draft should not mandate = its usage into one or the other imho and it will be up to service = providers to include these links into host-meta (if this can be = generalized) or user descriptors. > =20 > Is that your suggestion john? > walter > =20 > Da: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] Per conto di John Bradley > Inviato: luned=EC 18 giugno 2012 22.42 > A: William Mills > Cc: apps-discuss@ietf.org > Oggetto: Re: [apps-discuss] Aggregated service discovery > =20 > OK but you are talking about the OAuth authorization service for IMAP, = do you intend to run different ones for different users? > =20 > If you are that's fine. However listing the service configuration in = the users XRD rather than pointing to it from the XRD is probably not a = good design. > =20 > Listing a generic OAuth 2.0 authorization service in the users XRD is = interesting, but probably not specific enough. > =20 > John B. > On 2012-06-18, at 4:35 PM, William Mills wrote: >=20 >=20 > I believe you meant description where you wrote decryption... > =20 > IMAP likely is advertized with host-meta, however I do have a use case = where premium users may get a different DOS guarantee and might be = handled on a different set of servers, and therefor a per-user return = would be appropriate. > =20 > From: John Bradley > To: William Mills =20 > Cc: Paul E. Jones ; 'Peter Saint-Andre' = ; "apps-discuss@ietf.org" =20 > Sent: Monday, June 18, 2012 1:19 PM > Subject: Re: [apps-discuss] Aggregated service discovery > =20 > That is not what I am saying. > =20 > I am saying that the user's discovery document has a link relation to = the providers decryption of the service. That is different from the = imap endpoint providing the link relation. > =20 > If you can trust the user's information to provide the Oauth endpoint = why can't you trust the user's information to link to the description of = the service. > =20 > As I have pointed out before you probably don't want per user = configuration for things like imap, the simplest thing is to describe = the service in host-meta and forget the extra user discovery steps and = maintenance. > =20 > John B. > =20 > On 2012-06-18, at 3:19 PM, William Mills wrote: >=20 >=20 > Unfortunately we came to the conclusion that letting a service = endpoint define it's authenticators is probably wrong, this was in the = context of discovery for SASL mechanisms. The core problem is when the = client supports the password grant if it then trusts the service = endpoint to tell it who to give the username password pair then it's = vulnerable. > =20 > From: John Bradley > To: Paul E. Jones =20 > Cc: 'William Mills' ; 'Peter Saint-Andre' = ; apps-discuss@ietf.org=20 > Sent: Monday, June 18, 2012 11:36 AM > Subject: Re: [apps-discuss] Aggregated service discovery > =20 > A user is likely to have a number of OAuth authorization services for = different things. =20 > =20 > I suspect that the best way to organize it is to describe the services = the user has: > openID Connect > imap > portable contacts > etc > =20 > and let the service describe how it is authenticated and where the = endpoints are. > =20 > For Connect there is a single relation for the Connect issuer and that = is then discovered to get the endpoint and other configuration = information. =20 > Given that user identifiers may point to services in other domains it = is best to leave it up to the service to describe itself rather than = relying on individual user information to be correct. > =20 > John B. > =20 > On 2012-06-18, at 2:22 PM, Paul E. Jones wrote: >=20 >=20 > Bill, > =20 > In the referenced draft below, I assume the =93grant-types=94 and = =93token-types=94 should be contained inside a =93properties=94? That = is, I think you want this: > =20 > { > "subject" : "acct:carol@example.com", > "links" : > [ > { > "rel" : "oauth2-athorize", > "href" : "http://login.example.com/oauth2/authorize" > }, > { > "rel" : "oauth2-token", > "href" : "https://login.example.com/oauth2/token", > "properties" : > { > "grant-types" : "code password", > "token-types" : "bearer" > } > } > ] > } > =20 > For auto-provisioning of email clients (which I understand was your = goal), we can either define one link relation that points to a separate = configuration document of some sort, or we define multiple link = relations. My previous example showed the single link relation and the = email below shows use of multiple. Both have pros and cons, but I tend = to favor using multiple link relations, since this allows one to = introduce new stuff without changing the one mail configuration file. = Also, it reduces the number of queries a mail client has to make to get = config information. > =20 > You indicate that IMAP already has a defined URI. Where is that = defined? I could not find it in the IANA link relations registry, so I = assume it=92s really a URI defined in a spec somewhere. In any case, we = could use URIs for these things (rather than defining single token link = relation values and registering them). I have no preference, but I = would like an agreed approach to provisioning. I hate configuring all = the stuff manually on email clients. :-) > =20 > Paul > =20 > From: William Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Monday, June 18, 2012 1:36 PM > To: Paul E. Jones; 'Peter Saint-Andre' > Cc: 'Cyrus Daboo'; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Aggregated service discovery > =20 > Paul, > =20 > Thanks for the reply on this. I do already have a separate doc for = registering the OAuth specific = relations,http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html > =20 > I don't think I like the thought of having to register a new link type = for every service, but that might be the right way. IMAP already has a = URI defined for example so if we use a more general link relation then = the URI scheme details the type. The tradeoff is whether you can look = for a specific link-type or if you have to scan list elements for the = URI type you need. > =20 > -bill > =20 > =20 > From: Paul E. Jones > To: 'William Mills' ; 'Peter Saint-Andre' = =20 > Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org=20 > Sent: Sunday, June 17, 2012 6:48 PM > Subject: RE: [apps-discuss] Aggregated service discovery > =20 > Bill, > =20 > My apologies for the belated reply. I=92ve been busy this week and = got rather behind on email. > =20 > I do not personally like using SRV records, either. SRV records could = work for smaller domains, but I=92m not sure that they=92re the best = solution for larger domains. Personally, I would prefer putting users = on specific servers or server clusters and SRV records will not = differentiate users. > =20 > To use WebFinger to find one=92s IMAP, SMTP, or POP server, we could = do as I suggested in my email. Now the question is what does one query? = Since these three services are email, I=92d suggest we query = =93mailto:paulej@packetizer.com=94. We could use another URI scheme = (e.g., =93acct:=94), but mailto seems most appropriate given that you=92re= seeking info about mail services. > =20 > I provided an example earlier that would simply point to a config file = with server information. We could do this directly via WebFinger like = this: > =20 > GET /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com > =20 > This query would then return something like this: > =20 > { > "subject" : "mailto:paulej@packetizer.com", > "links" : > [ > { > "rel" : "smtp-server", > "properties" : > { > "host" : "smtp.packetizer.com", > "port" : "587", > "login-required" : "yes", > "transport" : "starttls" > } > }, > { > "rel" : "imap-server", > "properties" : > { > "host" : "imap.packetizer.com", > "port" : "993", > "transport" : "ssl" > } > } > ] > } > =20 > We would need to standardize the link relation values (smtp-server and = imap-server). We would also need to document what the various = properties would be. If you would like to create such a configuration = document based on WebFinger, I=92d be happy to help out. In any case, = you can see that WebFinger would serve quite nicely for conveying = configuration information given a user=92s email ID. > =20 > I=92m not sure exactly what you would need for OAuth endpoints, but I = would suggest you make that a separate document since it is not mail = related. (At least I assume it=92s not. Even if it were, the mail = server information and OAuth information are still different animals.) > =20 > Paul > =20 > From: William Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Wednesday, June 13, 2012 7:32 PM > To: Peter Saint-Andre > Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Aggregated service discovery > =20 > In my use case it's a service/server. > =20 > Not a terribly happy answer to say "DNS SRV records won't work for = you, and there is no other solution.". By the same token I could ask = "Why do we need Webfinger and host meta at all if we have DNS SRV = records?". > =20 > If XMPP uses SRV records for discovery, that's fine. IMAP and = outbound SMTP services both lack a defined discovery method other than = the ubiquitous "service documentation". Is there a compelling reason to = pick DNS over WF for this? =46rom the app developer point of view I = don't want to have N ways to discover M services. > =20 > -bill > =20 > =20 > From: Peter Saint-Andre > To: William Mills =20 > Cc: Paul E. Jones ; 'Cyrus Daboo' = ; "apps-discuss@ietf.org" =20 > Sent: Wednesday, June 13, 2012 3:57 PM > Subject: Re: [apps-discuss] Aggregated service discovery >=20 > On 6/13/12 4:54 PM, William Mills wrote: > > As I said, I'm interested specifically in IMAP, SMTP and OAuth = endpoints.=20 >=20 > What exactly is an "endpoint"? A client? An account? A server? >=20 > > As a data point, DNS SRV records are not controllable in many hosted > > domain models. >=20 > At the last XMPP Summit a few months ago, we learned that DNS SRV > records are unavailable in whole countries (e.g., Japan). That doesn't > mean we should define a replacement for DNS over HTTP. :) >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 >=20 > =20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > =20 > =20 >=20 > =20 > =20 >=20 > =20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. > This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks. >=20 > Rispetta l'ambiente. Non stampare questa = mail se non =E8 necessario. >=20 > --Apple-Mail=_A8907D4B-9249-48F7-BF10-4EDB340E69C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yes,

I wouldn't preclude putting = config info into the users XRD.   =  

It is mostly the protocols that use WF = for discovery that should be specifying the lookup = pattern.

For Connect you would discover the = issuer link relation in the user XRD and then follow that to get the = configuration for the IdP.

Allowing a user XRD = to define the OAuth endpoint URI and signing keys would open all sorts = of interesting attacks.  

For Connect we = don't assume that the IdP/Issuer controls the user's WF.   I think = that is consistent with the overall WF = approach.

Putting service config directly in a = XRD/JRD is supported, however if those config settings have security = implications, that probably limits them to XRD/JRD that are under the = control of the service.

When we did XRD several = years ago the format was intended to be generic and allow the protocols = using them to define the higher level = semantics.

For things like IMAP you need to = consider that as an enterprise I may be foo.com but host key email with Google or = Yahoo etc. 

My MTA is going to need to = discover me based on my enterprise email but use the service provider = IMAP/SMTP and perhaps my enterprise SSO/OAuth Authorization service or = Mail Service provider SSO/OAuth Authorization service for getting = an access token.

There is also the problem of = what to do if the enterprise is not hosting a web server on a host with = the same name as the domain(not uncommon, at least not on a trusted = host).
This is something WF doesn't yet support but I suspect = is important to Bill's use case and also important to = Connect.

You probably need to have enough = flexibility to accommodate the various use cases. =  

John = B.

On 2012-06-19, at 10:33 AM, Goix = Laurent Walter wrote:

I also = believe the the oauth related links could typically stay in the = host-meta rather than the user=92s xrd/jrd. The draft should not mandate = its usage into one or the other imho and it will be up to service = providers to include these links into host-meta (if this can be = generalized) or user descriptors.
Is that your suggestion = john?
walter
 
Da: apps-discuss-bounces@ietf.or= g [mailto:apps-discuss-bounces@ietf.org] Per conto di John = Bradley
Inviato: luned=EC 18 giugno 2012 = 22.42
A: William = Mills
Cc: apps-discuss@ietf.org
Ogge= tto: Re: = [apps-discuss] Aggregated service = discovery
OK but you are talking about = the OAuth authorization service for IMAP,  do you intend to run = different ones for different users?
 
If you are that's fine.   However listing the = service configuration in the users XRD rather than pointing to it from = the XRD is probably not a good design.
 
Listing a generic OAuth 2.0 authorization service in = the users XRD is interesting, but probably not specific = enough.
John = B.
On 2012-06-18, at 4:35 = PM, William Mills wrote:
I = believe you meant description where you wrote = decryption...
 
IMAP likely is advertized with host-meta, = however I do have a use case where premium users may get a different DOS = guarantee and might be handled on a different set of servers, and = therefor a per-user return would be = appropriate.
From: John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills@yahoo-inc.com> 
Cc: Paul E. Jones <paulej@packetizer.com>; 'Peter = Saint-Andre' <stpeter@stpeter.im>; "apps-discuss@ietf.org" <apps-discuss@ietf.org> 
Sent: Monday, June 18, 2012 1:19 = PM
Subject: Re: [apps-discuss] = Aggregated service discovery 
That is not what I am saying.
I am saying that the user's = discovery document has a link relation to the providers decryption of = the service.   That is different from the imap endpoint providing = the link relation.
If you can trust the user's = information to provide the Oauth endpoint why can't you trust the user's = information to link to the description of the = service.
As I have pointed out before you = probably don't want per user configuration for things like imap, =  the simplest thing is to describe the service in host-meta and = forget the extra user discovery steps and = maintenance.
John = B.
 
On 2012-06-18, = at 3:19 PM, William Mills wrote:
Unfortunately we came to the conclusion that letting a = service endpoint define it's authenticators is probably wrong, this was = in the context of discovery for SASL mechanisms.  The core problem = is when the client supports the password grant if it then trusts the = service endpoint to tell it who to give the username password pair then = it's vulnerable.
From: John Bradley < Paul E. Jones <paulej@packetizer.com> 
Cc: 'William Mills' <wmills@yahoo-inc.com>; 'Peter = Saint-Andre' < apps-discuss@ietf.org 
Sent: Monday, June 18, 2012 11:36 = AM
Subject: Re: [apps-discuss] = Aggregated service discovery 
A user is likely to have a number of OAuth authorization = services for different things.  
I suspect that the best way to = organize it is to describe the services the user = has:
openID Connect
portable contacts
 
and let the = service describe how it is authenticated and where the endpoints = are.
 
For Connect = there is a single relation for the Connect issuer and that is then = discovered to get the endpoint and other configuration information. =  
Given that user identifiers may point to services in other = domains it is best to leave it up to the service to describe itself = rather than relying on individual user information to be = correct.
John = B.
 
On 2012-06-18, = at 2:22 PM, Paul E. Jones wrote:
Bill, 
In the referenced draft = below, I assume the =93grant-types=94 and =93token-types=94 should be = contained inside a =93properties=94?  That is, I think you want = this: 
{
  = "subject" : "acct:carol@example.com",
  = "links" :  [    {
      = "rel" : "oauth2-athorize",
      = "href" : "    },
 
From:Paul E. Jones < 'William = Mills' <stpeter@stpeter.im> 
Cc: 'Cyrus = Daboo' < apps-discuss@ietf.org 
Sent:=  Sunday, = June 17, 2012 6:48 PM
Subject: RE: = [apps-discuss] Aggregated service discovery
Bill, My apologies for the = belated reply.  I=92ve been busy this week and got rather behind on = email. I do not personally like = using SRV records, either.  SRV records could work for smaller = domains, but I=92m not sure that they=92re the best solution for larger = domains.  Personally, I would prefer putting users on specific = servers or server clusters and SRV records will not differentiate = users. To use WebFinger to find = one=92s IMAP, SMTP, or POP server, we could do as I suggested in my = email.  Now the question is what does one query?  Since these = three services are email, I=92d suggest we query =93 I provided an example = earlier that would simply point to a config file with server = information.  We could do this directly via WebFinger like = this: GET = /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com This query would then = return something like this:
From:Peter Saint-Andre < William Mills = < 
Cc: Paul E. = Jones <cyrus@daboo.name>; "apps-discuss@ietf.org" <apps-discuss@ietf.org> 
Sent:=  Wednesday,= June 13, 2012 3:57 PM
Subject: Re: = [apps-discuss] Aggregated service discovery


On 6/13/12 4:54 PM, William = Mills wrote:
> As I said, I'm interested specifically in IMAP, = SMTP and OAuth endpoints. 

What = exactly is an "endpoint"? A client? An account? A server?

> As = a data point, DNS SRV records are not controllable in many = hosted
> domain models.

At the last XMPP Summit a few = months ago, we learned that DNS SRV
records are unavailable in whole = countries (e.g., Japan). That doesn't
mean we should define a = replacement for DNS over HTTP. :)

Peter

-- 
Peter = Saint-Andre

 

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

This e-mail and any attachmentsis 

<logo = Ambiente_foglia2.jpg>Rispetta l'ambiente. Non stampare questa = mail se non =E8 necessario.

&= lt;logo = Ambiente_foglia2.jpg>

<= /body>= --Apple-Mail=_A8907D4B-9249-48F7-BF10-4EDB340E69C1-- --Apple-Mail=_69EDF29C-6322-4A9D-AFED-439E84F6FA86 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYx OTE1MzAzNlowIwYJKoZIhvcNAQkEMRYEFDYUNeKAQmJabAoPw9fku3XbeIqpMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AC4t0/d+GEc6hC/yOcf8avm8oXLzf39UBabS/XOijHAOOjm6RhE5DyOxGpwbpgDxeKM6E5l2oNPv YrZwVI4wqA3eDvsU6b7oMdCBjjggPuCpXIaizfd7N184p0YSR7Pgl7BhYg9CrAaWSV2vBtojMjZb oQ12UaW4rgEYzqzLomoFEx0rr2e5+G9NEmMGnR0LmQh6JcykVnimZRCEe5Q2vtSC9GDCx8Pzysdd GOaAq0L86Xse/DtzxcwShoTqQMslkEqxqYMtZ/SfLJk2MYaI2uQ0ka3vWTgVgzb5q7XgaKSt2Hpc Sy5OjGQfGV3T4sCcACCpJunv6M6CZN2hnbj75JIAAAAAAAA= --Apple-Mail=_69EDF29C-6322-4A9D-AFED-439E84F6FA86-- From wmills@yahoo-inc.com Tue Jun 19 08:51: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 5014421F8466 for ; Tue, 19 Jun 2012 08:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.539 X-Spam-Level: X-Spam-Status: No, score=-17.539 tagged_above=-999 required=5 tests=[AWL=0.059, 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 RkdS4bxzLrEf for ; Tue, 19 Jun 2012 08:51:50 -0700 (PDT) Received: from nm30.bullet.mail.sp2.yahoo.com (nm30.bullet.mail.sp2.yahoo.com [98.139.91.100]) by ietfa.amsl.com (Postfix) with SMTP id C73DD11E8085 for ; Tue, 19 Jun 2012 08:51:50 -0700 (PDT) Received: from [98.139.91.62] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 19 Jun 2012 15:51:50 -0000 Received: from [98.139.91.20] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 19 Jun 2012 15:51:50 -0000 Received: from [127.0.0.1] by omp1020.mail.sp2.yahoo.com with NNFMP; 19 Jun 2012 15:51:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 680047.99894.bm@omp1020.mail.sp2.yahoo.com Received: (qmail 55192 invoked by uid 60001); 19 Jun 2012 15:51:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1340121110; bh=Z/Vcd220IST0dUXlwtuGizpvSeuXaJihU6grfokQNzw=; 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=AWriykqGBrjUz8BxdB0eDJvIbAFhmMeixb64XmrT26Ctqpn3QS7MriBl0eVHM/x+UDUGy632zY/ygeIDSTU2DELuD6ISNLBQto4LrAwuEh+d+Lp2UDLjMw2JKBo5sCytzjkIH0NnmqA95zQaV136FVf4nePuWXN7N3YqRNXWkRw= 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=I5Io51RrEAGokPt8NxtUq2L5Y7bD1djmmuZhBe9xBfW+EsWuN6Z73sQyhjLYRMHKWeVxgqtEjPul+kUysChIQSn2k04TNiMCm4h6Ht3d0qT/GpRRBkc0cq7G6FQHHQz/iOj8DjNeS7AXxPJfTrWq0f0gBTjcAD3WKRWHRpj1ncE=; X-YMail-OSG: WP3SwrQVM1nDgJVt.MdgRb3kghUv8BtunOiC.gJS_GleS9U CZR7GfuFScVnZM_CLO5ImUyiElq5rt.7BJhrlPdTMyIQMZCLzkCe_1RmsEWa iwgNModySNcn48fc_qyvLLVWHOHHoFkcJlZ67d8ZZdZ_BzxNln94kxRZKYs9 EdSelClBVPdECHHEfwopbaY1LnFQJ2I2QzOOrzNVXFqIP1L7JCmomndTvW._ zfx6sE3wpspiyeVWMY4yS1hPsurz1gp21Zyafyx3CWfWHb5C3kxs2_Dfvp9Z EKtzf06UiQYdcq7HiKSXTE4mQ3vtrRMUCzVmCY9RuSHe.2rS6RmSMrke5UFc eDDGn0JV9gUwrzKjc8brb0Ww5lBKA36McWpp5lDhLxaGawZ.mO7PPLYMalwp PTYNOSXnbqEQvKWByzw4aK_o4DXuRXie60gRzwpWzJ2l8iABO674EF4j1wws fPtmj5l5FEXrH5EjgOTf.4AieSm_FKvMiZkr1wDMPOmJTysZqlGjC9iZcau0 MKolVpGKzKQxefVcTvWMB8TYcdm6jBykT_7DlaI4_AYZPyA-- Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Tue, 19 Jun 2012 08:51:49 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> <1340047154.69599.YahooMailNeo@web31803.mail.mud.yahoo.com> <24783551-C1B8-456B-8E94-9BF59A3CAC75@ve7jtb.com> <1340051757.92228.YahooMailNeo@web31803.mail.mud.yahoo.com> <3E2D94E4-C8E3-4AF2-A0F0-0C2BCB5B0AA5@ve7jtb.com> Message-ID: <1340121109.49261.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Tue, 19 Jun 2012 08:51:49 -0700 (PDT) From: William Mills To: Goix Laurent Walter , John Bradley In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1502656925-1692655810-1340121109=:49261" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] R: Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 15:51:53 -0000 --1502656925-1692655810-1340121109=:49261 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Agreed, and in fact the 3rd avenue this might be used in is Link headers on= a failed OAuth authorization in a webservices context.=C2=A0 I'll re-read = with that in mind and see if we need edits.=0A=0A=0A=0A=0A>________________= ________________=0A> From: Goix Laurent Walter =0A>To: John Bradley ; William Mills =0A>Cc: "apps-discuss@ietf.org" =0A>Se= nt: Tuesday, June 19, 2012 7:33 AM=0A>Subject: R: [apps-discuss] Aggregated= service discovery=0A> =0A>=0A> =0A>I also believe the the oauth related li= nks could typically stay in the host-meta rather than the user=E2=80=99s xr= d/jrd. The draft should not mandate its usage into one or the other imho an= d it will be up to service providers to include these links into host-meta = (if this can be generalized) or user descriptors.=0A>=C2=A0=0A>Is that your= suggestion john?=0A>walter=0A>=C2=A0=0A>Da:apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] Per conto di John Bradley=0A>Inviato:= luned=C3=AC 18 giugno 2012 22.42=0A>A: William Mills=0A>Cc: apps-discuss@i= etf.org=0A>Oggetto: Re: [apps-discuss] Aggregated service discovery=0A>=C2= =A0=0A>OK but you are talking about the OAuth authorization service for IMA= P, =C2=A0do you intend to run different ones for different users?=0A>=C2=A0= =0A>If you are that's fine. =C2=A0 However listing the service configuratio= n in the users XRD rather than pointing to it from the XRD is probably not = a good design.=0A>=C2=A0=0A>Listing a generic OAuth 2.0 authorization servi= ce in the users XRD is interesting, but probably not specific enough.=0A>= =C2=A0=0A>John B.=0A>On 2012-06-18, at 4:35 PM, William Mills wrote:=0A>=0A= >=0A>=0A>I believe you meant description where you wrote decryption...=0A>= =C2=A0=0A>IMAP likely is advertized with host-meta, however I do have a use= case where premium users may get a different DOS guarantee and might be ha= ndled on a different set of servers, and therefor a per-user return would b= e appropriate.=0A>=C2=A0=0A>>=0A>>________________________________=0A>> =0A= >>From:John Bradley =0A>>To: William Mills =0A>>Cc: Paul E. Jones ; 'Peter Saint-Andr= e' ; "apps-discuss@ietf.org" = =0A>>Sent: Monday, June 18, 2012 1:19 PM=0A>>Subject: Re: [apps-discuss] Ag= gregated service discovery=0A>>=C2=A0=0A>>That is not what I am saying.=0A>= >=C2=A0=0A>>I am saying that the user's discovery document has a link relat= ion to the providers decryption of the service. =C2=A0 That is different fr= om the imap endpoint providing the link relation.=0A>>=C2=A0=0A>>If you can= trust the user's information to provide the Oauth endpoint why can't you t= rust the user's information to link to the description of the service.=0A>>= =C2=A0=0A>>As I have pointed out before you probably don't want per user co= nfiguration for things like imap, =C2=A0the simplest thing is to describe t= he service in host-meta and forget the extra user discovery steps and maint= enance.=0A>>=C2=A0=0A>>John B.=0A>>=C2=A0=0A>>On 2012-06-18, at 3:19 PM, Wi= lliam Mills wrote:=0A>>=0A>>=0A>>=0A>>Unfortunately we came to the conclusi= on that letting a service endpoint define it's authenticators is probably w= rong, this was in the context of discovery for SASL mechanisms.=C2=A0 The c= ore problem is when the client supports the password grant if it then trust= s the service endpoint to tell it who to give the username password pair th= en it's vulnerable.=0A>>=C2=A0=0A>>>=0A>>>________________________________= =0A>>> =0A>>>From:John Bradley =0A>>>To: Paul E. Jones <= paulej@packetizer.com> =0A>>>Cc: 'William Mills' ; 'P= eter Saint-Andre' ; apps-discuss@ietf.org =0A>>>Sent: M= onday, June 18, 2012 11:36 AM=0A>>>Subject: Re: [apps-discuss] Aggregated s= ervice discovery=0A>>>=C2=A0=0A>>>A user is likely to have a number of OAut= h authorization services for different things. =C2=A0=0A>>>=C2=A0=0A>>>I su= spect that the best way to organize it is to describe the services the user= has:=0A>>>openID Connect=0A>>>imap=0A>>>portable contacts=0A>>>etc=0A>>>= =C2=A0=0A>>>and let the service describe how it is authenticated and where = the endpoints are.=0A>>>=C2=A0=0A>>>For Connect there is a single relation = for the Connect issuer and that is then discovered to get the endpoint and = other configuration information. =C2=A0=0A>>>Given that user identifiers ma= y point to services in other domains it is best to leave it up to the servi= ce to describe itself rather than relying on individual user information to= be correct.=0A>>>=C2=A0=0A>>>John B.=0A>>>=C2=A0=0A>>>On 2012-06-18, at 2:= 22 PM, Paul E. Jones wrote:=0A>>>=0A>>>=0A>>>=0A>>>Bill,=0A>>>=C2=A0=0A>>>I= n the referenced draft below, I assume the =E2=80=9Cgrant-types=E2=80=9D an= d =E2=80=9Ctoken-types=E2=80=9D should be contained inside a =E2=80=9Cprope= rties=E2=80=9D?=C2=A0 That is, I think you want this:=0A>>>=C2=A0=0A>>>{=0A= >>>=C2=A0 "subject" : "acct:carol@example.com",=0A>>>=C2=A0 "links" :=0A>>>= =C2=A0 [=0A>>>=C2=A0=C2=A0=C2=A0 {=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel= " : "oauth2-athorize",=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "href" : "http:/= /login.example.com/oauth2/authorize"=0A>>>=C2=A0=C2=A0=C2=A0 },=0A>>>=C2=A0= =C2=A0=C2=A0 {=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : "oauth2-token",= =0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "href" : "https://login.example.com/oa= uth2/token",=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"properties" :=0A>>>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 {=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"= grant-types" : "code password",=0A>>>=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0"token-types" : "bearer"=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=0A>>>= =C2=A0=C2=A0=C2=A0 }=0A>>>=C2=A0 ]=0A>>>}=0A>>>=C2=A0=0A>>>For auto-provisi= oning of email clients (which I understand was your goal), we can either de= fine one link relation that points to a separate configuration document of = some sort, or we define multiple link relations.=C2=A0 My previous example = showed the single link relation and the email below shows use of multiple.= =C2=A0 Both have pros and cons, but I tend to favor using multiple link rel= ations, since this allows one to introduce new stuff without changing the o= ne mail configuration file.=C2=A0 Also, it reduces the number of queries a = mail client has to make to get config information.=0A>>>=C2=A0=0A>>>You ind= icate that IMAP already has a defined URI.=C2=A0 Where is that defined?=C2= =A0 I could not find it in the IANA link relations registry, so I assume it= =E2=80=99s really a URI defined in a spec somewhere.=C2=A0 In any case, we = could use URIs for these things (rather than defining single token link rel= ation values and registering them).=C2=A0 I have no preference, but I would= like an agreed approach to provisioning.=C2=A0 I hate configuring all the = stuff manually on email clients. :-)=0A>>>=C2=A0=0A>>>Paul=0A>>>=C2=A0=0A>>= >From:=C2=A0William Mills [mailto:wmills@yahoo-inc.com]=C2=A0=0A>>>Sent:=C2= =A0Monday, June 18, 2012 1:36 PM=0A>>>To:=C2=A0Paul E. Jones; 'Peter Saint-= Andre'=0A>>>Cc:=C2=A0'Cyrus Daboo'; apps-discuss@ietf.org=0A>>>Subject:=C2= =A0Re: [apps-discuss] Aggregated service discovery=0A>>>=C2=A0=0A>>>Paul,= =0A>>>=C2=A0=0A>>>Thanks for the reply on this.=C2=A0 I do already have a s= eparate doc for registering the OAuth specific relations,http://tools.ietf.= org/id/draft-wmills-oauth-lrdd-01.html=0A>>>=C2=A0=0A>>>I don't think I lik= e the thought of having to register a new link type for every service, but = that might be the right way.=C2=A0 IMAP already has a URI defined for examp= le so if we use a more general link relation then the URI scheme details th= e type.=C2=A0 The tradeoff is whether you can look for a specific link-type= or if you have to scan list elements for the URI type you need.=0A>>>=C2= =A0=0A>>>-bill=0A>>>=C2=A0=0A>>>=C2=A0=0A>>>>=0A>>>>_______________________= _________=0A>>>> =0A>>>>From:=C2=A0Paul E. Jones =0A= >>>>To:=C2=A0'William Mills' ; 'Peter Saint-Andre' =C2=A0=0A>>>>Cc:=C2=A0'Cyrus Daboo' ;= =C2=A0apps-discuss@ietf.org=C2=A0=0A>>>>Sent:=C2=A0Sunday, June 17, 2012 6:= 48 PM=0A>>>>Subject:=C2=A0RE: [apps-discuss] Aggregated service discovery= =0A>>>>=C2=A0=0A>>>>Bill,=0A>>>>=C2=A0=0A>>>>My apologies for the belated r= eply.=C2=A0 I=E2=80=99ve been busy this week and got rather behind on email= .=0A>>>>=C2=A0=0A>>>>I do not personally like using SRV records, either.=C2= =A0 SRV records could work for smaller domains, but I=E2=80=99m not sure th= at they=E2=80=99re the best solution for larger domains.=C2=A0 Personally, = I would prefer putting users on specific servers or server clusters and SRV= records will not differentiate users.=0A>>>>=C2=A0=0A>>>>To use WebFinger = to find one=E2=80=99s IMAP, SMTP, or POP server, we could do as I suggested= in my email.=C2=A0 Now the question is what does one query?=C2=A0 Since th= ese three services are email, I=E2=80=99d suggest we query =E2=80=9Cmailto:= paulej@packetizer.com=E2=80=9D.=C2=A0 We could use another URI scheme (e.g.= , =E2=80=9Cacct:=E2=80=9D), but mailto seems most appropriate given that yo= u=E2=80=99re seeking info about mail services.=0A>>>>=C2=A0=0A>>>>I provide= d an example earlier that would simply point to a config file with server i= nformation.=C2=A0 We could do this directly via WebFinger like this:=0A>>>>= =C2=A0=0A>>>>GET /.well-known/host-meta?resource=3Dmailto:paulej@packetizer= .com=0A>>>>=C2=A0=0A>>>>This query would then return something like this:= =0A>>>>=C2=A0=0A>>>>{=0A>>>>=C2=A0 "subject" : "mailto:paulej@packetizer.co= m",=0A>>>>=C2=A0 "links" :=0A>>>>=C2=A0 [=0A>>>>=C2=A0=C2=A0=C2=A0 {=0A>>>>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : "smtp-server",=0A>>>>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "properties" :=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=0A>>>= >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "host" : "smtp.packetizer.com",= =0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "port" : "587",=0A>>>>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "login-required" : "yes",=0A>>>>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "transport" : "starttls"=0A>>>>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 }=0A>>>>=C2=A0=C2=A0=C2=A0 },=0A>>>>=C2=A0=C2= =A0=C2=A0 {=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rel" : "imap-server",=0A>= >>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "properties" :=0A>>>>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 {=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "host" : "i= map.packetizer.com",=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "port= " : "993",=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "transport" : "= ssl"=0A>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=0A>>>>=C2=A0=C2=A0=C2=A0 }=0A>>= >>=C2=A0 ]=0A>>>>}=0A>>>>=C2=A0=0A>>>>We would need to standardize the link= relation values (smtp-server and imap-server).=C2=A0 We would also need to= document what the various properties would be.=C2=A0 If you would like to = create such a configuration document based on WebFinger, I=E2=80=99d be hap= py to help out.=C2=A0 In any case, you can see that WebFinger would serve q= uite nicely for conveying configuration information given a user=E2=80=99s = email ID.=0A>>>>=C2=A0=0A>>>>I=E2=80=99m not sure exactly what you would ne= ed for OAuth endpoints, but I would suggest you make that a separate docume= nt since it is not mail related.=C2=A0 (At least I assume it=E2=80=99s not.= =C2=A0 Even if it were, the mail server information and OAuth information a= re still different animals.)=0A>>>>=C2=A0=0A>>>>Paul=0A>>>>=C2=A0=0A>>>>Fro= m:=C2=A0William Mills=C2=A0[mailto:wmills@yahoo-inc.com]=C2=A0=0A>>>>Sent:= =C2=A0Wednesday, June 13, 2012 7:32 PM=0A>>>>To:=C2=A0Peter Saint-Andre=0A>= >>>Cc:=C2=A0Paul E. Jones; 'Cyrus Daboo';=C2=A0apps-discuss@ietf.org=0A>>>>= Subject:=C2=A0Re: [apps-discuss] Aggregated service discovery=0A>>>>=C2=A0= =0A>>>>In my use case it's a service/server.=0A>>>>=C2=A0=0A>>>>Not a terri= bly happy answer to say "DNS SRV records won't work for you, and there is n= o other solution.".=C2=A0 By the same token I could ask "Why do we need Web= finger and host meta at all if we have DNS SRV records?".=0A>>>>=C2=A0=0A>>= >>If XMPP uses SRV records for discovery, that's fine.=C2=A0 IMAP and outbo= und SMTP services both lack a defined discovery method other than the ubiqu= itous "service documentation".=C2=A0 Is there a compelling reason to pick D= NS over WF for this?=C2=A0 From the app developer point of view I don't wan= t to have N ways to discover M services.=0A>>>>=C2=A0=0A>>>>-bill=0A>>>>=C2= =A0=0A>>>>=C2=A0=0A>>>>>=0A>>>>>________________________________=0A>>>>> = =0A>>>>>From:=C2=A0Peter Saint-Andre =0A>>>>>To:=C2=A0W= illiam Mills =C2=A0=0A>>>>>Cc:=C2=A0Paul E. Jones ; 'Cyrus Daboo' ; "apps-discuss@ietf.= org" =C2=A0=0A>>>>>Sent:=C2=A0Wednesday, June 13, 20= 12 3:57 PM=0A>>>>>Subject:=C2=A0Re: [apps-discuss] Aggregated service disco= very=0A>>>>>=0A>>>>>On 6/13/12 4:54 PM, William Mills wrote:=0A>>>>>> As I = said, I'm interested specifically in IMAP, SMTP and OAuth endpoints.=C2=A0= =0A>>>>>=0A>>>>>What exactly is an "endpoint"? A client? An account? A serv= er?=0A>>>>>=0A>>>>>> As a data point, DNS SRV records are not controllable = in many hosted=0A>>>>>> domain models.=0A>>>>>=0A>>>>>At the last XMPP Summ= it a few months ago, we learned that DNS SRV=0A>>>>>records are unavailable= in whole countries (e.g., Japan). That doesn't=0A>>>>>mean we should defin= e a replacement for DNS over HTTP. :)=0A>>>>>=0A>>>>>Peter=0A>>>>>=0A>>>>>-= -=C2=A0=0A>>>>>Peter Saint-Andre=0A>>>>>https://stpeter.im/=0A>>>>>=0A>>>>>= =0A>>>>>=0A>>>>>=0A>>>>=C2=A0=0A>>>________________________________________= _______=0A>>>apps-discuss mailing list=0A>>>apps-discuss@ietf.org=0A>>>http= s://www.ietf.org/mailman/listinfo/apps-discuss=0A>>>=C2=A0=0A>>>=C2=A0=0A>>= =C2=A0=0A>>=C2=A0=0A>=C2=A0 =0A>Questo messaggio e i suoi allegati sono ind= irizzati esclusivamente alle persone indicate. La diffusione, copia o quals= iasi altra azione derivante dalla conoscenza di queste informazioni sono ri= gorosamente vietate. Qualora abbiate ricevuto questo documento per errore s= iete cortesemente pregati di darne immediata comunicazione al mittente e di= provvedere alla sua distruzione, Grazie. =0A>This e-mail and any attachmen= ts=C2=A0is=C2=A0confidential and may contain privileged information intende= d for the addressee(s) only. Dissemination, copying, printing or use by any= body else is unauthorised. If you are not the intended recipient, please de= lete this message and any attachments and advise the sender by return e-mai= l, Thanks.Rispetta l'ambiente. Non stampare questa mail se non =C3=A8 neces= sario. =0A>=0A> --1502656925-1692655810-1340121109=:49261 Content-Type: multipart/related; boundary="1502656925-236941992-1340121109=:49261" --1502656925-236941992-1340121109=:49261 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Agreed, and in fact the 3rd avenue this might be used in is Link headers = on a failed OAuth authorization in a webservices context.  I'll re-rea= d with that in mind and see if we need edits.

From: Goix Laurent Walter <la= urentwalter.goix@telecomitalia.it>
To: John Bradley <ve7jtb@ve7jtb.com>; William Mills <wmills@yahoo-inc.com>
Cc:= "apps-discuss@ietf.org" <apps-discuss@ietf.org>
<= span style=3D"font-weight: bold;">Sent: Tuesday, June 19, 2012 7= :33 AM
Subject: R: [ap= ps-discuss] Aggregated service discovery

=0A=0A =0A =0A=0A=0A
=0A
=0A
I also believe the the oauth rel= ated links could typically stay in the host-meta rather than the user=E2=80= =99s xrd/jrd. The draft should not mandate=0A its usage into one or the oth= er imho and it will be up to service providers to include these links into = host-meta (if this can be generalized) or user descriptors.
= =0A
 
=0A
Is that your suggestion john?
=0A
walter
=0A
 
=0A
=0A
=0A
=0A
Da: apps-discuss= -bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]=0APer conto di = John Bradley
=0AInviato: luned=C3=AC 18 giugno 2012 22.42
= =0AA: William Mills
=0ACc: apps-discuss@ietf.org
=0A= Oggetto: Re: [apps-discuss] Aggregated service discovery
= =0A
=0A
=0A
 
= =0A
OK but you are talking about the O= Auth authorization service for IMAP,  do you intend to run different o= nes for different users?
=0A
=0A
 
=0A
=0A
=0A
If you are that's fine.   However listing the service configuration = in the users XRD rather than pointing to it from the XRD is probably not a = good design.
=0A
=0A
=0A
 
=0A
=0A
=0A
L= isting a generic OAuth 2.0 authorization service in the users XRD is intere= sting, but probably not specific enough.
=0A
=0A
=0A
 
=0A
=0A
=0A
John B.
=0A
=0A
=0A
On 2012-06-18, at 4:35 PM, William Mills wrote: =0A
=0A

=0A
=0A
= =0A
=0A
=0A
=0A
I believe y= ou meant description where you wrote decryption...
=0A
= =0A
=0A
 
=0A=0A
=0A
IMAP likely is advertize= d with host-meta, however I do have a use case where premium users may get = a different DOS guarantee and might be handled=0A on a different set of ser= vers, and therefor a per-user return would be appropriate.
=0A=
=0A
=0A
=0A
  =0A
=0A
=0A=0A
 
=0A
=0A
=0A
That is not what I am saying.=
=0A
=0A
 
=0A
=0A=0A
I am saying that the user's discovery document has = a link relation to the providers decryption of the service.   That is = different from the imap endpoint providing the link relation.
= =0A
=0A
=0A
 
=0A
=0A=0A
If you can trust the user's information to provid= e the Oauth endpoint why can't you trust the user's information to link to = the description of the service.
=0A
=0A
=0A
 
=0A
=0A
=0A
As I= have pointed out before you probably don't want per user configuration for= things like imap,  the simplest thing is to describe the service in h= ost-meta and forget the extra user discovery=0A steps and maintenance.
=0A
=0A
=0A
 
=0A=0A
=0A
John B.
=0A
=0A
= =0A
 
=0A
=0A
=0A
On 2012-06-18, at 3:19 PM, William Mills wrote:
=0A<= /div>=0A
<= span style=3D"color:black;">
=0A
=0A
=0A
=0A
=0A=
=0A
<= span style=3D"font-size:14.0pt;color:black;">Unfortunately we came to the c= onclusion that letting a service endpoint define it's authenticators is pro= bably wrong, this was in the context=0A of discovery for SASL mechanisms.&n= bsp; The core problem is when the client supports the password grant if it = then trusts the service endpoint to tell it who to give the username passwo= rd pair then it's vulnerable.
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
= =0A
=0A=0A
=0A
=0AFrom: John Bradley <ve7jtb@ve7jtb.com>
=0ATo: Paul E. Jones <paulej@packetizer.com>=0A
=0ACc:<= /b> 'William Mills' <wmills@yaho= o-inc.com>; 'Peter Saint-Andre' <stpeter@stpeter.im>;=0Aapps-discuss@ietf.org
=0ASent: Monday, June 18, 2012 11:36 = AM
=0ASubject: Re: [apps-discuss] Aggregated service discovery
=0A
=0A
 
=0A
=0A
=0A
A user is likely to have a number of OAuth authorization services= for different things.  
=0A
=0A
=  
=0A
=0A
=0A
I suspect that = the best way to organize it is to describe the services the user has:
=0A
=0A
=0A
openID Connect
= =0A
=0A
=0A
imap
=0A
=0A=0A
portable contacts
=0A
=0A
=0A=
etc
=0A
=0A
=0A
 
=0A
=0A
=0A
and let the = service describe how it is authenticated and where the endpoints are.
=0A
=0A
=0A
 
=0A=0A
=0A
For Connect there is a single relation fo= r the Connect issuer and that is then discovered to get the endpoint and ot= her configuration information.  
=0A
=0A
=0AGiven that user identifiers may point to services in othe= r domains it is best to leave it up to the service to describe itself rathe= r than relying on individual user information to be correct.
= =0A
=0A
=0A
 
=0A
=0A=0A
John B.
=0A
=0A
=0A
 
=0A
=0A
=0A
On = 2012-06-18, at 2:22 PM, Paul E. Jones wrote:
=0A
=0A

=0A
=0A
=0A
=0A
=0A
=0A
Bill,
=0A
=0A
=0A
 
=0A
=0A
=0A
In the referenced draft = below, I assume the =E2=80=9Cgrant-types=E2=80=9D and =E2=80=9Ctoken-types= =E2=80=9D should be contained inside a =E2=80=9Cproperties=E2=80=9D? = =0A That is, I think you want this:
=0A
=0A
=0A
 
=0A
=0A
=0A
{
=0A
=0A
=0A
  "subject" : "acct:carol@example.com",
=0A
=0A
=0A<= div class=3D"yiv1191038169MsoNormal" style=3D"background:white;">  "links" :
=0A
=0A<= div>=0A
  [
=0A
=0A<= div>=0A
  = ;  {
= =0A
=0A
=0A
      "rel" : "oauth2-athorize",
=0A
=0A
=0A =0A=0A
=0A
 =    }, =0A
=0A
=0A
    {
=0A
=0A
=0A
      "rel" : "oauth2-token",
=0A
=0A=
=0A
<= span style=3D"=0Afont-size:10.0pt;color:#1F497D;" lang=3D"EN-US"> &nbs= p;    "href" : "https://login.example.com/oauth= 2/token", =0A
=0A
=0A
     "properties" :
=0A
=0A
=0A
      {
=0A
=0A=0A
  =      "grant-types" : "code password",
=0A
=0A
=0A    &= nbsp;   "token-types" : "bearer"
=0A
=0A
=0A
      }
=0A
=0A=0A
  =   }
= =0A
=0A
=0A
  ]
= =0A
=0A
=0A
}
=0A=0A
=0A
 = ;
=0A
= =0A
=0A
For aut= o-provisioning of email clients (which I understand was your goal), we can = either define one link relation that=0A points to a separate configuration = document of some sort, or we define multiple link relations.  My previ= ous example showed the single link relation and the email below shows use o= f multiple.  Both have pros and cons, but I tend to favor using multip= le link=0A relations, since this allows one to introduce new stuff without = changing the one mail configuration file.  Also, it reduces the number= of queries a mail client has to make to get config information.
=0A
=0A
=0A<= div class=3D"yiv1191038169MsoNormal" style=3D"background:white;"> 
=0A
=0A
=0AYou indicate that IM= AP already has a defined URI.  Where is that defined?  I could no= t find it in the IANA link relations=0A registry, so I assume it=E2=80=99s = really a URI defined in a spec somewhere.  In any case, we could use U= RIs for these things (rather than defining single token link relation value= s and registering them).  I have no preference, but I would like an ag= reed approach=0A to provisioning.  I hate configuring all the stuff ma= nually on email clients. :-)
=0A
=0A
=0A
 
=0A
=0A
=0A
Paul
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
=0A
From: Wi= lliam=0A Mills [mailto:wmills@yahoo-inc.com] 
=0ASent: Monday, June 18, 2012 1:36 PM
= =0ATo: Paul E. Jones; 'Peter Saint-Andre'
=0ACc: 'Cyrus Daboo';=0Aapps-discuss@ietf.org
=0ASubject: Re: [apps-dis= cuss] Aggregated service discovery
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A=0A
Paul,
=0A
=0A
= =0A
=0A
=0A
&= nbsp;
=0A=0A
=0A
=0A
=0A
Thanks for the reply on this.  I do already have a separat= e doc for registering the OAuth specific relations,http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html
=0A
=0A
= =0A
=0A
=0A
&= nbsp;
=0A=0A
=0A
=0A
=0A
I don't think I like the thought of having to register a new li= nk type for every service, but that might be the right way.  IMAP=0A a= lready has a URI defined for example so if we use a more general link relat= ion then the URI scheme details the type.  The tradeoff is whether you= can look for a specific link-type or if you have to scan list elements for= the URI type you need.<= /span>
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
-bill
=0A
=0A
=0A
=0A
= =0A
 
=0A
=0A
=0A=
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
From: Paul=0A E. Jones <paulej@packetizer.com>
=0ATo: 'William Mills'= <wmills@yahoo-inc.com>; = 'Peter Saint-Andre' <stpeter@stpeter= .im> =
=0ACc: <= /span>'Cyrus Daboo' <cyrus@daboo.name>; apps-discuss@ietf.org 
=0ASent: Sunday, June 1= 7, 2012 6:48 PM
=0ASubject: RE: [apps-discuss] Aggregated service discovery
=0A
=0A=
=0A
=0A
 
=0A=
=0A
=0A
=0A
=0A
=0A
=0A
Bill,
=0A
=0A
=0A
= =0A
=0A
 <= /span>
=0A
= =0A
=0A
=0A
=0A
My apologies for the belated reply.  I=E2=80=99ve been busy= this week and got rather behind on email.
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
= =0A
=0A
I do no= t personally like using SRV records, either.  SRV records could work f= or smaller domains, but I=E2=80=99m not sure that=0A they=E2=80=99re the be= st solution for larger domains.  Personally, I would prefer putting us= ers on specific servers or server clusters and SRV records will not differe= ntiate users. =0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
To use WebFinger to find one=E2=80=99s= IMAP, SMTP, or POP server, we could do as I suggested in my email.  N= ow the question is=0A what does one query?  Since these three services= are email, I=E2=80=99d suggest we query =E2=80=9Cmailto:paulej@packetizer.com=E2=80=9D.  We could = use another URI scheme (e.g., =E2=80=9Cacct:=E2=80=9D), but mailto seems mo= st appropriate=0A given that you=E2=80=99re seeking info about mail service= s.
=0A=0A
=0A
=0A
=0A
 =
=0A
=0A
=0A
=0A
=0A
I provided an example earlier that would simply p= oint to a config file with server information.  We could do this direc= tly=0A via WebFinger like this:
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0AGET /.well-known/hos= t-meta?resource=3Dmailto:paulej@packetizer.com
=0A
=0A
=0A
=0A
=0A 
=0A
=0A
=0A=0A
=0A
This = query would then return something like this:
=0A
=0A
=0A
=0A
=0A 
=0A
=0A
=0A=0A
=0A
{
=0A
=0A=0A
=0A
=0A
  "subject" : "mailto:p= aulej@packetizer.com",
=0A
=0A
=0A
=0A
=0A
  "links" :
=0A
=0A
=0A
=0A
= =0A
  [=
=0A
=0A=0A
=0A
=0A
    {
=0A
=0A
=0A
=0A
=0A
      "rel" : "smtp-s= erver",
=0A=
=0A
=0A
=0A
=0A
      "properties" :
=0A
=0A
=0A=0A
=0A
 = ;     {
=0A
=0A
=0A
=0A
=0A
      &nb= sp; "host" : "smtp.packetizer.com",
=0A
=0A
=0A
=0A
=0A
    &nb= sp;   "port" : "587",
=0A
=0A
=0A
=0A
=0A
      = ;  "login-required" : "yes",
=0A
=0A
=0A
=0A
=0A
     &= nbsp;  "transport" : "starttls"
=0A
=0A
=0A
=0A
=0A
    &nbs= p; }
=0A=0A
=0A
=0A
=0A
    },
=0A
=0A
=0A
=0A
=0A
    {
=0A
=0A
=0A=
=0A
=0A
&nbs= p;     "rel" : "imap-server",
=0A
=0A
=0A
=0A
= =0A
  &nb= sp;   "properties" :
=0A
=0A
=0A
=0A
=0A
      {
=0A
=0A=0A
=0A
=0A
        "host" : "imap.packetizer.c= om",
= =0A
=0A
=0A
=0A
=0A
        "port" : "993= ",
=0A=0A
=0A
=0A
=0A
        "transport" : "ssl"
=0A
=0A=
=0A
=0A
=0A
      }
=0A
=0A
=0A
=0A
=0A
    }=
=0A
=0A=0A
=0A
=0A
  ]
= =0A
=0A
=0A
=0A
=0A
}
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
We would need to standardize th= e link relation values (smtp-server and imap-server).  We would also n= eed to document what=0A the various properties would be.  If you would= like to create such a configuration document based on WebFinger, I=E2=80= =99d be happy to help out.  In any case, you can see that WebFinger wo= uld serve quite nicely for conveying configuration information given a user= =E2=80=99s=0A email ID.<= /span>
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
I=E2=80=99m not sure exactly= what you would need for OAuth endpoints, but I would suggest you make that= a separate document since=0A it is not mail related.  (At least I ass= ume it=E2=80=99s not.  Even if it were, the mail server information an= d OAuth information are still different animals.)
=0A
=0A
=0A
=0A
= =0A
 
=0A
=0A
= =0A
=0A
=0A
Paul
=0A=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
From: William=0A Mills [= mailto:wmills@yahoo-inc.com] 
=0ASent: Wednesday, June 13, 2012 7:32 PM
=0ATo:<= /b> Peter Sa= int-Andre
=0ACc: Paul E. Jones; 'Cyrus Daboo'; = apps-discuss@ietf.org
=0ASubject: Re: [apps-discuss] Aggregated service d= iscovery
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A=0A
=0A
In my u= se case it's a service/server.
=0A
=0A
=0A
=0A
=0A
=0A
=0A<= div class=3D"yiv1191038169MsoNormal" style=3D"background:white;"> 
=0A
=0A
=0A=0A
=0A
=0A
=0A
Not a terribly happy answer to say "DNS SRV records won't work f= or you, and there is no other solution.".  By the same token I=0A coul= d ask "Why do we need Webfinger and host meta at all if we have DNS SRV rec= ords?".
=0A=
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
=0A=0A
If XMPP uses S= RV records for discovery, that's fine.  IMAP and outbound SMTP service= s both lack a defined discovery method other=0A than the ubiquitous "servic= e documentation".  Is there a compelling reason to pick DNS over WF fo= r this?  From the app developer point of view I don't want to have N w= ays to discover M services.
=0A
=0A
=0A
=0A
=0A
=0A
=0A 
=0A
=0A
=0A=0A
=0A
=0A
=0A
-bill =0A
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A=
=0A
=0A
=0A<= div>=0A
From:<= /b> Peter=0A Saint-Andre <= stpeter@stpeter.im>
=0ATo:=  William= Mills <wmills@yahoo-inc.com= > 
=0A= Cc: P= aul E. Jones <paulej@packetize= r.com>; 'Cyrus Daboo' <cyrus@dabo= o.name>; "apps-discuss@iet= f.org"=0A <apps-discuss@ie= tf.org> 
=0ASent:&n= bsp;Wednesday, June 13, 2012 3:57 PM
=0ASubject: Re: [apps-discuss] Ag= gregated service discovery
=0A
=0A
=0A
=0A
=0A
=0A

=0AOn 6/13/12 4:54 PM, William Mills w= rote:
=0A> As I said, I'm interested specifically in IMAP, SMTP and O= Auth endpoints. 
=0A
=0AWhat exactly is an "endpoint"? A client? An account? A se= rver?
=0A
=0A> As a data point, DNS SRV records are not controllab= le in many hosted
=0A> domain models.
=0A
=0AAt the last XMPP S= ummit a few months ago, we learned that DNS SRV
=0Arecords are unavailab= le in whole countries (e.g., Japan). That doesn't
=0Amean we should defi= ne a replacement for DNS over HTTP. :)
=0A
=0APeter
=0A
=0A-- 
=0APeter = Saint-Andre
=0Ahttps://stpeter.im/
=0A
=0A
=0A
=0A
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A<= div class=3D"yiv1191038169MsoNormal" style=3D"background:white;"> 
=0A
=0A
=0A=
=0A
=0A
=0A
=0A
=0A
=0A
__________________________________= _____________
=0Aapps-discuss mailing list
=0Aapps-discuss@ietf.org
=0Ah= ttps://www.ietf.org/mailman/listinfo/apps-discuss
=0A=0A
=0A
 
=0A
=0A
=0A=
=0A
 
=0A<= /div>=0A
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A=0A
 
=0A=0A=0A=0A=0A=0A=0A=0A
 
=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A
=0A
Questo messaggio e i suoi allegati sono indirizzati esclusiv= amente alle persone indicate. La diffusione, copia o qualsiasi=0A altra azi= one derivante dalla conoscenza di queste informazioni sono rigorosamente vi= etate. Qualora abbiate ricevuto questo documento per errore siete corteseme= nte pregati di darne immediata comunicazione al mittente e di provvedere al= la sua distruzione, Grazie.=0A
=0A
<= span style=3D"font-size:7.5pt;font-family:Verdana;" lang=3D"EN-GB">This e-m= ail and any attachments i= s confidential=0A and may contain privileged informat= ion intended for the addressee(s) only. Dissemination, copying, printing or= use by anybody else is unauthorised. If you are not the intended recipient= , please delete this message and any attachments and advise the sender=0A b= y return e-mail, Thanks.=0A
=0A<= img src=3D"cid:00000000000000000000000000000003@TI.Disclaimer" alt=3D"rispe= tta l'ambiente" height=3D"40" width=3D"26">Rispetta l'ambiente. Non stampar= e questa mail se non =C3=A8 necessario.=0A=0A
=0A=0A=0A

--1502656925-236941992-1340121109=:49261 Content-Type: image/jpeg; name=logo Content-Transfer-Encoding: base64 Content-Id: <1.4031777517@web31803.mail.mud.yahoo.com> Content-Description: logo Ambiente_foglia2.jpg Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" 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= --1502656925-236941992-1340121109=:49261-- --1502656925-1692655810-1340121109=:49261-- From ajs@crankycanuck.ca Mon Jun 18 19:30: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 053B621F85AD; Mon, 18 Jun 2012 19:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 LMtWnl9y3eOQ; Mon, 18 Jun 2012 19:30:38 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2270D21F85A5; Mon, 18 Jun 2012 19:30:38 -0700 (PDT) Received: from crankycanuck.ca (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 D34691ECB41D; Tue, 19 Jun 2012 02:30:36 +0000 (UTC) Date: Mon, 18 Jun 2012 22:30:34 -0400 From: Andrew Sullivan To: S Moonesamy Message-ID: <20120619023034.GJ32683@crankycanuck.ca> References: <6.2.5.6.2.20120522092115.0900a4a0@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120522092115.0900a4a0@elandnews.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 19 Jun 2012 10:31:03 -0700 Cc: iesg@ietf.org, draft-ietf-dnsext-dnssec-bis-updates.all@tools.ietf.org, apps-discuss@ietf.org, dnsext@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dnsext-dnssec-bis-updates-18 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2012 02:30:39 -0000 Hi, I'm the shepherd for this document. Thanks for the review. Some questions and comments inline. On Tue, May 22, 2012 at 10:12:27AM -0700, S Moonesamy wrote: > Summary: This document is not ready for publication as a Proposed Standard. > > The proposal seems targeted at implementers who are fully conversant > with the ins and outs of DNSSEC. Although the proposal is > well-written, it lacks clarity as to what is being changed in the > "DNSSECbis document set". It may end up being more confusing. To whom would it be confusing? The draft is indeed aimed at implementers of DNSSEC (that is, people putting signing and validation into code), and not at users of DNSSEC. I'm also not sure about which places are not clear about what they're changing. Some things are simply facts that have become clear about the way the protocol works, but places where the actual text of the original documents is either added to or altered are, as far as I know, marked. Could you give an example of things you think aren't clear as to what they have changed? > There was an announcement that the DNSEXT WG would be shut down. > The rush to publish these clarifications raises questions about > whether the DNSSECbis documents will ever be advanced in the near > future from Proposed Standard to Internet Standard. It is hard to see how there is a rush here. The earliest version of this draft was submitted in 2005. I know things have slowed down around the IETF, but I can't think of seven years as a rush. > > "DNSSECbis" seems more like an internal IETF term to identify the > document set. RFC 4033, for example, does not have any mention of > "DNSSECbis". I suggest using "DNSSEC protocol document set" and > amending the title accordingly. This view seems to be shared by others. I think we can change the term to "DNSSEC" and, on first reference, say "(sometimes known as DNSSECbis)" in order to make clear that the document is not referring to the earlier incarnation. > In Section 2.1: > > "Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3- > SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512) > signal that a zone MAY be using NSEC3, rather than NSEC. The zone > MAY be using either and validators supporting these algorithms MUST > support both NSEC3 and NSEC responses." > > It is not clear from the above text which parts of RFC 5155 is being > modified. 5155 isn't being modified, but the class of things we call DNSSEC is: this section is there to tell people that NSSEC3 isn't really optional, because if you don't implement it you won't be able to validate .com, .net, or .org to name but three relevant zones. That's supposed to be clear from the first paragraph; is it not? > In Section 3.1: > > "Section 4.7 of RFC4035 permits security-aware resolvers to implement > a BAD cache. Because of scaling concerns not discussed in this > document, that guidance has changed: security-aware resolvers SHOULD > implement a BAD cache as described in RFC4035." > > From Section 4.7 of RFC 4035: > > "To prevent such unnecessary DNS traffic, security-aware resolvers MAY > cache data with invalid signatures, with some restrictions." > > If I understood the text from this draft, the "MAY" is being changed > into a recommendation. In which cases would it better not to follow > the recommendation? There aren't any, but we can't practically require it because under memory constraints a cache is going to be emptied anyway. > In Section 4.1: > > "In particular, the algorithm as presented would incorrectly allow > an NSEC or NSEC3 RR from an ancestor zone to prove the non-existence > of RRs in the child zone." > > Where is ancestor zone defined? That's a good point. I don't know of anywhere, but I'm not sure this document is an appropriate place to define it. Since the DNS is a tree structure, "ancestor" has the same meaning it would for other tree structures. I think it would be a very bad idea to add definitions of this sort to this document, because the term applies to all of the DNS and not just to DNSSEC. The DNS RFCs are hard enough to navigate as it is. > "Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non- > existence of any RRs below that zone cut, which include all RRs at > that (original) owner name other than DS RRs, and all RRs below that > owner name regardless of type." > > It is not clear what is being clarified. The problem that is described in the paragraph immediately before this paragraph -- the one you quoted just above. Richard Barnes also complained about not understanding this section, so I acknowledge there's a problem here, but I'm not sure how to fix it. What is unclear to you? > In the Introduction Section: > > The IETF is now using two maturity levels. "Draft Standard" has been > changed to "Internet Standard" Good catch, thanks. I suggest "when advancing the DNSSEC documents along the standards track". How's that? > In Section 6.3: > > This section discusses about errors in the examples in RFC 4035. As > a stylistic comment, it is clearer to the reader if he/she could see > the actual examples with the corrections made. I think the intention was that the reader would have the original open along with this document when reading. How would you like it rewritten? Best, A -- Andrew Sullivan ajs@crankycanuck.ca From jasnell@gmail.com Tue Jun 19 11:28: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 8AD6C11E8129 for ; Tue, 19 Jun 2012 11:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nxq7IUDihVN for ; Tue, 19 Jun 2012 11:28:54 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9770711E8128 for ; Tue, 19 Jun 2012 11:28:54 -0700 (PDT) Received: by wgbfm10 with SMTP id fm10so7616709wgb.34 for ; Tue, 19 Jun 2012 11:28:53 -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=ntcvem4n/u08LsGJBDwMM4VdAf1SW4+kQxHy3tFzo4U=; b=KUN/aRUKKcwAFy0okWCksHBobuTsMrClvD9AUKM0KMq00mPfgqwA3nPPBmWLz76nU8 sgYnTLNUBjrzu3mzRkQFCZdVQkseWjv/NKJXkYU/G+3JanHWDq1iy62koMNOXlGVQTNQ Y4ftKRFyVJU3C1h3vUNTXEGci7sb9HpsnYgt6ozRs6mbfYDFhbBst4VuD6MT6S/UC7+1 1KHYQ+c2nouPLUCtJm881XIjugV0NY30D3P3JI1YyebzIWeQPISKkoVHVgs+bmVDjuWf CLugKmtCzjA8Qqp0pC0gzBjxCNwpAdSxZwFi9pETkS+VRUrze3hIhcGyG2xszcNr5ewv H2lQ== Received: by 10.180.24.39 with SMTP id r7mr5496494wif.9.1340130533540; Tue, 19 Jun 2012 11:28:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.67 with HTTP; Tue, 19 Jun 2012 11:28:33 -0700 (PDT) In-Reply-To: References: <4FD5921F.4090600@gmx.de> From: James M Snell Date: Tue, 19 Jun 2012 11:28:33 -0700 Message-ID: To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Julian Reschke , 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: Tue, 19 Jun 2012 18:28:55 -0000 Per the feedback provided here, I have published an updated rev of the spec that pulls the generic merge-patch type back out and focused specifically and solely on the json semantics. The json type is renamed to "application/json-merge-patch". This should address all of the voiced concerns. Update is here: http://www.ietf.org/id/draft-snell-merge-patch-03.txt - James On Mon, Jun 11, 2012 at 5:29 AM, 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 wo= nder 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 fundamenta= lly bad idea; after all, it's not really a media type; if you want to devel= op 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 clea= r for any conceivable target format? > > 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 =C2=A0 http://www.mnot.net/ > > > From superuser@gmail.com Tue Jun 19 23:15: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 E473F21F8748 for ; Tue, 19 Jun 2012 23:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=0.177, 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 eaWDz6lRpqmB for ; Tue, 19 Jun 2012 23:15:08 -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 F3DA721F872E for ; Tue, 19 Jun 2012 23:15:07 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so157728lbb.31 for ; Tue, 19 Jun 2012 23:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lFhyk0huBjNocuilzsHM/stok2SL0XgDS7C3M9+9Yxc=; b=J/9pDfsr0mmYbF7SpMFafCxQ1nLSNPCXw5LlPQvr7U3OQSOEzNjtcUKBJ+tMtHLjNb rsVQNJlII25/9mLEWBHXKrDsoY67f9gXz3tSybZyc1Q/yvvkWHuVZP/X9aQMWUBU7KqJ wxxj3lEbQGMQ9Z+aXhHsrnwAm2e4zIWvVLQxtiCx+lTYpudVPydtmhYOPuhNCpT52MaP +IXmEoa5/p1qD9r4RydW4NwpYj1MbS8gumc0g8QmIHcB0x8UkT0As690dHTASbRq1COp nsYtt4oQ+LLp2yhNhZzQ/cvQhWsQODwKL+uMoOSp44Gm4QwLGck2EH48w/vdxrsA4vHZ AOEw== MIME-Version: 1.0 Received: by 10.112.36.225 with SMTP id t1mr9375963lbj.67.1340172906858; Tue, 19 Jun 2012 23:15:06 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Tue, 19 Jun 2012 23:15:06 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Jun 2012 23:15:06 -0700 Message-ID: From: "Murray S. Kucherawy" To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=e0cb4efe2f4c0d08a704c2e152f0 Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 06:15:09 -0000 --e0cb4efe2f4c0d08a704c2e152f0 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 11, 2012 at 5:25 AM, Murray S. Kucherawy wrote: > This note begins a Working Group Last Call on > draft-ietf-appsawg-media-type-suffix-regs, ending Monday, June 25. Please > review the document and comment on it. > > Note that its "parent" document, draft-ietf-appsawg-media-type-regs, is > now in IESG Evaluation. > > A reminder that this WGLC closes in less than a week. Please review the document and send your comments soon. Thanks, -MSK, APPSAWG co-chair --e0cb4efe2f4c0d08a704c2e152f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jun 11, 2012 at 5:25 AM, Murray S. Kucherawy <= superuser@gmail.co= m> wrote:
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.

=A0
A reminder that this WGLC closes in le= ss than a week.=A0 Please review the document and send your comments soon.<= br>
Thanks,
-MSK, APPSAWG co-chair

--e0cb4efe2f4c0d08a704c2e152f0-- From dzonatas@gmail.com Tue Jun 19 13: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 BE76411E812D for ; Tue, 19 Jun 2012 13:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=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 Q+ClFtKI4rhx for ; Tue, 19 Jun 2012 13:05:02 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AFE9811E8116 for ; Tue, 19 Jun 2012 13:05:01 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4021296vbb.31 for ; Tue, 19 Jun 2012 13:05:01 -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=ur0y+P47Kput9jWQcdPGP669TFxm4WBUWnoVLbDgMP4=; b=gG2POKe5Mh1Gvt7VozBNRj5JcNRNKUFyLdBLzjApICn9WjUFZzeED1JC8nYQcNOSNa wFpLv6M7nfo0ga9Z4VllCTFVTPK/8AlUF+Te/LKWq9IoOkcJFgV5nxOrbF0K9zJzY0yL BKCgstWWxs+7jwx4EDtBhua6MRQSsUpT+oYueHInS6IFcKwxGFw2ssnkTG8RNA3tl+b9 2yU/rR1/0dKQsSUE4LRl95z3DLezqCSccudPbsver6kliMDkXZ/DlvgvIktIJlIBjbCu 65obJt3EgKONq8VJYaySBLcjg1f3Qervo+D4xL4A4ndBbQ7o/OlsZbEDhPPDrKajP+OM jCMA== MIME-Version: 1.0 Received: by 10.52.172.208 with SMTP id be16mr8224006vdc.62.1340136300964; Tue, 19 Jun 2012 13:05:00 -0700 (PDT) Received: by 10.52.23.109 with HTTP; Tue, 19 Jun 2012 13:05:00 -0700 (PDT) In-Reply-To: <20120618062622.8206872E042@rfc-editor.org> References: <20120618062622.8206872E042@rfc-editor.org> Date: Tue, 19 Jun 2012 13:05:00 -0700 Message-ID: From: Jonathan Ballard To: rfc-editor@rfc-editor.org Content-Type: multipart/alternative; boundary=bcaec51ba3fb2b69cd04c2d8cc9f X-Mailman-Approved-At: Wed, 20 Jun 2012 08:03:14 -0700 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC 6647 on Email Greylisting: An Applicability Statement for 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, 19 Jun 2012 20:05:02 -0000 --bcaec51ba3fb2b69cd04c2d8cc9f Content-Type: text/plain; charset=ISO-8859-1 "Greylisting" seems more appropriate for WebFinger. On Sun, Jun 17, 2012 at 11:26 PM, wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6647 > > Title: Email Greylisting: An Applicability Statement > for SMTP > Author: M. Kucherawy, D. Crocker > Status: Standards Track > Stream: IETF > Date: June 2012 > Mailbox: superuser@gmail.com, > dcrocker@bbiw.net > Pages: 17 > Characters: 38097 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-appsawg-greylisting-09.txt > > URL: http://www.rfc-editor.org/rfc/rfc6647.txt > > This document describes the art of email greylisting, the practice of > providing temporarily degraded service to unknown email clients as an > anti-abuse mechanism. > > Greylisting is an established mechanism deemed essential to the > repertoire of current anti-abuse email filtering systems. > [STANDARDS-TRACK] > > This document is a product of the Applications Area Working Group Working > Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html > . > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --bcaec51ba3fb2b69cd04c2d8cc9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable "Greylisting" seems more appropriate for WebFinger.

On Sun, Jun 17, 2012 at 11:26 PM, &= lt;rfc-edito= r@rfc-editor.org> wrote:

A new Request for Comments is now available in online RFC libraries.


=A0 =A0 =A0 =A0RFC 6647

=A0 =A0 =A0 =A0Title: =A0 =A0 =A0Email Greylisting: An Applicability State= ment
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for SMTP
=A0 =A0 =A0 =A0Author: =A0 =A0 M. Kucherawy, D. Crocker
=A0 =A0 =A0 =A0Status: =A0 =A0 Standards Track
=A0 =A0 =A0 =A0Stream: =A0 =A0 IETF
=A0 =A0 =A0 =A0Date: =A0 =A0 =A0 June 2012
=A0 =A0 =A0 =A0Mailbox: =A0 =A0supe= ruser@gmail.com,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dcrocker@bbiw.net
=A0 =A0 =A0 =A0Pages: =A0 =A0 =A017
=A0 =A0 =A0 =A0Characters: 38097
=A0 =A0 =A0 =A0Updates/Obsoletes/SeeAlso: =A0 None

=A0 =A0 =A0 =A0I-D Tag: =A0 =A0draft-ietf-appsawg-greylisting-09.txt

=A0 =A0 =A0 =A0URL: =A0 =A0 =A0 =A0http://www.rfc-editor.org/rfc/rfc6647.txt<= /a>

This document describes the art of email greylisting, the practice of
providing temporarily degraded service to unknown email clients as an
anti-abuse mechanism.

Greylisting is an established mechanism deemed essential to the
repertoire of current anti-abuse email filtering systems.
[STANDARDS-TRACK]

This document is a product of the Applications Area Working Group Working G= roup of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions=
for improvements. =A0Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and
status of this protocol. =A0Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
=A0http://www.ietf.org/mailman/listinfo/ietf-announce
=A0http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist<= br>
For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.=
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. =A0Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

--bcaec51ba3fb2b69cd04c2d8cc9f-- From bonatti252@ieca.com Wed Jun 20 11:17: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 4239A21F8787 for ; Wed, 20 Jun 2012 11:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsegTaEiDkLM for ; Wed, 20 Jun 2012 11:17:42 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.224.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFB221F8782 for ; Wed, 20 Jun 2012 11:17:42 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 1AB9F8FBFFC29; Wed, 20 Jun 2012 13:17:42 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 0DDE38FBFFBDE for ; Wed, 20 Jun 2012 13:17:42 -0500 (CDT) Received: from [173.73.132.2] (port=61948 helo=[192.168.0.50]) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1ShPTJ-0004gv-UN for apps-discuss@ietf.org; Wed, 20 Jun 2012 13:17:42 -0500 Message-ID: <4FE213C5.7090102@ieca.com> Date: Wed, 20 Jun 2012 14:17:41 -0400 From: Chris Bonatti Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.0.50]) [173.73.132.2]:61948 X-Source-Auth: chris.bonatti@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [apps-discuss] APP Area Consideration of draft-cailleux-secure-headers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2012 18:17:43 -0000 Hello Apps Area: Laurent Cailleux and have started a draft that we intend to document=20 some experimental work on the protection of email headers. I would like = to recommend it to APPS folks for review and comment. We had some=20 limited feedback on the -00 version, which resulted in an improved -01=20 issued in April. This has been laying fallow for a few months, and we=20 have had very little input. The draft (now=20 http://www.ietf.org/id/draft-cailleux-secure-headers-01.txt) describes=20 how the S/MIME protocol can be extended in order to secure message=20 header fields. It defines a 'Secure Headers' extension that provides=20 security services such as data integrity, non-repudiation and=20 confidentiality. Ordinarily S/MIME secures message body parts, but does not protect the=20 message header fields. However, it does define an alternative solution to secure header fields. = To wit: "The sending client MAY wrap a full MIME [RFC 2045] message in a = message/rfc822 wrapper in order to apply S/MIME security services to=20 header fields". This encapsulation solution does not allow selection of=20 a subset of message header fields to secure, and confidentiality service = cannot be implemented for message header fields. Other security=20 mechanisms introduced to date (DKIM, TLS, etc.) similarly address only=20 parts of the problem. The solution we propose overcomes those limitation= s. This draft primarily documents a security mechanism, so I view it as a=20 product of the SEC Area. However, it clearly has a lot to do with=20 email. So I'd like to recommend that the APPS area people take an=20 earnest look. Our proposal is that this be advanced as an Experimental R= FC. I look forward to your feedback. Regards, Chris B. From internet-drafts@ietf.org Wed Jun 20 13:44: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 464BC11E8093; Wed, 20 Jun 2012 13:44: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 jkf+EM1COKtw; Wed, 20 Jun 2012 13:44:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01F711E8083; Wed, 20 Jun 2012 13:44:13 -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: <20120620204413.8929.22878.idtracker@ietfa.amsl.com> Date: Wed, 20 Jun 2012 13:44:13 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-14.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, 20 Jun 2012 20:44:14 -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-14.txt Pages : 32 Date : 2012-06-20 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/draft-ietf-appsawg-media-type-regs-14 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-media-type-regs-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yaojk@cnnic.cn Thu Jun 21 05:47: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 11C9821F85F8 for ; Thu, 21 Jun 2012 05:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.554 X-Spam-Level: X-Spam-Status: No, score=-98.554 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_40=-0.185, MIME_BASE64_TEXT=1.753, 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 w-WhCAXj3m+J for ; Thu, 21 Jun 2012 05:47:17 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 2DDAE21F85F1 for ; Thu, 21 Jun 2012 05:47:16 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 21 Jun 2012 20:45:41 +0800 Message-ID: <9D782E7B4A4F42D5AB5B85C5D391B752@LENOVO47E041CF> From: "Jiankang YAO" To: "Andrew Sullivan" , "S Moonesamy" References: <6.2.5.6.2.20120522092115.0900a4a0@elandnews.com> <20120619023034.GJ32683@crankycanuck.ca> Date: Thu, 21 Jun 2012 20:45:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: iesg@ietf.org, apps-discuss@ietf.org, dnsext@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dnsext-dnssec-bis-updates-18 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2012 12:47:18 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFuZHJldyBTdWxsaXZhbiIg PGFqc0BjcmFua3ljYW51Y2suY2E+DQpUbzogIlMgTW9vbmVzYW15IiA8c20raWV0ZkBlbGFuZHN5 cy5jb20+DQpDYzogPGllc2dAaWV0Zi5vcmc+OyA8ZHJhZnQtaWV0Zi1kbnNleHQtZG5zc2VjLWJp cy11cGRhdGVzLmFsbEB0b29scy5pZXRmLm9yZz47IDxhcHBzLWRpc2N1c3NAaWV0Zi5vcmc+OyA8 ZG5zZXh0QGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgSnVuZSAxOSwgMjAxMiAxMDozMCBBTQ0K U3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIEFQUFNESVIgcmV2aWV3IG9mIGRyYWZ0LWlldGYt ZG5zZXh0LWRuc3NlYy1iaXMtdXBkYXRlcy0xOA0KDQoNCj4gLi4uLi4uDQo+PiBUaGVyZSB3YXMg YW4gYW5ub3VuY2VtZW50IHRoYXQgdGhlIEROU0VYVCBXRyB3b3VsZCBiZSBzaHV0IGRvd24uDQo+ PiBUaGUgcnVzaCB0byBwdWJsaXNoIHRoZXNlIGNsYXJpZmljYXRpb25zIHJhaXNlcyBxdWVzdGlv bnMgYWJvdXQNCj4+IHdoZXRoZXIgdGhlIEROU1NFQ2JpcyBkb2N1bWVudHMgd2lsbCBldmVyIGJl IGFkdmFuY2VkIGluIHRoZSBuZWFyDQo+PiBmdXR1cmUgZnJvbSBQcm9wb3NlZCBTdGFuZGFyZCB0 byBJbnRlcm5ldCBTdGFuZGFyZC4NCj4gDQo+IEl0IGlzIGhhcmQgdG8gc2VlIGhvdyB0aGVyZSBp cyBhIHJ1c2ggaGVyZS4gIFRoZSBlYXJsaWVzdCB2ZXJzaW9uIG9mDQo+IHRoaXMgZHJhZnQgd2Fz IHN1Ym1pdHRlZCBpbiAyMDA1LiAgSSBrbm93IHRoaW5ncyBoYXZlIHNsb3dlZCBkb3duDQo+IGFy b3VuZCB0aGUgSUVURiwgYnV0IEkgY2FuJ3QgdGhpbmsgb2Ygc2V2ZW4geWVhcnMgYXMgYSBydXNo Lg0KPiANCg0KIFNNIGRvZXMgbm90IG1lYW4gc2V2ZW4geWVhcnMgaXMgYSBydXNoLg0KSGUgbWVh biB0aGF0IHRoaXMgZHJhZnQgc3Vydml2ZXMgYWxtb3N0IDcgeWVhcnMgYW5kIHRoZSBkcmFmdCBo YXMgbm90IGNsZWFyIGNsdWUgb2YgYmVpbmcgcmVhZHkgdG8gYmUgcHVibGlzaGVkIGJlZm9yZSBh bm5vdW5jZW1lbnQgb2YgRE5TRVhUIFdHIHNodXR0aW5nIGRvd24uDQpPbmx5IGFmdGVyIHRoZSBh bm5vdW5jZW1lbnQsIHNvbWVvbmUgc2FpZCB0aGF0IHRoaXMgZHJhZnQgaXMgcmVhZHkgZm9yIHB1 YmxpY2F0aW9uLg0KTWFueSByZWFkZXJzLCAgSSB0aGluayBpdCBpcyBub3Qgb25seSBTTSwgIGZl ZWwgdGhhdCB0aGVyZSBpcyBhIGxpdHRsZSBzdXJwcmlzZSBvciB1bmV4cGVjdGVkLg0KDQpGcm9t IDAgbW9udGggdG8gNiB5ZWFyIGFuZCAxMSBtb250aCwgdGhlcmUgaXMgbm8gc2lnbiBvZiByZWFk eS4NCkZyb20gNiB5ZWFyIGFuZCAxMSBtb250aCB0byA2IHllYXIgYW5kIDEyIG1vbnRoLCBzdWRk ZW50bHkgc2F5IHRoYXQgIml0IGlzIHJlYWR5IHRvIGdvIg0KDQpUaGlzIGlzIGEgcnVzaCwgbm90 IDcgeWVhcnMgYXMgYSBydXNoLg0KDQoNCklmIEkgdW5kZXJzdGFuZCBTTSBjb3JyZWN0bHksIEkg dGhpbmsgVGhhdCBpcyB3aHkgdGhlcmUgaXMgYSBydXNoLg0KDQpKaWFua2FuZyBZYW8= From alexey.melnikov@isode.com Thu Jun 21 06:47: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 AA7DC21F8645; Thu, 21 Jun 2012 06:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 Y0YgMbPsOkxV; Thu, 21 Jun 2012 06:47:25 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4B89721F8630; Thu, 21 Jun 2012 06:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1340286407; d=isode.com; s=selector; i=@isode.com; bh=E4D5VcHBBKlsQJIiWCKfrfQAXl92x+flQu8r25bkDc8=; 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=FYOhbUJ1PJz7eNUkfYWv/o+1Z+6OpgG/zgc64xhKFLH5fOYurQTV27JcWxCzFlxAD++zYq 1eFQI+vFB4kc4II29mYn6iDQD0qoq3I6X14WbmdBB8OKl+DPCJnWwxARsHcoxgFtLQo5uW 6wsUCsIpWc1YTonCbeSqlOjGiRlB22g=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 21 Jun 2012 14:46:47 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FE325F2.4020700@isode.com> Date: Thu, 21 Jun 2012 14:47:30 +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> <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> <01OGKA8DLA0Y0006TF@mauve.mrochek.com> In-Reply-To: <01OGKA8DLA0Y0006TF@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ken carlberg , 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, 21 Jun 2012 13:47:26 -0000 Hi Ned, Thank you for very constructive comments. On 11/06/2012 15:29, Ned Freed wrote: > 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. A very good point. Yes. > 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. I've added a new section on this in -19. > (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. This was always allowed. It is implied from the procedure of calculating the priority as specified by the sender (and using 0 if not specified), then changing it due to the local policy. Actually, I thought the current text was quite clear: The SMTP server MAY also alter the message priority (to lower or to raise it) in order to enforce some other site policy. For example an MSA might have a mapping table that assigns priorities to messages based on authentication credentials. I added "(Note that this also includes the case when the priority is not explicitly specified.)" after the first sentence quoted above. I will also added an extra example that demonstrates that. > 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. I changed the existing Enhanced Status Code for "the priority was lowered" to "the priority was changed". Pete asked for it earlier anyway, but I just didn't see much use case, so didn't do that. I don't think there is a need in 2 Enhanced Status Codes, because the selected priority is communicated back in the response anyway. > (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. Personally I have no preferences and I think either will work. Considering that you implemented the extended environment test, we might as well use that. > 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. I think doing this in a separate document would be best at this stage in the process. > (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. Agreed. Added in -19. > (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.) You mean where it is first defined? I copied the text from the IANA registration section to make this clear. > (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. Added. > I also spotted a minor typo in the Introduction: sattelite -> satellite. Fixed. > 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. I think I fixed these. > Now on to the more difficult stuff. I mostly agree with these comments. They will be addressed in -20. From ajs@anvilwalrusden.com Thu Jun 21 07:03: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 6646A21F8692; Thu, 21 Jun 2012 07:03:13 -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 fCOLPcNV0NnG; Thu, 21 Jun 2012 07:03:12 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9A95E21F8690; Thu, 21 Jun 2012 07:03:10 -0700 (PDT) Received: from crankycanuck.ca (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 18F821ECB41D; Thu, 21 Jun 2012 14:03:09 +0000 (UTC) Date: Thu, 21 Jun 2012 10:03:01 -0400 From: Andrew Sullivan To: Jiankang YAO Message-ID: <20120621140301.GA42780@crankycanuck.ca> References: <6.2.5.6.2.20120522092115.0900a4a0@elandnews.com> <20120619023034.GJ32683@crankycanuck.ca> <9D782E7B4A4F42D5AB5B85C5D391B752@LENOVO47E041CF> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9D782E7B4A4F42D5AB5B85C5D391B752@LENOVO47E041CF> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsext@ietf.org, S Moonesamy , apps-discuss@ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] [dnsext] APPSDIR review of draft-ietf-dnsext-dnssec-bis-updates-18 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2012 14:03:13 -0000 On Thu, Jun 21, 2012 at 08:45:36PM +0800, Jiankang YAO wrote: > He mean that this draft survives almost 7 years and the draft has not clear clue of being ready to be published before announcement of DNSEXT WG shutting down. I see. With respect, I think I must have said about thirty times over the past several years, "It is time to get this document published." The minutes from meetings at IETF 77 and IETF 78 both say that it seems time to publish the document, just for example; I haven't even looked at the list arhives. SM was not an active participant in DNSEXT for much of that time, so he might well have overlooked those previous discussions. Did you miss them also? I will cheerfully accept responsibility for having failed to press hard enough. I nevertheless object to the characterization of "rush". It's simply not true. This document has been pursued in the most leisurely way possible. Best regards, Andrew (as shepherd) -- Andrew Sullivan ajs@anvilwalrusden.com From alexey.melnikov@isode.com Thu Jun 21 08:18: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 C2B0621F8705 for ; Thu, 21 Jun 2012 08:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.917 X-Spam-Level: X-Spam-Status: No, score=-102.917 tagged_above=-999 required=5 tests=[AWL=-0.319, 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 tZgb7yB5v4-W for ; Thu, 21 Jun 2012 08:18:57 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6893A21F86EA for ; Thu, 21 Jun 2012 08:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1340291894; d=isode.com; s=selector; i=@isode.com; bh=fYJXCNL8KAwleKLoZrrfwnVryZOLksd0tqNz1ZyDF+0=; 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=pMq6BO8lHZVui9qe9l9NhOhQoNEWm5YuvG3uX34az0yWECZ+sCkuKGMG+vOfyFLhLKQhKW 77zNBWbFlFUARFcq5qkNBa7ZpT3DN+gEaIjp1ibJET1Y1liYd3mDz+lSp6HOWxbKs6svHY 7OLjUTKdfwcPeJBmSJbIQSNg+IB9hrg=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 21 Jun 2012 16:18:14 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FE33B5F.4020205@isode.com> Date: Thu, 21 Jun 2012 16:18:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: apps-discuss@ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000201030205070206030701" Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 15:18:58 -0000 This is a multi-part message in MIME format. --------------000201030205070206030701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 20/06/2012 07:15, Murray S. Kucherawy wrote: > On Mon, Jun 11, 2012 at 5:25 AM, Murray S. Kucherawy > > wrote: > > This note begins a Working Group Last Call on > draft-ietf-appsawg-media-type-suffix-regs, ending Monday, June > 25. Please review the document and comment on it. > > Note that its "parent" document, > draft-ietf-appsawg-media-type-regs, is now in IESG Evaluation. > > A reminder that this WGLC closes in less than a week. Please review > the document and send your comments soon. I've just reviewed the document. I think it looks quite reasonable in general. I have 1 (and maybe one more later) question: 3.1. The +json Structured Syntax Suffix Fragment identifier considerations: Media types using "+json" SHOULD process any fragment identifiers defined for "application/json" in the same way as defined for that media type. (At publication of this document, there is no fragment identification syntax defined for "application/json".) Specific media types using "+json" MAY identify additional fragment identifier considerations, MAY define processing for fragment identifiers that are classed as errors for "application/json" and MAY designate fragment identifiers defined for "application/json" that SHOULD NOT be used. Are you trying to say that a specific +json can do arbitrary changes to the rules for handling of fragment identifiers when compared to the media type it is based on? Is there a feeling for what is more likely: +json defines a more restricted fragment identifier syntax or it defines a richer one? (Similar text for a couple of other suffixes being registered in the same document.) --------------000201030205070206030701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 20/06/2012 07:15, Murray S. Kucherawy wrote:
On Mon, Jun 11, 2012 at 5:25 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
This note begins a Working Group Last Call on draft-ietf-appsawg-media-type-suffix-regs, ending Monday, June 25.  Please review the document and comment on it.

Note that its "parent" document, draft-ietf-appsawg-media-type-regs, is now in IESG Evaluation.
 
A reminder that this WGLC closes in less than a week.  Please review the document and send your comments soon.

I've just reviewed the document. I think it looks quite reasonable in general. I have 1 (and maybe one more later) question:

3.1.  The +json Structured Syntax Suffix

   Fragment identifier considerations: Media types using "+json" SHOULD
                       process any fragment identifiers defined for
                       "application/json" in the same way as defined for
                       that media type.  (At publication of this
                       document, there is no fragment identification
                       syntax defined for "application/json".) Specific
                       media types using "+json" MAY identify additional
                       fragment identifier considerations, MAY define
                       processing for fragment identifiers that are
                       classed as errors for "application/json" and MAY
                       designate fragment identifiers defined for
                       "application/json" that SHOULD NOT be used.

Are you trying to say that a specific <media-type>+json can do arbitrary changes to the rules for handling of fragment identifiers when compared to the media type it is based on? Is there a feeling for what is more likely: <media-type>+json defines a more restricted fragment identifier syntax or it defines a richer one?

(Similar text for a couple of other suffixes being registered in the same document.)

--------------000201030205070206030701-- From internet-drafts@ietf.org Thu Jun 21 10:11: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 891C821F8779; Thu, 21 Jun 2012 10:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 mF72T45Vxy4p; Thu, 21 Jun 2012 10:11:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA4F21F8771; Thu, 21 Jun 2012 10:11:32 -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: <20120621171132.5037.30218.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2012 10:11:32 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-received-state-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 17:11:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Indicating Email Handling States in Trace Fields Author(s) : D. Crocker Murray S. Kucherawy Filename : draft-ietf-appsawg-received-state-02.txt Pages : 11 Date : 2012-06-21 Abstract: This memo registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queueing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-received-state There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-received-state-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-received-state-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From superuser@gmail.com Thu Jun 21 11: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 470B821F8564 for ; Thu, 21 Jun 2012 11:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=0.169, 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 VdPY5XpMSF0T for ; Thu, 21 Jun 2012 11:07:03 -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 272F121F855E for ; Thu, 21 Jun 2012 11:07:01 -0700 (PDT) Received: by bkty8 with SMTP id y8so939092bkt.31 for ; Thu, 21 Jun 2012 11:07:01 -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=A5PRkEck54Jzh6sJJCtyMl3HrIMv3MzVdDxeozszPow=; b=MQUEe0HYcgOU2+SfR9wCB8ZElmas3MjK71P4bAWnE843RFfHcbz0rcLkTcWQoKQ51P Zl4V4ZI52uLdbiXMXGWSTg3WN5NahmNbRTKo4a4jKAOFz05JH0dIq/5gsd0EdIGLhI46 pmpJR85NKiKS2C7hmF036dkZLHBvsZnHSHR3E7vCX8y5p/B3aUOE9dbVBn4v7TgnX/sf 5L1rZvUjIkO1zfquP7XRHZq/Bwx9rQH1lXTHS/y+smIVcBLJg9Pj4tcq/fKe/EXw6DbE c3ESLFrfFGt0t38gQEN5xlXmu0wU77g/XJl9dW14dvVsYDkjlAv0zsb7qADePbwG7Vg0 sKrw== MIME-Version: 1.0 Received: by 10.152.148.199 with SMTP id tu7mr27626526lab.43.1340302021071; Thu, 21 Jun 2012 11:07:01 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 21 Jun 2012 11:07:01 -0700 (PDT) In-Reply-To: <4FE33B5F.4020205@isode.com> References: <4FE33B5F.4020205@isode.com> Date: Thu, 21 Jun 2012 11:07:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alexey Melnikov Content-Type: multipart/alternative; boundary=e89a8f2353bbdb915404c2ff616f Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 18:07:04 -0000 --e89a8f2353bbdb915404c2ff616f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 21, 2012 at 8:18 AM, Alexey Melnikov wrote: > On 20/06/2012 07:15, Murray S. Kucherawy wrote: > > On Mon, Jun 11, 2012 at 5:25 AM, Murray S. Kucherawy wrote: > >> This note begins a Working Group Last Call on >> draft-ietf-appsawg-media-type-suffix-regs, ending Monday, June 25. Please >> review the document and comment on it. >> >> Note that its "parent" document, draft-ietf-appsawg-media-type-regs, is >> now in IESG Evaluation. >> > > A reminder that this WGLC closes in less than a week. Please review the > document and send your comments soon. > > > I've just reviewed the document. I think it looks quite reasonable in > general. I have 1 (and maybe one more later) question: > [...] > Also, I think that this document (like its parent) should have BCP status. -MSK --e89a8f2353bbdb915404c2ff616f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 21, 2012 at 8:18 AM, Alexey Melnikov <alexey.melnikov@= isode.com> wrote:
=20 =20 =20
On 20/06/2012 07:15, Murray S. Kucherawy wrote:
On Mon, Jun 11, = 2012 at 5:25 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
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 comment on it.

Note that its "parent" document, draft-ietf-appsawg-media-type-regs, is now in IESG Evaluation.
=A0
A reminder that this WGLC closes in less than a week.=A0 Please review the document and send your comments soon.

I've just reviewed the document. I think it looks quite reasonable in general. I have 1 (and maybe one more later) question:
[...]

Also, I think that this document (= like its parent) should have BCP status.

-MSK
--e89a8f2353bbdb915404c2ff616f-- From ht@inf.ed.ac.uk Thu Jun 21 11:48: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 0F12421F8733 for ; Thu, 21 Jun 2012 11:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=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 x9jRctNoeEnh for ; Thu, 21 Jun 2012 11:48:26 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id C96A521F8726 for ; Thu, 21 Jun 2012 11:48:25 -0700 (PDT) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q5LImF31020087; Thu, 21 Jun 2012 19:48:17 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q5LImFtO022510; Thu, 21 Jun 2012 19:48:15 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q5LImEHp031010; Thu, 21 Jun 2012 19:48:14 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q5LImEkG031006; Thu, 21 Jun 2012 19:48:14 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Alexey Melnikov References: <4FE33B5F.4020205@isode.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 21 Jun 2012 19:48:14 +0100 In-Reply-To: <4FE33B5F.4020205@isode.com> (Alexey Melnikov's message of "Thu, 21 Jun 2012 16:18:55 +0100") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 18:48:27 -0000 Alexey Melnikov writes: > I've just reviewed the document. I think it looks quite reasonable in > general. I have 1 (and maybe one more later) question: > > 3.1. The +json Structured Syntax Suffix > > Fragment identifier considerations: Media types using "+json" SHOULD > process any fragment identifiers defined for > "application/json" in the same way as defined for > that media type. (At publication of this > document, there is no fragment identification > syntax defined for "application/json".) Specific > media types using "+json" MAY identify additional > fragment identifier considerations, MAY define > processing for fragment identifiers that are > classed as errors for "application/json" and MAY > designate fragment identifiers defined for > "application/json" that SHOULD NOT be used. > > Are you trying to say that a specific +json can do > arbitrary changes to the rules for handling of fragment identifiers > when compared to the media type it is based on? Is there a feeling for > what is more likely: +json defines a more restricted > fragment identifier syntax or it defines a richer one? > > (Similar text for a couple of other suffixes being registered in the > same document.) I didn't read it that way. It quite specifically circumscribes what a particular xxx+json registration should do. The phrasing is perhaps a little too concise. I believe what we should be aiming for, which I believe this is trying to say, consistent with the best practices under development by the W3C TAG, is as follows a) Syntax and semantics of fragids specified for +SUF should be same as specified for xxx/SUF b) Syntax and semantics for fragids for a specific xxx/yyy+SUF as follows: b1) For cases defined in +SUF, where the fragid resolves per the +SUF rules, then as specified in +SUF b2) For cases defined in +SUF, where the fragid _doesn't_ resolve per the +SUF rules, then as specified in xxx/yyy+SUF b3) For cases not defined in +SUF, then as specified in xxx/yyy+SUF Is that better? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From sm@elandsys.com Thu Jun 21 13:32: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 CE82721F8694; Thu, 21 Jun 2012 13:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 bBzZANe+ZppU; Thu, 21 Jun 2012 13:32:54 -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 67CBA21F8659; Thu, 21 Jun 2012 13:32:54 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.9]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5LKWYpZ018614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2012 13:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340310769; i=@elandsys.com; bh=M5CZ2NMNE8oAvkY8GrOi+UV04MIrYZVlk5HB5Fw2YYY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NwkzE2NiCfjMu7idBbGS52Zq5PkcwvE9FwDS3MobQXE7RtiScyNKWr6lIqbFOaIby 3gTFSuSj4GnOqdsjK/iXqRocY5JnjCKosiJX8B4mXbDvvWiw6g3w4bUS7YbINsB5h5 2quPRdp3IeKk3jZw2eueuWgdy7ajL9Bux7f4KLQE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340310769; i=@elandsys.com; bh=M5CZ2NMNE8oAvkY8GrOi+UV04MIrYZVlk5HB5Fw2YYY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UIoIwlajYDZl5KgCEwgcSKrRBdEg1Q4kdW9RZLve38rnaFJV8GRF45I6yGYd2Sfcw AkrvK2yRGHvUppIZQqxy65UQkxGCgkG3lg2pBuIDGJUgYyJrSOm475vLQsYoLgBLeU MVKkYJl9xaEJSJvXYAVo6RriQYhl4GAHVPZvGQd0= Message-Id: <6.2.5.6.2.20120621110715.0a33ef38@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 21 Jun 2012 13:31:33 -0700 To: Andrew Sullivan From: S Moonesamy In-Reply-To: <20120619023034.GJ32683@crankycanuck.ca> References: <6.2.5.6.2.20120522092115.0900a4a0@elandnews.com> <20120619023034.GJ32683@crankycanuck.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org, draft-ietf-dnsext-dnssec-bis-updates.all@tools.ietf.org, apps-discuss@ietf.org, dnsext@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dnsext-dnssec-bis-updates-18 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2012 20:32:57 -0000 Hi Andrew, At 19:30 18-06-2012, Andrew Sullivan wrote: >To whom would it be confusing? The draft is indeed aimed at >implementers of DNSSEC (that is, people putting signing and validation >into code), and not at users of DNSSEC. I'm also not sure about which >places are not clear about what they're changing. Some things are >simply facts that have become clear about the way the protocol works, >but places where the actual text of the original documents is either >added to or altered are, as far as I know, marked. Could you give an >example of things you think aren't clear as to what they have changed? I mentioned "implementers who are fully conversant with the ins and outs of DNSSEC". There are people implementing code using DNSSEC signing and/or validation who are will be using the DNSSEC document set. The text in the draft does not mention that it is aimed at, for example, BIND, Unbound and Powerdns implementers only. In the review posted at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05954.html I mentioned three parts of the draft which did not seem clear to me. I'll comment more on this below. >It is hard to see how there is a rush here. The earliest version of >this draft was submitted in 2005. I know things have slowed down >around the IETF, but I can't think of seven years as a rush. Jiankang Yao commented on this in a message at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06315.html The other part of the comment was "raises questions about whether the DNSSECbis documents will ever be advanced in the near future from Proposed Standard to Internet Standard". >This view seems to be shared by others. I think we can change the >term to "DNSSEC" and, on first reference, say "(sometimes known as >DNSSECbis)" in order to make clear that the document is not referring >to the earlier incarnation. Ok. >5155 isn't being modified, but the class of things we call DNSSEC is: >this section is there to tell people that NSSEC3 isn't really >optional, because if you don't implement it you won't be able to >validate .com, .net, or .org to name but three relevant zones. That's >supposed to be clear from the first paragraph; is it not? The above explanation is clear. The first paragraph of Section 2.1 is clear. This draft updates RFC 5155. When I performed the review I compared the requirements in the last paragraph of Section 2.1 with what's in RFC 5155 to find out whether there is a change in the requirements. >There aren't any, but we can't practically require it because under >memory constraints a cache is going to be emptied anyway. Ok. >That's a good point. I don't know of anywhere, but I'm not sure this >document is an appropriate place to define it. Since the DNS is a >tree structure, "ancestor" has the same meaning it would for other >tree structures. I think it would be a very bad idea to add >definitions of this sort to this document, because the term applies to >all of the DNS and not just to DNSSEC. The DNS RFCs are hard enough >to navigate as it is. Agreed. >The problem that is described in the paragraph immediately before this >paragraph -- the one you quoted just above. Richard Barnes also >complained about not understanding this section, so I acknowledge >there's a problem here, but I'm not sure how to fix it. What is >unclear to you? I found your answer to Richard Barnes' comments clear. I'll quote it: "In the original specification, an attacker could use such an RR to prove the non-existence of some name in a subordinate zone. That was the problem." Quoting from Section 4.1 of the draft: "[RFC4035] Section 5.4 under-specifies the algorithm for checking non- existence proofs. In particular, the algorithm as presented would incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove the non-existence of RRs in the child zone." I'll suggest text and leave it to the editor to see what's better: In [RFC4035] Section 5.4, an attacker could use an NSEC or NSEC3 RR from an ancestor zone to prove the non-existence of RRs in the child zone. An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: o the NS bit set, o the SOA bit clear, and o a signer field that is shorter than the owner name of the NSEC RR, or the original owner name for the NSEC3 RR. The algorithm in [RFC4035] Section 5.4 is updated as follows: Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume ... As a matter of style I would replace Section 5.4 altogether so that it is clear to the reader. >I think the intention was that the reader would have the original open >along with this document when reading. How would you like it >rewritten? I generally go through all the normative references before reading a draft. I also refer to the original (opened) document when reading. Although I don't think that it will be done, I would suggest updating the actual RFCs instead of publishing a set of clarifications. I'll keep to the publication recommendation I made previously. I suggest not to pay too much attention to that. I cannot give the draft a pass. The IESG can do that and nobody will be unhappy. :-) Regards, S. Moonesamy From barryleiba@gmail.com Fri Jun 22 06:33: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 E165721F8604 for ; Fri, 22 Jun 2012 06:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=0.035, 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 8vmJIlWKp7Qa for ; Fri, 22 Jun 2012 06:33:55 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 099AA21F8601 for ; Fri, 22 Jun 2012 06:33:54 -0700 (PDT) Received: by qabj34 with SMTP id j34so499484qab.4 for ; Fri, 22 Jun 2012 06:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=uLbOYr+bfInR/FYsEmGHO2/QeZ6w9pl0hKhHd8YPHp0=; b=AY/UUYfAZPmr/AXrBCi3TnHi301P+wt3ZAfDBOtgjBmo5Piiion3Mv2gNEn8QYBd59 pvgIbe+RrTq76nYrrh7fsAzfEdu/1FijImrAlrZKNQKYUdIYW45iryIicwemYnzwf+FF U+V5ffvaGOfkIOoFl7SFqL2Mq9MYwDA0VNtikdTOBHt+TovekPllfFIYKLQIleUw8KTV s/7Ho5tQy+Onr95Wau4NpAcbFsCbu8OAs0BG4EvvRGK9YKNVXqcpNyidcAlbZtSIp6YB nD/qgz9KksPmAfrBaqF8zXsFarAxoZJwp8LPNCtMrab6EnP3LkL/st+0/QQ9+/Gvemjp L6KA== MIME-Version: 1.0 Received: by 10.229.136.135 with SMTP id r7mr1066076qct.79.1340372034224; Fri, 22 Jun 2012 06:33:54 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Fri, 22 Jun 2012 06:33:54 -0700 (PDT) Date: Fri, 22 Jun 2012 09:33:54 -0400 X-Google-Sender-Auth: _Oj70y8WUYuXJmzzvL_in38suL0 Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Applications Area Working Group (AppsAWG) chairs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2012 13:33:56 -0000 At the Paris IETF meeting, we announced that we would be swapping out appsawg chairs, and we did some of the swap then. Alexey has remained in the chair... um... chair for a transition period, and it's time to complete the swap now. Salvatore Loreto will co-chair AppsAWG with Murray beginning on 1 July, and Alexey will step down at that time. Salvatore also chairs HyBi, as well as SIP Overload Control (soc) in the RAI Area. He's an active reviewer on the Applications Directorate, and many of you know him. Alexey plans to finish up some of his shepherding tasks. He also still chairs WebSec in the App Area, Kitten in the Sec Area, and SIDR in the Rtg Area; he's in the App and Sec Directorates, and serves on the RFC Series Oversight Committee. Giving up AppsAWG doesn't mean he's in retirement, and we'll have more to pile on him soon enough. Alexey, thanks very much for your work in AppsAWG! Barry From alexey.melnikov@isode.com Fri Jun 22 09:32: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 DDA9721F8535 for ; Fri, 22 Jun 2012 09:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, J_CHICKENPOX_34=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 vDlJtSGGgXpu for ; Fri, 22 Jun 2012 09:32:05 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id A2E3A21F852A for ; Fri, 22 Jun 2012 09:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1340382686; d=isode.com; s=selector; i=@isode.com; bh=2gkEWBJ1MUf5CBFxEQzjRlWP+llI8m7yaexHfCr5VUE=; 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=ddYC/5fYVcaA3IR0SKcSBE7PUxWCuLYAIaHRz4o1oAZEWWvP5Ra8IKxUqOIcmPjj/FduF7 eWNp8HchMBlYnkhRAra5NGH2Rjr5DFGOFC6tw0WUA7JvMeGJCocMkNrP69eMd9vWLuLXp/ VsJ4wCoZ5Z2hfS+W9uUDRuLx0oPnPgU=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 22 Jun 2012 17:31:26 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FE49E08.3010501@isode.com> Date: Fri, 22 Jun 2012 17:32:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "Henry S. Thompson" References: <4FE33B5F.4020205@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 16:32:06 -0000 On 21/06/2012 19:48, Henry S. Thompson wrote: > Alexey Melnikov writes: > >> I've just reviewed the document. I think it looks quite reasonable in >> general. I have 1 (and maybe one more later) question: >> >> 3.1. The +json Structured Syntax Suffix >> >> Fragment identifier considerations: Media types using "+json" SHOULD >> process any fragment identifiers defined for >> "application/json" in the same way as defined for >> that media type. (At publication of this >> document, there is no fragment identification >> syntax defined for "application/json".) Specific >> media types using "+json" MAY identify additional >> fragment identifier considerations, MAY define >> processing for fragment identifiers that are >> classed as errors for "application/json" and MAY >> designate fragment identifiers defined for >> "application/json" that SHOULD NOT be used. >> >> Are you trying to say that a specific+json can do >> arbitrary changes to the rules for handling of fragment identifiers >> when compared to the media type it is based on? Is there a feeling for >> what is more likely:+json defines a more restricted >> fragment identifier syntax or it defines a richer one? >> >> (Similar text for a couple of other suffixes being registered in the >> same document.) > I didn't read it that way. It quite specifically circumscribes what a > particular xxx+json registration should do. The phrasing is perhaps a > little too concise. I believe what we should be aiming for, which I > believe this is trying to say, consistent with the best practices under > development by the W3C TAG, is as follows > > a) Syntax and semantics of fragids specified for +SUF should be same > as specified for xxx/SUF > b) Syntax and semantics for fragids for a specific xxx/yyy+SUF as > follows: > b1) For cases defined in +SUF, where the fragid resolves per > the +SUF rules, then as specified in +SUF > b2) For cases defined in +SUF, where the fragid _doesn't_ resolve per > the +SUF rules, then as specified in xxx/yyy+SUF > b3) For cases not defined in +SUF, then as specified in xxx/yyy+SUF > > Is that better? Yes, I think so. I think the current set of restrictions/recommendations can be derived from what you wrote above, but your text conveys rules in a clearer way, IMHO. From alexey.melnikov@isode.com Fri Jun 22 10:08: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 2221011E8080 for ; Fri, 22 Jun 2012 10:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.828 X-Spam-Level: X-Spam-Status: No, score=-102.828 tagged_above=-999 required=5 tests=[AWL=-0.229, 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 KEsPhIJywbST for ; Fri, 22 Jun 2012 10:08:10 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 547D721F877B for ; Fri, 22 Jun 2012 10:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1340384853; d=isode.com; s=selector; i=@isode.com; bh=vzyfEJ+j328serACyDxDDPCaT3iQuMinqyEFWN0opBg=; 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=O1eLjYaHdqmRpg250O6D6enAu4lwjwNwmSZagJiHZFdhJ87GSOTbwItwNnUm+AQEIhJhKU ueK7zHO3BfhYjy4pbwGfwWuSIF12mctPW733RBDXDL6bvvjy4XK4aW0ZenqFQ1mLFPZU1Y ly6SGlnbVX0hkkxkV/6DQ0U4Bqi+Vjc=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 22 Jun 2012 18:07:33 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FE4A67F.7020803@isode.com> Date: Fri, 22 Jun 2012 18:08:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Barry Leiba References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Applications Area Working Group (AppsAWG) chairs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2012 17:08:11 -0000 On 22/06/2012 14:33, Barry Leiba wrote: > At the Paris IETF meeting, we announced that we would be swapping out > appsawg chairs, and we did some of the swap then. Alexey has remained > in the chair... um... chair for a transition period, and it's time to > complete the swap now. > > Salvatore Loreto will co-chair AppsAWG with Murray beginning on 1 > July, and Alexey will step down at that time. Salvatore also chairs > HyBi, as well as SIP Overload Control (soc) in the RAI Area. He's an > active reviewer on the Applications Directorate, and many of you know > him. > > Alexey plans to finish up some of his shepherding tasks. He also > still chairs WebSec in the App Area, Kitten in the Sec Area, and SIDR > in the Rtg Area; he's in the App and Sec Directorates, and serves on > the RFC Series Oversight Committee. Giving up AppsAWG doesn't mean > he's in retirement, and we'll have more to pile on him soon enough. Yay, retirement :-). > Alexey, thanks very much for your work in AppsAWG! Thank you. Rest assured that I will be causing more troubles in the WG in the future ;-). From stpeter@stpeter.im Fri Jun 22 10:12: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 9EFD721F85B1 for ; Fri, 22 Jun 2012 10:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 I13SBz6uiqUN for ; Fri, 22 Jun 2012 10:12:48 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E9F7E21F851E for ; Fri, 22 Jun 2012 10:12:47 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 98C4A400EE; Fri, 22 Jun 2012 11:30:28 -0600 (MDT) Message-ID: <4FE4A78E.3050905@stpeter.im> Date: Fri, 22 Jun 2012 11:12:46 -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: Alexey Melnikov References: <4FE4A67F.7020803@isode.com> In-Reply-To: <4FE4A67F.7020803@isode.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Barry Leiba , Apps Discuss Subject: Re: [apps-discuss] Applications Area Working Group (AppsAWG) chairs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2012 17:12:48 -0000 On 6/22/12 11:08 AM, Alexey Melnikov wrote: > On 22/06/2012 14:33, Barry Leiba wrote: >> At the Paris IETF meeting, we announced that we would be swapping out >> appsawg chairs, and we did some of the swap then. Alexey has remained >> in the chair... um... chair for a transition period, and it's time to >> complete the swap now. >> >> Salvatore Loreto will co-chair AppsAWG with Murray beginning on 1 >> July, and Alexey will step down at that time. Salvatore also chairs >> HyBi, as well as SIP Overload Control (soc) in the RAI Area. He's an >> active reviewer on the Applications Directorate, and many of you know >> him. >> >> Alexey plans to finish up some of his shepherding tasks. He also >> still chairs WebSec in the App Area, Kitten in the Sec Area, and SIDR >> in the Rtg Area; he's in the App and Sec Directorates, and serves on >> the RFC Series Oversight Committee. Giving up AppsAWG doesn't mean >> he's in retirement, and we'll have more to pile on him soon enough. > Yay, retirement :-). We saw how well that worked when you retired from the IESG. ;-) Thanks, Alexey! Peter -- Peter Saint-Andre https://stpeter.im/ From alexey.melnikov@isode.com Fri Jun 22 11:06:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C0211E80C5 for ; Fri, 22 Jun 2012 11:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.813 X-Spam-Level: X-Spam-Status: No, score=-102.813 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 aMk-m6KdSwqc for ; Fri, 22 Jun 2012 11:06:24 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3C69F11E80BF for ; Fri, 22 Jun 2012 11:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1340388376; d=isode.com; s=selector; i=@isode.com; bh=e/kmxi/atl7+/5+Phj4nyQdyXUJIYmvNfMVqkL7YS98=; 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=or3Wgg6WKVw6ZFArkUyZrSWjtZwp3JYgdOzciU8MgKMK0hQa239oM0LoGsu/6d4kV+lUga Zh1gNBw60WhbGo07aUD70c0c3WZRUfAWVCa03JgNNkM4Mg5j+KS+Gs681zuX/zYauCJNCu 0jvGVQs9Q9056sHGJtuaUyQN4/S7Cd0=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 22 Jun 2012 19:06:16 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FE4B41F.1060808@isode.com> Date: Fri, 22 Jun 2012 19:06:23 +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" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Existing and planned implementations of draft-ietf-appsawg-received-state-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 18:06:25 -0000 Dear WG participants, I would like to ask if you already implemented this draft or intend to implement it. Please send replies to the mailing list or directly to me. Thanks, Alexey, as an APPSAWG co-chair. From jyee@afilias.info Fri Jun 22 14:48: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 AD44F21F860E for ; Fri, 22 Jun 2012 14:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.643 X-Spam-Level: X-Spam-Status: No, score=-5.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 gRjThKZNChEt for ; Fri, 22 Jun 2012 14:48:49 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 18EB521F860D for ; Fri, 22 Jun 2012 14:48:48 -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 1SiBii-000297-3v for apps-discuss@ietf.org; Fri, 22 Jun 2012 21:48:48 +0000 Received: from mail-vb0-f50.google.com ([209.85.212.50]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1SiBii-0008Tr-6b for apps-discuss@ietf.org; Fri, 22 Jun 2012 21:48:48 +0000 Received: by vbal1 with SMTP id l1so1204711vba.9 for ; Fri, 22 Jun 2012 14:48:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=BiHo9ehi9MTQBrmrL+vKYxSlCUc6A7qnzj5jfpZUghU=; b=DALao2rl5hp3Q97DcOm8bVqprd75lTkApicLMhZNzR/vZkqJspTIrLggv0kg8c1+eE Q0ryiBJCpAFcqLI1CJ3e0gkQiBcTDlDEIHe0lqzVtijGUiVggJnhOhJDcDH4V/ZXOBvF tvRcyy53Dr4+URWwo1L/OAnPrxqqSKkmCWlUEHmPWMiyDNYe42ilgoJLt1VtgbwWGe00 vwmjlbhH/eWHbWM/IlWK253rzY5HLMvsdDo/kPzHXTYqHaK2SzkfBZHODZ9aoZsGOosv TJCghnUTu4izvKaNYBq5Rn869BSBrqI0k9skr9ws/Th55e//cUUv6J2+QXUJek26Y1Sh j8zA== MIME-Version: 1.0 Received: by 10.52.95.110 with SMTP id dj14mr1518550vdb.69.1340401727408; Fri, 22 Jun 2012 14:48:47 -0700 (PDT) Received: by 10.52.158.34 with HTTP; Fri, 22 Jun 2012 14:48:47 -0700 (PDT) Date: Fri, 22 Jun 2012 17:48:47 -0400 Message-ID: From: Joseph Yee To: apps-discuss@ietf.org, draft-melnikov-smtp-priority-tunneling.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlZFXKSCXMAJaidKFrEUQWktI1s3hZ811HPgXkmTlSDNAJNx4mFLyNdVHuDGo59Pp9M1Xoy Subject: [apps-discuss] APPSDIR review of draft-melnikov-smtp-priority-tunneling-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 21:48: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. Document: draft-melnikov-smtp-priority-tunneling-02 Title: Tunneling of Message Transfer Priorities Reviewer: Joseph Yee Review Date: 2012-06-22 Summary: This draft is ready for publication as an Experimental RFC. Major Issues: none Minor Issues: none Nits: (1) At section 1 Introduction, the text in third paragraph talks about unextended MUA in scenario 2, but in the detailed description at 5th paragraph, it says "The client is extended via a plugin.....". Although the text meant many MUA plugin do not cover SMTP protocol features, the word "extended" in detailed description has some confusion. Suggest to change it to "The client is extendable via ...." (2) Section 1 Introduction, 3rd paragraph, typo s/scenarious/scenarios/ (3) Several references (Normative References) were not used. Although some textes "touched" keywords like 'MSA', it did not cite specific rules or concepts. So either add the reference back in text or remove the references work, IMHO. - [RFC2034] - [RFC5321] - [RFC5248] - [RFC6409] Regards, Joseph From ned.freed@mrochek.com Sat Jun 23 09:30: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 2E05321F84D0 for ; Sat, 23 Jun 2012 09:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 jAB8gJE3Q4Rk for ; Sat, 23 Jun 2012 09:30:28 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id AF98C21F84CE for ; Sat, 23 Jun 2012 09:30:28 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OH0QMX8GRK0048D2@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 23 Jun 2012 09:25:24 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OGPLORC04W000058@mauve.mrochek.com>; Sat, 23 Jun 2012 09:25:20 -0700 (PDT) Message-id: <01OH0QMU6SK8000058@mauve.mrochek.com> Date: Sat, 23 Jun 2012 09:23:59 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 22 Jun 2012 19:06:23 +0100" <4FE4B41F.1060808@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4FE4B41F.1060808@isode.com> To: Alexey Melnikov Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Existing and planned implementations of draft-ietf-appsawg-received-state-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 16:30:29 -0000 > Dear WG participants, > I would like to ask if you already implemented this draft or intend to > implement it. Please send replies to the mailing list or directly to me. I've implemented it. FWIW, it was trivial to do. The technical/functional specification took much longer than the coding and testing. Ned From internet-drafts@ietf.org Sat Jun 23 16:31: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 2D3B121F8646; Sat, 23 Jun 2012 16:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 0PDGetAxGy8e; Sat, 23 Jun 2012 16:31:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5DA21F8615; Sat, 23 Jun 2012 16:31:25 -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.21 Message-ID: <20120623233125.11811.17104.idtracker@ietfa.amsl.com> Date: Sat, 23 Jun 2012 16:31:25 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-received-state-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: Sat, 23 Jun 2012 23:31:26 -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 : Indicating Email Handling States in Trace Fields Author(s) : D. Crocker Murray S. Kucherawy Filename : draft-ietf-appsawg-received-state-03.txt Pages : 11 Date : 2012-06-23 Abstract: This memo registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queueing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-received-state There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-received-state-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-received-state-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From McQuilWP@pobox.com Sat Jun 23 17:58: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 7661F21F8691 for ; Sat, 23 Jun 2012 17:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GV3B12nKBX6 for ; Sat, 23 Jun 2012 17:58:41 -0700 (PDT) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 47CE921F8697 for ; Sat, 23 Jun 2012 17:58:41 -0700 (PDT) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 2D47295DE; Sat, 23 Jun 2012 20:58:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:subject:mime-version:content-type :content-transfer-encoding; s=sasl; bh=njqEHoZ3CVbflL0VzRk3BqO11 LI=; b=AbQ5JkVrWhLRZZp7c82GuQiRdMFWwHjUX0jzNWAlidSBIeKOyNsgobTd2 JyO5KCfNTmbsOcN5a+VSRKi0tn/84ViKnJfFJMFygKvuZ+z9jW8+6O540vnSgy1g B88wI9+ZCt3RezzcEnWrMmU5ekMId7nNeOnRhRxzARuwZ1QPDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:subject:mime-version:content-type :content-transfer-encoding; q=dns; s=sasl; b=TD6tvq7YXn30Tgie4ud ypObkqcGeDrH7zF3Pe6E2dTbm54MCBI2V3O5B4bg4jXimSYTQQBuw5xeLcB6o62Y EQEoyNQzZxzMB//ew+sEJnA8Fvku7wnx0XqNU1p5Z4sdgU4CbN5v4QObeCCV9hNM UEks5XCZh2Kya/mQ9R/YMqNg= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 2466295DD; Sat, 23 Jun 2012 20:58:34 -0400 (EDT) Received: from BQ07NB (unknown [68.107.110.211]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id 8733595DC; Sat, 23 Jun 2012 20:58:33 -0400 (EDT) Date: Sat, 23 Jun 2012 17:58:32 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1522965284.20120623175832@pobox.com> To: Apps-Discusssion MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: B8EC6116-BD97-11E1-A40B-FC762E706CDE-02871704!b-pb-sasl-quonix.pobox.com Subject: [apps-discuss] draft-ietf-appsawg-received-state-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2012 00:58:45 -0000 In section 3, end of the first paragraph: That is, the presence of this clause on a trace field is an indication of the entry of the message into that state; a later trace field added would indicate its departure from that state. This seems to imply that there is some "End of State" trace field to be inserted when the processing is complete. I would suggest changing "a later trace field" to "any later trace field" or perhaps "some later trace field". ------------------------------------------------------------------- In the next paragraph: Appropriate use of this mechanism does not include associating meta- data with the message, such as categorizing the message (e.g., the notions of "is spam" or "was 8-bit, converted to 7-bit"). seems, in spirit, to be in conflict with the later paragraphs in the same section: A transfer agent making use of this extension MAY also include header field comments to provide additional information. The "value" is available for providing additional labels as explanation for the state transition. Examples could include: o convert/unicode2ascii o moderation/not-subscribed o quarantine/spam At least to me, these "values" and "header field comments" are exactly that sort of meta-data. Since the "meta-data" is likely to be useful, I suggest removing the earlier paragraph. ------------------------------------------------------------------- In section 4, third paragraph: Rather, an agent that wishes to make a state annotation SHOULD add only a single Received header field including such annotation, thus indicating (a) the time of completion of its handling of the message via the date portion of the field, and (b) the final disposition of that message relative to that agent. For example, an MTA receiving a message that performs various checks on the message before immediately handing it off to a Mailing List Manager (MLM) would only record a "normal" state, assuming it passes those checks. The MLM would then evaluate the message and record its own state once it decides what the next step will be for the handling of that message. This seems to imply that the trace field will be added at the *end* of the state to explain the previous delay. I thought that the intent was to add the state subfield to the trace field when *entering* some possibly lengthy processing step. -- Bill McQuillan From superuser@gmail.com Sat Jun 23 22:36: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 8076C21F86B2 for ; Sat, 23 Jun 2012 22:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.162, 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 VvFamN2EUUko for ; Sat, 23 Jun 2012 22:36:23 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id F01DA21F86A3 for ; Sat, 23 Jun 2012 22:36:22 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so6836671lbb.22 for ; Sat, 23 Jun 2012 22:36:21 -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=ybO09W8ia8wRsL1a/6rfd0PhzoaRbrLypL5MWKAyW70=; b=MmT/AaJe9WogwInVjr+H5haIEAREcBiG9A617fCSGqllChkcjoAK/su9i4xuXETvZ+ D06KmzRbPVWRZnqiA7CLFcl1rcKwYqpZLjouoik9zh4oNxXH6qO373OETrjvIAkiacVn eWX38CcbD2fisodS2g5kPokil+ayCv/dhOjTWelkqiN0tMXOij6MvOah8tfoGj5EvK1i wJhkszz7EnwXQmrSLpnIbWIZhMlUR1SZyhMPHaPUtbGLG30xWChivkV8QVqkMTPync92 ynoe1VO9ZU53Z+QeX/uNRinziq7D2JhS9glqS/6JGOORwGN9sGRAeb2mi8Ug0aLZ6Qq4 hXdg== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr7690057lab.9.1340516181670; Sat, 23 Jun 2012 22:36:21 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sat, 23 Jun 2012 22:36:21 -0700 (PDT) In-Reply-To: <1522965284.20120623175832@pobox.com> References: <1522965284.20120623175832@pobox.com> Date: Sat, 23 Jun 2012 22:36:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Bill McQuillan Content-Type: multipart/alternative; boundary=e89a8f22c411d2fb4104c3313e4d Cc: Apps-Discusssion Subject: Re: [apps-discuss] draft-ietf-appsawg-received-state-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2012 05:36:24 -0000 --e89a8f22c411d2fb4104c3313e4d Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 23, 2012 at 5:58 PM, Bill McQuillan wrote: > In section 3, end of the first paragraph: > > That is, the presence of this > clause on a trace field is an indication of the entry of the message > into that state; a later trace field added would indicate its > departure from that state. > > This seems to imply that there is some "End of State" trace field > to be inserted when the processing is complete. I would suggest > changing "a later trace field" to "any later trace field" or > perhaps "some later trace field". > The next Received field indicates the exit from that state. Consider MLM moderation: release of the message from moderation lands it in an MTA's outbound queue, which generates a new Received field. > ------------------------------------------------------------------- > > In the next paragraph: > > Appropriate use of this mechanism does not include associating meta- > data with the message, such as categorizing the message (e.g., the > notions of "is spam" or "was 8-bit, converted to 7-bit"). > > seems, in spirit, to be in conflict with the later paragraphs in > the same section: > > A transfer agent making use of this extension MAY also include header > field comments to provide additional information. > There's a difference between "queued for conversion" and "was converted". We're explaining the reason a processing delay occurred, not tagging the message itself in some way. You could in theory have two opposite conversions occur (say, through a tunnel of some kind) that cancel each other out; you'd have to parse all of that to figure out the state of the content. Thus, that's not what this is for. > ------------------------------------------------------------------- > > In section 4, third paragraph: > > Rather, an agent that wishes to make a state annotation SHOULD add > only a single Received header field including such annotation, thus > indicating (a) the time of completion of its handling of the message > via the date portion of the field, and (b) the final disposition of > that message relative to that agent. For example, an MTA receiving a > message that performs various checks on the message before > immediately handing it off to a Mailing List Manager (MLM) would only > record a "normal" state, assuming it passes those checks. The MLM > would then evaluate the message and record its own state once it > decides what the next step will be for the handling of that message. > > This seems to imply that the trace field will be added at the > *end* of the state to explain the previous delay. I thought that > the intent was to add the state subfield to the trace field when > *entering* some possibly lengthy processing step. > When a handling agent finishes with a message, it's in some kind of state. That might be queued for next hop ("normal"), or it might be any of the example hold reasons the document identifies. That's the point of entry of that message into that state, even if it is not the beginning of the cycle of handling of the message by that agent. -MSK --e89a8f22c411d2fb4104c3313e4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jun 23, 2012 at 5:58 PM, Bill McQuillan <McQuilWP@pobox.com&g= t; wrote:
In section 3, end of the first paragraph:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0That is, the presence of this
=A0 clause on a trace field is an indication of the entry of the message =A0 into that state; a later trace field added would indicate its
=A0 departure from that state.

This seems to imply that there is some "End of State" trace field=
to be inserted when the processing is complete. I would suggest
changing "a later trace field" to "any later trace field&quo= t; or
perhaps "some later trace field".

The ne= xt Received field indicates the exit from that state.=A0 Consider MLM moder= ation: release of the message from moderation lands it in an MTA's outb= ound queue, which generates a new Received field.
=A0
-------------------------------------------------------------------

In the next paragraph:

=A0 Appropriate use of this mechanism does not include associating meta- =A0 data with the message, such as categorizing the message (e.g., the
=A0 notions of "is spam" or "was 8-bit, converted to 7-bit&= quot;).

seems, in spirit, to be in conflict with the later paragraphs in
the same section:

=A0 A transfer agent making use of this extension MAY also include header<= br> =A0 field comments to provide additional information.

There's a difference between "queued for conversion" and= "was converted".=A0 We're explaining the reason a processing= delay occurred, not tagging the message itself in some way.=A0 You could i= n theory have two opposite conversions occur (say, through a tunnel of some= kind) that cancel each other out; you'd have to parse all of that to f= igure out the state of the content.=A0 Thus, that's not what this is fo= r.


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

In section 4, third paragraph:

=A0 Rather, an agent that wishes to make a state annotation SHOULD add
=A0 only a single Received header field including such annotation, thus =A0 indicating (a) the time of completion of its handling of the message =A0 via the date portion of the field, and (b) the final disposition of =A0 that message relative to that agent. =A0For example, an MTA receiving = a
=A0 message that performs various checks on the message before
=A0 immediately handing it off to a Mailing List Manager (MLM) would only<= br> =A0 record a "normal" state, assuming it passes those checks. = =A0The MLM
=A0 would then evaluate the message and record its own state once it
=A0 decides what the next step will be for the handling of that message.
This seems to imply that the trace field will be added at the
*end* of the state to explain the previous delay. I thought that
the intent was to add the state subfield to the trace field when
*entering* some possibly lengthy processing step.

= When a handling agent finishes with a message, it's in some kind of sta= te.=A0 That might be queued for next hop ("normal"), or it might = be any of the example hold reasons the document identifies.=A0 That's t= he point of entry of that message into that state, even if it is not the be= ginning of the cycle of handling of the message by that agent.

-MSK
--e89a8f22c411d2fb4104c3313e4d-- From mnot@mnot.net Sun Jun 24 22:52: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 1E88921F84FF for ; Sun, 24 Jun 2012 22:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.355 X-Spam-Level: X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=-3.756, 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 A2D9JDYzRvjv for ; Sun, 24 Jun 2012 22:52:19 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id A0CF821F84D6 for ; Sun, 24 Jun 2012 22:52:19 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4F3C122E253; Mon, 25 Jun 2012 01:52:11 -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: Mon, 25 Jun 2012 15:52:09 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1278) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 05:52:24 -0000 I still haven't seen a satisfying answer to my questions about how this = is actually going to be used. They may be out there, but I can't escape = the feeling that people are going along with this because it "seems like = a good idea", and I'm concerned that the implications of allowing a = multitude of suffixes -- thereby effectively adding another dimension of = identity to our format identifiers -- hasn't been properly considered. I'm especially concerned because, as I noted in my review of the media = type registrations document, there isn't any discussion of appropriate = vs. inappropriate use in this registry; the only guidance given to the = experts for this registry is: > The primary guideline for whether a structured type name suffix is > registrable is that it be described by a readily-available > description, preferably within a document published by an = established > standards organization, and for which there's a reference that can = be > used in a Normative References section of an RFC. Now, if that isn't a hole that you can drive a tank through, I don't = know what is (BTW, the media types registration document doesn't even = explicitly specify a policy for this registry; it appears to be Expert = Review). E.g., the recent +merge-patch suffix proposal. If James had chosen to = pursue that, on what grounds could the Expert (whoever that will be) = reject the proposal? I realise this document is only a shell for registering the suffixes, = rather than their registration, but I still haven't seen any meaningful = response to the concerns that I brought up, first in review of the media = type registrations document, and later in separate e-mail.=20 Regards, On 20/06/2012, at 4:15 PM, Murray S. Kucherawy wrote: > On Mon, Jun 11, 2012 at 5:25 AM, Murray S. Kucherawy = wrote: > This note begins a Working Group Last Call on = draft-ietf-appsawg-media-type-suffix-regs, ending Monday, June 25. = Please review the document and comment on it. >=20 > Note that its "parent" document, draft-ietf-appsawg-media-type-regs, = is now in IESG Evaluation. >=20 > =20 > A reminder that this WGLC closes in less than a week. Please review = the document and send your comments soon. >=20 > Thanks, > -MSK, APPSAWG co-chair >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From wwwrun@rfc-editor.org Mon Jun 25 10:32: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 75A6421F84E6; Mon, 25 Jun 2012 10:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.759 X-Spam-Level: X-Spam-Status: No, score=-104.759 tagged_above=-999 required=5 tests=[AWL=0.918, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 oSBuc9SofShp; Mon, 25 Jun 2012 10:32:30 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 57E7B21F84E1; Mon, 25 Jun 2012 10:32:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C4786B1E003; Mon, 25 Jun 2012 10:31:34 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120625173134.C4786B1E003@rfc-editor.org> Date: Mon, 25 Jun 2012 10:31:34 -0700 (PDT) Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] BCP 178, RFC 6648 on Deprecating the "X-" Prefix and Similar Constructs in Application Protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2012 17:32:31 -0000 A new Request for Comments is now available in online RFC libraries. BCP 178 RFC 6648 Title: Deprecating the "X-" Prefix and Similar Constructs in Application Protocols Author: P. Saint-Andre, D. Crocker, M. Nottingham Status: Best Current Practice Stream: IETF Date: June 2012 Mailbox: psaintan@cisco.com, dcrocker@bbiw.net, mnot@mnot.net Pages: 13 Characters: 28393 See Also: BCP0178 I-D Tag: draft-ietf-appsawg-xdash-05.txt URL: http://www.rfc-editor.org/rfc/rfc6648.txt Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols. This memo documents an Internet Best Current Practice. This document is a product of the Applications Area Working Group Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From melvincarvalho@gmail.com Tue Jun 26 05:06: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 0173821F863C for ; Tue, 26 Jun 2012 05:06:22 -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 On+IC-kgzUdt for ; Tue, 26 Jun 2012 05:06:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 118D821F8631 for ; Tue, 26 Jun 2012 05:06:20 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2932510vbb.31 for ; Tue, 26 Jun 2012 05:06:20 -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=1n/cwibHaA306WFQj4CwCS1f3Zsf/87Y+FtioRlC2Qc=; b=0DRef7TI8xJ4vIzXCTK+NI0OtPU2nWmMpu/DHaK3PksxWG7iP7tkE182ydpTlzCfot E39U/SN7dHqzWfzED0IoCNl0JpoJNgUKMPemqOQdSplKMFDbyDP0AFgCLwlwNYNGX0wQ wpOPj+UxlH86gDTgj+5gi4o8fBh+GBDoP1tQbu1jb9M7D048xij/0HhhDSieaaThP2ua xTzmHxJ65Y0jypOFO76fPwd/qsSoWFxgbb8zpKrPNQFprFSGnEDAATERqpNMEN7G6hK2 L4P3d2DyDHFH9I78XNXVAqwXp/qQ69Dk1tyGKwQUEPNPAw+EbhE7iRu3HbtQIttrDxu+ cZcQ== MIME-Version: 1.0 Received: by 10.52.72.137 with SMTP id d9mr8803939vdv.122.1340712380564; Tue, 26 Jun 2012 05:06:20 -0700 (PDT) Received: by 10.52.166.102 with HTTP; Tue, 26 Jun 2012 05:06:20 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> Date: Tue, 26 Jun 2012 14:06:20 +0200 Message-ID: From: Melvin Carvalho To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=bcaec50163013085d304c35eed53 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 12:06:22 -0000 --bcaec50163013085d304c35eed53 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 22 May 2012 09:22, Murray S. Kucherawy wrote: > As we prepare to bring webfinger into appsawg, it looks a lot like > there=92s substantial discussion just on the point of the proposed =93acc= t:=94 > scheme.**** > > ** ** > > So, a question for those tracking the discussion: Is this a big enough > topic that it should be split into its own document? This would be a > useful thing to decide as we figure out how to handle the work once it > enters working group mode.**** > > ** ** > > (This by itself has me wondering if we should revisit the conversation > about whether webfinger needs its own working group, but I=92ll leave it = to > Barry and Pete to make that call.) > There has been some discussion of this here and on other lists, and the consensus I think is for people to follow the process at : . I think the current state of play is that webfinger can be used with any URI type e.g. mailto: http: acct: etc. acct: is recommended in the RFC. **** > > ** ** > > -MSK**** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --bcaec50163013085d304c35eed53 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 22 May 2012 09:22, Murray S. Kucheraw= y <msk@cloudmark.com> wrote:

As we prepare to bring webfinger into appsawg, it lo= oks a lot like there=92s substantial discussion just on the point of the pr= oposed =93acct:=94 scheme.

=A0

So, a question for those tracking the discussion:=A0= Is this a big enough topic that it should be split into its own document?= =A0 This would be a useful thing to decide as we figure out how to handle t= he work once it enters working group mode.

=A0

(This by itself has me wondering if we should revisi= t the conversation about whether webfinger needs its own working group, but= I=92ll leave it to Barry and Pete to make that call.)


There has been some discussion of this here and on other lists, an= d the consensus I think is for people to follow the process at :

<uri-review@iet= f.org>.

I think the current state of play is that webfinger can be used with any UR= I=20 type e.g. mailto: http: acct: etc. acct: is recommended in the RFC.=A0

=A0

-MSK


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


--bcaec50163013085d304c35eed53-- From Michael.Jones@microsoft.com Tue Jun 26 06:20: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 E524021F8644 for ; Tue, 26 Jun 2012 06:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.833 X-Spam-Level: X-Spam-Status: No, score=-3.833 tagged_above=-999 required=5 tests=[AWL=-0.235, 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 UgX2By+LCtfF for ; Tue, 26 Jun 2012 06:20:27 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 63F0121F85B8 for ; Tue, 26 Jun 2012 06:20:22 -0700 (PDT) Received: from mail113-am1-R.bigfish.com (10.3.201.237) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 13:18:40 +0000 Received: from mail113-am1 (localhost [127.0.0.1]) by mail113-am1-R.bigfish.com (Postfix) with ESMTP id 54250460581; Tue, 26 Jun 2012 13:18:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz98dI9371Ic85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail113-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail113-am1 (localhost.localdomain [127.0.0.1]) by mail113-am1 (MessageSwitch) id 1340716719298844_19879; Tue, 26 Jun 2012 13:18:39 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.251]) by mail113-am1.bigfish.com (Postfix) with ESMTP id 3D0053C0048; Tue, 26 Jun 2012 13:18:39 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 13:18:37 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Tue, 26 Jun 2012 13:20:18 +0000 From: Mike Jones To: Melvin Carvalho , "Murray S. Kucherawy" Thread-Topic: [apps-discuss] The acct: scheme question Thread-Index: Ac0367W7uVNJxgK+Tf6qpowkmE64wgbqGMQAAAKM2jA= Date: Tue, 26 Jun 2012 13:20:16 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366568E4FTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 13:20:29 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366568E4FTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I believe that the acct: scheme should be considered separately from d= iscovery, in its own document. -- Mike From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Melvin Carvalho Sent: Tuesday, June 26, 2012 5:06 AM To: Murray S. Kucherawy Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question On 22 May 2012 09:22, Murray S. Kucherawy > wrote: As we prepare to bring webfinger into appsawg, it looks a lot like there's = substantial discussion just on the point of the proposed "acct:" scheme. So, a question for those tracking the discussion: Is this a big enough top= ic that it should be split into its own document? This would be a useful t= hing to decide as we figure out how to handle the work once it enters worki= ng group mode. (This by itself has me wondering if we should revisit the conversation abou= t whether webfinger needs its own working group, but I'll leave it to Barry= and Pete to make that call.) There has been some discussion of this here and on other lists, and the con= sensus I think is for people to follow the process at : >. I think the current state of play is that webfinger can be used with any UR= I type e.g. mailto: http: acct: etc. acct: is recommended in the RFC. -MSK _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_000_4E1F6AAD24975D4BA5B168042967394366568E4FTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, I believe that the a= cct: scheme should be considered separately from discovery, in its own docu= ment.

 <= /p>

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

 <= /p>

From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Melvin Carvalho
Sent: Tuesday, June 26, 2012 5:06 AM
To: Murray S. Kucherawy
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] The acct: scheme question

 

 

On 22 May 2012 09:22, Murray S. Kucherawy <msk@cloudmark.com> = wrote:

As we prepare to bring webfinger into appsawg, it looks a lot like= there’s substantial discussion just on the point of the proposed = 220;acct:” scheme.

 

So, a question for those tracking the discussion:  Is this a = big enough topic that it should be split into its own document?  This = would be a useful thing to decide as we figure out how to handle the work once it enters working group mode.

 

(This by itself has me wondering if we should revisit the conversa= tion about whether webfinger needs its own working group, but I’ll le= ave it to Barry and Pete to make that call.)


There has been some discussion of this here and on other lists, and the con= sensus I think is for people to follow the process at :

<uri-review@iet= f.org>.

I think the current state of play is that webfinger can be used with any UR= I type e.g. mailto: http: acct: etc. acct: is recommended in the RFC. 

 

-MSK


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

 

--_000_4E1F6AAD24975D4BA5B168042967394366568E4FTK5EX14MBXC283r_-- From stpeter@stpeter.im Tue Jun 26 06:58: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 9831921F85FB for ; Tue, 26 Jun 2012 06:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 XAlUspJYcT5z for ; Tue, 26 Jun 2012 06:58:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EC48521F8503 for ; Tue, 26 Jun 2012 06:58:19 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 17DCC4005A; Tue, 26 Jun 2012 08:16:12 -0600 (MDT) Message-ID: <4FE9BFF9.9060403@stpeter.im> Date: Tue, 26 Jun 2012 07:58:17 -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: Mike Jones References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 13:58:20 -0000 On 6/26/12 7:20 AM, Mike Jones wrote: > Yes, I believe that the acct: scheme should be considered separately > from discovery, in its own document. Personally I have no strong preference, although given that the relevant sections of draft-jones-appsawg-webfinger-06 take up about a page, it will be quite a brief specification. :) http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06#section-6 http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06#section-12.1 Do folks think that the 'acct' link relation would belong in the webfinger spec, in the 'acct' URI spec, or in a separate spec? Peter -- Peter Saint-Andre https://stpeter.im/ From bobwyman@gmail.com Tue Jun 26 07: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 CC46721F84FC for ; Tue, 26 Jun 2012 07:36:36 -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 hPy7-pC1Rkca for ; Tue, 26 Jun 2012 07:36:36 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id 100C521F84FB for ; Tue, 26 Jun 2012 07:36:36 -0700 (PDT) Received: by yhp26 with SMTP id 26so6326086yhp.26 for ; Tue, 26 Jun 2012 07:36:35 -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=Bc6J6Y5jdyIsIB7WBpOI5ZWaWQGRYzW22hCssgfAzT4=; b=F5UmA7/vgJUAKZKUBd4UQCQFDz3c1V+wE6/8sl7nLARB6v5Hb7qpH08uFCsnSglErr 0b2xKW9LJCAKWgfQ7593VkNFx6Z44Ma96dxnLIftnQU3Zux+zjxpv18XPA3ib/jsbnOq Z9Mpqokx1jHRcvvUEWnHevbnTAmzy615U+hmN8aTBHbNaat2ybnIKRfMetIxrV/l79LM +KdJiIT1210mlpGHT/pjuGqbPiZ2ULoOUoei218YLCaW6cnPcdMUyWKWCc0ngWlg55Rm GlVlj29LNmclRO3JNHqJmLB5ZtZwvGz4dvOYrtup4VUPSKou7Vx3+ECs2FnJ5oorYQsH esdQ== MIME-Version: 1.0 Received: by 10.236.175.166 with SMTP id z26mr17820826yhl.56.1340721395641; Tue, 26 Jun 2012 07:36:35 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.100.95.20 with HTTP; Tue, 26 Jun 2012 07:36:35 -0700 (PDT) In-Reply-To: <4FE9BFF9.9060403@stpeter.im> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE9BFF9.9060403@stpeter.im> Date: Tue, 26 Jun 2012 10:36:35 -0400 X-Google-Sender-Auth: g20NSEnqX69ZF4gGmEhddQ5sZRc Message-ID: From: Bob Wyman To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=20cf303f635287ac1104c36106c1 Cc: "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 14:36:36 -0000 --20cf303f635287ac1104c36106c1 Content-Type: text/plain; charset=ISO-8859-1 I would leave acct: link relation in the WebFinger spec. I can see no utility in breaking it out. Nothing but additional process overhead and more fragmentation of the specs will result from breaking it out. bob wyman On Tue, Jun 26, 2012 at 9:58 AM, Peter Saint-Andre wrote: > On 6/26/12 7:20 AM, Mike Jones wrote: > > Yes, I believe that the acct: scheme should be considered separately > > from discovery, in its own document. > > Personally I have no strong preference, although given that the relevant > sections of draft-jones-appsawg-webfinger-06 take up about a page, it > will be quite a brief specification. :) > > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06#section-6 > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06#section-12.1 > > Do folks think that the 'acct' link relation would belong in the > webfinger spec, in the 'acct' URI spec, or in a separate spec? > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --20cf303f635287ac1104c36106c1 Content-Type: text/html; charset=ISO-8859-1 I would leave acct: link relation in the WebFinger spec.

I can see no utility in breaking it out. Nothing but additional process overhead and more fragmentation of the specs will result from breaking it out.

bob wyman

On Tue, Jun 26, 2012 at 9:58 AM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 6/26/12 7:20 AM, Mike Jones wrote:
> Yes, I believe that the acct: scheme should be considered separately
> from discovery, in its own document.

Personally I have no strong preference, although given that the relevant
sections of draft-jones-appsawg-webfinger-06 take up about a page, it
will be quite a brief specification. :)

http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06#section-6
http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06#section-12.1

Do folks think that the 'acct' link relation would belong in the
webfinger spec, in the 'acct' URI spec, or in a separate spec?

Peter

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




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

--20cf303f635287ac1104c36106c1-- From ve7jtb@ve7jtb.com Tue Jun 26 07:38: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 EA33121F8540 for ; Tue, 26 Jun 2012 07:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 eBoo8BoCA4eu for ; Tue, 26 Jun 2012 07:38:17 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA13121F8541 for ; Tue, 26 Jun 2012 07:38:16 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4276653ghb.31 for ; Tue, 26 Jun 2012 07:38:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=uYpQrpXNismjMi34pHNXjxBwwJhullN21i0uGYCTb8E=; b=VjpJdSdsBRgatdi3kP4RFWg3Q5bFT2wYkymv8AQOF2joULXAVbxdGQW3z0cxQ1RIG0 qd5Jf81+uRYcoRJyOQzMihBLxchhJA0/MG0xqpPSGjAK3KMOd1YMs16uQT/dTuJFzgA/ yJP02hb8k6LH5lYwgGTOB3jVfPDI9bFifDrlD+qplU/Z0vDyT5UhJzW47aLvbOzihGNT mG7gtqy5zbaydFUOMUVRWLYBfDDKLMkANaOaneaAqov3/jInnNomtlpnRo586F+VizHH h7qkoN9GmSncl12uvht2Xw/MN1wml8Yuh3nCPi5WZohwWWDFSvTGJih6719CN0xJY8MU 4dzA== Received: by 10.101.96.15 with SMTP id y15mr5526451anl.32.1340721496437; Tue, 26 Jun 2012 07:38:16 -0700 (PDT) Received: from [192.168.1.34] (190-20-38-238.baf.movistar.cl. [190.20.38.238]) by mx.google.com with ESMTPS id a34sm140717117yhh.0.2012.06.26.07.38.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 07:38:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_02F42B32-4FCC-4F5C-A119-B46E7EBD9E24"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4FE9BFF9.9060403@stpeter.im> Date: Tue, 26 Jun 2012 10:37:59 -0400 Message-Id: <035988BC-A9BC-4397-8593-D5F84710ECF3@ve7jtb.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE9BFF9.9060403@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQm0qFR33On0IG+Yq0iNHf07EEljV8qY5Y/ogvCXHw7R4890O2Y0wacTO5qlk61Cm+AJNK50 Cc: "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 14:38:18 -0000 --Apple-Mail=_02F42B32-4FCC-4F5C-A119-B46E7EBD9E24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think it is better to have it in a separate spec. The current spec requires normalization of bare identifiers i.e. = foo@bar.com to acct:foo@bar.com. That would also need to change if we separate the specs. John B. On 2012-06-26, at 9:58 AM, Peter Saint-Andre wrote: > On 6/26/12 7:20 AM, Mike Jones wrote: >> Yes, I believe that the acct: scheme should be considered separately >> from discovery, in its own document. >=20 > Personally I have no strong preference, although given that the = relevant > sections of draft-jones-appsawg-webfinger-06 take up about a page, it > will be quite a brief specification. :) >=20 > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06#section-6 > = http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06#section-12.1 >=20 > Do folks think that the 'acct' link relation would belong in the > webfinger spec, in the 'acct' URI spec, or in a separate spec? >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_02F42B32-4FCC-4F5C-A119-B46E7EBD9E24 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NjE0Mzc2MFowIwYJKoZIhvcNAQkEMRYEFDNoykBh6umnlBGFsi37JQEanwecMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACC0f1yY9Q5bmVr6LEvILBUGua5w+ZTFYCTZyBLcV2JCussgpgd+PV5Nkeoa7acG99NEMFRBlGW2 2gwDo2Ty6FoGkgIeU/agtrxv6dsdSCconINrxyQhBFjKQKgkrLV4l4PWcTLyX9eGhKe7k8wknc/+ irC70b0aMR7nqTBXIn88Bu98ENZUCpFA1SmmdAPT9VqRdnBX2KN0vZ0m+eVk+4HHRx6fCTbPP2qw 0vQ/fr/UTVloFmcQlsiG4OvT7eMjOQpXl5egVTt7oXSrlB3m5hypUgwyjOaLNRfebzNJW9IYUVXW gG5L7T9G8oPGUsOaW7qADxBp7DuPi66qKDnfyXwAAAAAAAA= --Apple-Mail=_02F42B32-4FCC-4F5C-A119-B46E7EBD9E24-- From stpeter@stpeter.im Tue Jun 26 07:40: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 252F521F855F for ; Tue, 26 Jun 2012 07:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 u6kuHfCichjN for ; Tue, 26 Jun 2012 07:40:22 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEFF21F8554 for ; Tue, 26 Jun 2012 07:40:22 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C138D4005A; Tue, 26 Jun 2012 08:58:14 -0600 (MDT) Message-ID: <4FE9C9D4.5060106@stpeter.im> Date: Tue, 26 Jun 2012 08:40:20 -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: John Bradley References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE9BFF9.9060403@stpeter.im> <035988BC-A9BC-4397-8593-D5F84710ECF3@ve7jtb.com> In-Reply-To: <035988BC-A9BC-4397-8593-D5F84710ECF3@ve7jtb.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 14:40:23 -0000 On 6/26/12 8:37 AM, John Bradley wrote: > The current spec requires normalization of bare identifiers i.e. foo@bar.com to acct:foo@bar.com. > That would also need to change if we separate the specs. In what way would it need to change? Peter -- Peter Saint-Andre https://stpeter.im/ From ve7jtb@ve7jtb.com Tue Jun 26 07:43: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 85F4221F85D0 for ; Tue, 26 Jun 2012 07:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 kbOVgc9pCR3i for ; Tue, 26 Jun 2012 07:43:23 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2DA521F856D for ; Tue, 26 Jun 2012 07:43:23 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4283325ghb.31 for ; Tue, 26 Jun 2012 07:43:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=riB+ZO/Q6nu3iLD162zfX0QcmSdkG6z2YF7LpT1CGwg=; b=bY/B6klFM5b9FVeDbvZhScnzFCxCAQq+Hl6TQFBKukJBqCumwOY/GVsHm0dAe1thxl doKWAsojMz+qehs72MujJ/rFR9EdX8JOeO0z/HdvRKl9JicvjFvQtJt1Dp4UtiVqbuPT yOafmZgRWxhe13vQ12V9TuJJGTMzWqd8VcBonlfgSZ19z8FjjbS8BLMz17vpCAPj4CKs 29PnhgNRzwlLASnpGRRKprkLeAaY47keret7gMI0+ERK7OFArVtUCvh2r53u3qzB6/Ql 0mk2VWpbcvqkA4MeM/vVtkOSAYkOmm29r1CcujnlQm0Kmnr8VhOzctTj244DM1VjbZNH TOKw== Received: by 10.236.75.232 with SMTP id z68mr18303398yhd.90.1340721803120; Tue, 26 Jun 2012 07:43:23 -0700 (PDT) Received: from [192.168.1.34] (190-20-38-238.baf.movistar.cl. [190.20.38.238]) by mx.google.com with ESMTPS id i67sm140703864yhh.21.2012.06.26.07.43.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 07:43:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_DA847025-C9E7-4331-A614-711A4F5F04F8"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Tue, 26 Jun 2012 10:43:05 -0400 Message-Id: References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE9BFF9.9060403@stpeter.im> To: Bob Wyman X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnENILt9776Zv+2Ph/WGGxiqhNaBVsQ9JengVCN/GE2Bhi+AGpIszjnGvlaiHiX3hNA8PzX Cc: "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 14:43:24 -0000 --Apple-Mail=_DA847025-C9E7-4331-A614-711A4F5F04F8 Content-Type: multipart/alternative; boundary="Apple-Mail=_4377C423-8EF2-4AEF-BE5B-99332DB106EC" --Apple-Mail=_4377C423-8EF2-4AEF-BE5B-99332DB106EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I would change the account link relation to use the http: scheme. acct: = is unnecessary for the link relation, other link relations don't require = a new scheme. That is one of the biggest things people will object to about acct: Yes if acct: is registered it looks nicer I will give you that. John B. On 2012-06-26, at 10:36 AM, Bob Wyman wrote: > I would leave acct: link relation in the WebFinger spec. >=20 > I can see no utility in breaking it out. Nothing but additional = process overhead and more fragmentation of the specs will result from = breaking it out. >=20 > bob wyman >=20 > On Tue, Jun 26, 2012 at 9:58 AM, Peter Saint-Andre = wrote: > On 6/26/12 7:20 AM, Mike Jones wrote: > > Yes, I believe that the acct: scheme should be considered separately > > from discovery, in its own document. >=20 > Personally I have no strong preference, although given that the = relevant > sections of draft-jones-appsawg-webfinger-06 take up about a page, it > will be quite a brief specification. :) >=20 > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06#section-6 > = http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06#section-12.1 >=20 > Do folks think that the 'acct' link relation would belong in the > webfinger spec, in the 'acct' URI spec, or in a separate spec? >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_4377C423-8EF2-4AEF-BE5B-99332DB106EC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 I would change the account link relation to use the http: scheme.  acct: is unnecessary for the link relation, other link relations don't require a new scheme.

That is one of the biggest things people will object to about acct:

Yes if acct: is registered it looks nicer I will give you that.


John B.

On 2012-06-26, at 10:36 AM, Bob Wyman wrote:

I would leave acct: link relation in the WebFinger spec.

I can see no utility in breaking it out. Nothing but additional process overhead and more fragmentation of the specs will result from breaking it out.

bob wyman

On Tue, Jun 26, 2012 at 9:58 AM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 6/26/12 7:20 AM, Mike Jones wrote:
> Yes, I believe that the acct: scheme should be considered separately
> from discovery, in its own document.

Personally I have no strong preference, although given that the relevant
sections of draft-jones-appsawg-webfinger-06 take up about a page, it
will be quite a brief specification. :)

http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06#section-6
http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06#section-12.1

Do folks think that the 'acct' link relation would belong in the
webfinger spec, in the 'acct' URI spec, or in a separate spec?

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

--Apple-Mail=_4377C423-8EF2-4AEF-BE5B-99332DB106EC-- --Apple-Mail=_DA847025-C9E7-4331-A614-711A4F5F04F8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NjE0NDMwNlowIwYJKoZIhvcNAQkEMRYEFEurr/drTyQkNcWacQJKHu+8QAXgMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ALDw9ATk+wlic+/FxKV8UtJy6WP7iNIRJ/7stIq6N3dcVWE5deh3GIKELgAB0AJdl/OVGkCng+Ul vcYLzCdyK1rigv7Pb7F0aa99DEF6SCu1f9NlFVe9Tkr6BlYuCB1IXSgOnKetuiPzXK84FhbdLgNq wszU9qEf6wd7/LstAhaJr/S5HowgY99LxhRb+VtlB94WlHO7dQtgzVzq7qo/RoSy2dz0q58YI6zv dVgTSp2/UCQNxcfkzEGLcfTutRcXXydCDhRb0QIGqBCfiR1slsdU23zHVS3WezFZtKnCs+0GneLy MHWqXXSErHXYlhdNR+1et/sZgUMTAwvBiQt2MCkAAAAAAAA= --Apple-Mail=_DA847025-C9E7-4331-A614-711A4F5F04F8-- From wmills@yahoo-inc.com Tue Jun 26 08:07: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 60DCB21F847B for ; Tue, 26 Jun 2012 08:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.541 X-Spam-Level: X-Spam-Status: No, score=-17.541 tagged_above=-999 required=5 tests=[AWL=0.057, 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 kugU1+37mCeW for ; Tue, 26 Jun 2012 08:07:12 -0700 (PDT) Received: from nm4-vm1.bullet.mail.ne1.yahoo.com (nm4-vm1.bullet.mail.ne1.yahoo.com [98.138.91.44]) by ietfa.amsl.com (Postfix) with SMTP id 4840A21F84CD for ; Tue, 26 Jun 2012 08:07:12 -0700 (PDT) Received: from [98.138.90.56] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jun 2012 15:07:09 -0000 Received: from [98.138.226.169] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jun 2012 15:07:09 -0000 Received: from [127.0.0.1] by omp1070.mail.ne1.yahoo.com with NNFMP; 26 Jun 2012 15:07:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 989969.93367.bm@omp1070.mail.ne1.yahoo.com Received: (qmail 61421 invoked by uid 60001); 26 Jun 2012 15:07:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1340723228; bh=9rTtidCkdbtonujgaTYvrDrg93FCizPN9dw9VTVi68k=; 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=qO7Or3PTt4KyThQ/4IVORf/xHOuODfoXAeB1DWN8WN8LjiyGSDQ3kWnH6WzTV0BvHbwnyx8rB66tdYulLgiHLbQJNYfT7CCd6KJsCzYi4AYEbPMUPX+2c1ny9YHie8vfFiT8p5JyaOegU7NTfx1fiD+T73gIVy9Ez2qhWhOUeLU= 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=eVfCxm3qaWAJpT91WXUhluNbhJIP4Zddlmc2eGZ4ibK59hTodri2IdXxNPvI29Sa84qN/ermXDF/jyPNP0z+Kg7LCC1b79mFB1o6J4AM0j3PMH1BY0YIaVVsk7kfwUlJzaxDic1XISx/L8rPMQjWDI1T5/dNgDhm05GI9oRiFvc=; X-YMail-OSG: _ke0QmMVM1lI.vwP7jnOcnFE0bdjqNK9S90Vn.QV8le7T9Z RHiVf5_sddfWKRuM6qd3fXx8CZgKRy0KG9VOWd8jkA7J7VOsApFAsUjE6erX FCut8KynlgnRpE1lCq9QRzDbCIWeOAsnMNJE8KDE37exMOp.J6h4INJN.mmT yxaxwLxuvADlRiqm._sLU.lchBI7RQJ6WoSnwnK9Jnn_ZqJniKJkg8UcVzcq pSRymuUHXkPLkXPHiDm9dVBOrku0PIkOgiEQfXrlwsn4XYo68hptX3.LsQN1 mm3LIQDajZBSGPjBr8LDRKHSJnobBiADQH0yAat0bOsV5dqit3gkUAeFV3e1 jSLFpAsNWGTXikaOrHuwC0L1E3ZX8zQtGh8c.rSmQc9Q7y493zIGMwzN3SFu KfSl3xA.8ldSFNQ3PocJ5FEIZrAx_NQ2gRiqgK0FyfzId26ddyy.nYg-- Received: from [209.131.62.115] by web31801.mail.mud.yahoo.com via HTTP; Tue, 26 Jun 2012 08:07:07 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-ID: <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Tue, 26 Jun 2012 08:07:07 -0700 (PDT) From: William Mills To: Mike Jones , Melvin Carvalho , "Murray S. Kucherawy" In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-368338466-1512346813-1340723227=:60315" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 15:07:13 -0000 ---368338466-1512346813-1340723227=:60315 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is there any advantage to breaking it out?=C2=A0 The WF draft depends on it= and so can't finalize until acct: does, right?=0A=0AWill one get done more= quickly than the other?=0A=0A=0A=0A=0A>________________________________=0A= > From: Mike Jones =0A>To: Melvin Carvalho ; Murray S. Kucherawy =0A>Cc: "a= pps-discuss@ietf.org" =0A>Sent: Tuesday, June 26, 2= 012 6:20 AM=0A>Subject: Re: [apps-discuss] The acct: scheme question=0A> = =0A>=0A> =0A>Yes, I believe that the acct: scheme should be considered sepa= rately from discovery, in its own document.=0A>=C2=A0=0A>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=0A>=C2=A0=0A>From:apps-discuss= -bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Melvi= n Carvalho=0A>Sent: Tuesday, June 26, 2012 5:06 AM=0A>To: Murray S. Kuchera= wy=0A>Cc: apps-discuss@ietf.org=0A>Subject: Re: [apps-discuss] The acct: sc= heme question=0A>=C2=A0=0A>=C2=A0=0A>On 22 May 2012 09:22, Murray S. Kucher= awy wrote:=0A>As we prepare to bring webfinger into app= sawg, it looks a lot like there=E2=80=99s substantial discussion just on th= e point of the proposed =E2=80=9Cacct:=E2=80=9D scheme.=0A>=C2=A0=0A>So, a = question for those tracking the discussion:=C2=A0 Is this a big enough topi= c that it should be split into its own document?=C2=A0 This would be a usef= ul thing to decide as we figure out how to handle the work once it enters w= orking group mode.=0A>=C2=A0=0A>(This by itself has me wondering if we shou= ld revisit the conversation about whether webfinger needs its own working g= roup, but I=E2=80=99ll leave it to Barry and Pete to make that call.)=0A>= =0A>There has been some discussion of this here and on other lists, and the= consensus I think is for people to follow the process at :=0A>=0A>.=0A>=0A>I think the current state of play is that webfinger c= an be used with any URI type e.g. mailto: http: acct: etc. acct: is recomme= nded in the RFC.=C2=A0 =0A>=C2=A0=0A>>-MSK=0A>>=0A>>_______________________= ________________________=0A>>apps-discuss mailing list=0A>>apps-discuss@iet= f.org=0A>>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>=C2=A0=0A>_= ______________________________________________=0A>apps-discuss mailing list= =0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/listinfo/apps-dis= cuss=0A>=0A>=0A> ---368338466-1512346813-1340723227=:60315 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Is there any advantage to breaking it out?  The WF draft depends on = it and so can't finalize until acct: does, right?

Will one get done more quickly than the other?

From: = Mike Jones <Michael.Jones@microsoft.com>
To: Melvin Carvalho <melvincarvalho@gmail.com&g= t;; Murray S. Kucherawy <msk@cloudmark.com>
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org> Sent: Tuesday, June 26,= 2012 6:20 AM
Subject:= Re: [apps-discuss] The acct: scheme question

=0A=0A=0A =0A =0A=0A=0A
=0A
=0A
Yes, I believe that the acct: = scheme should be considered separately from discovery, in its own document.=
=0A
 
=0A
  &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       -- Mike
=0A
=  
=0A
From: a= pps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]=0AOn= Behalf Of Melvin Carvalho
=0ASent: Tuesday, June 26, 2012 5:= 06 AM
=0ATo: Murray S. Kucherawy
=0ACc: apps-discuss@ie= tf.org
=0ASubject: Re: [apps-discuss] The acct: scheme question
=0A
 
=0A
  =0A
=0A
On 22 May 2012 09:22, Mur= ray S. Kucherawy <msk@cloudmark.com> wrote:
=0A
=0A
=0A
As we prepare to bring webfinger into appsawg, it looks a lot li= ke there=E2=80=99s substantial discussion just on the point of the proposed= =E2=80=9Cacct:=E2=80=9D scheme.
=0A
 
=0A
So, a question for those tracking the discussion:  Is this a big= enough topic that it should be split into its own document?  This wou= ld be a useful thing to decide as we figure=0A out how to handle the work o= nce it enters working group mode.
=0A
 
=0A
(This by itself has me wondering if we should revisit the conversatio= n about whether webfinger needs its own working group, but I=E2=80=99ll lea= ve it to Barry and Pete to make that call.)
=0A
=0A
=0A=0A
=0AThere has been some discussion of this here and on other lists, and th= e consensus I think is for people to follow the process at :
=0A
=0A&= lt;uri-review@ietf.org>.
= =0A
=0AI think the current state of play is that webfinger can be used w= ith any URI type e.g. mailto: http: acct: etc. acct: is recommended in the = RFC. =0A
=0A
=0A
=0A
=0A
=0A
 
=0A
-MSK =0A
=0A
=0A

=0A_______________________________________________=0Aapps-discuss mailing list
=0Aapps-discuss@ietf.org
=0Ahttps://www.ietf.= org/mailman/listinfo/apps-discuss
=0A
=0A
=0A  
=0A
=0A
=0A=0A
_______________________________________________
apps-discuss mail= ing list
apps-discuss@ietf.org
https://www.ietf.org/= mailman/listinfo/apps-discuss


---368338466-1512346813-1340723227=:60315-- From ve7jtb@ve7jtb.com Tue Jun 26 08:12: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 DD88621F84FC for ; Tue, 26 Jun 2012 08:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=0.191, 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 fmyCHFHhk2rC for ; Tue, 26 Jun 2012 08:12:06 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B463021F8530 for ; Tue, 26 Jun 2012 08:12:05 -0700 (PDT) Received: by ghbg16 with SMTP id g16so22421ghb.31 for ; Tue, 26 Jun 2012 08:12:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=AN/P6SJPYqGXzmGWwvMCtHzSYm6la+e/7Ba1zdHSz4o=; b=La1/VADtzzfChnctvb+35pggcQ1c+sRh3eyejWLyEr5Roebvtsd/7KoKLEhqeUm42j p4CzJWtab7dTP648sKNukWLd8N854fnj4zviDDwG3RVi1N5yDWz3woBjH64MyNAbnY7C Z/rK3REJagWgspqX+MpatQcfV8swzHM7khHbqZVy+8kCAlfU2W4iufk/w3PU0WXFGVrQ n53RO0DNZlSal6pWv2cFUankss703nyfsDrITu6lPbXmUs1fJi2XIj9kNMZw+bEy4UOo wQNB2iYHy29ckN74YSynL2Ta12Y+2TZnagY1C6irPdzNBbQ0EMcFzdbSQoKWU14jH8L+ 9Wvg== Received: by 10.236.176.129 with SMTP id b1mr17865554yhm.126.1340723525114; Tue, 26 Jun 2012 08:12:05 -0700 (PDT) Received: from [192.168.1.34] (190-20-38-238.baf.movistar.cl. [190.20.38.238]) by mx.google.com with ESMTPS id e5sm60385405ani.18.2012.06.26.08.12.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 08:12:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_2A19B1CF-AB4A-4A54-8EF7-16B4293FF264"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4FE9C9D4.5060106@stpeter.im> Date: Tue, 26 Jun 2012 11:11:48 -0400 Message-Id: <49510B16-56BF-4445-8865-4FE3CF6ED99C@ve7jtb.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE9BFF9.9060403@stpeter.im> <035988BC-A9BC-4397-8593-D5F84710ECF3@ve7jtb.com> <4FE9C9D4.5060106@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQl50719dRyjLThTRbJRAKOlsVP7aAPJ4NHnw5r3ommdcTXVd96kHh5bfCd9ddxICN6FQ909 Cc: "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 15:12:07 -0000 --Apple-Mail=_2A19B1CF-AB4A-4A54-8EF7-16B4293FF264 Content-Type: multipart/alternative; boundary="Apple-Mail=_7F947606-8A87-48C5-A5FD-55DFCF92AAE9" --Apple-Mail=_7F947606-8A87-48C5-A5FD-55DFCF92AAE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The "resource" parameter is currently a fully qualified URI, and that is = normalized to acct: The template paramater {uri} also precludes relative URI as near as I = can tell. Perhaps Paul can correct me, but I think that the request. GET /.well-known/host-meta.json?resource=3Dfoo@bar.com HTTP/1.1 Host: bar.com Is not allowed by the spec, or be interoperable. The goal of SWD was = to make the above (slightly different syntax same idea) work. There are a lot of places in the spec where the acct: uri and = normalizing things to it are baked in. There are likely also issues with host-meta as that is where the = template is defined. Paul's likely reaction will be that separating them is not trivial, and = he may be correct in that. On the other hand it is probably the right thing to do, even if it = touches a bunch of things. John B. On 2012-06-26, at 10:40 AM, Peter Saint-Andre wrote: > On 6/26/12 8:37 AM, John Bradley wrote: >=20 >> The current spec requires normalization of bare identifiers i.e. = foo@bar.com to acct:foo@bar.com. >> That would also need to change if we separate the specs. >=20 > In what way would it need to change? >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 >=20 --Apple-Mail=_7F947606-8A87-48C5-A5FD-55DFCF92AAE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = "resource" parameter is currently a fully qualified URI, and that is = normalized to acct:

The template paramater {uri} also = precludes relative URI as near as I can = tell.

Perhaps Paul can correct me,  but I = think that the request.

GET /.well-known/host-meta.json?resource=3Dfoo@bar.com =
HTTP/1.1
Host: bar.com

= Is not allowed by the spec, or be interoperable.    The goal = of SWD was to make the above (slightly different syntax same idea) = work.

There are a lot of places in the spec = where the acct: uri and normalizing things to it are baked = in.

There are likely also issues with host-meta = as that is where the template is = defined.

Paul's likely reaction will be that = separating them is not trivial, and he may be correct in = that.

On the other hand it is probably the = right thing to do, even if it touches a bunch of = things.

John B.

On = 2012-06-26, at 10:40 AM, Peter Saint-Andre wrote:

On = 6/26/12 8:37 AM, John Bradley wrote:

The = current spec requires normalization of bare identifiers i.e. foo@bar.com to = acct:foo@bar.com.
That would = also need to change if we separate the specs.

In = what way would it need to change?

Peter

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





= --Apple-Mail=_7F947606-8A87-48C5-A5FD-55DFCF92AAE9-- --Apple-Mail=_2A19B1CF-AB4A-4A54-8EF7-16B4293FF264 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy NjE1MTE0OFowIwYJKoZIhvcNAQkEMRYEFMjpI2Fi7QSkUuiKUTqv2+GodlsHMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AJymelwIpsrX+k2y295S+FJLlVGDVDFHBFvykOgcnsYhOooxZvS4ERV+JMm4Nc95yKeVTDsYlD9K ANKVim1VqVkBJunH7IJOPf6ZvkpHbwxDUhiMt1AUosl23mcE/Po1IjG7ABbS98aFzJscrY5fTKcX b0soWNr6QNjy0HkFcGEB4cr+byBtgjtZ5z1yLpUu9D4fS7hgYMTlis35vGh2lSADEmYH2oMIyNyG uZ5EFgHeqNjps+yet/gVnk8jXvEI9FsFLn5kiapG4kw5kbcjkP/7Mo+tSBnqb6eUVQZEVOUI0CJV lb+jMWzXuOYPvTCHjp27E1KLkmSLHUIJ65jKc7QAAAAAAAA= --Apple-Mail=_2A19B1CF-AB4A-4A54-8EF7-16B4293FF264-- From Michael.Jones@microsoft.com Tue Jun 26 08:18: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 4017821F85DF for ; Tue, 26 Jun 2012 08:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.827 X-Spam-Level: X-Spam-Status: No, score=-3.827 tagged_above=-999 required=5 tests=[AWL=-0.229, 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 Ve3o7Tu2Xn7T for ; Tue, 26 Jun 2012 08:18:02 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id A39B921F85AF for ; Tue, 26 Jun 2012 08:18:01 -0700 (PDT) Received: from mail112-db3-R.bigfish.com (10.3.81.253) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 15:16:19 +0000 Received: from mail112-db3 (localhost [127.0.0.1]) by mail112-db3-R.bigfish.com (Postfix) with ESMTP id 80F73C03DB; Tue, 26 Jun 2012 15:16:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz98dI9371Ic89bhc857hzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail112-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail112-db3 (localhost.localdomain [127.0.0.1]) by mail112-db3 (MessageSwitch) id 1340723776853679_6057; Tue, 26 Jun 2012 15:16:16 +0000 (UTC) Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.235]) by mail112-db3.bigfish.com (Postfix) with ESMTP id CDAF71A0048; Tue, 26 Jun 2012 15:16:16 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 15:16:15 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0298.005; Tue, 26 Jun 2012 15:17:35 +0000 From: Mike Jones To: William Mills , Melvin Carvalho , "Murray S. Kucherawy" Thread-Topic: [apps-discuss] The acct: scheme question Thread-Index: Ac0367W7uVNJxgK+Tf6qpowkmE64wgbqGMQAAAKM2jAAA8N6gAAAR9EQ Date: Tue, 26 Jun 2012 15:17:34 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> In-Reply-To: <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366568FF8TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 15:18:03 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366568FF8TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB0aGVyZeKAmXMgYSBzaWduaWZpY2FudCBhZHZhbnRhZ2UuICBJdCBhbGxvd3MgdGhlIGFj Y3Q6IHNjaGVtZSB0byBiZSBhcHByb3ZlZCAob3IgcmVqZWN0ZWQpIHF1aWNrbHkgc28gdGhhdCB3 ZSB3aWxsIGtub3cgd2hldGhlciBpdCBpcyBzYWZlIGZvciBXZWJGaW5nZXIgYW5kIG90aGVyIHNw ZWNpZmljYXRpb25zIHRvIHVzZSBpdC4gIFRoYXQgYXBwcm92YWwvcmVqZWN0aW9uIGNhbiB0aGVu IGhhcHBlbiBpbiBwYXJhbGxlbCB3aXRoIHJlZmluaW5nIHRoZSBkaXNjb3Zlcnkgc3BlY2lmaWNh dGlvbi4NCg0KT3RoZXJ3aXNlLCB3ZSBjb3VsZCBiZSBpbiBhIHBvc2l0aW9uIHdoZXJlIHdlIHRo aW5rIHdlIGhhdmUgYSBmaW5hbCBkaXNjb3Zlcnkgc3BlY2lmaWNhdGlvbiwgb25seSB0byBsZWFy biB0aGF0IGl0IGNhbuKAmXQgZ28gZm9yd2FyZCBiZWNhdXNlIG9mIG9iamVjdGlvbnMgdG8gdGhl IGFjY3Q6IHNjaGVtZSBmcm9tIHRoZSBXM0MgYW5kIHBvc3NpYmx5IG90aGVycy4gIEl0IHdvdWxk IGJlIG11Y2ggYmV0dGVyIGZvciB1cyB0byBrbm93IHdoZXRoZXIgdGhhdCBpcyB0aGUgY2FzZSB1 cCBmcm9udC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBXaWxsaWFtIE1pbGxzIFttYWlsdG86d21p bGxzQHlhaG9vLWluYy5jb21dDQpTZW50OiBUdWVzZGF5LCBKdW5lIDI2LCAyMDEyIDg6MDcgQU0N ClRvOiBNaWtlIEpvbmVzOyBNZWx2aW4gQ2FydmFsaG87IE11cnJheSBTLiBLdWNoZXJhd3kNCkNj OiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBUaGUg YWNjdDogc2NoZW1lIHF1ZXN0aW9uDQoNCklzIHRoZXJlIGFueSBhZHZhbnRhZ2UgdG8gYnJlYWtp bmcgaXQgb3V0PyAgVGhlIFdGIGRyYWZ0IGRlcGVuZHMgb24gaXQgYW5kIHNvIGNhbid0IGZpbmFs aXplIHVudGlsIGFjY3Q6IGRvZXMsIHJpZ2h0Pw0KDQpXaWxsIG9uZSBnZXQgZG9uZSBtb3JlIHF1 aWNrbHkgdGhhbiB0aGUgb3RoZXI/DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpGcm9tOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQpUbzogTWVsdmluIENhcnZhbGhvIDxtZWx2aW5j YXJ2YWxob0BnbWFpbC5jb208bWFpbHRvOm1lbHZpbmNhcnZhbGhvQGdtYWlsLmNvbT4+OyBNdXJy YXkgUy4gS3VjaGVyYXd5IDxtc2tAY2xvdWRtYXJrLmNvbTxtYWlsdG86bXNrQGNsb3VkbWFyay5j b20+Pg0KQ2M6ICJhcHBzLWRpc2N1c3NAaWV0Zi5vcmc8bWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRm Lm9yZz4iIDxhcHBzLWRpc2N1c3NAaWV0Zi5vcmc8bWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9y Zz4+DQpTZW50OiBUdWVzZGF5LCBKdW5lIDI2LCAyMDEyIDY6MjAgQU0NClN1YmplY3Q6IFJlOiBb YXBwcy1kaXNjdXNzXSBUaGUgYWNjdDogc2NoZW1lIHF1ZXN0aW9uDQoNClllcywgSSBiZWxpZXZl IHRoYXQgdGhlIGFjY3Q6IHNjaGVtZSBzaG91bGQgYmUgY29uc2lkZXJlZCBzZXBhcmF0ZWx5IGZy b20gZGlzY292ZXJ5LCBpbiBpdHMgb3duIGRvY3VtZW50Lg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206 IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNl c0BpZXRmLm9yZz4gW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRv OlttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgTWVs dmluIENhcnZhbGhvDQpTZW50OiBUdWVzZGF5LCBKdW5lIDI2LCAyMDEyIDU6MDYgQU0NClRvOiBN dXJyYXkgUy4gS3VjaGVyYXd5DQpDYzogYXBwcy1kaXNjdXNzQGlldGYub3JnPG1haWx0bzphcHBz LWRpc2N1c3NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gVGhlIGFjY3Q6 IHNjaGVtZSBxdWVzdGlvbg0KDQoNCk9uIDIyIE1heSAyMDEyIDA5OjIyLCBNdXJyYXkgUy4gS3Vj aGVyYXd5IDxtc2tAY2xvdWRtYXJrLmNvbTxtYWlsdG86bXNrQGNsb3VkbWFyay5jb20+PiB3cm90 ZToNCkFzIHdlIHByZXBhcmUgdG8gYnJpbmcgd2ViZmluZ2VyIGludG8gYXBwc2F3ZywgaXQgbG9v a3MgYSBsb3QgbGlrZSB0aGVyZeKAmXMgc3Vic3RhbnRpYWwgZGlzY3Vzc2lvbiBqdXN0IG9uIHRo ZSBwb2ludCBvZiB0aGUgcHJvcG9zZWQg4oCcYWNjdDrigJ0gc2NoZW1lLg0KDQpTbywgYSBxdWVz dGlvbiBmb3IgdGhvc2UgdHJhY2tpbmcgdGhlIGRpc2N1c3Npb246ICBJcyB0aGlzIGEgYmlnIGVu b3VnaCB0b3BpYyB0aGF0IGl0IHNob3VsZCBiZSBzcGxpdCBpbnRvIGl0cyBvd24gZG9jdW1lbnQ/ ICBUaGlzIHdvdWxkIGJlIGEgdXNlZnVsIHRoaW5nIHRvIGRlY2lkZSBhcyB3ZSBmaWd1cmUgb3V0 IGhvdyB0byBoYW5kbGUgdGhlIHdvcmsgb25jZSBpdCBlbnRlcnMgd29ya2luZyBncm91cCBtb2Rl Lg0KDQooVGhpcyBieSBpdHNlbGYgaGFzIG1lIHdvbmRlcmluZyBpZiB3ZSBzaG91bGQgcmV2aXNp dCB0aGUgY29udmVyc2F0aW9uIGFib3V0IHdoZXRoZXIgd2ViZmluZ2VyIG5lZWRzIGl0cyBvd24g d29ya2luZyBncm91cCwgYnV0IEnigJlsbCBsZWF2ZSBpdCB0byBCYXJyeSBhbmQgUGV0ZSB0byBt YWtlIHRoYXQgY2FsbC4pDQoNClRoZXJlIGhhcyBiZWVuIHNvbWUgZGlzY3Vzc2lvbiBvZiB0aGlz IGhlcmUgYW5kIG9uIG90aGVyIGxpc3RzLCBhbmQgdGhlIGNvbnNlbnN1cyBJIHRoaW5rIGlzIGZv ciBwZW9wbGUgdG8gZm9sbG93IHRoZSBwcm9jZXNzIGF0IDoNCg0KPHVyaS1yZXZpZXdAaWV0Zi5v cmc8bWFpbHRvOnVyaS1yZXZpZXdAaWV0Zi5vcmc+Pi4NCg0KSSB0aGluayB0aGUgY3VycmVudCBz dGF0ZSBvZiBwbGF5IGlzIHRoYXQgd2ViZmluZ2VyIGNhbiBiZSB1c2VkIHdpdGggYW55IFVSSSB0 eXBlIGUuZy4gbWFpbHRvOiBodHRwOiBhY2N0OiBldGMuIGFjY3Q6IGlzIHJlY29tbWVuZGVkIGlu IHRoZSBSRkMuDQoNCi1NU0sNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCmFwcHMtZGlzY3Vzc0BpZXRm Lm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdA0KYXBw cy1kaXNjdXNzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0KDQo= --_000_4E1F6AAD24975D4BA5B168042967394366568FF8TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLnlpdjk3MTE2MDQ1NG1zb25vcm1hbCwgbGkueWl2 OTcxMTYwNDU0bXNvbm9ybWFsLCBkaXYueWl2OTcxMTYwNDU0bXNvbm9ybWFsDQoJe21zby1zdHls ZS1uYW1lOnlpdjk3MTE2MDQ1NG1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KcC55aXY5NzExNjA0NTRtc29jaHBkZWZhdWx0LCBsaS55aXY5NzEx NjA0NTRtc29jaHBkZWZhdWx0LCBkaXYueWl2OTcxMTYwNDU0bXNvY2hwZGVmYXVsdA0KCXttc28t c3R5bGUtbmFtZTp5aXY5NzExNjA0NTRtc29jaHBkZWZhdWx0Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLnlpdjk3MTE2MDQ1NG1zb2h5cGVybGluaw0K CXttc28tc3R5bGUtbmFtZTp5aXY5NzExNjA0NTRtc29oeXBlcmxpbms7fQ0Kc3Bhbi55aXY5NzEx NjA0NTRtc29oeXBlcmxpbmtmb2xsb3dlZA0KCXttc28tc3R5bGUtbmFtZTp5aXY5NzExNjA0NTRt c29oeXBlcmxpbmtmb2xsb3dlZDt9DQpzcGFuLnlpdjk3MTE2MDQ1NGVtYWlsc3R5bGUxOA0KCXtt c28tc3R5bGUtbmFtZTp5aXY5NzExNjA0NTRlbWFpbHN0eWxlMTg7fQ0KcC55aXY5NzExNjA0NTRt c29ub3JtYWwxLCBsaS55aXY5NzExNjA0NTRtc29ub3JtYWwxLCBkaXYueWl2OTcxMTYwNDU0bXNv bm9ybWFsMQ0KCXttc28tc3R5bGUtbmFtZTp5aXY5NzExNjA0NTRtc29ub3JtYWwxOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLnlpdjk3MTE2MDQ1NG1z b2h5cGVybGluazENCgl7bXNvLXN0eWxlLW5hbWU6eWl2OTcxMTYwNDU0bXNvaHlwZXJsaW5rMTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi55aXY5NzEx NjA0NTRtc29oeXBlcmxpbmtmb2xsb3dlZDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2OTcxMTYwNDU0 bXNvaHlwZXJsaW5rZm9sbG93ZWQxOw0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4ueWl2OTcxMTYwNDU0ZW1haWxzdHlsZTE4MQ0KCXttc28tc3R5bGUt bmFtZTp5aXY5NzExNjA0NTRlbWFpbHN0eWxlMTgxOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KcC55aXY5NzExNjA0NTRtc29jaHBkZWZhdWx0 MSwgbGkueWl2OTcxMTYwNDU0bXNvY2hwZGVmYXVsdDEsIGRpdi55aXY5NzExNjA0NTRtc29jaHBk ZWZhdWx0MQ0KCXttc28tc3R5bGUtbmFtZTp5aXY5NzExNjA0NTRtc29jaHBkZWZhdWx0MTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTI3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5ZZXMsIHRoZXJl4oCZcyBhIHNpZ25pZmljYW50IGFkdmFudGFnZS4mbmJz cDsgSXQgYWxsb3dzIHRoZSBhY2N0OiBzY2hlbWUgdG8gYmUgYXBwcm92ZWQgKG9yIHJlamVjdGVk KSBxdWlja2x5IHNvIHRoYXQgd2Ugd2lsbCBrbm93IHdoZXRoZXIgaXQgaXMgc2FmZSBmb3IgV2Vi RmluZ2VyDQogYW5kIG90aGVyIHNwZWNpZmljYXRpb25zIHRvIHVzZSBpdC4mbmJzcDsgVGhhdCBh cHByb3ZhbC9yZWplY3Rpb24gY2FuIHRoZW4gaGFwcGVuIGluIHBhcmFsbGVsIHdpdGggcmVmaW5p bmcgdGhlIGRpc2NvdmVyeSBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3RoZXJ3aXNlLCB3ZSBj b3VsZCBiZSBpbiBhIHBvc2l0aW9uIHdoZXJlIHdlIHRoaW5rIHdlIGhhdmUgYSBmaW5hbCBkaXNj b3Zlcnkgc3BlY2lmaWNhdGlvbiwgb25seSB0byBsZWFybiB0aGF0IGl0IGNhbuKAmXQgZ28gZm9y d2FyZCBiZWNhdXNlIG9mIG9iamVjdGlvbnMgdG8NCiB0aGUgYWNjdDogc2NoZW1lIGZyb20gdGhl IFczQyBhbmQgcG9zc2libHkgb3RoZXJzLiZuYnNwOyBJdCB3b3VsZCBiZSBtdWNoIGJldHRlciBm b3IgdXMgdG8ga25vdyB3aGV0aGVyIHRoYXQgaXMgdGhlIGNhc2UgdXAgZnJvbnQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFdpbGxpYW0gTWlsbHMg W21haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5 LCBKdW5lIDI2LCAyMDEyIDg6MDcgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM7IE1lbHZp biBDYXJ2YWxobzsgTXVycmF5IFMuIEt1Y2hlcmF3eTxicj4NCjxiPkNjOjwvYj4gYXBwcy1kaXNj dXNzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbYXBwcy1kaXNjdXNzXSBUaGUg YWNjdDogc2NoZW1lIHF1ZXN0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPklzIHRoZXJlIGFueSBhZHZhbnRhZ2UgdG8gYnJlYWtpbmcgaXQgb3V0 PyZuYnNwOyBUaGUgV0YgZHJhZnQgZGVwZW5kcyBvbiBpdCBhbmQgc28gY2FuJ3QgZmluYWxpemUg dW50aWwgYWNjdDogZG9lcywgcmlnaHQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPldpbGwgb25lIGdldCBkb25lIG1vcmUgcXVpY2tseSB0aGFuIHRoZSBv dGhlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzEwMTBGRiAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjMuNzVwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i Y2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIxIiB3aWR0aD0i MTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxi PlRvOjwvYj4gTWVsdmluIENhcnZhbGhvICZsdDs8YSBocmVmPSJtYWlsdG86bWVsdmluY2FydmFs aG9AZ21haWwuY29tIj5tZWx2aW5jYXJ2YWxob0BnbWFpbC5jb208L2E+Jmd0OzsgTXVycmF5IFMu IEt1Y2hlcmF3eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1za0BjbG91ZG1hcmsuY29tIj5tc2tAY2xv dWRtYXJrLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj5DYzo8L2I+ICZxdW90OzxhIGhyZWY9Im1haWx0 bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmciPmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmciPmFwcHMtZGlzY3Vzc0Bp ZXRmLm9yZzwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAyNiwgMjAx MiA2OjIwIEFNPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbYXBwcy1kaXNjdXNzXSBUaGUgYWNj dDogc2NoZW1lIHF1ZXN0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJ5aXY5NzExNjA0NTQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlllcywgSSBiZWxpZXZlIHRoYXQg dGhlIGFjY3Q6IHNjaGVtZSBzaG91bGQgYmUgY29uc2lkZXJlZCBzZXBhcmF0ZWx5IGZyb20gZGlz Y292ZXJ5LCBpbiBpdHMgb3duIGRvY3VtZW50Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPg0KPGEgaHJlZj0ibWFpbHRvOmFwcHMtZGlz Y3Vzcy1ib3VuY2VzQGlldGYub3JnIj5hcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzwvYT4g PGEgaHJlZj0ibWFpbHRvOlttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIj4N ClttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddPC9hPiA8Yj5PbiBCZWhhbGYg T2YgPC9iPk1lbHZpbiBDYXJ2YWxobzxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDI2 LCAyMDEyIDU6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+IE11cnJheSBTLiBLdWNoZXJhd3k8YnI+DQo8 Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmciPmFwcHMtZGlz Y3Vzc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFthcHBzLWRpc2N1c3Nd IFRoZSBhY2N0OiBzY2hlbWUgcXVlc3Rpb248L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5PbiAyMiBNYXkgMjAxMiAw OToyMiwgTXVycmF5IFMuIEt1Y2hlcmF3eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1za0BjbG91ZG1h cmsuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXNrQGNsb3VkbWFyay5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPkFzIHdlIHByZXBhcmUgdG8gYnJpbmcgd2ViZmluZ2VyIGludG8gYXBwc2F3Zywg aXQgbG9va3MgYSBsb3QgbGlrZSB0aGVyZeKAmXMgc3Vic3RhbnRpYWwgZGlzY3Vzc2lvbiBqdXN0 IG9uIHRoZSBwb2ludCBvZiB0aGUgcHJvcG9zZWQg4oCcYWNjdDrigJ0gc2NoZW1lLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNvLCBhIHF1 ZXN0aW9uIGZvciB0aG9zZSB0cmFja2luZyB0aGUgZGlzY3Vzc2lvbjombmJzcDsgSXMgdGhpcyBh IGJpZyBlbm91Z2ggdG9waWMgdGhhdCBpdCBzaG91bGQgYmUgc3BsaXQgaW50byBpdHMgb3duIGRv Y3VtZW50PyZuYnNwOyBUaGlzIHdvdWxkIGJlIGEgdXNlZnVsIHRoaW5nIHRvIGRlY2lkZSBhcyB3 ZSBmaWd1cmUgb3V0IGhvdw0KIHRvIGhhbmRsZSB0aGUgd29yayBvbmNlIGl0IGVudGVycyB3b3Jr aW5nIGdyb3VwIG1vZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+KFRoaXMgYnkgaXRzZWxmIGhhcyBtZSB3b25kZXJpbmcgaWYgd2Ugc2hv dWxkIHJldmlzaXQgdGhlIGNvbnZlcnNhdGlvbiBhYm91dCB3aGV0aGVyIHdlYmZpbmdlciBuZWVk cyBpdHMgb3duIHdvcmtpbmcgZ3JvdXAsIGJ1dCBJ4oCZbGwgbGVhdmUgaXQgdG8gQmFycnkgYW5k IFBldGUgdG8gbWFrZSB0aGF0IGNhbGwuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48YnI+DQpUaGVyZSBoYXMgYmVlbiBzb21lIGRpc2N1c3Npb24gb2Yg dGhpcyBoZXJlIGFuZCBvbiBvdGhlciBsaXN0cywgYW5kIHRoZSBjb25zZW5zdXMgSSB0aGluayBp cyBmb3IgcGVvcGxlIHRvIGZvbGxvdyB0aGUgcHJvY2VzcyBhdCA6PGJyPg0KPGJyPg0KJmx0Ozxh IGhyZWY9Im1haWx0bzp1cmktcmV2aWV3QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dXJpLXJl dmlld0BpZXRmLm9yZzwvYT4mZ3Q7Ljxicj4NCjxicj4NCkkgdGhpbmsgdGhlIGN1cnJlbnQgc3Rh dGUgb2YgcGxheSBpcyB0aGF0IHdlYmZpbmdlciBjYW4gYmUgdXNlZCB3aXRoIGFueSBVUkkgdHlw ZSBlLmcuIG1haWx0bzogaHR0cDogYWNjdDogZXRjLiBhY2N0OiBpcyByZWNvbW1lbmRlZCBpbiB0 aGUgUkZDLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9y OiM4ODg4ODgiPi1NU0s8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+YXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3M8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzphcHBzLWRp c2N1c3NAaWV0Zi5vcmciPmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3VzcyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNj dXNzPC9hPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_4E1F6AAD24975D4BA5B168042967394366568FF8TK5EX14MBXC283r_-- From ht@inf.ed.ac.uk Tue Jun 26 08:52: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 9D00B21F8592 for ; Tue, 26 Jun 2012 08:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUZ-Tz-A8eEV for ; Tue, 26 Jun 2012 08:52:13 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3F84C21F857D for ; Tue, 26 Jun 2012 08:52:12 -0700 (PDT) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q5QFpcW5009458; Tue, 26 Jun 2012 16:51:38 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q5QFpbDE028072; Tue, 26 Jun 2012 16:51:37 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q5QFpbhZ021806; Tue, 26 Jun 2012 16:51:37 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q5QFpa3P021802; Tue, 26 Jun 2012 16:51:36 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Mike Jones References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 26 Jun 2012 16:51:36 +0100 In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> (Mike Jones's message of "Tue, 26 Jun 2012 13:20:16 +0000") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 15:52:14 -0000 Mike Jones writes: > Yes, I believe that the acct: scheme should be considered separately > from discovery, in its own document. Yes, please. Discussion on uri-review@ietf.org will be much more focussed and appropriate given a specific self-contained uri-scheme proposal to consider. I for one have been standing back from this discussion lately because I can no longer tell exactly what is part of the acct: scheme and what isn't -- a separate document will, I hope, clarify that. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From andy@hxr.us Tue Jun 26 11:54: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 5970E21F84FF for ; Tue, 26 Jun 2012 11:54:27 -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 xUq3mBZBOyt2 for ; Tue, 26 Jun 2012 11:54:26 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id BD92221F84FE for ; Tue, 26 Jun 2012 11:54:26 -0700 (PDT) Received: by qcmt36 with SMTP id t36so138282qcm.15 for ; Tue, 26 Jun 2012 11:54:26 -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:subject:date:message-id :to:mime-version:x-mailer:x-gm-message-state; bh=mDmAXpey+5IQwBh4QVqxwf957PGPpUtIQiCsg7n2KDA=; b=a/8C9awxw9XNARHjkyNIJbaxwQe4VH2lx1bKjkhFhYxmVgzPLhMfiZc5AUf9yljoqX bokZmTVt/p4TRs9NpG09gzw27VIOOZT6fZRc8+2A5oGAYZHRfX+oJsT6VLPUZDDLLE/m e+2tzS8iIKeBAS9inq4Ff4orDLZw/vbg1DGPu2VyN/zhT4IFk3VS1UoAzadHR3qwB01Y WUTZsi83uWsmR/m3ah9HNcp2XZENryn4NTv7aFzwO4x195eu7BE61Lv/EVFYQMFAXjT8 Rqrc7BDmDAtpMYYXeVuJ3e+QqXFgu7EJfBfgwJMP/WIRCKTqAyfwGcZaRN+MLHF8vmu/ ZqZA== Received: by 10.224.32.7 with SMTP id a7mr26867197qad.23.1340736866224; Tue, 26 Jun 2012 11:54:26 -0700 (PDT) Received: from andytop.arin.net (core.arin.net. [192.149.252.11]) by mx.google.com with ESMTPS id j12sm19123563qak.15.2012.06.26.11.54.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 11:54:25 -0700 (PDT) From: Andy Newton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jun 2012 14:54:23 -0400 Message-Id: <4AB1590B-710F-4EF2-B1B5-A1BA7A877BBE@hxr.us> To: apps-discuss@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkjmI+VhBY/oWBGOw8kYt14ki3Yjb9UpxCjKKzmk9mndeoTOQ+cPxu788ynAMI1U5Zn2DG0 Subject: [apps-discuss] URNBIS needs your eyeballs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jun 2012 18:54:27 -0000 All, As you know, for years the IETF has suffered with topics that are too = exhilarating and highly exciting. With the URNBIS working group we had = top IETF scientists don their white lab coats and fill beakers with = bubbling fluids to moderate this otherwise explosive subject matter, = however we may have solved this problem "too much". Seriously, the URNBIS work is in need of greater participation from a = wider audience. The group is currently weighing revisions to RFC 2141 = (URN syntax and namespace subdivision rules, = draft-ietf-urnbis-rfc2141bis-urn-02) and RFC 3406 (URN namespace = registration procedures, draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02). = Presently the low number of participants of the working group make = judging consensus precarious. So if you have a few moments, your review of these drafts and the URNBIS = work in general would be much appreciated. Otherwise, I'm told, IETF = executives are considering selling URNBIS to a pharmaceutical outfit = wishing to market sedative hypnotics. -andy (co-chair, URNBIS) Links: https://www.ietf.org/mailman/listinfo/urn http://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ http://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc3406bis-urn-ns-reg/= From wmills@yahoo-inc.com Tue Jun 26 13:06:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA03121F85FF for ; Tue, 26 Jun 2012 13:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.543 X-Spam-Level: X-Spam-Status: No, score=-17.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 DyZ2C36T-U2A for ; Tue, 26 Jun 2012 13:06:43 -0700 (PDT) Received: from nm35-vm7.bullet.mail.ne1.yahoo.com (nm35-vm7.bullet.mail.ne1.yahoo.com [98.138.229.103]) by ietfa.amsl.com (Postfix) with SMTP id DB64221F85F7 for ; Tue, 26 Jun 2012 13:06:42 -0700 (PDT) Received: from [98.138.90.53] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jun 2012 20:06:42 -0000 Received: from [98.138.87.7] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 26 Jun 2012 20:06:42 -0000 Received: from [127.0.0.1] by omp1007.mail.ne1.yahoo.com with NNFMP; 26 Jun 2012 20:06:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 456643.58996.bm@omp1007.mail.ne1.yahoo.com Received: (qmail 37753 invoked by uid 60001); 26 Jun 2012 20:06:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1340741202; bh=Oz40qb/AM/NJVRL6T6aRgk5Mt8AcrDwcPa8hPBx8SGU=; 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=TTMUWgxvXroiAy+xjzLV7QYj+XyyFMqRSi8+QkYXfq0dc6j7sbDW+1OWcib/FuffkaZ2DlTftvbd14CWMjv1MnqwKwO5m2XId+CgG5IRkKbTcABqqI12imFiCY4CAPJRQm3fFxdg4j4u+lXaKAhIjptXyzJ6SzXD1BV1meb1f9g= 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=kDld0sL9B9dGMSsHyy7gGGGhx/oBayaLN/74NkU+Bb9KonqBcSIaKv7yusnlE64xxqL8rODOny5LbSUZTADhcoS421f3Fy3pHEkE9pzZ7DVaqmSYu8U7WuXsPkLqsObgD7gfjDjN87RoR4WqpIbPcf0Z7C9P6cC1Sjxuqvre9Ig=; X-YMail-OSG: rhS8zxYVM1lw9Q4uwL0QMwthqIMNLtPuCJh0OJt0ezHtSnK D1GzOBGV0u.wcFwflTUVL593OEEvcl77RHFBT01pUT.vGNZYXpsV557xB1Fh 26qUElmkZ8XU9r2Zd9nG8fuxgB7luBrJAH4V7QUm0aP57m32PMyY9Xt6glYO fxFDCaMoZ66vF8Mh05ecEHEaSZW7BJqzJzNF_pmGaaiwcXGw2gufYg6iifph 3AxoAXvdvNd7vb0_CKFkb9g68UwGcJg4p6GhIbcG4NIZVbW8aYBQRj9ouymt HLIO5NJY8flYCEv0aBK5AEBz2BZUOwtCTX6H9PjAQqUGUKWChykJtghGAac6 JfEhDLO8tklXSkuQmEiaVm6o.cO4m9llUh8G4NBBc_vzI546qDPFxsvDTIs_ 5Q1VK_HkRBOrlllBmOqkFRLzGDLzdVH3w7IkbR5BiqMbeE6JR_w0- Received: from [209.131.62.120] by web31810.mail.mud.yahoo.com via HTTP; Tue, 26 Jun 2012 13:06:41 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-ID: <1340741201.99354.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Tue, 26 Jun 2012 13:06:41 -0700 (PDT) From: William Mills To: "Henry S. Thompson" , Mike Jones In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 20:06:43 -0000 =0A=0AI note that Paul's message there dated June 15th has generated no tra= ffic in reply yet.=0A=0A=0A=0A>________________________________=0A> From: H= enry S. Thompson =0A>To: Mike Jones =0A>Cc: "apps-discuss@ietf.org" ; Murray S. = Kucherawy =0A>Sent: Tuesday, June 26, 2012 8:51 AM=0A>S= ubject: Re: [apps-discuss] The acct: scheme question=0A> =0A>Mike Jones wri= tes:=0A>=0A>> Yes, I believe that the acct: scheme should be considered sep= arately=0A>> from discovery, in its own document.=0A>=0A>Yes, please.=A0 Di= scussion on uri-review@ietf.org will be much more=0A>focussed and appropria= te given a specific self-contained uri-scheme=0A>proposal to consider.=A0 I= for one have been standing back from this=0A>discussion lately because I c= an no longer tell exactly what is part of=0A>the acct: scheme and what isn'= t -- a separate document will, I hope,=0A>clarify that.=0A>=0A>ht=0A>-- =0A= >=A0 =A0 =A0=A0=A0Henry S. Thompson, School of Informatics, University of E= dinburgh=0A>=A0 =A0 =A0 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- = (44) 131 650-4440=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: (44) 131 650-4587= , e-mail: ht@inf.ed.ac.uk=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0= =A0URL: http://www.ltg.ed.ac.uk/~ht/=0A>[mail from me _always_ has a .sig l= ike this -- mail without it is forged spam]=0A>____________________________= ___________________=0A>apps-discuss mailing list=0A>apps-discuss@ietf.org= =0A>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>=0A>=0A> From duerst@it.aoyama.ac.jp Tue Jun 26 18:48: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 1A80711E8104 for ; Tue, 26 Jun 2012 18:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.617 X-Spam-Level: X-Spam-Status: No, score=-99.617 tagged_above=-999 required=5 tests=[AWL=0.173, 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 VyLQp97r+Tm4 for ; Tue, 26 Jun 2012 18:48:52 -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 2ADFE11E8103 for ; Tue, 26 Jun 2012 18:48:51 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q5R1mesD032287 for ; Wed, 27 Jun 2012 10:48:41 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 192c_8003_386f489a_bffa_11e1_bfaf_001d096c5782; Wed, 27 Jun 2012 10:48:39 +0900 Received: from [IPv6:::1] ([133.2.210.1]:36072) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 27 Jun 2012 10:48:45 +0900 Message-ID: <4FEA6677.3020705@it.aoyama.ac.jp> Date: Wed, 27 Jun 2012 10:48:39 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Melvin Carvalho References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 01:48:53 -0000 On 2012/06/26 21:06, Melvin Carvalho wrote: > On 22 May 2012 09:22, Murray S. Kucherawy wrote: > >> As we prepare to bring webfinger into appsawg, it looks a lot like >> there’s substantial discussion just on the point of the proposed “acct:” >> scheme.**** >> >> ** ** >> >> So, a question for those tracking the discussion: Is this a big enough >> topic that it should be split into its own document? This would be a >> useful thing to decide as we figure out how to handle the work once it >> enters working group mode.**** Others have pointed out that it's only a page or two. In my opinion, that would strongly suggest a single document. > There has been some discussion of this here and on other lists, and the > consensus I think is for people to follow the process at : > > . Warning: procedural nitpicking ahead! I think we should be careful about this. uri-review@ietf.org is for review of URI/IRI schemes in general. This has a rather low barrier. The fact that it gets approved there doesn't mean that it will pass through the IETF standardization process. On the other hand, if the IETF standardizes it, it has the possibility of overriding the decision on uri-review@ietf.org if that should be necessary. I'm just mentioning this here because we have been through this for another URI scheme. So I think the correct use of mailing lists would be: apps-discuss@ietf.org: (or a dedicated WG if that gets created) General discussion of scheme, working towards IETF standardization. uri-review@ietf.org: Comments from URI/IRI experts, check of basic criteria for registrability, ... public-iri@w3.org (the mailing list of the IETF IRI WG): General discussion about registration criteria for new IRI schemes, for RFC 4395bis. tag@w3.org (I'm just mentioning this list because that's where the most discussion so far has taken place): General discussion as it relates to Web architecture. Regards, Martin. From mnot@mnot.net Tue Jun 26 19:22: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 528CA11E80FD for ; Tue, 26 Jun 2012 19:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=-3.567, 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 X0sM1IKJV6GL for ; Tue, 26 Jun 2012 19:22:21 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 831D911E80EF for ; Tue, 26 Jun 2012 19:22:21 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AA98222DD6D for ; Tue, 26 Jun 2012 22:22:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Mark Nottingham In-Reply-To: <01173171-110F-4FBE-993A-E858B51E9068@mnot.net> Date: Wed, 27 Jun 2012 12:22:11 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1278) 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, 27 Jun 2012 02:22:22 -0000 I've tried to address this (taking into account subsequent discussion) = with: http://trac.tools.ietf.org/wg/appsawg/trac/changeset/67 Cheers, On 31/05/2012, at 1:45 PM, Mark Nottingham wrote: >=20 > On 03/03/2012, at 9:47 AM, Murray S. Kucherawy wrote: >=20 >>> -----Original Message----- >>> From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mike Acar >>> Sent: Friday, March 02, 2012 2:35 PM >>> To: apps-discuss@ietf.org >>> Subject: Re: [apps-discuss] Feedback on = draft-ietf-appsawg-json-pointer-00 >>>=20 >>>>> It's easy to imagine a case where a Pointer refers to a deep >>>>> hierarchy, e.g. /a/b/c/d, and the application semantics of = following >>>>> it are to create automatically any non-existent intermediate = objects. >>>>>=20 >>>>> My initial thought was that the Pointer RFC should explicitly say >>>>> that specs which use it (e.g. Patch) should define semantics for >>>>> ambiguous cases (non-unique or non-existent member names, array = index >>>>> out of bounds, etc). >>>=20 >>> There is another case: What to do if a non-terminal reference token >>> names a value which is not a structured type; e.g. >>>=20 >>> { "a" : "b" } >>>=20 >>> How should you interpret "/a/c/d"? For Patch this should be an = error, >>> but another application might promote the value of "a" from a string = to >>> an object or array. If the Pointer RFC says this MAY be an error, it >>> disallows those semantics. >>=20 >> I don't agree that MAY disallows anything, but I do think the current = expression is too mushy. >>=20 >> I think it's fine for the pointer document to say that the handling = of such cases is application-specific, but it should actually say that, = perhaps by using your two examples to illustrate how different = applications using the pointer specification could behave. >=20 >=20 > This is . >=20 > 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? >=20 > That said, personally I think of JSON-Pointer as a way to find a node = in a current document, *not* a way to manipulate that document, and I'm = not sure overloading its semantics are a good thing. >=20 > Cheers, >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Jun 26 19:25: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 DB17F11E8106 for ; Tue, 26 Jun 2012 19:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.108 X-Spam-Level: X-Spam-Status: No, score=-106.108 tagged_above=-999 required=5 tests=[AWL=-3.509, 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 p3xtmOjiAQ11 for ; Tue, 26 Jun 2012 19:25:16 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3E62B11E80EF for ; Tue, 26 Jun 2012 19:25:16 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3C57D22E253; Tue, 26 Jun 2012 22:25:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F4FC0BE7@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 27 Jun 2012 12:25:06 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <2C0CE224-A63F-4500-BDB9-DF8A5C1761E5@mnot.net> References: <52C872CB-7A7F-4C01-8B6E-2857093F94F3@mnot.net> <1338372624.2412.1.camel@hoboken> <9DF51172-2789-467F-8AEF-B6B57D333B42@mnot.net> <255B9BB34FB7D647A506DC292726F6E114F4FC0B37@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F4FC0BE7@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss Subject: Re: [apps-discuss] #1: json-pointer internationalisation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2012 02:25:17 -0000 On 31/05/2012, at 12:58 PM, Manger, James H wrote: >=20 > How about changing > "=85the object member with the name identified by the reference = token" > To > "=85the object member with the name (after unescaping any backslash = escape sequences that can occur in a JSON string) identified by the = reference token" Applied with . -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Jun 26 19:32: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 8214511E8104 for ; Tue, 26 Jun 2012 19:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.053 X-Spam-Level: X-Spam-Status: No, score=-106.053 tagged_above=-999 required=5 tests=[AWL=-3.454, 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 3iNS7M7S3Xkp for ; Tue, 26 Jun 2012 19:32:55 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8114711E80FD for ; Tue, 26 Jun 2012 19:32:55 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4DAE522E257; Tue, 26 Jun 2012 22:32:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <1334247691.2570.8.camel@neutron> Date: Wed, 27 Jun 2012 12:32:50 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F86F5E9.1040202@gmx.de> <1334247691.2570.8.camel@neutron> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1278) Cc: "Julian F. Reschke" Subject: [apps-discuss] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 02:32:56 -0000 This is . The current draft uses ^, and Paul explains why the draft chose that = over %-encoding. I haven't seen any response to Paul's message. Julian (and Joe, who also = supported this), are you OK with leaving it as-is? Regards, On 13/04/2012, at 2:21 AM, Paul C. Bryan wrote: > This takes us back to a previous version of JSON Pointer, which in = fact did use URI escaping of %2F to distinguish between the '/' token = delimiter and a '/' character within a token. IIRC, the objections that = lead us to change were: >=20 > 1. It requires URI decoding logic in non-URI-processing code (e.g. = when pointers are used in JSON strings rather than in URI fragment = identifiers). This has always been a somewhat weak argument, IMO. >=20 > 2. Some URI parsers normalize the URI (i.e. expand %2F into '/') = before any JSON Pointer parsing code can get a chance to see it. >=20 > In response to this, I went down the path of using a single escape = character. If we can overcome these objections, I'd be happy to = entertain returning to URI escaping. >=20 > Paul >=20 > On Thu, 2012-04-12 at 17:34 +0200, Julian Reschke wrote: >> Hi there, >>=20 >> right now, the draft escapes forward slashes in reference tokens = using=20 >> ^-escapes, that is: >>=20 >> a/b >>=20 >> becomes >>=20 >> a^/b >>=20 >> and >>=20 >> a^b >>=20 >> becomes >>=20 >> a^^b >>=20 >> (Reminder: previously "\" was used, but it results in ugly double=20 >> escaping when the pointer occurs in a JSON string). >>=20 >> A drawback of this scheme is that when the pointer is used inside a = URI,=20 >> such as the path component of a an HTTP URI, the / still needs to be=20= >> escaped, so the name >>=20 >> a/b >>=20 >> becomes the pointer >>=20 >> a^/b >>=20 >> and would end up as >>=20 >> a%5e%2fb >>=20 >> in the URI. >>=20 >>=20 >> An alternate proposal I heard during the IETF meeting in Paris was to=20= >> simply apply URI percent escaping to the characters in the URI=20 >> gen-delims range: >>=20 >> gen-delims =3D ":" / "/" / "?" / "#" / "[" / "]" / "@" >>=20 >> so >>=20 >> a/b >>=20 >> would simply become >>=20 >> a%2fb >>=20 >> and wouldn't need any further escaping in a URI path component. >>=20 >> Feedback appreciated, >>=20 >> Julian >> _______________________________________________ >> apps-discuss mailing list >>=20 >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Jun 26 19:41: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 305F211E8104 for ; Tue, 26 Jun 2012 19:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-3.400, 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 PMJelB5PAvjD for ; Tue, 26 Jun 2012 19:41:29 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2956611E80EF for ; Tue, 26 Jun 2012 19:41:28 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5326D22E257; Tue, 26 Jun 2012 22:41:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4F044AEE.2080205@gmx.de> Date: Wed, 27 Jun 2012 12:41:24 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F044AEE.2080205@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1278) Cc: apps-discuss@ietf.org Subject: [apps-discuss] #4: draft-ietf-appsawg-json-pointer-00 feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2012 02:41:30 -0000 This is . I've tried to address them all with = , except: 1) I haven't said anything about 0 being allowed; Julian, do you have a = proposal for text in Security Considerations? 2) I haven't attempted to address the status of this being JSON's = fragment identifier.=20 Julian, you mentioned reserving more characters, but the downside there = will be (potentially) making it more difficult to use with existing JSON = that uses those characters. However, we *do* define an escape character; = couldn't we just say that future escape sequences can be defined by = updating this specification? Cheers, On 04/01/2012, at 11:49 PM, Julian Reschke wrote: > Hi Paul, >=20 > below some feedback: >=20 > Section 3: >=20 >> ABNF syntax: >>=20 >> json-pointer =3D *( "/" reference-token ) >> reference-token =3D *( unescaped / escaped ) >> unescaped =3D %x00-2E / %x30-5B / %x5D-10FFFF >=20 > Is 0 really allowed? (I see JSON allows this as well; maybe that's = something that needs to be discussed in the security considerations). >=20 >> escaped =3D "\" ( "/" / "\" ) >>=20 >> It is an error condition if a JSON Pointer value does not conform = to >> this syntax. >=20 > I'm fine with this because it allows using \ to escape more values in = the future. >=20 > Section 4: >=20 >> If the currently referenced value is a JSON array, the reference >> token MUST contain an unsigned base-10 integer value, and the = new >> referenced value is the array element with the zero-based index >> identified by the token. >=20 > Do we want to say something about leading zeroes in index values? I = assume they are allowed? >=20 > Section 5: >=20 >> A JSON Pointer MAY be represented in a JSON string value. Per >> [RFC4627], section 2.5, all instances of quotation mark '"' (%x22), >> reverse solidus '\' (%x5C) and control (%x00-1F) characters MUST be >> escaped. >=20 > The MAY is a statement of fact, not a normative requirement. Just say = "can". >=20 > Section 6: >=20 >> A JSON Pointer MAY be represented in a URI fragment identifier. = The >> JSON pointer MUST be UTF-8 [RFC3629] encoded as octets; octets in = the >> URI "unreserved" set SHOULD be percent-encoded, per [RFC3986], >> section 2.5. >=20 > See above. >=20 > Appendix A: >=20 > The semantics of fragment identifiers depends on the media type. You = need to be clear whether you're trying to define the fragid semantics = for application/json (which as far as I recall doesn't define any), or = something else. >=20 > That being said: >=20 >> http://example.com/example.json# >> Resolves to the object value at the root of the JSON text >> document. >=20 > The same would be true for >=20 > http://example.com/example.json#/ >=20 > right? I think we should stay away from empty fragment identifiers if = we can. (There MAY be dragons here). >=20 > Best regards, Julian >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From James.H.Manger@team.telstra.com Tue Jun 26 20:19: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 A415911E8104 for ; Tue, 26 Jun 2012 20:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NC1IosmsUhvm for ; Tue, 26 Jun 2012 20:19:36 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id C59F011E8102 for ; Tue, 26 Jun 2012 20:19:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,481,1336312800"; d="scan'208";a="84568064" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 27 Jun 2012 13:19:27 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6754"; a="73728898" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipccni.tcif.telstra.com.au with ESMTP; 27 Jun 2012 13:19:27 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Wed, 27 Jun 2012 13:19:26 +1000 From: "Manger, James H" To: Mark Nottingham , Julian Reschke Date: Wed, 27 Jun 2012 13:19:25 +1000 Thread-Topic: json-pointer: empty fragment Thread-Index: Ac1UDl5s366bgX3rSzeBjOoDAcyr9gAA0PWg Message-ID: <255B9BB34FB7D647A506DC292726F6E114F722F2AE@WSMSG3153V.srv.dir.telstra.com> References: <4F044AEE.2080205@gmx.de> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] json-pointer: empty fragment X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2012 03:19:36 -0000 Pj4gICBodHRwOi8vZXhhbXBsZS5jb20vZXhhbXBsZS5qc29uIw0KPj4gICAgICBSZXNvbHZlcyB0 byB0aGUgb2JqZWN0IHZhbHVlIGF0IHRoZSByb290IG9mIHRoZSBKU09OIHRleHQNCj4+ICAgICAg ZG9jdW1lbnQuDQo+DQo+IFRoZSBzYW1lIHdvdWxkIGJlIHRydWUgZm9yDQo+DQo+ICBodHRwOi8v ZXhhbXBsZS5jb20vZXhhbXBsZS5qc29uIy8NCj4NCj4gcmlnaHQ/IEkgdGhpbmsgd2Ugc2hvdWxk IHN0YXkgYXdheSBmcm9tIGVtcHR5IGZyYWdtZW50IGlkZW50aWZpZXJzIGlmDQo+IHdlIGNhbi4g KFRoZXJlIE1BWSBiZSBkcmFnb25zIGhlcmUpLg0KDQp3cm9uZz8NCkkgZG9uJ3QgdGhpbmsgd2Ug Y2FuIGF2b2lkIGVtcHR5IGZyYWdtZW50IGlkZW50aWZpZXJzIHNvIGVhc2lseS4NCg0KQ29uc2lk ZXIgdGhlIGZvbGxvd2luZyBKU09OIHZhbHVlOg0KICB7DQogICAgIiI6MSwNCiAgICAiZm9vIjoy DQogIH0NCg0KVVJJICAgIHJlZmVycyB0bw0KLS0tICAgIC0tLS0tLS0tLQ0KIy8gICAgIDENCiMv Zm9vICAyDQojICAgICAgey4uLn0gICh0aGUgcm9vdCBvYmplY3QpDQoNCg0KSGVuY2UgSSB0aGlu ayB3ZSBuZWVkIHRvIHVuZG8gcGFydCBvZiB0aGUgY2hhbmdlc2V0IDxodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy93Zy9hcHBzYXdnL3RyYWMvY2hhbmdlc2V0LzY5PiBbYXQgbGluZSAyMDZdLg0K DQpUaGUgZXhhbXBsZXMgbmVlZCB0byBpbmNsdWRlIGVsZW1lbnQgbmFtZXMgd2l0aCAiXiIgYW5k ICIvIiBjaGFyYWN0ZXJzLCBhbmQgcGVyaGFwcyBhbiBlbXB0eSBlbGVtZW50IG5hbWUgZm9yIGNv bXBsZXRlbmVzcy4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCg== From mnot@mnot.net Tue Jun 26 20:21: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 C797911E8102 for ; Tue, 26 Jun 2012 20:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.946 X-Spam-Level: X-Spam-Status: No, score=-105.946 tagged_above=-999 required=5 tests=[AWL=-3.347, 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 HfCjLbu3MWm9 for ; Tue, 26 Jun 2012 20:21:17 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2008711E80EA for ; Tue, 26 Jun 2012 20:21:17 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D95F122E253; Tue, 26 Jun 2012 23:21:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F722F2AE@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 27 Jun 2012 13:21:06 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F044AEE.2080205@gmx.de> <255B9BB34FB7D647A506DC292726F6E114F722F2AE@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] json-pointer: empty fragment X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2012 03:21:17 -0000 Good point; will fix. On 27/06/2012, at 1:19 PM, Manger, James H wrote: >>> http://example.com/example.json# >>> Resolves to the object value at the root of the JSON text >>> document. >>=20 >> The same would be true for >>=20 >> http://example.com/example.json#/ >>=20 >> right? I think we should stay away from empty fragment identifiers if >> we can. (There MAY be dragons here). >=20 > wrong? > I don't think we can avoid empty fragment identifiers so easily. >=20 > Consider the following JSON value: > { > "":1, > "foo":2 > } >=20 > URI refers to > --- --------- > #/ 1 > #/foo 2 > # {...} (the root object) >=20 >=20 > Hence I think we need to undo part of the changeset = [at line 206]. >=20 > The examples need to include element names with "^" and "/" = characters, and perhaps an empty element name for completeness. >=20 > -- > James Manger >=20 >=20 -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Jun 26 20:35: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 BD43411E80CD for ; Tue, 26 Jun 2012 20:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.896 X-Spam-Level: X-Spam-Status: No, score=-105.896 tagged_above=-999 required=5 tests=[AWL=-3.297, 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 bJaRkevxkLXQ for ; Tue, 26 Jun 2012 20:35:36 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9E011E80A4 for ; Tue, 26 Jun 2012 20:35:35 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7333C22E1F4 for ; Tue, 26 Jun 2012 23:35:29 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jun 2012 13:35:26 +1000 Message-Id: <93D6EE30-B07F-4964-8110-5DE3E914A3A1@mnot.net> To: Apps Discuss Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [apps-discuss] json-pointer in fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 03:35:36 -0000 I think this has been brought up before, but couldn't find where I'd = seen it. In our current draft, it says: > A JSON Pointer can be represented in a URI fragment = identifier. > The JSON pointer MUST be UTF-8 > encoded as octets; octets not in the URI "unreserved" set = SHOULD > be percent-encoded, per , = section 2.5. This is far more restrictive than RFC3986, which defines a fragment = identifer as: > fragment =3D *( pchar / "/" / "?" ) > pchar =3D unreserved / pct-encoded / sub-delims / ":" / "@" as becomes evident once you look at the examples I just generated, e.g.: > #%2Ffoo%5B0%5D "bar" I think we need to make this advisory (no need to re-require what 3986 = specifies), as well as more permissive.=20 Proposal: """ A JSON Pointer can be represented in a URI fragment identifier by = encoding it using UTF-8 [ref] into octets, percent-encoding those = characters not allowed by the fragment rule in RFC3986. """ Thoughts? -- Mark Nottingham http://www.mnot.net/ From James.H.Manger@team.telstra.com Tue Jun 26 21:35: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 F3FA211E8102 for ; Tue, 26 Jun 2012 21:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.154 X-Spam-Level: X-Spam-Status: No, score=-1.154 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtYHgLuKqTjl for ; Tue, 26 Jun 2012 21:35:16 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id BF6E911E80C5 for ; Tue, 26 Jun 2012 21:35:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,482,1336312800"; d="scan'208";a="79766836" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 27 Jun 2012 14:35:14 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6754"; a="72477786" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipccvi.tcif.telstra.com.au with ESMTP; 27 Jun 2012 14:35:14 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Wed, 27 Jun 2012 14:35:13 +1000 From: "Manger, James H" To: Mark Nottingham , Apps Discuss Date: Wed, 27 Jun 2012 14:35:12 +1000 Thread-Topic: errors in json-pointer examples Thread-Index: Ac1UFe4+dQ15/YD6T5S/+MCdxTytdwABPEWw Message-ID: <255B9BB34FB7D647A506DC292726F6E114F722F488@WSMSG3153V.srv.dir.telstra.com> References: <93D6EE30-B07F-4964-8110-5DE3E914A3A1@mnot.net> In-Reply-To: <93D6EE30-B07F-4964-8110-5DE3E914A3A1@mnot.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [apps-discuss] errors in json-pointer examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2012 04:35:17 -0000 Q2hhbmdlc2V0IDcwIDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9hcHBzYXdnL3RyYWMv Y2hhbmdlc2V0LzcwL2pzb24tcG9pbnRlci9kcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1wb2ludGVy LnhtbD4gc2VlbXMgdG8gaGF2ZSBzb21lIGVycm9yczoNCg0KMS4gVGhlIGxlYWRpbmcgIi8iIGlz IHByZXNlbnQgZm9yIHRoZSAxc3QgMyBKU09OIHBvaW50ZXJzLCBidXQgbWlzc2luZyBmcm9tIHRo ZSBuZXh0IDUuIEZvciBpbnN0YW5jZSAiYyVkIiBzaG91bGQgYmUgIi9jJWQiDQoNCjIuICIvZm9v WzBdIiBzaG91bGQgYmUgIi9mb28vMCIuIFRoZSBmb3JtZXIgd2FzIGEgc3VnZ2VzdGlvbiAoZnJv bSBKdWxpZW4/KSwgYnV0IEkgZG9uJ3QgdGhpbmsgaXQgd2FzIGFkb3B0ZWQuDQoNCjMuIEEgSlNP TiBzdHJpbmcgaG9sZGluZyBhIHBvaW50ZXIgdG8gNSBpbiB7ICJpXFxqIjo1IH0gc2hvdWxkIGJl ICIvaV5cXGoiIChub3QgImlcXGoiKQ0KDQo0LiAia1wibCIgc2hvdWxkIGJlICIva15cImwiDQoN CjUuIE1vc3Qgb2YgdGhlIGZyYWdtZW50IGlkIGV4YW1wbGVzIGFyZSB3cm9uZyBpbiB0aGUgc2Ft ZSB3YXlzIGFzIHBvaW50cyAxLCAyLCAzICYgNCBhYm92ZQ0KDQo2LiAjZyU3QyBzaG91bGQgYmUg I2clN0NoDQoNCkFmdGVyIHRoZSBKU09OIGRvY3VtZW50LCBJIHdvdWxkIGJlIHRlbXB0ZWQgdG8g bGlzdCB0aGUgcmF3IEpTT04gcG9pbnRlcnMgKGVnIC9pXlxqKSB0aGVuIGxpc3QgdGhlIEpTT04g cG9pbnRlcnMgYXMgSlNPTiBzdHJpbmdzIChlZyAiL2leXFxqIikgdGhlbiB0aGUgcG9pbnRlcnMg YXMgZnJhZ21lbnRzIChlZyAjJTJGaSU1RSU1Q2opLg0KDQoNClAuUy4gdGhlIHByb3Bvc2FsIGJl bG93IGxvb2tzIGdvb2Q6DQoNCj4gSSB0aGluayB3ZSBuZWVkIHRvIG1ha2UgdGhpcyBhZHZpc29y eSAobm8gbmVlZCB0byByZS1yZXF1aXJlIHdoYXQgMzk4Ng0KPiBzcGVjaWZpZXMpLCBhcyB3ZWxs IGFzIG1vcmUgcGVybWlzc2l2ZS4NCj4gDQo+IFByb3Bvc2FsOg0KPiANCj4gIiIiDQo+IEEgSlNP TiBQb2ludGVyIGNhbiBiZSByZXByZXNlbnRlZCBpbiBhIFVSSSBmcmFnbWVudCBpZGVudGlmaWVy IGJ5DQo+IGVuY29kaW5nIGl0IHVzaW5nIFVURi04IFtyZWZdIGludG8gb2N0ZXRzLCBwZXJjZW50 LWVuY29kaW5nIHRob3NlDQo+IGNoYXJhY3RlcnMgbm90IGFsbG93ZWQgYnkgdGhlIGZyYWdtZW50 IHJ1bGUgaW4gUkZDMzk4Ni4NCj4gIiIiDQo+IA0KPiBUaG91Z2h0cz8NCg0KLS0NCkphbWVzIE1h bmdlcg0K From James.H.Manger@team.telstra.com Tue Jun 26 21:44: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 E807211E8107 for ; Tue, 26 Jun 2012 21:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.213 X-Spam-Level: X-Spam-Status: No, score=-0.213 tagged_above=-999 required=5 tests=[AWL=-1.171, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4C3awUmgwVB for ; Tue, 26 Jun 2012 21:44:26 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 24DA611E80C5 for ; Tue, 26 Jun 2012 21:44:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,482,1336312800"; d="scan'208";a="79768336" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 27 Jun 2012 14:44:25 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6754"; a="72063782" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbvi.tcif.telstra.com.au with ESMTP; 27 Jun 2012 14:44:25 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Wed, 27 Jun 2012 14:44:24 +1000 From: "Manger, James H" To: Mark Nottingham , Apps Discuss Date: Wed, 27 Jun 2012 14:44:24 +1000 Thread-Topic: errors in json-pointer examples Thread-Index: Ac1UFe4+dQ15/YD6T5S/+MCdxTytdwABPEWwAAD3+yA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114F722F4CD@WSMSG3153V.srv.dir.telstra.com> References: <93D6EE30-B07F-4964-8110-5DE3E914A3A1@mnot.net> <255B9BB34FB7D647A506DC292726F6E114F722F488@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F722F488@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] errors in json-pointer examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2012 04:44:27 -0000 Ii8iIGRvZXMgbm90IG5lZWQgdG8gYmUgZXNjYXBlZCBpbiBhIGZyYWdtZW50IHNvIHVuZXNjYXBl ICUyRiBpbiBhbGwgdGhlIGZyYWdtZW50IGV4YW1wbGVzLg0KDQojL2Zvbw0KIy9mb28vMA0KIy9j JTI1ZA0KIy9lJTVFJTVFZg0KIy9nJTdDaA0KIy9pJTVFJTVDag0KIy9rJTIybA0KDQotLQ0KSmFt ZXMgTWFuZ2VyDQoNCg0KPiA2LiAjZyU3QyBzaG91bGQgYmUgI2clN0NoDQoNCk9wcHMuIFNob3Vs ZCBiZSAjL2clN0NoDQoNCg== From mnot@mnot.net Tue Jun 26 21:48: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 186E921F8494 for ; Tue, 26 Jun 2012 21:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.858 X-Spam-Level: X-Spam-Status: No, score=-105.858 tagged_above=-999 required=5 tests=[AWL=-3.259, 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 IvdDojFoe4CZ for ; Tue, 26 Jun 2012 21:47:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id CE9D921F846C for ; Tue, 26 Jun 2012 21:47:52 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1F07622DD6D; Wed, 27 Jun 2012 00:47:45 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F722F488@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 27 Jun 2012 14:47:42 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <121B6279-5998-4153-8C47-626242D0F052@mnot.net> References: <93D6EE30-B07F-4964-8110-5DE3E914A3A1@mnot.net> <255B9BB34FB7D647A506DC292726F6E114F722F488@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss Subject: Re: [apps-discuss] errors in json-pointer examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2012 04:48:05 -0000 I didn't want to spend too much time on them until we had agreement on = the change I suggested. Since I've got at least one +1 now, I'll incorporate that and update the = examples. Thanks! On 27/06/2012, at 2:35 PM, Manger, James H wrote: > Changeset 70 = seems to have some errors: >=20 > 1. The leading "/" is present for the 1st 3 JSON pointers, but missing = from the next 5. For instance "c%d" should be "/c%d" >=20 > 2. "/foo[0]" should be "/foo/0". The former was a suggestion (from = Julien?), but I don't think it was adopted. >=20 > 3. A JSON string holding a pointer to 5 in { "i\\j":5 } should be = "/i^\\j" (not "i\\j") >=20 > 4. "k\"l" should be "/k^\"l" >=20 > 5. Most of the fragment id examples are wrong in the same ways as = points 1, 2, 3 & 4 above >=20 > 6. #g%7C should be #g%7Ch >=20 > After the JSON document, I would be tempted to list the raw JSON = pointers (eg /i^\j) then list the JSON pointers as JSON strings (eg = "/i^\\j") then the pointers as fragments (eg #%2Fi%5E%5Cj). >=20 >=20 > P.S. the proposal below looks good: >=20 >> I think we need to make this advisory (no need to re-require what = 3986 >> specifies), as well as more permissive. >>=20 >> Proposal: >>=20 >> """ >> A JSON Pointer can be represented in a URI fragment identifier by >> encoding it using UTF-8 [ref] into octets, percent-encoding those >> characters not allowed by the fragment rule in RFC3986. >> """ >>=20 >> Thoughts? >=20 > -- > James Manger -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Jun 26 22:02: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 0036821F84DD for ; Tue, 26 Jun 2012 22:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.81 X-Spam-Level: X-Spam-Status: No, score=-105.81 tagged_above=-999 required=5 tests=[AWL=-3.211, 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 Jfa+4Dan2SOi for ; Tue, 26 Jun 2012 22:02:22 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D506721F84D5 for ; Tue, 26 Jun 2012 22:02:21 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4EB5D22E1F4; Wed, 27 Jun 2012 01:02:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F722F488@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 27 Jun 2012 15:02:17 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93D6EE30-B07F-4964-8110-5DE3E914A3A1@mnot.net> <255B9BB34FB7D647A506DC292726F6E114F722F488@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss Subject: Re: [apps-discuss] errors in json-pointer examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2012 05:02:23 -0000 See ; I *think* = it's correct now. The choice of the caret as an escape character is a bit unfortunate in = the URI fragment encoding, because it's not in sub-delims (or the other = chars allowed in fragment). A few comments below. On 27/06/2012, at 2:35 PM, Manger, James H wrote: > Changeset 70 = seems to have some errors: >=20 > 1. The leading "/" is present for the 1st 3 JSON pointers, but missing = from the next 5. For instance "c%d" should be "/c%d" >=20 > 2. "/foo[0]" should be "/foo/0". The former was a suggestion (from = Julien?), but I don't think it was adopted. Ah, old habits die hard. > 3. A JSON string holding a pointer to 5 in { "i\\j":5 } should be = "/i^\\j" (not "i\\j") We don't caret escape backslash... > 4. "k\"l" should be "/k^\"l" Same as above. > 5. Most of the fragment id examples are wrong in the same ways as = points 1, 2, 3 & 4 above >=20 > 6. #g%7C should be #g%7Ch >=20 > After the JSON document, I would be tempted to list the raw JSON = pointers (eg /i^\j) then list the JSON pointers as JSON strings (eg = "/i^\\j") then the pointers as fragments (eg #%2Fi%5E%5Cj). Yeah. Let's let things settle a bit. Thanks again, >=20 >=20 > P.S. the proposal below looks good: >=20 >> I think we need to make this advisory (no need to re-require what = 3986 >> specifies), as well as more permissive. >>=20 >> Proposal: >>=20 >> """ >> A JSON Pointer can be represented in a URI fragment identifier by >> encoding it using UTF-8 [ref] into octets, percent-encoding those >> characters not allowed by the fragment rule in RFC3986. >> """ >>=20 >> Thoughts? >=20 > -- > James Manger -- Mark Nottingham http://www.mnot.net/ From James.H.Manger@team.telstra.com Tue Jun 26 22:20: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 3C10811E8104 for ; Tue, 26 Jun 2012 22:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4QNeLA2F7xq for ; Tue, 26 Jun 2012 22:20:52 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id D16CC11E8102 for ; Tue, 26 Jun 2012 22:20:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,482,1336312800"; d="scan'208";a="79774682" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 27 Jun 2012 15:20:50 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6754"; a="72485108" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipccvi.tcif.telstra.com.au with ESMTP; 27 Jun 2012 15:20:50 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Wed, 27 Jun 2012 15:20:50 +1000 From: "Manger, James H" To: Mark Nottingham Date: Wed, 27 Jun 2012 15:20:45 +1000 Thread-Topic: errors in json-pointer examples Thread-Index: Ac1UIgq7mZuwxvvBSYK0eHK6GZ6+EwAAPPXg Message-ID: <255B9BB34FB7D647A506DC292726F6E114F722F5E0@WSMSG3153V.srv.dir.telstra.com> References: <93D6EE30-B07F-4964-8110-5DE3E914A3A1@mnot.net> <255B9BB34FB7D647A506DC292726F6E114F722F488@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {A4D0B95E-CC0D-4762-8231-FAAB06DE7379} x-cr-hashedpuzzle: EMo= vJs= EDIl EhMx ExLk FM8g H7eS La0x NLTy NQzl PVXZ P5fQ SKmm VjmP Xcgn XfDN; 2; ZABpAHMAYwB1AHMAcwBAAGEAcABwAHMALgBpAGUAdABmAC4AbwByAGcAOwBtAG4AbwB0AEAAbQBuAG8AdAAuAG4AZQB0AA==; Sosha1_v1; 7; {A4D0B95E-CC0D-4762-8231-FAAB06DE7379}; agBhAG0AZQBzAC4AaAAuAG0AYQBuAGcAZQByAEAAdABlAGEAbQAuAHQAZQBsAHMAdAByAGEALgBjAG8AbQA=; Wed, 27 Jun 2012 05:20:45 GMT; UgBFADoAIABlAHIAcgBvAHIAcwAgAGkAbgAgAGoAcwBvAG4ALQBwAG8AaQBuAHQAZQByACAAZQB4AGEAbQBwAGwAZQBzAA== acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Apps Discuss Subject: Re: [apps-discuss] errors in json-pointer examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2012 05:20:54 -0000 PiBTZWUgPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2FwcHNhd2cvdHJhYy9jaGFuZ2Vz ZXQvNzc+OyBJDQo+ICp0aGluayogaXQncyBjb3JyZWN0IG5vdy4NCg0KR2V0dGluZyBjbG9zZS4N Cg0KTGluZSAxNTcgc2hvdWxkIGJlDQogICIvIiAgIDAgDQppbnN0ZWFkIG9mDQogICIiICAgIDAN Cg0KVGhlICJtL24iIGVsZW1lbnQgaXMgdW5uZWNlc3NhcnkgYXMgd2UgaGF2ZSB0aGUgImEvYiIg ZWxlbWVudCBzbyBsaW5lcyAxNDUsIDE2NCwgYW5kIDE5MSBjYW4gZ28uDQoNCkxpbmUgMTg1IHNo b3VsZCBiZQ0KICAjL2ElNUUvYiAgICAxDQppbnN0ZWFkIG9mDQogICMvYS9iICAgICAgIDENCg0K DQotLQ0KSmFtZXMgTWFuZ2VyDQo= From mnot@mnot.net Tue Jun 26 22: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 6B87621F85B8 for ; Tue, 26 Jun 2012 22:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.764 X-Spam-Level: X-Spam-Status: No, score=-105.764 tagged_above=-999 required=5 tests=[AWL=-3.165, 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 iUKTCnilax2W for ; Tue, 26 Jun 2012 22:28:20 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 92AB721F85B4 for ; Tue, 26 Jun 2012 22:28:20 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BEE8822E256; Wed, 27 Jun 2012 01:28:13 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F722F5E0@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 27 Jun 2012 15:28:10 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93D6EE30-B07F-4964-8110-5DE3E914A3A1@mnot.net> <255B9BB34FB7D647A506DC292726F6E114F722F488@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F722F5E0@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss Subject: Re: [apps-discuss] errors in json-pointer examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2012 05:28:21 -0000 Done in 78. Thanks for the extra pair of eyes. Cheers, On 27/06/2012, at 3:20 PM, Manger, James H wrote: >> See ; I >> *think* it's correct now. >=20 > Getting close. >=20 > Line 157 should be > "/" 0=20 > instead of > "" 0 >=20 > The "m/n" element is unnecessary as we have the "a/b" element so lines = 145, 164, and 191 can go. >=20 > Line 185 should be > #/a%5E/b 1 > instead of > #/a/b 1 >=20 >=20 > -- > James Manger -- Mark Nottingham http://www.mnot.net/ From sm@resistor.net Tue Jun 26 23:23: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 557DB11E8102 for ; Tue, 26 Jun 2012 23:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, 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 pH6hb-0reI5o for ; Tue, 26 Jun 2012 23:23:11 -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 292B211E80C5 for ; Tue, 26 Jun 2012 23:23:11 -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 q5R6N0W4006846; Tue, 26 Jun 2012 23:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340778188; bh=RIA0UnScuEKAPhcF3OSX3ZDLyNOfVvIFnb0tBTcqBD4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vThzU2Qg7jbGexLQYj2/vHm3ZAsJDxNkt7kA2mTWfjfPM05uBfwRvIE+Ezc1D/G3w 4CmqSupUtSvqtteXmzThQtUDHcfW0u0RY/3gqSDuz823ptiFGQ7dDjtLLvVjM9nDHs aRkaAXQ6BOMyv6VS3waZnjfTcKhlVCQlrx4IjWV0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1340778188; i=@resistor.net; bh=RIA0UnScuEKAPhcF3OSX3ZDLyNOfVvIFnb0tBTcqBD4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BYelDQFwguQWqePUxYkF0OhWIrW44mCqrHGU8Ahkg22xmpVwtLys2oswKAIxklRol ba56D/uQRVxw4eNP8cOWtwj2TWMTEDhSiULFP0Loz8vzE8m3lwPniY++q2w9SjYboJ P1TQA65s6zwYRS6OpmEGkdlCZSBo+iNKL57843HU= Message-Id: <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 26 Jun 2012 23:06:54 -0700 To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= From: SM In-Reply-To: <4FEA6677.3020705@it.aoyama.ac.jp> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 06:23:13 -0000 Hi Martin, At 18:48 26-06-2012, Martin J. D=FCrst wrote: >Warning: procedural nitpicking ahead! > >I think we should be careful about this.=20 >uri-review@ietf.org is for review of URI/IRI=20 >schemes in general. This has a rather low=20 >barrier. The fact that it gets approved there=20 >doesn't mean that it will pass through the IETF=20 >standardization process. On the other hand, if=20 >the IETF standardizes it, it has the possibility=20 >of overriding the decision on uri-review@ietf.org if that should be= necessary. >I'm just mentioning this here because we have=20 >been through this for another URI scheme. I don't like the idea of mixing registration=20 criteria and the standardization process. The=20 authors of the other URI scheme were nice not to=20 turn such a matter into an issue. This is the=20 sort of issue which generate controversies. It=20 will be detrimental to the IETF as people will walk away. Regards, -sm=20 From julian.reschke@gmx.de Wed Jun 27 00:19: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 ACD4311E8108 for ; Wed, 27 Jun 2012 00:19:46 -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 H8nwjYqlDmiU for ; Wed, 27 Jun 2012 00:19:46 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 85B5411E8105 for ; Wed, 27 Jun 2012 00:19:45 -0700 (PDT) Received: (qmail invoked by alias); 27 Jun 2012 07:19:43 -0000 Received: from unknown (EHLO [42.1.1.153]) [192.147.117.12] by mail.gmx.net (mp038) with SMTP; 27 Jun 2012 09:19:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Du1tGenqD7wOMq0Q25l1VukENCkhwMqFBcCxiF3 SCxmQRYJyA0ohT Message-ID: <4FEAB40D.3010607@gmx.de> Date: Wed, 27 Jun 2012 09:19:41 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Paul C. Bryan" References: <4F86F5E9.1040202@gmx.de> <1334247691.2570.8.camel@neutron> In-Reply-To: <1334247691.2570.8.camel@neutron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 07:19:46 -0000 On 2012-04-12 18:21, Paul C. Bryan wrote: > This takes us back to a previous version of JSON Pointer > , which in > fact did use URI escaping of %2F to distinguish between the '/' token > delimiter and a '/' character within a token. IIRC, the objections that > lead us to change were: > > 1. It requires URI decoding logic in non-URI-processing code (e.g. when > pointers are used in JSON strings rather than in URI fragment > identifiers). This has always been a somewhat weak argument, IMO. The way you state is slightly misleading. You don't need URI decoding logic; you just need percent-decoding logic (which is only small part of URI parsing). And you need *some* kind of unescaping anyway, so I don't see the material difference... > 2. Some URI parsers normalize the URI (i.e. expand %2F into '/') before > any JSON Pointer parsing code can get a chance to see it. Again; don't use a URI parser. Just %-unescape. > In response to this, I went down the path of using a single escape > character. If we can overcome these objections, I'd be happy to > entertain returning to URI escaping. I think it would be worthwhile to do. Best regards, Julian From julian.reschke@gmx.de Wed Jun 27 00:25: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 CD6F421F8579 for ; Wed, 27 Jun 2012 00:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG2cuvMPkRh5 for ; Wed, 27 Jun 2012 00:25:09 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2871021F855F for ; Wed, 27 Jun 2012 00:25:07 -0700 (PDT) Received: (qmail invoked by alias); 27 Jun 2012 07:25:07 -0000 Received: from unknown (EHLO [42.1.1.153]) [192.147.117.12] by mail.gmx.net (mp032) with SMTP; 27 Jun 2012 09:25:07 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+m6gI2jk+mjsDB7U3PLgvwIRl7fMNG6Uv+Rg4abZ qdORSyYjyoRh3C Message-ID: <4FEAB551.4050204@gmx.de> Date: Wed, 27 Jun 2012 09:25:05 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Nottingham References: <4F044AEE.2080205@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@ietf.org Subject: Re: [apps-discuss] #4: draft-ietf-appsawg-json-pointer-00 feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2012 07:25:09 -0000 On 2012-06-27 04:41, Mark Nottingham wrote: > This is . > > I've tried to address them all with , except: > > 1) I haven't said anything about 0 being allowed; Julian, do you have a proposal for text in Security Considerations? "Note that JSON pointers can contain the NUL (Unicode U+0000) character, which may not be representable in all programming languages." (I personally think we should disallow it, though). > 2) I haven't attempted to address the status of this being JSON's fragment identifier. > > Julian, you mentioned reserving more characters, but the downside there will be (potentially) making it more difficult to use with existing JSON that uses those characters. However, we *do* define an escape character; couldn't we just say that future escape sequences can be defined by updating this specification? I'd prefer that we simplify things by not attempting to define fragment identifier syntax for now. Doing so without updating the application/json spec will lead to lots of confusion. Best regards, Julian From mnot@mnot.net Wed Jun 27 00:29: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 C6A6121F85E0 for ; Wed, 27 Jun 2012 00:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.677 X-Spam-Level: X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=-3.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 Esfc+OjR7KDk for ; Wed, 27 Jun 2012 00:29:48 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1FE21F85C2 for ; Wed, 27 Jun 2012 00:29:48 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5DAA122E1F4; Wed, 27 Jun 2012 03:29:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: <4FEAB551.4050204@gmx.de> Date: Wed, 27 Jun 2012 17:29:44 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <1242223C-C63E-43D4-8966-0F8A97E88D1A@mnot.net> References: <4F044AEE.2080205@gmx.de> <4FEAB551.4050204@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1278) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] #4: draft-ietf-appsawg-json-pointer-00 feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2012 07:29:49 -0000 On 27/06/2012, at 5:25 PM, Julian Reschke wrote: > On 2012-06-27 04:41, Mark Nottingham wrote: >> This is . >>=20 >> I've tried to address them all with = , except: >>=20 >> 1) I haven't said anything about 0 being allowed; Julian, do you have = a proposal for text in Security Considerations? >=20 > "Note that JSON pointers can contain the NUL (Unicode U+0000) = character, which may not be representable in all programming languages." >=20 > (I personally think we should disallow it, though). I'll insert the text now, as it seems uncontroversial; if there's a = decision to disallow it later, we can change it. >> 2) I haven't attempted to address the status of this being JSON's = fragment identifier. >>=20 >> Julian, you mentioned reserving more characters, but the downside = there will be (potentially) making it more difficult to use with = existing JSON that uses those characters. However, we *do* define an = escape character; couldn't we just say that future escape sequences can = be defined by updating this specification? >=20 > I'd prefer that we simplify things by not attempting to define = fragment identifier syntax for now. Doing so without updating the = application/json spec will lead to lots of confusion. Isn't that just a matter of updating the registry entry? Regards, -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Wed Jun 27 00:34: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 CDDC121F85E6 for ; Wed, 27 Jun 2012 00:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 G0x+5bUQr1AI for ; Wed, 27 Jun 2012 00:34:03 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D4F8D21F85E4 for ; Wed, 27 Jun 2012 00:34:02 -0700 (PDT) Received: (qmail invoked by alias); 27 Jun 2012 07:34:01 -0000 Received: from unknown (EHLO [42.1.1.153]) [192.147.117.12] by mail.gmx.net (mp032) with SMTP; 27 Jun 2012 09:34:01 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/toI9wHPHtlCn7jzTDhDXL6QKmWjROl1Q1JekWHd wwtnWNmqPf1w6E Message-ID: <4FEAB766.6050406@gmx.de> Date: Wed, 27 Jun 2012 09:33:58 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Nottingham References: <93D6EE30-B07F-4964-8110-5DE3E914A3A1@mnot.net> In-Reply-To: <93D6EE30-B07F-4964-8110-5DE3E914A3A1@mnot.net> 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] json-pointer in fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 07:34:03 -0000 On 2012-06-27 05:35, Mark Nottingham wrote: > I think this has been brought up before, but couldn't find where I'd seen it. > > In our current draft, it says: > >> A JSON Pointer can be represented in a URI fragment identifier. >> The JSON pointer MUST be UTF-8 >> encoded as octets; octets not in the URI "unreserved" set SHOULD >> be percent-encoded, per , section 2.5. > ... I believe we should discuss first (which is about whether to do fragment identifiers at all). On the other hand, I agree that the escaping should just follow from the character repertoire and RFC 3986. Note that JSON pointers in path segments might be much more interesting than in fragment identifiers... Best regards, Julian From mnot@mnot.net Wed Jun 27 00: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 5601B21F85A8 for ; Wed, 27 Jun 2012 00:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.634 X-Spam-Level: X-Spam-Status: No, score=-105.634 tagged_above=-999 required=5 tests=[AWL=-3.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uj9DtIz5Gruz for ; Wed, 27 Jun 2012 00:38:41 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id B1AFA21F85A5 for ; Wed, 27 Jun 2012 00:38:29 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F196522E1EB; Wed, 27 Jun 2012 03:38:22 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Mark Nottingham In-Reply-To: <4FEAB766.6050406@gmx.de> Date: Wed, 27 Jun 2012 17:38:19 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93D6EE30-B07F-4964-8110-5DE3E914A3A1@mnot.net> <4FEAB766.6050406@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss Subject: Re: [apps-discuss] json-pointer in fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 07:38:42 -0000 On 27/06/2012, at 5:33 PM, Julian Reschke wrote: > On 2012-06-27 05:35, Mark Nottingham wrote: >> I think this has been brought up before, but couldn't find where I'd = seen it. >>=20 >> In our current draft, it says: >>=20 >>> A JSON Pointer can be represented in a URI fragment = identifier. >>> The JSON pointer MUST be UTF-8 >>> encoded as octets; octets not in the URI "unreserved" = set SHOULD >>> be percent-encoded, per , = section 2.5. >> ... >=20 > I believe we should discuss = first (which is = about whether to do fragment identifiers at all). Was that intended for json-pointer? If so, I'll change the details = (right now it says it's about patch). > On the other hand, I agree that the escaping should just follow from = the character repertoire and RFC 3986. I'll take that as a +1, thank you. > Note that JSON pointers in path segments might be much more = interesting than in fragment identifiers... Indeed.=20 -- Mark Nottingham http://www.mnot.net/ From duerst@it.aoyama.ac.jp Wed Jun 27 00:43:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D269A21F85EA for ; Wed, 27 Jun 2012 00:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.626 X-Spam-Level: X-Spam-Status: No, score=-99.626 tagged_above=-999 required=5 tests=[AWL=0.164, 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 38B1unaeMNAO for ; Wed, 27 Jun 2012 00:43:19 -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 E258021F857D for ; Wed, 27 Jun 2012 00:43:18 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q5R7hCmv019857 for ; Wed, 27 Jun 2012 16:43:12 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 1930_c799_bf9036e6_c02b_11e1_a0ca_001d096c5782; Wed, 27 Jun 2012 16:43:12 +0900 Received: from [IPv6:::1] ([133.2.210.1]:45268) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 27 Jun 2012 16:43:17 +0900 Message-ID: <4FEAB98E.307@it.aoyama.ac.jp> Date: Wed, 27 Jun 2012 16:43:10 +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: SM References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> In-Reply-To: <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 07:43:20 -0000 Hello SM, On 2012/06/27 15:06, SM wrote: > Hi Martin, > At 18:48 26-06-2012, Martin J. Dürst wrote: >> Warning: procedural nitpicking ahead! >> >> I think we should be careful about this. uri-review@ietf.org is for >> review of URI/IRI schemes in general. This has a rather low barrier. >> The fact that it gets approved there doesn't mean that it will pass >> through the IETF standardization process. On the other hand, if the >> IETF standardizes it, it has the possibility of overriding the >> decision on uri-review@ietf.org if that should be necessary. >> I'm just mentioning this here because we have been through this for >> another URI scheme. > > I don't like the idea of mixing registration criteria and the > standardization process. The authors of the other URI scheme were nice > not to turn such a matter into an issue. This is the sort of issue which > generate controversies. It will be detrimental to the IETF as people > will walk away. I can't disagree with what you say, but I'm not sure whether you agree or disagree with what I said. Can you clarify? Regards, Martin. From duerst@it.aoyama.ac.jp Wed Jun 27 00:50: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 968F821F8645 for ; Wed, 27 Jun 2012 00:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.534 X-Spam-Level: X-Spam-Status: No, score=-98.534 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_BACKHAIR_23=1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=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 BbZ1Gs+WyLX2 for ; Wed, 27 Jun 2012 00:50:41 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id D274921F8643 for ; Wed, 27 Jun 2012 00:50:40 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q5R7ob2F027075 for ; Wed, 27 Jun 2012 16:50:37 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2928_9101_c8a4fe46_c02c_11e1_8fbd_001d096c566a; Wed, 27 Jun 2012 16:50:36 +0900 Received: from [IPv6:::1] ([133.2.210.1]:54912) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 27 Jun 2012 16:50:41 +0900 Message-ID: <4FEABB4B.7050405@it.aoyama.ac.jp> Date: Wed, 27 Jun 2012 16:50:35 +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: <93D6EE30-B07F-4964-8110-5DE3E914A3A1@mnot.net> In-Reply-To: <93D6EE30-B07F-4964-8110-5DE3E914A3A1@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] json-pointer in fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 07:50:41 -0000 Hello Mark, On 2012/06/27 12:35, Mark Nottingham wrote: > I think this has been brought up before, but couldn't find where I'd seen it. > > In our current draft, it says: > >> A JSON Pointer can be represented in a URI fragment identifier. >> The JSON pointer MUST beUTF-8 >> encoded as octets; octets not in the URI "unreserved" set SHOULD >> be percent-encoded, per, section 2.5. > > This is far more restrictive than RFC3986, which defines a fragment identifer as: > >> fragment = *( pchar / "/" / "?" ) > >> pchar = unreserved / pct-encoded / sub-delims / ":" / "@" > > as becomes evident once you look at the examples I just generated, e.g.: > >> #%2Ffoo%5B0%5D "bar" > > > I think we need to make this advisory (no need to re-require what 3986 specifies), as well as more permissive. > > Proposal: > > """ > A JSON Pointer can be represented in a URI fragment identifier by encoding it using UTF-8 [ref] into octets, percent-encoding those characters not allowed by the fragment rule in RFC3986. > """ > > Thoughts? RFC 3986 does not nail down UTF-8 for fragment identifiers, and your new text makes that advisory, so we could end up with fragment identifiers based on Shift_JIS, Latin-1, and other legacy stuff, which we definitely don't want. So: - Use of UTF-8 has to be mandatory (for interoperability), and we have to mandate it in this spec. That's where your proposal falls short. - %-encoding for bytes/octets not allowed in fragment identifiers is mandatory, but that's a given in RFC 3986 (and somewhat differently in RFC 3987, because in IRIs, you can use Unicode characters). - There is no need for %-escaping sub-delims or ":" or "@", so we should not require that. Regards, Martin. From julian.reschke@gmx.de Wed Jun 27 00:56: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 42F3321F864E for ; Wed, 27 Jun 2012 00:56:03 -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 s0iDg+Pwee8w for ; Wed, 27 Jun 2012 00:56:02 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 077BB21F8648 for ; Wed, 27 Jun 2012 00:56:01 -0700 (PDT) Received: (qmail invoked by alias); 27 Jun 2012 07:56:01 -0000 Received: from unknown (EHLO [42.1.1.153]) [192.147.117.12] by mail.gmx.net (mp037) with SMTP; 27 Jun 2012 09:56:01 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19CUclYZPZCHas4eN1FueFy2VCJBABbzmjh6IyuLX CgmIFqMAgtf3eC Message-ID: <4FEABC8F.1090509@gmx.de> Date: Wed, 27 Jun 2012 09:55:59 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Nottingham References: <93D6EE30-B07F-4964-8110-5DE3E914A3A1@mnot.net> <4FEAB766.6050406@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] json-pointer in fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 07:56:03 -0000 On 2012-06-27 09:38, Mark Nottingham wrote: > > On 27/06/2012, at 5:33 PM, Julian Reschke wrote: > >> On 2012-06-27 05:35, Mark Nottingham wrote: >>> I think this has been brought up before, but couldn't find where I'd seen it. >>> >>> In our current draft, it says: >>> >>>> A JSON Pointer can be represented in a URI fragment identifier. >>>> The JSON pointer MUST be UTF-8 >>>> encoded as octets; octets not in the URI "unreserved" set SHOULD >>>> be percent-encoded, per , section 2.5. >>> ... >> >> I believe we should discuss first (which is about whether to do fragment identifiers at all). > > Was that intended for json-pointer? If so, I'll change the details (right now it says it's about patch). Yes and no :-). json-patch contains sections that suggest that fragment identifiers are defined, and uses the syntax defined in json-pointer. > ... Best regards, Julian From sm@resistor.net Wed Jun 27 02:01: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 ECDAD21F85A2 for ; Wed, 27 Jun 2012 02:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.416 X-Spam-Level: X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, 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 BMtijMjJY5gH for ; Wed, 27 Jun 2012 02:01:37 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CB821F8514 for ; Wed, 27 Jun 2012 02:01:37 -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 q5R91U3o011316; Wed, 27 Jun 2012 02:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340787696; bh=8wwC2TtyG+Cey/FXZ4PuZaqj1X6zAs56X/RKLdOO4KE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0Q5x3f6lzptewoQso8tWMTEWw3GG5Qfl8aGgtmu5PE1vxi8mJLBfv+txfGFIWkELk fKmxZIAkGfeQS6QLoOFAIk2blj10NRBZcQER1dnOJSMvY8W4uiO2gfQwcDZ+xRnrwy UV1r45OxJ1YtCtDlMrqZKmMcltlu1ffRVTr+hSLQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1340787696; i=@resistor.net; bh=8wwC2TtyG+Cey/FXZ4PuZaqj1X6zAs56X/RKLdOO4KE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=M7xoPh691R0iu6N2KcPnnF9CuGIfKwmRyEcR1XPI82LFkyz0RraeVej6zw7VURx0R woiqGUsePAf8zWWo1PdD3gpeBGLYXW4RAuCnX0EdJico6cJKRl60arTwKt+9LPGQxx 9TeKFCYoaNaR6GKC3Es0k4eD+U9PtB8MV9VsRPxg= Message-Id: <6.2.5.6.2.20120627012228.0a8b4298@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 Jun 2012 01:56:27 -0700 To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= From: SM In-Reply-To: <4FEAB98E.307@it.aoyama.ac.jp> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> <4FEAB98E.307@it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 09:01:42 -0000 Hi Martin, At 00:43 27-06-2012, Martin J. D=FCrst wrote: >I can't disagree with what you say, but I'm not=20 >sure whether you agree or disagree with what I said. Can you clarify? I think that what you said makes sense. I don't=20 like the override as it is difficult to explain=20 that to someone who views Expert review as a=20 barrier he or she should not jump over twice. Regards, -sm=20 From melvincarvalho@gmail.com Wed Jun 27 03: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 AF0F021F8671 for ; Wed, 27 Jun 2012 03:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.015 X-Spam-Level: X-Spam-Status: No, score=-3.015 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jxnY9pNustW for ; Wed, 27 Jun 2012 03:18:15 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D3A9021F8668 for ; Wed, 27 Jun 2012 03:18:14 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so621722vbb.31 for ; Wed, 27 Jun 2012 03:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5nvb+r1fXk2AZjsJ8DTmaC2nt4lVU6LdFfySE5Ma0Bc=; b=UVm2cKnsfmdSGSyzIO+0EMxnlzKli/h8TQ1FsBulx3bQp6GpHtju7r6njwhrYftt+I 11prVOnvV57wUyEy4AVJLyeHKnN+HOTSzkuohD34vlXPG8Yqss07Lced7n82uVyqYnRL 6F2I+VVrAF3tSjtOErItdMq4myZBMl3BiXNko4p3LjWg8EIsvBzPmU0cwhex17SUsk+L 8bKTNl/xHQ9qQkfJiI0x9ADE2HvVNcDedgt/XvyREJcJjNbeoZ/3RRhPEKRws6nmksf+ aYQnRBF+19WPcqNoCPbfkCX66Wr33DOmsyflkbDbS0RxOh5m0CUPdYEMe94S2kjWmVuv 9EAA== MIME-Version: 1.0 Received: by 10.52.64.146 with SMTP id o18mr11341532vds.55.1340792294314; Wed, 27 Jun 2012 03:18:14 -0700 (PDT) Received: by 10.52.166.102 with HTTP; Wed, 27 Jun 2012 03:18:14 -0700 (PDT) In-Reply-To: <4FEA6677.3020705@it.aoyama.ac.jp> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> Date: Wed, 27 Jun 2012 12:18:14 +0200 Message-ID: From: Melvin Carvalho To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: multipart/alternative; boundary=20cf3079bcb66b91e904c371885d Cc: "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 10:18:15 -0000 --20cf3079bcb66b91e904c371885d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 27 June 2012 03:48, "Martin J. D=FCrst" wrote: > On 2012/06/26 21:06, Melvin Carvalho wrote: > >> On 22 May 2012 09:22, Murray S. Kucherawy wrote: >> >> As we prepare to bring webfinger into appsawg, it looks a lot like >>> there=92s substantial discussion just on the point of the proposed =93a= cct:=94 >>> scheme.**** >>> >>> ** ** >>> >>> >>> So, a question for those tracking the discussion: Is this a big enough >>> topic that it should be split into its own document? This would be a >>> useful thing to decide as we figure out how to handle the work once it >>> enters working group mode.**** >>> >> > Others have pointed out that it's only a page or two. In my opinion, that > would strongly suggest a single document. I agree with others that it would be good for acct: to have its own document. Webfinger describes itself as scheme "agnostic" which I think is the right way to be. This also means that both acct: and webfinger can be evaluated, and further developed, on their own merits. > > > > There has been some discussion of this here and on other lists, and the >> consensus I think is for people to follow the process at : >> >> . >> > > Warning: procedural nitpicking ahead! > > I think we should be careful about this. uri-review@ietf.org is for > review of URI/IRI schemes in general. This has a rather low barrier. The > fact that it gets approved there doesn't mean that it will pass through t= he > IETF standardization process. On the other hand, if the IETF standardizes > it, it has the possibility of overriding the decision on > uri-review@ietf.org if that should be necessary. > I'm just mentioning this here because we have been through this for > another URI scheme. > > So I think the correct use of mailing lists would be: > > apps-discuss@ietf.org: (or a dedicated WG if that gets created) General > discussion of scheme, working towards IETF standardization. > > uri-review@ietf.org: Comments from URI/IRI experts, check of basic > criteria for registrability, ... > > public-iri@w3.org (the mailing list of the IETF IRI WG): General > discussion about registration criteria for new IRI schemes, for RFC 4395b= is. > > tag@w3.org (I'm just mentioning this list because that's where the most > discussion so far has taken place): General discussion as it relates to W= eb > architecture. > > Regards, Martin. > --20cf3079bcb66b91e904c371885d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 27 June 2012 03:48, "Martin J. D= =FCrst" <duerst@it.aoyama.ac.jp> wrote:
On 2012/06/26 21:06, Melvin Carvalho wrote:
On 22 May 2012 09:22, Murray S. Kucherawy<msk@cloudmark.com> =A0wrote:

=A0As we prepare to bring webfinger into appsawg, it looks a lot like
there=92s substantial discussion just on the point of the proposed =93acct:= =94
scheme.****

** **


So, a question for those tracking the discussion: =A0Is this a big enough topic that it should be split into its own document? =A0This would be a
useful thing to decide as we figure out how to handle the work once it
<= /div> enters working group mode.****

Others have pointed out that it's only a page or two. In my opinion, th= at would strongly suggest a single document.

I agree w= ith others that it would be good for acct: to have its own document.

Webfinger describes itself as scheme "agnostic" which I think= is the right way to be.

This also means that both acct: and webfing= er can be evaluated, and further developed, on their own merits.
=A0
<= br>

There has been some discussion of this here and on other lists, and the
consensus I think is for people to follow the process at :

<uri-review@iet= f.org>.

Warning: procedural nitpicking ahead!

I think we should be careful about this. uri-review@ietf.org is for review of URI/IRI sch= emes in general. This has a rather low barrier. The fact that it gets appro= ved there doesn't mean that it will pass through the IETF standardizati= on process. On the other hand, if the IETF standardizes it, it has the poss= ibility of overriding the decision on uri-review@ietf.org if that should be necessary. I'm just mentioning this here because we have been through this for ano= ther URI scheme.

So I think the correct use of mailing lists would be:

apps-discuss@iet= f.org: (or a dedicated WG if that gets created) General discussion of s= cheme, working towards IETF standardization.

uri-review@ietf.or= g: Comments from URI/IRI experts, check of basic criteria for registrab= ility, ...

public-iri@w3.org (the mailing list of the IETF IRI WG): General discussion about registrat= ion criteria for new IRI schemes, for RFC 4395bis.

tag@w3.org (I'm jus= t mentioning this list because that's where the most discussion so far = has taken place): General discussion as it relates to Web architecture.

Regards, =A0 =A0Martin.

--20cf3079bcb66b91e904c371885d-- From mnot@mnot.net Wed Jun 27 03:39: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 444EC21F86C7 for ; Wed, 27 Jun 2012 03:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.593 X-Spam-Level: X-Spam-Status: No, score=-105.593 tagged_above=-999 required=5 tests=[AWL=-2.994, 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 rjENj7eXAOO1 for ; Wed, 27 Jun 2012 03:39:46 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC7921F86BD for ; Wed, 27 Jun 2012 03:39:46 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.196.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4E3BA22E257; Wed, 27 Jun 2012 06:39:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4FEAB40D.3010607@gmx.de> Date: Wed, 27 Jun 2012 20:39:36 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <0D87C65F-06D0-46F3-A520-F83BD3C752D4@mnot.net> References: <4F86F5E9.1040202@gmx.de> <1334247691.2570.8.camel@neutron> <4FEAB40D.3010607@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1278) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 10:39:47 -0000 On 27/06/2012, at 5:19 PM, Julian Reschke wrote: >> 2. Some URI parsers normalize the URI (i.e. expand %2F into '/') = before >> any JSON Pointer parsing code can get a chance to see it. >=20 > Again; don't use a URI parser. Just %-unescape. I thought the point here was that if it appeared in a URI, it would be = prone to being escaped at the wrong time. Unless you're talking about double-percent-escaping, which I really hope = you're not. Cheers, -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Wed Jun 27 04:33: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 BAC4D21F86BA for ; Wed, 27 Jun 2012 04:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhvJXWjjr+CN for ; Wed, 27 Jun 2012 04:33:49 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3B9AC21F86B1 for ; Wed, 27 Jun 2012 04:33:48 -0700 (PDT) Received: (qmail invoked by alias); 27 Jun 2012 11:33:46 -0000 Received: from unknown (EHLO [42.1.1.153]) [192.147.117.12] by mail.gmx.net (mp019) with SMTP; 27 Jun 2012 13:33:46 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19GPltywadGrsswGGr4dUrxpv5xVeP1TVo4h0oiu6 d26z3eTIFafFx/ Message-ID: <4FEAEF96.8020301@gmx.de> Date: Wed, 27 Jun 2012 13:33:42 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mark Nottingham References: <4F86F5E9.1040202@gmx.de> <1334247691.2570.8.camel@neutron> <4FEAB40D.3010607@gmx.de> <0D87C65F-06D0-46F3-A520-F83BD3C752D4@mnot.net> In-Reply-To: <0D87C65F-06D0-46F3-A520-F83BD3C752D4@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 11:33:49 -0000 On 2012-06-27 12:39, Mark Nottingham wrote: > > On 27/06/2012, at 5:19 PM, Julian Reschke wrote: > >>> 2. Some URI parsers normalize the URI (i.e. expand %2F into '/') before >>> any JSON Pointer parsing code can get a chance to see it. >> >> Again; don't use a URI parser. Just %-unescape. > > I thought the point here was that if it appeared in a URI, it would be prone to being escaped at the wrong time. > > Unless you're talking about double-percent-escaping, which I really hope you're not. No, I wasn't; I misunderstood the issue. So the problem is about *preserving* the escaped slash when processing the URI. Test: - a JSON name of "a/b" - the JSON pointer would be "a%2Fb" - embedded into a URI it might show up as: "http://example.com/a%2Fb" - parsing this might loose the escaping too early, returning a hier-part (http://greenbytes.de/tech/webdav/rfc3986.html#components) of "/a/b" instead of "/a%2AFb"? This may indeed be a problem. Best regards, Julian From alexey.melnikov@isode.com Wed Jun 27 08:00: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 3AAF821F8720 for ; Wed, 27 Jun 2012 08:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.777 X-Spam-Level: X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=-0.178, 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 tMQ-lO6rnVPz for ; Wed, 27 Jun 2012 08:00:25 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C78721F8763 for ; Wed, 27 Jun 2012 08:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1340809204; d=isode.com; s=selector; i=@isode.com; bh=QoMYwQdnawyq1UP29F1HlOhbKEXJjDiwJ2PyUrK43Tk=; 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=mbX6cvfEtsRPK65IoQ6Sb+IH06pGtoD83HdLt9MONCiXamas/4UgI/VLAl3af5K/WK0ym0 AEKr7XlxOGo8T7t6cq294z93kXibOYJ6TduaKxS3NdhtQBwDI8Y4MIExfTzzfom3xzAWhc qt2syL7xohM9xU27g0NJCvyHrVJbF/4=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 27 Jun 2012 16:00:04 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FEB2003.9000508@isode.com> Date: Wed, 27 Jun 2012 16:00:19 +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" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:00:26 -0000 Dear WG participants, The Working Group Last Call for this document has ended and there were a couple of updates to it to address issues (-03 and -04). I believe all issues were addressed, but it would be good for the WG to check the latest version and confirm that. If one of your issues is not addressed (and especially if it wasn't replied to), please let me know. In the meantime, I've started working on the shepherding write-up before asking our AD Barry to review and initiate IETF Last Call for the document. Thank you, Alexey, as an APPSAWG co-chair. From jhildebr@cisco.com Wed Jun 27 00:13: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 1ACA911E80E3 for ; Wed, 27 Jun 2012 00:13:24 -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 dx6aYNNwV-hw for ; Wed, 27 Jun 2012 00:13:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 03A6A11E80CB for ; Wed, 27 Jun 2012 00:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=3604; q=dns/txt; s=iport; t=1340781203; x=1341990803; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=fTXhL5GH90w8RoDataJPB27wQhrKyThgVkaeM7dvOfM=; b=eEG1QkKMVs0twY7MiQmxvPv5mJOjN/l3ZkDNShMwkS6daJRxZPN1vkAb 2w0OZK9uRe85Ov6vOewyRWYn/H35K6iE9R4JC+2a2hpRvRIYkXiGIHdaP tJ+JIoShBBF3wfdi3JtwulvbM/oABEnF40YS+27EdP+MZpwjUHqzUqULo A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKyx6k+tJV2a/2dsb2JhbABFtjSBB4IYAQEBAwEBAQEPAScCATELBQ0BCA4KVTABAQQBDQUih2QFC5kpoCKLNwoahWYDiEqMaIESjQuBZoJ+ X-IronPort-AV: E=Sophos;i="4.77,481,1336348800"; d="scan'208";a="96396929" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jun 2012 07:13:22 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5R7DMKg032548; Wed, 27 Jun 2012 07:13:22 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jun 2012 02:13:22 -0500 Received: from 10.21.94.83 ([10.21.94.83]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Jun 2012 07:13:22 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Wed, 27 Jun 2012 01:13:21 -0600 From: Joe Hildebrand To: Mark Nottingham , IETF Apps Discuss Message-ID: Thread-Topic: #3: json-pointer escape characters Thread-Index: Ac1UNFVQzgwqj024L0i4i2zwjhYVlg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Jun 2012 07:13:22.0472 (UTC) FILETIME=[56315A80:01CD5434] X-Mailman-Approved-At: Wed, 27 Jun 2012 08:01:57 -0700 Cc: Julian Reschke Subject: Re: [apps-discuss] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 07:13:24 -0000 I'll say that I wish that we had found a way to use %-escaping for XEP-106 (http://xmpp.org/extensions/xep-0106.html), and that I wish I could go back in time and talk then-me out of caring about the edge case that drove us there. I think argument #1 is irrelevant; implementing %-escaping from scratch is easy. Argument #2 makes sense, but one could specify that in URI contexts, you %-encode '%' as %25, so to match a literal '/', you specify %252F in URI-land. Regardless, if everyone else likes ^, I'll still use JSON-pointer, and will merely shake my fist at the heavens a little every time I have to implement another encoder and decoder in a new programming language. On 6/26/12 8:32 PM, "Mark Nottingham" wrote: > This is . > > The current draft uses ^, and Paul explains why the draft chose that over > %-encoding. > > I haven't seen any response to Paul's message. Julian (and Joe, who also > supported this), are you OK with leaving it as-is? > > Regards, > > > > On 13/04/2012, at 2:21 AM, Paul C. Bryan wrote: > >> This takes us back to a previous version of JSON Pointer, which in fact did >> use URI escaping of %2F to distinguish between the '/' token delimiter and a >> '/' character within a token. IIRC, the objections that lead us to change >> were: >> >> 1. It requires URI decoding logic in non-URI-processing code (e.g. when >> pointers are used in JSON strings rather than in URI fragment identifiers). >> This has always been a somewhat weak argument, IMO. >> >> 2. Some URI parsers normalize the URI (i.e. expand %2F into '/') before any >> JSON Pointer parsing code can get a chance to see it. >> >> In response to this, I went down the path of using a single escape character. >> If we can overcome these objections, I'd be happy to entertain returning to >> URI escaping. >> >> Paul >> >> On Thu, 2012-04-12 at 17:34 +0200, Julian Reschke wrote: >>> Hi there, >>> >>> right now, the draft escapes forward slashes in reference tokens using >>> ^-escapes, that is: >>> >>> a/b >>> >>> becomes >>> >>> a^/b >>> >>> and >>> >>> a^b >>> >>> becomes >>> >>> a^^b >>> >>> (Reminder: previously "\" was used, but it results in ugly double >>> escaping when the pointer occurs in a JSON string). >>> >>> A drawback of this scheme is that when the pointer is used inside a URI, >>> such as the path component of a an HTTP URI, the / still needs to be >>> escaped, so the name >>> >>> a/b >>> >>> becomes the pointer >>> >>> a^/b >>> >>> and would end up as >>> >>> a%5e%2fb >>> >>> in the URI. >>> >>> >>> An alternate proposal I heard during the IETF meeting in Paris was to >>> simply apply URI percent escaping to the characters in the URI >>> gen-delims range: >>> >>> gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" >>> >>> so >>> >>> a/b >>> >>> would simply become >>> >>> a%2fb >>> >>> and wouldn't need any further escaping in a URI path component. >>> >>> Feedback appreciated, >>> >>> Julian >>> _______________________________________________ >>> 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 > > -- > Mark Nottingham http://www.mnot.net/ > > > -- Joe Hildebrand From GK@ninebynine.org Wed Jun 27 10:13: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 4F13A21F865C for ; Wed, 27 Jun 2012 10:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YC9Q1L-o8RyW for ; Wed, 27 Jun 2012 10:13:20 -0700 (PDT) Received: from relay9.mail.ox.ac.uk (relay9.mail.ox.ac.uk [163.1.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 17BFC21F8653 for ; Wed, 27 Jun 2012 10:13:20 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay9.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1Sjvnm-00086s-TL; Wed, 27 Jun 2012 18:13:14 +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 1Sjvnl-0003SV-56; Wed, 27 Jun 2012 18:13:14 +0100 Message-ID: <4FEB3060.1040805@ninebynine.org> Date: Wed, 27 Jun 2012 17:10:08 +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: SM References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> In-Reply-To: <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:13:21 -0000 On 27/06/2012 07:06, SM wrote: > Hi Martin, > At 18:48 26-06-2012, Martin J. Drst wrote: >> Warning: procedural nitpicking ahead! >> >> I think we should be careful about this. uri-review@ietf.org is for review of >> URI/IRI schemes in general. This has a rather low barrier. The fact that it >> gets approved there doesn't mean that it will pass through the IETF >> standardization process. On the other hand, if the IETF standardizes it, it >> has the possibility of overriding the decision on uri-review@ietf.org if that >> should be necessary. >> I'm just mentioning this here because we have been through this for another >> URI scheme. > > I don't like the idea of mixing registration criteria and the standardization > process. The authors of the other URI scheme were nice not to turn such a matter > into an issue. This is the sort of issue which generate controversies. It will > be detrimental to the IETF as people will walk away. FWIW, as URI scheme reviewer, I would generally regard achieving standards-track status as demonstrating satisfaction of criteria for permanent registration. It's one of the strongest expressions of community consensus that I know of. As far as I'm aware, the URI-review list doesn't make decisions, but it does provide a pool of comments that can help to indicate the level of consensus for a proposal, and highlight if there are any potential problems that need to be addressed. Considering the role of the reviewer as more concierge than gatekeeper, this helps me to make hopefully constructive comments to a submitter. #g -- From wmills@yahoo-inc.com Wed Jun 27 10:27: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 2D9A921F8687 for ; Wed, 27 Jun 2012 10:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.544 X-Spam-Level: X-Spam-Status: No, score=-17.544 tagged_above=-999 required=5 tests=[AWL=0.054, 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 HrCM6woulOdO for ; Wed, 27 Jun 2012 10:27:14 -0700 (PDT) Received: from nm23-vm3.bullet.mail.ne1.yahoo.com (nm23-vm3.bullet.mail.ne1.yahoo.com [98.138.91.153]) by ietfa.amsl.com (Postfix) with SMTP id 4BB4221F867D for ; Wed, 27 Jun 2012 10:27:14 -0700 (PDT) Received: from [98.138.90.52] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 27 Jun 2012 17:27:11 -0000 Received: from [98.138.88.235] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 27 Jun 2012 17:27:11 -0000 Received: from [127.0.0.1] by omp1035.mail.ne1.yahoo.com with NNFMP; 27 Jun 2012 17:27:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 173397.41035.bm@omp1035.mail.ne1.yahoo.com Received: (qmail 11855 invoked by uid 60001); 27 Jun 2012 17:27:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1340818030; bh=LZ8OPxebVCVzOBp9TyJ3TAR/gY5u0ar+7O6gNxMLiFE=; 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=sCrmgh2ac9y2zqLcJjIepRI84Kdue6hPpGIPoNLpqqyB/CAt6udQhfOr/sczk+yiqXyZsqk6af70yyUpDTHsVqYuWZmpQQiayQcAhtN8RXVQRjrjcoisBOR7rKjh3xHV+vrIkZL96ih2MOp8eKoaxxyv6S09GSG+qEsbYqWK43M= 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=IrdH1V0SKXohokCfGXAYgv5WsXlLik3MnoWYYIWhGf+alq6LNi4EB5kdXhKDztVKmWxV0+A1qC8bCJghga8Rq7RttWYsyDAnyzZHa20+5+ko2ofnkTbtuNnsRZi/VrOovwh7ghx2rocdQXtYtjmt6I4V07Vl1dXMuryFed+LF94=; X-YMail-OSG: KE5XhSoVM1myo06cBi__e6HLVafsy1b6EcQAPXF5YCPN9OV egWlMZDdymhzzvRE02wI0DKHnlJcKulHVpODeY2NqgJ0_X9sM4W8FF.xVDa0 RyyQB8tROSBmkRXBOYmXw4OB..TTLfqs0tPp2B.1PW2RJ3IOj0wD7sFdpi0F ndMWIUkVxEmVWvKgd1QtGqC49f7UN_WnG4U.PA5k1ix9fjUi7pizUmu0zr1V Uy8OPIGUMSnvBKxG5T9MSU_QP8N9FFP8gVmNrvMmxNtNR65ZfOUmhqEHxXlz T8IP0E0og6vN6J9oW3ggjRsxySpZG0TUOQYpuOqi26ILGwDuox2J5nJNbU0u 1lWcjNAREmJRBQCrkkcUFZU1Y12GZpZGxhzUbjLDLPGR3AKjk37lZLoResva hwWnWqyIeUf_.XD0abtaKTT.qcDKqJfmTNDI26S7_T9RFQWJM92ZZYh9s Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Wed, 27 Jun 2012 10:27:10 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> <4FEB3060.1040805@ninebynine.org> Message-ID: <1340818030.8183.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Wed, 27 Jun 2012 10:27:10 -0700 (PDT) From: William Mills To: Graham Klyne , SM In-Reply-To: <4FEB3060.1040805@ninebynine.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-1854079672-1340818030=:8183" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 27 Jun 2012 17:27:15 -0000 ---1055047407-1854079672-1340818030=:8183 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Based on the comments to date is there consensus for a path forward?=A0 Wil= l we leave acct: in the WF draft or split it out?=A0 =0A=0AIf we're splitti= ng it do we have someone stepping up to author the new draft?=0A=0AThanks,= =0A=0A-bill=0A ---1055047407-1854079672-1340818030=:8183 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Based on = the comments to date is there consensus for a path forward?  Will we l= eave acct: in the WF draft or split it out? 

If we're splittin= g it do we have someone stepping up to author the new draft?

Thanks,=

-bill
---1055047407-1854079672-1340818030=:8183-- From paulej@packetizer.com Wed Jun 27 13:32: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 37F7921F859A for ; Wed, 27 Jun 2012 13:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4KPZ+zjTKVL for ; Wed, 27 Jun 2012 13:32:34 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3226421F858A for ; Wed, 27 Jun 2012 13:32:34 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5RKVvtC015978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 16:31:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340829118; bh=94dpecFcbyV9fAJMkFtK6Ori3SWJDBUG98MwDYDm31k=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Pqyi4krCWEzqZ7YrRLp7x+hjBGZX9PDVrWZcwL8tZ72jQS4bnikkutsNNIfI7lr8F 062/WHp6ZVrZXnO5b2G+0PDlotXX/QFlaRnRAu0/iIZqog8EMQOo7IZHUmuG5YUrua HR/74HL7/aVdwTgZJWzzXsm5e1/9o2/Kkh+n+BOQ= From: "Paul E. Jones" To: "'John Bradley'" , "'Bob Wyman'" References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE9BFF9.9060403@stpeter.im> In-Reply-To: Date: Wed, 27 Jun 2012 16:32:04 -0400 Message-ID: <041801cd54a3$eab957b0$c02c0710$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0419_01CD5482.63A8A210" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHACExhZgXedi2je/bJAOmWfz8jRwJIaUzKAl3mCNAByYqi0gNXlyRpAi7E+PWWyYTXsA== Content-Language: en-us Cc: apps-discuss@ietf.org, "'Murray S. Kucherawy'" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:32:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0419_01CD5482.63A8A210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit No, no. I think overloading http is a bad idea. http has a very well-defined purpose in life. Yes, we could do this: http://packetizer.com/acct/ But, that steps on the namespace of domain owners. I do not think it would be good practice for RFCs to dictate to domain owners how to use their namespace. We need something predictable and simple. acct:paulej@packetizer.com is precisely that. Paul From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley Sent: Tuesday, June 26, 2012 10:43 AM To: Bob Wyman Cc: apps-discuss@ietf.org; Murray S. Kucherawy Subject: Re: [apps-discuss] The acct: scheme question I would change the account link relation to use the http: scheme. acct: is unnecessary for the link relation, other link relations don't require a new scheme. That is one of the biggest things people will object to about acct: Yes if acct: is registered it looks nicer I will give you that. John B. On 2012-06-26, at 10:36 AM, Bob Wyman wrote: I would leave acct: link relation in the WebFinger spec. I can see no utility in breaking it out. Nothing but additional process overhead and more fragmentation of the specs will result from breaking it out. bob wyman On Tue, Jun 26, 2012 at 9:58 AM, Peter Saint-Andre wrote: On 6/26/12 7:20 AM, Mike Jones wrote: > Yes, I believe that the acct: scheme should be considered separately > from discovery, in its own document. Personally I have no strong preference, although given that the relevant sections of draft-jones-appsawg-webfinger-06 take up about a page, it will be quite a brief specification. :) http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06#section-6 http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06#section-12.1 Do folks think that the 'acct' link relation would belong in the webfinger spec, in the 'acct' URI spec, or in a separate spec? 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 ------=_NextPart_000_0419_01CD5482.63A8A210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, no… I think overloading http is a bad = idea.

 

http has a very well-defined purpose in life.  Yes, we could do = this:

 

http://packetizer.com/acct= /<user_id>

 

But, that steps on the namespace of domain owners.  I do not = think it would be good practice for RFCs to dictate to domain owners how = to use their namespace.

 

We need something predictable and simple. acct:paulej@packetizer.com = is precisely that.

 

Paul

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of John Bradley
Sent: Tuesday, June 26, 2012 = 10:43 AM
To: Bob Wyman
Cc: apps-discuss@ietf.org; = Murray S. Kucherawy
Subject: Re: [apps-discuss] The acct: = scheme question

 

I would = change the account link relation to use the http: scheme.  acct: is = unnecessary for the link relation, other link relations don't require a = new scheme.

 

That is one of the biggest things people will object = to about acct:

 

Yes if acct: is registered it looks nicer I will give = you that.

 

 

John B.

 

On 2012-06-26, at 10:36 AM, Bob Wyman = wrote:



I would = leave acct: link relation in the WebFinger spec.

 

I = can see no utility in breaking it out. Nothing but additional process = overhead and more fragmentation of the specs will result from breaking = it out.

 

bob wyman

 

On Tue, = Jun 26, 2012 at 9:58 AM, Peter Saint-Andre <stpeter@stpeter.im> = wrote:

On 6/26/12 7:20 AM, Mike Jones = wrote:
> Yes, I believe that the acct: scheme should be considered = separately
> from discovery, in its own = document.

Personally I have no = strong preference, although given that the relevant
sections of = draft-jones-appsawg-webfinger-06 take up about a page, it
will be = quite a brief specification. :)

http://tools.ietf.org/html/draft-jones-appsawg-webfinge= r-06#section-6
http://tools.ietf.org/html/draft-jones-appsawg-webfinge= r-06#section-12.1

Do folks think that the 'acct' link = relation would belong in the
webfinger spec, in the 'acct' URI spec, = or in a separate spec?


Peter

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



<= /div>

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

 

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

 

------=_NextPart_000_0419_01CD5482.63A8A210-- From paulej@packetizer.com Wed Jun 27 13:40: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 3838421F85D3 for ; Wed, 27 Jun 2012 13:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+mEkANSYrs0 for ; Wed, 27 Jun 2012 13:40:04 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D117821F85D5 for ; Wed, 27 Jun 2012 13:40:02 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5RKdGCu016222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 16:39:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340829557; bh=cra+Oj3kgW0Lo2JbQMs6lQUFttRo+v4n/VWhCnxhEvI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=LgdVQdfKhq7sV8/SiBqDBep8rpCQGCcoqP/VBZA9Td7CwolWQhnawh9JAYeZNWSKt GM9b2GpWl0KoB4af8rQAiA/V2rJe3RNQDt9PHPxc5PMypwoA4u3Dx2M+OsyxA7qHld vGaNvqucLPveDh186XO9JHBcomvejDLwPHCZDuuE= From: "Paul E. Jones" To: "'John Bradley'" , "'Peter Saint-Andre'" References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE9BFF9.9060403@stpeter.im> <035988BC-A9BC-4397-8593-D5F84710ECF3@ve7jtb.com> <4FE9C9D4.5060106@stpeter.im> <49510B16-56BF-4445-8865-4FE3CF6ED99C@ve7jtb.com> In-Reply-To: <49510B16-56BF-4445-8865-4FE3CF6ED99C@ve7jtb.com> Date: Wed, 27 Jun 2012 16:39:24 -0400 Message-ID: <042501cd54a4$f0b054b0$d210fe10$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0426_01CD5483.699F9F10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHACExhZgXedi2je/bJAOmWfz8jRwJIaUzKAl3mCNAByYqi0gHWboHrAbhZHT0Bauk3hpbN6yag Content-Language: en-us Cc: apps-discuss@ietf.org, "'Murray S. Kucherawy'" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:40:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0426_01CD5483.699F9F10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit John, That's correct, but not a function of the WebFinger draft, but one of RFC 6415. The URI template accepts URIs, not bits and pieces of URIs. We had discussed long ago to use only "paulej@packetizer.com", for example, but the group decided to use URIs and "acct" was the preferred URI scheme to refer to user accounts. What I've been doing was trying to document the agreements various folks had reached on WebFinger. Don't shoot the messenger. That said, I don't see a good reason to backtrack at this point. The "acct" URI scheme is out in the wild, its use has a limited scope and specific purpose, etc. If we were to separate them, we would have the question thrust upon us of "what URI scheme do I use to refer to paulej's Twitter account?" It's not mailto. It should not be http. I do agree with the group who reached the consensus before that "acct" is a reasonable way forward. Nobody was in love with "acct", but nothing else worked better. Paul From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley Sent: Tuesday, June 26, 2012 11:12 AM To: Peter Saint-Andre Cc: apps-discuss@ietf.org; Murray S. Kucherawy Subject: Re: [apps-discuss] The acct: scheme question The "resource" parameter is currently a fully qualified URI, and that is normalized to acct: The template paramater {uri} also precludes relative URI as near as I can tell. Perhaps Paul can correct me, but I think that the request. GET /.well-known/host-meta.json?resource=foo@bar.com HTTP/1.1 Host: bar.com Is not allowed by the spec, or be interoperable. The goal of SWD was to make the above (slightly different syntax same idea) work. There are a lot of places in the spec where the acct: uri and normalizing things to it are baked in. There are likely also issues with host-meta as that is where the template is defined. Paul's likely reaction will be that separating them is not trivial, and he may be correct in that. On the other hand it is probably the right thing to do, even if it touches a bunch of things. John B. On 2012-06-26, at 10:40 AM, Peter Saint-Andre wrote: On 6/26/12 8:37 AM, John Bradley wrote: The current spec requires normalization of bare identifiers i.e. foo@bar.com to acct:foo@bar.com. That would also need to change if we separate the specs. In what way would it need to change? Peter -- Peter Saint-Andre https://stpeter.im/ ------=_NextPart_000_0426_01CD5483.699F9F10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John,

 

That’s correct, but not a function of the WebFinger draft, but = one of RFC 6415.  The URI template accepts URIs, not bits and = pieces of URIs.

 

We had discussed long ago to use only = “paulej@packetizer.com”, for example, but the group decided = to use URIs and “acct” was the preferred URI scheme to refer = to user accounts.

 

What I’ve been doing was trying to document the agreements = various folks had reached on WebFinger.  Don’t shoot the = messenger.  That said, I don’t see a good reason to backtrack = at this point.  The “acct” URI scheme is out in the = wild, its use has a limited scope and specific purpose, = etc.

 

If we were to separate them, we would have the question thrust upon = us of “what URI scheme do I use to refer to paulej’s Twitter = account?”  It’s not mailto.  It should not be = http.  I do agree with the group who reached the consensus before = that “acct” is a reasonable way forward.  Nobody was in = love with “acct”, but nothing else worked = better.

 

Paul

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of John Bradley
Sent: Tuesday, June 26, 2012 = 11:12 AM
To: Peter Saint-Andre
Cc: = apps-discuss@ietf.org; Murray S. Kucherawy
Subject: Re: = [apps-discuss] The acct: scheme = question

 

The = "resource" parameter is currently a fully qualified URI, and = that is normalized to acct:

 

The template paramater {uri} also precludes relative = URI as near as I can tell.

 

Perhaps Paul can correct me,  but I think that = the request.

 

GET /.well-known/host-meta.json?resource=3Dfoo@bar.com =
HTTP/1.1
Host: =
bar.com

 

Is not allowed by the spec, or be interoperable. =    The goal of SWD was to make the above (slightly different = syntax same idea) work.

 

There are a lot of places in the spec where the acct: = uri and normalizing things to it are baked = in.

 

There are likely also issues with host-meta as that is = where the template is defined.

 

Paul's likely reaction will be that separating them is = not trivial, and he may be correct in that.

 

On the other hand it is probably the right thing to = do, even if it touches a bunch of things.

 

John B.

 

On = 2012-06-26, at 10:40 AM, Peter Saint-Andre wrote:



On = 6/26/12 8:37 AM, John Bradley wrote:


The current spec requires normalization of bare = identifiers i.e. foo@bar.com to = acct:foo@bar.com.

That = would also need to change if we separate the = specs.


In what way would it need to = change?

Peter

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



=

 

------=_NextPart_000_0426_01CD5483.699F9F10-- From paulej@packetizer.com Wed Jun 27 13:43: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 EF89421F8637 for ; Wed, 27 Jun 2012 13:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taWnLhtsn7TK for ; Wed, 27 Jun 2012 13:43:10 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 88AAD21F8636 for ; Wed, 27 Jun 2012 13:43:10 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5RKh7fK016363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 16:43:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340829788; bh=cqsYZwq9JjgDZfqVezUGq1Z4QgCN4d6JIJHmqtXlEag=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=C+H4SPP08YxGT9p3rM+MNV/3cYw6EQELmkrpAE7hR8M48a8B0EL8YLcs/AmxFj0zw LSqyHwZ5Xw+tnxQvKOLOYAukIhQz8p0YUF3gLOZcUr+hmC4WcN9fsccI/KLOlLk80K faltB7UGDt5KEkH86KjfkjZu5+yF+ZIJF7IMgxsc= From: "Paul E. Jones" To: "'Mike Jones'" , "'William Mills'" , "'Melvin Carvalho'" , "'Murray S. Kucherawy'" References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 27 Jun 2012 16:43:14 -0400 Message-ID: <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0433_01CD5483.F2E2EF20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHACExhZgXedi2je/bJAOmWfz8jRwJIaUzKAl3mCNAA4XnPygFMoDK7lvKWD8A= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:43:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0433_01CD5483.F2E2EF20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I submitted a query to the uri-review list on June 18. So far, there = have been no comments on the list. =20 I do not see a reason why the URI review could not be concluded fairly = quickly regardless of where it is documented. =20 Now, should the URI review process result in rejecting = =E2=80=9Cacct=E2=80=9D then we have to scramble to come up with an = alternative. It cannot simply be left to speculation. We need a = concrete and predictable way of constructing URIs that refer to user = accounts. How do I query a Twitter user=E2=80=99s account? Flickr? = Google+? (Don=E2=80=99t get me started about the Facebook deciding = their email address was my preferred email address...) =20 Paul =20 From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, June 26, 2012 11:18 AM To: William Mills; Melvin Carvalho; Murray S. Kucherawy Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question =20 Yes, there=E2=80=99s a significant advantage. It allows the acct: = scheme to be approved (or rejected) quickly so that we will know whether = it is safe for WebFinger and other specifications to use it. That = approval/rejection can then happen in parallel with refining the = discovery specification. =20 Otherwise, we could be in a position where we think we have a final = discovery specification, only to learn that it can=E2=80=99t go forward = because of objections to the acct: scheme from the W3C and possibly = others. It would be much better for us to know whether that is the case = up front. =20 -- Mike =20 From: William Mills [mailto:wmills@yahoo-inc.com]=20 Sent: Tuesday, June 26, 2012 8:07 AM To: Mike Jones; Melvin Carvalho; Murray S. Kucherawy Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question =20 Is there any advantage to breaking it out? The WF draft depends on it = and so can't finalize until acct: does, right? =20 Will one get done more quickly than the other? =20 _____ =20 From: Mike Jones To: Melvin Carvalho ; Murray S. Kucherawy = =20 Cc: "apps-discuss@ietf.org" =20 Sent: Tuesday, June 26, 2012 6:20 AM Subject: Re: [apps-discuss] The acct: scheme question =20 Yes, I believe that the acct: scheme should be considered separately = from discovery, in its own document. =20 -- Mike =20 From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Melvin Carvalho Sent: Tuesday, June 26, 2012 5:06 AM To: Murray S. Kucherawy Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question =20 =20 On 22 May 2012 09:22, Murray S. Kucherawy wrote: As we prepare to bring webfinger into appsawg, it looks a lot like = there=E2=80=99s substantial discussion just on the point of the proposed = =E2=80=9Cacct:=E2=80=9D scheme. =20 So, a question for those tracking the discussion: Is this a big enough = topic that it should be split into its own document? This would be a = useful thing to decide as we figure out how to handle the work once it = enters working group mode. =20 (This by itself has me wondering if we should revisit the conversation = about whether webfinger needs its own working group, but I=E2=80=99ll = leave it to Barry and Pete to make that call.) There has been some discussion of this here and on other lists, and the = consensus I think is for people to follow the process at : . I think the current state of play is that webfinger can be used with any = URI type e.g. mailto: http: acct: etc. acct: is recommended in the RFC. = =20 -MSK _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss =20 _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_0433_01CD5483.F2E2EF20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I submitted a query to the uri-review list on June 18. So far, there = have been no comments on the list.

 

I do not see a reason why the URI review could not be concluded = fairly quickly regardless of where it is = documented.

 

Now, should the URI review process result in rejecting = =E2=80=9Cacct=E2=80=9D then we have to scramble to come up with an = alternative.=C2=A0 It cannot simply be left to speculation.=C2=A0 We = need a concrete and predictable way of constructing URIs that refer to = user accounts.=C2=A0 How do I query a Twitter user=E2=80=99s = account?=C2=A0 Flickr? Google+?=C2=A0 (Don=E2=80=99t get me started = about the Facebook deciding their email address was my preferred email = address...)

 

Paul

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Mike Jones
Sent: Tuesday, June 26, 2012 = 11:18 AM
To: William Mills; Melvin Carvalho; Murray S. = Kucherawy
Cc: apps-discuss@ietf.org
Subject: Re: = [apps-discuss] The acct: scheme = question

 

Yes, there=E2=80=99s a significant advantage.  It allows the = acct: scheme to be approved (or rejected) quickly so that we will know = whether it is safe for WebFinger and other specifications to use = it.  That approval/rejection can then happen in parallel with = refining the discovery specification.

 

Otherwise, we could be in a position where we think we have a final = discovery specification, only to learn that it can=E2=80=99t go forward = because of objections to the acct: scheme from the W3C and possibly = others.  It would be much better for us to know whether that is the = case up front.

 

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

 

From:= = William Mills [mailto:wmills@yahoo-inc.co= m]
Sent: Tuesday, June 26, 2012 8:07 AM
To: = Mike Jones; Melvin Carvalho; Murray S. Kucherawy
Cc: apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] The acct: scheme = question

 

Is = there any advantage to breaking it out?  The WF draft depends on it = and so can't finalize until acct: does, = right?

 

Will = one get done more quickly than the = other?

 

<= hr size=3D1 width=3D"100%" align=3Dcenter>

F= rom: = Mike Jones <Michael.Jones@microsoft.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>= ; Murray S. Kucherawy <msk@cloudmark.com> =
Cc: "apps-discuss@ietf.org" = <apps-discuss@ietf.org> =
Sent: Tuesday, June 26, 2012 6:20 AM
Subject: Re: = [apps-discuss] The acct: scheme question

 

Yes, I believe that the acct: = scheme should be considered separately from discovery, in its own = document.

 

     &n= bsp;           &nb= sp;           &nbs= p;            = ;            =       -- Mike

 

From: apps-discuss-bounces@ietf.o= rg [mailto:apps-discu= ss-bounces@ietf.org] On Behalf Of Melvin = Carvalho
Sent: Tuesday, June 26, 2012 5:06 AM
To: = Murray S. Kucherawy
Cc: apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] The acct: scheme question

 

 

On 22 May 2012 09:22, Murray S. Kucherawy <msk@cloudmark.com> = wrote:

As we prepare to = bring webfinger into appsawg, it looks a lot like there=E2=80=99s = substantial discussion just on the point of the proposed = =E2=80=9Cacct:=E2=80=9D scheme.

 

So, a question for those tracking the = discussion:  Is this a big enough topic that it should be split = into its own document?  This would be a useful thing to decide as = we figure out how to handle the work once it enters working group = mode.

 

(This by itself has me wondering if we should = revisit the conversation about whether webfinger needs its own working = group, but I=E2=80=99ll leave it to Barry and Pete to make that = call.)


There has = been some discussion of this here and on other lists, and the consensus = I think is for people to follow the process at :

<uri-review@ietf.org>.

I think the = current state of play is that webfinger can be used with any URI type = e.g. mailto: http: acct: etc. acct: is recommended in the RFC.  =

 

-MSK


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

 


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

------=_NextPart_000_0433_01CD5483.F2E2EF20-- From Michael.Jones@microsoft.com Wed Jun 27 13:44:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAF311E8089 for ; Wed, 27 Jun 2012 13:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.786 X-Spam-Level: X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[AWL=-0.188, 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 SZDcjcbmtzrw for ; Wed, 27 Jun 2012 13:44:36 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5290411E8086 for ; Wed, 27 Jun 2012 13:44:36 -0700 (PDT) Received: from mail200-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Jun 2012 20:42:52 +0000 Received: from mail200-ch1 (localhost [127.0.0.1]) by mail200-ch1-R.bigfish.com (Postfix) with ESMTP id 6713032006F; Wed, 27 Jun 2012 20:42:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VS-25(zzbb2dI98dI9371I936eIc85fh1418Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail200-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail200-ch1 (localhost.localdomain [127.0.0.1]) by mail200-ch1 (MessageSwitch) id 1340829769191922_14289; Wed, 27 Jun 2012 20:42:49 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail200-ch1.bigfish.com (Postfix) with ESMTP id 2BFF5A0044; Wed, 27 Jun 2012 20:42:49 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Jun 2012 20:42:48 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0309.003; Wed, 27 Jun 2012 20:44:29 +0000 From: Mike Jones To: "Paul E. Jones" , 'John Bradley' , 'Peter Saint-Andre' Thread-Topic: [apps-discuss] The acct: scheme question Thread-Index: Ac0367W7uVNJxgK+Tf6qpowkmE64wgbqGMQAAAKM2jAAAVwPgAABYvKAAAAVAwAAARlWAAA9u5MAAAAOkqA= Date: Wed, 27 Jun 2012 20:44:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436656BAA3@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE9BFF9.9060403@stpeter.im> <035988BC-A9BC-4397-8593-D5F84710ECF3@ve7jtb.com> <4FE9C9D4.5060106@stpeter.im> <49510B16-56BF-4445-8865-4FE3CF6ED99C@ve7jtb.com> <042501cd54a4$f0b054b0$d210fe10$@packetizer.com> In-Reply-To: <042501cd54a4$f0b054b0$d210fe10$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436656BAA3TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "apps-discuss@ietf.org" , "'Murray S. Kucherawy'" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:44:39 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436656BAA3TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If we separate them, the WebFinger draft would continue to have a normative= dependency on the Acct draft. But practically then the Acct draft could g= o up for working group last call and then IETF last call essentially immedi= ately after the draft is produced and we'd get a clear up/down standards de= cision sooner, rather than later. If you don't have the time to be editor for that draft, I'm willing to do s= o. It won't take more than a few hours to tease apart. -- Mike From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Paul E. Jones Sent: Wednesday, June 27, 2012 1:39 PM To: 'John Bradley'; 'Peter Saint-Andre' Cc: apps-discuss@ietf.org; 'Murray S. Kucherawy' Subject: Re: [apps-discuss] The acct: scheme question John, That's correct, but not a function of the WebFinger draft, but one of RFC 6= 415. The URI template accepts URIs, not bits and pieces of URIs. We had discussed long ago to use only "paulej@packetizer.com", for example, but the group decided to use URIs and "acct"= was the preferred URI scheme to refer to user accounts. What I've been doing was trying to document the agreements various folks ha= d reached on WebFinger. Don't shoot the messenger. That said, I don't see= a good reason to backtrack at this point. The "acct" URI scheme is out in= the wild, its use has a limited scope and specific purpose, etc. If we were to separate them, we would have the question thrust upon us of "= what URI scheme do I use to refer to paulej's Twitter account?" It's not m= ailto. It should not be http. I do agree with the group who reached the c= onsensus before that "acct" is a reasonable way forward. Nobody was in lov= e with "acct", but nothing else worked better. Paul From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley Sent: Tuesday, June 26, 2012 11:12 AM To: Peter Saint-Andre Cc: apps-discuss@ietf.org; Murray S. Kucheraw= y Subject: Re: [apps-discuss] The acct: scheme question The "resource" parameter is currently a fully qualified URI, and that is no= rmalized to acct: The template paramater {uri} also precludes relative URI as near as I can t= ell. Perhaps Paul can correct me, but I think that the request. GET /.well-known/host-meta.json?resource=3Dfoo@bar.com HTTP/1.1 Host: bar.com Is not allowed by the spec, or be interoperable. The goal of SWD was to = make the above (slightly different syntax same idea) work. There are a lot of places in the spec where the acct: uri and normalizing t= hings to it are baked in. There are likely also issues with host-meta as that is where the template i= s defined. Paul's likely reaction will be that separating them is not trivial, and he = may be correct in that. On the other hand it is probably the right thing to do, even if it touches = a bunch of things. John B. On 2012-06-26, at 10:40 AM, Peter Saint-Andre wrote: On 6/26/12 8:37 AM, John Bradley wrote: The current spec requires normalization of bare identifiers i.e. foo@bar.co= m to acct:foo@bar.com. That would also need to change if we separate the specs. In what way would it need to change? Peter -- Peter Saint-Andre https://stpeter.im/ --_000_4E1F6AAD24975D4BA5B16804296739436656BAA3TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If we separate them, the = WebFinger draft would continue to have a normative dependency on the Acct d= raft.  But practically then the Acct draft could go up for working group last call and then IETF last call essentially immediately af= ter the draft is produced and we’d get a clear up/down standards deci= sion sooner, rather than later.

 <= /p>

If you don’t have t= he time to be editor for that draft, I’m willing to do so.  It w= on’t take more than a few hours to tease apart.

 <= /p>

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

 <= /p>

From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Wednesday, June 27, 2012 1:39 PM
To: 'John Bradley'; 'Peter Saint-Andre'
Cc: apps-discuss@ietf.org; 'Murray S. Kucherawy'
Subject: Re: [apps-discuss] The acct: scheme question

 

John,

 <= /p>

That’s correct, but= not a function of the WebFinger draft, but one of RFC 6415.  The URI = template accepts URIs, not bits and pieces of URIs.

 <= /p>

We had discussed long ago= to use only “paulej@packeti= zer.com”, for example, but the group decided to use URIs and “acct” was the preferred URI scheme to refer to user accounts.=

 <= /p>

What I’ve been doin= g was trying to document the agreements various folks had reached on WebFin= ger.  Don’t shoot the messenger.  That said, I don’t = see a good reason to backtrack at this point.  The “acct” URI scheme= is out in the wild, its use has a limited scope and specific purpose, etc.=

 <= /p>

If we were to separate th= em, we would have the question thrust upon us of “what URI scheme do = I use to refer to paulej’s Twitter account?”  It’s n= ot mailto.  It should not be http.  I do agree with the group who reached the con= sensus before that “acct” is a reasonable way forward.  No= body was in love with “acct”, but nothing else worked better.

 <= /p>

Paul

 <= /p>

 

The "resource" parameter is currently a fu= lly qualified URI, and that is normalized to acct:

 

The template paramater {uri} also precludes relative= URI as near as I can tell.

 

Perhaps Paul can correct me,  but I think that = the request.

 

Is not allowed by the spec, or be interoperable. &nb= sp;  The goal of SWD was to make the above (slightly different syntax = same idea) work.

 

There are a lot of places in the spec where the acct= : uri and normalizing things to it are baked in.

 

There are likely also issues with host-meta as that = is where the template is defined.

 

Paul's likely reaction will be that separating them = is not trivial, and he may be correct in that.

 

On the other hand it is probably the right thing to = do, even if it touches a bunch of things.

 

John B.

 

On 2012-06-26, at 10:40 AM, Peter Saint-Andre wrote:=

 

On 6/26/12 8:37 AM, J= ohn Bradley wrote:

The current spec requires normalization of bare iden= tifiers i.e. foo@bar.com to acct:foo@bar.com.

That would also need to change if we separate the sp= ecs.


In what way would it need to change?

Peter

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


 

--_000_4E1F6AAD24975D4BA5B16804296739436656BAA3TK5EX14MBXC283r_-- From paulej@packetizer.com Wed Jun 27 14:50: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 2F1CB21F860B for ; Wed, 27 Jun 2012 14:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dG9x94Y90F6E for ; Wed, 27 Jun 2012 14:50:12 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 701E321F8613 for ; Wed, 27 Jun 2012 14:49:42 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5RLneUA018140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 17:49:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340833781; bh=PDNgCpiHdotYzFClj+VwsvtSYTwVutGBaiMrA4hrjEw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=I1fhqdQt9ObZi1DMT/7qna1DD7oq2T3UjfVyQLuwobyCJ9v5+8PAbaOzdCG3K9jdn nlj1K8gLQak5Wm0q62a9I9sKLmqC9mQKhnFJ7afDKkW3Xvde1fiT5W5FCi6sCeqZ4D zlGIFSsfczhMdzSGDMCdl0EpuLwoiqMFlpcf4zaM= From: "Paul E. Jones" To: "'William Mills'" , "'Graham Klyne'" , "'SM'" References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> <4FEB3060.1040805@ninebynine.org> <1340818030.8183.YahooMailNeo@web31806.mail.mud.yahoo.com> In-Reply-To: <1340818030.8183.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Wed, 27 Jun 2012 17:49:48 -0400 Message-ID: <047501cd54ae$c6848a30$538d9e90$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0476_01CD548D.3F738670" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHACExhZgXedi2je/bJAOmWfz8jRwJIaUzKAmC+4owBc2Np4gGLJqkJAYQI6cyW3+3rcA== Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 21:50:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0476_01CD548D.3F738670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bill, I'd say there is a division right down the middle. It's not clear if there are more in favor of keeping it there or moving it to a separate document. However, there is not an overwhelming number on one side. Moving it to a separate document should not be necessary. We can publish the WF RFC with the "acct" URI scheme and work to get URI reviewer approval in parallel. Is URI reviewer approval required first? I don't think so. Graham suggested that having it agreed in a standards-track RFC carries a lot of weight. It seems that those who want to separate it are mostly concerned that it will delay the RFC publication. That does not appear to be an issue at all. Paul From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of William Mills Sent: Wednesday, June 27, 2012 1:27 PM To: Graham Klyne; SM Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question Based on the comments to date is there consensus for a path forward? Will we leave acct: in the WF draft or split it out? If we're splitting it do we have someone stepping up to author the new draft? Thanks, -bill ------=_NextPart_000_0476_01CD548D.3F738670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bill,

 

I’d say there is a division right down the middle.  = It’s not clear if there are more in favor of keeping it there or = moving it to a separate document.  However, there is not an = overwhelming number on one side.

 

Moving it to a separate document should not be necessary.  We = can publish the WF RFC with the “acct” URI scheme and work = to get URI reviewer approval in parallel.  Is URI reviewer approval = required first?  I don’t think so.  Graham suggested = that having it agreed in a standards-track RFC carries a lot of = weight.

 

It seems that those who want to separate it are mostly concerned that = it will delay the RFC publication.  That does not appear to be an = issue at all.

 

Paul

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of William Mills
Sent: Wednesday, June 27, = 2012 1:27 PM
To: Graham Klyne; SM
Cc: = apps-discuss@ietf.org
Subject: Re: [apps-discuss] The acct: = scheme question

 

Based = on the comments to date is there consensus for a path forward?  = Will we leave acct: in the WF draft or split it out? 

If = we're splitting it do we have someone stepping up to author the new = draft?

Thanks,

-bill

------=_NextPart_000_0476_01CD548D.3F738670-- From Michael.Jones@microsoft.com Wed Jun 27 14:54:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4670811E8095 for ; Wed, 27 Jun 2012 14:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.782 X-Spam-Level: X-Spam-Status: No, score=-3.782 tagged_above=-999 required=5 tests=[AWL=-0.184, 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 or4u-w6wjUQM for ; Wed, 27 Jun 2012 14:54:12 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4574521F8557 for ; Wed, 27 Jun 2012 14:54:12 -0700 (PDT) Received: from mail18-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Jun 2012 21:52:26 +0000 Received: from mail18-va3 (localhost [127.0.0.1]) by mail18-va3-R.bigfish.com (Postfix) with ESMTP id B4ED3A00E2; Wed, 27 Jun 2012 21:52:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz9371Ic85fh4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail18-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail18-va3 (localhost.localdomain [127.0.0.1]) by mail18-va3 (MessageSwitch) id 1340833944850478_2003; Wed, 27 Jun 2012 21:52:24 +0000 (UTC) Received: from VA3EHSMHS045.bigfish.com (unknown [10.7.14.249]) by mail18-va3.bigfish.com (Postfix) with ESMTP id C1D1C260048; Wed, 27 Jun 2012 21:52:24 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS045.bigfish.com (10.7.99.55) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Jun 2012 21:52:24 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0309.003; Wed, 27 Jun 2012 21:53:59 +0000 From: Mike Jones To: "Paul E. Jones" , 'William Mills' , 'Graham Klyne' , 'SM' Thread-Topic: [apps-discuss] The acct: scheme question Thread-Index: Ac0367W7uVNJxgK+Tf6qpowkmE64wgbqGMQAABy4FoAACQTvAAAVEVMAAAKwvAAACSwgAAAAC1Wg Date: Wed, 27 Jun 2012 21:53:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436656BCF0@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> <4FEB3060.1040805@ninebynine.org> <1340818030.8183.YahooMailNeo@web31806.mail.mud.yahoo.com> <047501cd54ae$c6848a30$538d9e90$@packetizer.com> In-Reply-To: <047501cd54ae$c6848a30$538d9e90$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436656BCF0TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 21:54:14 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436656BCF0TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At least based upon my experience with the OAuth Core and OAuth Bearer spec= s, until IESG/IETF last call, a lot of the IESG members don't raise issues,= and then they're often raised as DISCUSS issues, which block publication u= ntil resolved. Sometimes these DISCUSS issues also call for cross-organiza= tional review with the W3C. Until the acct: URI is actually in a spec in IESG/IETF last call, my experi= ence says that we really won't know where we stand. Hence me wanting to ge= t us there as soon after Vancouver as possible. -- Mike From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Paul E. Jones Sent: Wednesday, June 27, 2012 2:50 PM To: 'William Mills'; 'Graham Klyne'; 'SM' Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question Bill, I'd say there is a division right down the middle. It's not clear if there= are more in favor of keeping it there or moving it to a separate document.= However, there is not an overwhelming number on one side. Moving it to a separate document should not be necessary. We can publish t= he WF RFC with the "acct" URI scheme and work to get URI reviewer approval = in parallel. Is URI reviewer approval required first? I don't think so. = Graham suggested that having it agreed in a standards-track RFC carries a l= ot of weight. It seems that those who want to separate it are mostly concerned that it wi= ll delay the RFC publication. That does not appear to be an issue at all. Paul From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of William Mills Sent: Wednesday, June 27, 2012 1:27 PM To: Graham Klyne; SM Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question Based on the comments to date is there consensus for a path forward? Will = we leave acct: in the WF draft or split it out? If we're splitting it do we have someone stepping up to author the new draf= t? Thanks, -bill --_000_4E1F6AAD24975D4BA5B16804296739436656BCF0TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At least based upon my ex= perience with the OAuth Core and OAuth Bearer specs, until IESG/IETF last c= all, a lot of the IESG members don’t raise issues, and then they’re often raised as DISCUSS issues, which block publication unti= l resolved.  Sometimes these DISCUSS issues also call for cross-organi= zational review with the W3C.

 <= /p>

Until the acct: URI is ac= tually in a spec in IESG/IETF last call, my experience says that we really = won’t know where we stand.  Hence me wanting to get us there as soon after Vancouver as possible.

 <= /p>

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

 <= /p>

From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Wednesday, June 27, 2012 2:50 PM
To: 'William Mills'; 'Graham Klyne'; 'SM'
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] The acct: scheme question

 

Bill,

 <= /p>

I’d say there is a = division right down the middle.  It’s not clear if there are mor= e in favor of keeping it there or moving it to a separate document.  H= owever, there is not an overwhelming number on one side.

 <= /p>

Moving it to a separate d= ocument should not be necessary.  We can publish the WF RFC with the &= #8220;acct” URI scheme and work to get URI reviewer approval in paral= lel.  Is URI reviewer approval required first?  I don’t think so.&nbs= p; Graham suggested that having it agreed in a standards-track RFC carries = a lot of weight.

 <= /p>

It seems that those who w= ant to separate it are mostly concerned that it will delay the RFC publicat= ion.  That does not appear to be an issue at all.

 <= /p>

Paul

 <= /p>

--_000_4E1F6AAD24975D4BA5B16804296739436656BCF0TK5EX14MBXC283r_-- From paulej@packetizer.com Wed Jun 27 14:56: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 BAF8011E8093 for ; Wed, 27 Jun 2012 14:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCwwDgufd9PB for ; Wed, 27 Jun 2012 14:56:01 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 65E6C11E808A for ; Wed, 27 Jun 2012 14:56:01 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5RLtwJI018305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 17:55:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340834159; bh=yy65Jw7LQ08BwV12NP5ThuD2gftMskQV184rUtOgqow=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=t0pi2gRWqWceildcs883AHiSXcj3DbDhAIWZKeujjBaDYOPsImKtfCyg4ESQIoKyF JT37zbZi/fBACe6HVUOHV0QE4PVaHQnnwiXpR+e1IfIuvOmyJP244jCkWXPOJSizBx 2Hn4/rpt1TVbpSF/G6kSUJM7H+hNxduX34t0WE8g= From: "Paul E. Jones" To: "'Mike Jones'" , "'John Bradley'" , "'Peter Saint-Andre'" References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE9BFF9.9060403@stpeter.im> <035988BC-A9BC-4397-8593-D5F84710ECF3@ve7jtb.com> <4FE9C9D4.5060106@stpeter.im> <49510B16-56BF-4445-8865-4FE3CF6ED99C@ve7jtb.com> <042501cd54a4$f0b054b0$d210fe10$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436656BAA3@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436656BAA3@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 27 Jun 2012 17:56:06 -0400 Message-ID: <048801cd54af$a7be9ef0$f73bdcd0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0489_01CD548E.20AE8590" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHACExhZgXedi2je/bJAOmWfz8jRwJIaUzKAl3mCNAByYqi0gHWboHrAbhZHT0Bauk3hgJGVCHrAdDReMuWrUgdkA== Content-Language: en-us Cc: apps-discuss@ietf.org, "'Murray S. Kucherawy'" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 21:56:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0489_01CD548E.20AE8590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mike, I would still like to at least try to keep these together. The "acct" URI is a WebFinger URI, so I think it's best to keep them together. It does not seem that approval of the RFC is contingent on the approval of the URI scheme. It could be registered provisionally at first. But, I think it would be approved given that it is already in use and the fact that folks agree to go forward with the document. If folks are absolutely opposed to the URI scheme and wish to hold up WebFinger over it, then we could consider splitting it. I don't hear that, though. I think folks see the value. The only concern is whether approval of the URI scheme might hold up approval of the RFC. That does not seem to be a problem, but perhaps I'm wrong. In any case, I'd prefer to split it out only if we absolutely had to. Paul From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, June 27, 2012 4:44 PM To: Paul E. Jones; 'John Bradley'; 'Peter Saint-Andre' Cc: apps-discuss@ietf.org; 'Murray S. Kucherawy' Subject: RE: [apps-discuss] The acct: scheme question If we separate them, the WebFinger draft would continue to have a normative dependency on the Acct draft. But practically then the Acct draft could go up for working group last call and then IETF last call essentially immediately after the draft is produced and we'd get a clear up/down standards decision sooner, rather than later. If you don't have the time to be editor for that draft, I'm willing to do so. It won't take more than a few hours to tease apart. -- Mike From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, June 27, 2012 1:39 PM To: 'John Bradley'; 'Peter Saint-Andre' Cc: apps-discuss@ietf.org; 'Murray S. Kucherawy' Subject: Re: [apps-discuss] The acct: scheme question John, That's correct, but not a function of the WebFinger draft, but one of RFC 6415. The URI template accepts URIs, not bits and pieces of URIs. We had discussed long ago to use only "paulej@packetizer.com", for example, but the group decided to use URIs and "acct" was the preferred URI scheme to refer to user accounts. What I've been doing was trying to document the agreements various folks had reached on WebFinger. Don't shoot the messenger. That said, I don't see a good reason to backtrack at this point. The "acct" URI scheme is out in the wild, its use has a limited scope and specific purpose, etc. If we were to separate them, we would have the question thrust upon us of "what URI scheme do I use to refer to paulej's Twitter account?" It's not mailto. It should not be http. I do agree with the group who reached the consensus before that "acct" is a reasonable way forward. Nobody was in love with "acct", but nothing else worked better. Paul From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of John Bradley Sent: Tuesday, June 26, 2012 11:12 AM To: Peter Saint-Andre Cc: apps-discuss@ietf.org; Murray S. Kucherawy Subject: Re: [apps-discuss] The acct: scheme question The "resource" parameter is currently a fully qualified URI, and that is normalized to acct: The template paramater {uri} also precludes relative URI as near as I can tell. Perhaps Paul can correct me, but I think that the request. GET /.well-known/host-meta.json?resource=foo@bar.com HTTP/1.1 Host: bar.com Is not allowed by the spec, or be interoperable. The goal of SWD was to make the above (slightly different syntax same idea) work. There are a lot of places in the spec where the acct: uri and normalizing things to it are baked in. There are likely also issues with host-meta as that is where the template is defined. Paul's likely reaction will be that separating them is not trivial, and he may be correct in that. On the other hand it is probably the right thing to do, even if it touches a bunch of things. John B. On 2012-06-26, at 10:40 AM, Peter Saint-Andre wrote: On 6/26/12 8:37 AM, John Bradley wrote: The current spec requires normalization of bare identifiers i.e. foo@bar.com to acct:foo@bar.com. That would also need to change if we separate the specs. In what way would it need to change? Peter -- Peter Saint-Andre https://stpeter.im/ ------=_NextPart_000_0489_01CD548E.20AE8590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mike,

 

I would still like to at least try to keep these = together.  The “acct” URI is a WebFinger URI, so I = think it’s best to keep them together.  It does not seem that = approval of the RFC is contingent on the approval of the URI = scheme.  It could be registered provisionally at first.  But, = I think it would be approved given that it is already in use and the = fact that folks agree to go forward with the = document.

 

If folks are absolutely opposed to the URI scheme and wish to hold up = WebFinger over it, then we could consider splitting it.  I = don’t hear that, though.  I think folks see the value.  = The only concern is whether approval of the URI scheme might hold up = approval of the RFC.  That does not seem to be a problem, but = perhaps I’m wrong.

 

In any case, I’d prefer to split it out only if we absolutely = had to.

 

Paul

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: = Wednesday, June 27, 2012 4:44 PM
To: Paul E. Jones; 'John = Bradley'; 'Peter Saint-Andre'
Cc: apps-discuss@ietf.org; = 'Murray S. Kucherawy'
Subject: RE: [apps-discuss] The acct: = scheme question

 

If we separate them, the WebFinger draft would continue to have a = normative dependency on the Acct draft.  But practically then the = Acct draft could go up for working group last call and then IETF last = call essentially immediately after the draft is produced and we’d = get a clear up/down standards decision sooner, rather than = later.

 

If you don’t have the time to be editor for that draft, = I’m willing to do so.  It won’t take more than a few = hours to tease apart.

 

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

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discu= ss-bounces@ietf.org] On Behalf Of Paul E. = Jones
Sent: Wednesday, June 27, 2012 1:39 PM
To: = 'John Bradley'; 'Peter Saint-Andre'
Cc: apps-discuss@ietf.org; 'Murray = S. Kucherawy'
Subject: Re: [apps-discuss] The acct: scheme = question

 

John,

 

That’s correct, but not a function of the WebFinger draft, but = one of RFC 6415.  The URI template accepts URIs, not bits and = pieces of URIs.

 

We had discussed long ago to use only “paulej@packetizer.com”, = for example, but the group decided to use URIs and “acct” = was the preferred URI scheme to refer to user = accounts.

 

What I’ve been doing was trying to document the agreements = various folks had reached on WebFinger.  Don’t shoot the = messenger.  That said, I don’t see a good reason to backtrack = at this point.  The “acct” URI scheme is out in the = wild, its use has a limited scope and specific purpose, = etc.

 

If we were to separate them, we would have the question thrust upon = us of “what URI scheme do I use to refer to paulej’s Twitter = account?”  It’s not mailto.  It should not be = http.  I do agree with the group who reached the consensus before = that “acct” is a reasonable way forward.  Nobody was in = love with “acct”, but nothing else worked = better.

 

Paul

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discu= ss-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Tuesday, June 26, 2012 11:12 AM
To: = Peter Saint-Andre
Cc: apps-discuss@ietf.org; Murray = S. Kucherawy
Subject: Re: [apps-discuss] The acct: scheme = question

 

The = "resource" parameter is currently a fully qualified URI, and = that is normalized to acct:

 

The template paramater {uri} also precludes relative = URI as near as I can tell.

 

Perhaps Paul can correct me,  but I think that = the request.

 

GET /.well-known/host-meta.json?resource=3Dfoo@bar.com =
HTTP/1.1
Host: =
bar.com

 

Is not allowed by the spec, or be interoperable. =    The goal of SWD was to make the above (slightly different = syntax same idea) work.

 

There are a lot of places in the spec where the acct: = uri and normalizing things to it are baked = in.

 

There are likely also issues with host-meta as that is = where the template is defined.

 

Paul's likely reaction will be that separating them is = not trivial, and he may be correct in that.

 

On the other hand it is probably the right thing to = do, even if it touches a bunch of things.

 

John B.

 

On = 2012-06-26, at 10:40 AM, Peter Saint-Andre wrote:

 

On 6/26/12 8:37 AM, = John Bradley wrote:

The current spec = requires normalization of bare identifiers i.e. foo@bar.com to = acct:foo@bar.com.

That = would also need to change if we separate the = specs.


In what way would it need to = change?

Peter

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

 

------=_NextPart_000_0489_01CD548E.20AE8590-- From paulej@packetizer.com Wed Jun 27 15:02: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 4E5A121F861C for ; Wed, 27 Jun 2012 15:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jwew4gOMgjsR for ; Wed, 27 Jun 2012 15:02:19 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F399521F8617 for ; Wed, 27 Jun 2012 15:02:18 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5RM2HP8018482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 18:02:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340834538; bh=fWxYFW1+jdmnDrhwF1E9g5iZxOSifBNgHndliSHakAw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Dk0xTdEwkiplb0szzAfDAiwr86QKDdzvuft7IcBU5boh7Roevw7zV1gTfnAXQnhht EyDsP+wL95Y7dhWgCLupg1o1OkwfygtU3I9rLCIIrw0JlXZ6HsTb/ik1+X1hHStCRp zOEUqBTdB4mqYNtcM077vLbp6jaB6qtpNpA9Dntc= From: "Paul E. Jones" To: "'Mike Jones'" , "'William Mills'" , "'Graham Klyne'" , "'SM'" References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> <4FEB3060.1040805@ninebynine.org> <1340818030.8183.YahooMailNeo@web31806.mail.mud.yahoo.com> <047501cd54ae$c6848a30$538d9e90$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436656BCF0@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436656BCF0@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 27 Jun 2012 18:02:25 -0400 Message-ID: <049e01cd54b0$89925ba0$9cb712e0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_049F_01CD548F.0281A600" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHACExhZgXedi2je/bJAOmWfz8jRwJIaUzKAmC+4owBc2Np4gGLJqkJAYQI6cwCpl4PgAEjO00olsGleBA= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 22:02:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_049F_01CD548F.0281A600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Who in the IESG might raise a concern? We should talk. So far, it seems like folks are happy in broad terms, but only concerned about the unknown. Worrying does not help us. Let's get whomever we need involved right now. Paul From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, June 27, 2012 5:54 PM To: Paul E. Jones; 'William Mills'; 'Graham Klyne'; 'SM' Cc: apps-discuss@ietf.org Subject: RE: [apps-discuss] The acct: scheme question At least based upon my experience with the OAuth Core and OAuth Bearer specs, until IESG/IETF last call, a lot of the IESG members don't raise issues, and then they're often raised as DISCUSS issues, which block publication until resolved. Sometimes these DISCUSS issues also call for cross-organizational review with the W3C. Until the acct: URI is actually in a spec in IESG/IETF last call, my experience says that we really won't know where we stand. Hence me wanting to get us there as soon after Vancouver as possible. -- Mike From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, June 27, 2012 2:50 PM To: 'William Mills'; 'Graham Klyne'; 'SM' Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question Bill, I'd say there is a division right down the middle. It's not clear if there are more in favor of keeping it there or moving it to a separate document. However, there is not an overwhelming number on one side. Moving it to a separate document should not be necessary. We can publish the WF RFC with the "acct" URI scheme and work to get URI reviewer approval in parallel. Is URI reviewer approval required first? I don't think so. Graham suggested that having it agreed in a standards-track RFC carries a lot of weight. It seems that those who want to separate it are mostly concerned that it will delay the RFC publication. That does not appear to be an issue at all. Paul From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of William Mills Sent: Wednesday, June 27, 2012 1:27 PM To: Graham Klyne; SM Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question Based on the comments to date is there consensus for a path forward? Will we leave acct: in the WF draft or split it out? If we're splitting it do we have someone stepping up to author the new draft? Thanks, -bill ------=_NextPart_000_049F_01CD548F.0281A600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Who in the IESG might raise a concern?  We should = talk.

 

So far, it seems like folks are happy in broad terms, but only = concerned about the unknown.  Worrying does not help us.  = Let’s get whomever we need involved right = now.

 

Paul

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: = Wednesday, June 27, 2012 5:54 PM
To: Paul E. Jones; 'William = Mills'; 'Graham Klyne'; 'SM'
Cc: = apps-discuss@ietf.org
Subject: RE: [apps-discuss] The acct: = scheme question

 

At least based upon my experience with the OAuth Core and OAuth = Bearer specs, until IESG/IETF last call, a lot of the IESG members = don’t raise issues, and then they’re often raised as DISCUSS = issues, which block publication until resolved.  Sometimes these = DISCUSS issues also call for cross-organizational review with the = W3C.

 

Until the acct: URI is actually in a spec in IESG/IETF last call, my = experience says that we really won’t know where we stand.  = Hence me wanting to get us there as soon after Vancouver as = possible.

 

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

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discu= ss-bounces@ietf.org] On Behalf Of Paul E. = Jones
Sent: Wednesday, June 27, 2012 2:50 PM
To: = 'William Mills'; 'Graham Klyne'; 'SM'
Cc: apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] The acct: scheme = question

 

Bill,

 

I’d say there is a division right down the middle.  = It’s not clear if there are more in favor of keeping it there or = moving it to a separate document.  However, there is not an = overwhelming number on one side.

 

Moving it to a separate document should not be necessary.  We = can publish the WF RFC with the “acct” URI scheme and work = to get URI reviewer approval in parallel.  Is URI reviewer approval = required first?  I don’t think so.  Graham suggested = that having it agreed in a standards-track RFC carries a lot of = weight.

 

It seems that those who want to separate it are mostly concerned that = it will delay the RFC publication.  That does not appear to be an = issue at all.

 

Paul

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discu= ss-bounces@ietf.org] On Behalf Of William = Mills
Sent: Wednesday, June 27, 2012 1:27 PM
To: = Graham Klyne; SM
Cc: apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] The acct: scheme = question

 

Based = on the comments to date is there consensus for a path forward?  = Will we leave acct: in the WF draft or split it out? 

If = we're splitting it do we have someone stepping up to author the new = draft?

Thanks,

-bill

------=_NextPart_000_049F_01CD548F.0281A600-- From ve7jtb@ve7jtb.com Wed Jun 27 15:13: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 258E121F8593 for ; Wed, 27 Jun 2012 15:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.755 X-Spam-Level: X-Spam-Status: No, score=-2.755 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo5BnBtXEMnr for ; Wed, 27 Jun 2012 15:13:39 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5037D21F858A for ; Wed, 27 Jun 2012 15:13:36 -0700 (PDT) Received: by yenq13 with SMTP id q13so1506893yen.31 for ; Wed, 27 Jun 2012 15:13:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=hV5rM6unre5p2QgN0aPO2zrNtKkR2mua/dP+aWOmPyM=; b=ayHZpwy2RJ2MFO4R40cPNlEt0jwSEwqzHyUcoEidUFwW53tr/3JP18wVTK7QXMjLoN aXWICH984Oa5P5gvuziV+z6ESNFXOtwCf5lNXirDami+FVnoG123OAjDC4EFqtrOp+gB tRS4J+/M7dOG/h1rjv03nNbfqD+cfcM14UoQaS0FjurDx7NcsfMS7CHLtsyxEk5w0P2W WpZkup5EXnzMXT74br3PFFZAIMpVwvQlyP55pShLm4Q7uRimHBuY15lR1eYPdrKud1pP Fr8yN54dJfD+kEQrlYfDXRt8snnMcdZpWgbfTAcZkwaEEIKJo98Z/+oaSOdoNrGhQhmn S+4w== Received: by 10.100.206.2 with SMTP id d2mr7766891ang.74.1340835215639; Wed, 27 Jun 2012 15:13:35 -0700 (PDT) Received: from [192.168.1.33] (190-20-41-237.baf.movistar.cl. [190.20.41.237]) by mx.google.com with ESMTPS id z19sm65051664anh.22.2012.06.27.15.13.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jun 2012 15:13:34 -0700 (PDT) References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> <4FEB3060.1040805@ninebynine.org> <1340818030.8183.YahooMailNeo@web31806.mail.mud.yahoo.com> <047501cd54ae$c6848a30$538d9e90$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436656BCF0@TK5EX14MBXC283.redmond.corp.microsoft.com> <049e01cd54b0$89925ba0$9cb712e0$@packetizer.com> In-Reply-To: <049e01cd54b0$89925ba0$9cb712e0$@packetizer.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-A76167CF-E5FD-4FA8-A992-ECD7D77717C4; protocol="application/pkcs7-signature" Message-Id: <6AF4CA7B-A7BC-47C7-8781-63DA7F4DB42D@ve7jtb.com> X-Mailer: iPhone Mail (9B206) From: John Bradley Date: Wed, 27 Jun 2012 18:13:27 -0400 To: "Paul E. Jones" X-Gm-Message-State: ALoCoQk5RMqsJt/RggEmnBN731uzN8yY9EcN0bnJu+M+de4qqfI9qlGTqhrnmlQxgR3GD9kRKEq7 Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 22:13:40 -0000 --Apple-Mail-A76167CF-E5FD-4FA8-A992-ECD7D77717C4 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-FEA5B89C-0B9B-4576-869B-D6F06E7DCFC4 --Apple-Mail-FEA5B89C-0B9B-4576-869B-D6F06E7DCFC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It is the W3C TAG that is the most likely to raise a blocking objection. =20= John B.=20 Sent from my iPhone On 2012-06-27, at 6:02 PM, "Paul E. Jones" wrote: > Who in the IESG might raise a concern? We should talk. > =20 > So far, it seems like folks are happy in broad terms, but only concerned a= bout the unknown. Worrying does not help us. Let=E2=80=99s get whomever we= need involved right now. > =20 > Paul > =20 > From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 > Sent: Wednesday, June 27, 2012 5:54 PM > To: Paul E. Jones; 'William Mills'; 'Graham Klyne'; 'SM' > Cc: apps-discuss@ietf.org > Subject: RE: [apps-discuss] The acct: scheme question > =20 > At least based upon my experience with the OAuth Core and OAuth Bearer spe= cs, until IESG/IETF last call, a lot of the IESG members don=E2=80=99t raise= issues, and then they=E2=80=99re often raised as DISCUSS issues, which bloc= k publication until resolved. Sometimes these DISCUSS issues also call for c= ross-organizational review with the W3C. > =20 > Until the acct: URI is actually in a spec in IESG/IETF last call, my exper= ience says that we really won=E2=80=99t know where we stand. Hence me wanti= ng to get us there as soon after Vancouver as possible. > =20 > -- Mike > =20 > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]= On Behalf Of Paul E. Jones > Sent: Wednesday, June 27, 2012 2:50 PM > To: 'William Mills'; 'Graham Klyne'; 'SM' > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] The acct: scheme question > =20 > Bill, > =20 > I=E2=80=99d say there is a division right down the middle. It=E2=80=99s n= ot clear if there are more in favor of keeping it there or moving it to a se= parate document. However, there is not an overwhelming number on one side. > =20 > Moving it to a separate document should not be necessary. We can publish t= he WF RFC with the =E2=80=9Cacct=E2=80=9D URI scheme and work to get URI rev= iewer approval in parallel. Is URI reviewer approval required first? I don= =E2=80=99t think so. Graham suggested that having it agreed in a standards-= track RFC carries a lot of weight. > =20 > It seems that those who want to separate it are mostly concerned that it w= ill delay the RFC publication. That does not appear to be an issue at all. > =20 > Paul > =20 > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]= On Behalf Of William Mills > Sent: Wednesday, June 27, 2012 1:27 PM > To: Graham Klyne; SM > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] The acct: scheme question > =20 > Based on the comments to date is there consensus for a path forward? Will= we leave acct: in the WF draft or split it out? =20 >=20 > If we're splitting it do we have someone stepping up to author the new dra= ft? >=20 > Thanks, >=20 > -bill > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-FEA5B89C-0B9B-4576-869B-D6F06E7DCFC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
It is the W3C TAG that is t= he most likely to raise a blocking objection.   

John B. 

Sent from my iPhone

On 201= 2-06-27, at 6:02 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:

Who in the IESG might raise a concern?&nb= sp; We should talk.

 

So far, it seems like folks are happy in broad terms, but only c= oncerned about the unknown.  Worrying does not help us.  Let=E2=80= =99s get whomever we need involved right now.

 

Paul

 

From: Mike J= ones [mailto:Michael.Jones@microsoft.com]
Sent: Wednesday, June 2= 7, 2012 5:54 PM
To: Paul E. Jones; 'William Mills'; 'Graham Klyne'= ; 'SM'
Cc: apps-discuss@i= etf.org
Subject: RE: [apps-discuss] The acct: scheme question<= o:p>

 

At least based upon my exp= erience with the OAuth Core and OAuth Bearer specs, until IESG/IETF last cal= l, a lot of the IESG members don=E2=80=99t raise issues, and then they=E2=80= =99re often raised as DISCUSS issues, which block publication until resolved= .  Sometimes these DISCUSS issues also call for cross-organizational re= view with the W3C.

 

Until the acct: URI is actually in a spec in IESG/IETF last call= , my experience says that we really won=E2=80=99t know where we stand. = Hence me wanting to get us there as soon after Vancouver as possible.<= /o:p>

 =

 &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;           -- Mike

&nbs= p;

From: apps-d= iscuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Pau= l E. Jones
Sent: Wednesday, June 27, 2012 2:50 PM
To: 'W= illiam Mills'; 'Graham Klyne'; 'SM'
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discus= s] The acct: scheme question

 

Bill,

 

I=E2=80=99d say there is a division right down the middle.  It=E2=80= =99s not clear if there are more in favor of keeping it there or moving it t= o a separate document.  However, there is not an overwhelming number on= one side.

 

Moving it to a separate document should not be necessary.  We can p= ublish the WF RFC with the =E2=80=9Cacct=E2=80=9D URI scheme and work to get= URI reviewer approval in parallel.  Is URI reviewer approval required f= irst?  I don=E2=80=99t think so.  Graham suggested that having it a= greed in a standards-track RFC carries a lot of weight.

 

It seems that those who w= ant to separate it are mostly concerned that it will delay the RFC publicati= on.  That does not appear to be an issue at all.

<= p class=3D"MsoNormal"> 

=

Paul

<= p class=3D"MsoNormal"> 

=

From: apps-discuss-bounce= s@ietf.org [ma= ilto:apps-discuss-bounces@ietf.org] On Behalf Of William MillsSent: Wednesday, June 27, 2012 1:27 PM
To: Graham Klyne; S= M
Cc: apps-discuss@ietf.o= rg
Subject: Re: [apps-discuss] The acct: scheme question<= /o:p>

 

Based on the comment= s to date is there consensus for a path forward?  Will we leave acct: i= n the WF draft or split it out? 

If we're splitting it do we ha= ve someone stepping up to author the new draft?

Thanks,

-bill<= o:p>

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman= /listinfo/apps-discuss
= --Apple-Mail-FEA5B89C-0B9B-4576-869B-D6F06E7DCFC4-- --Apple-Mail-A76167CF-E5FD-4FA8-A992-ECD7D77717C4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6 tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d 5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu 9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8 9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL 3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk 4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA2MjcyMjEzMzJaMCMGCSqGSIb3DQEJBDEWBBRsqpJf TfnvZt8Ysc/Ch1Arca5JgTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQCLkoR5JZwxyY5rt47ebd2TsmIV5Gf1jAXAkb2W vHMTtCt7g375OC5JFwmYGtbTtDFVqAByJxbBSbE9RFBvR0r0+I+QVWbeY1L7RCg8Xjle9B7Czfwl jn34TjPLOrGfWBedaButH5/TNhLEw0RWI8QZWo4HN6YVaw+4VkR2F39F0ezTBWZtxwWdiIEV+yUT vI4DZOVOU7rPdTp079arhDm07iGA820uoQoapenopP9p86NoANsixQLSl98Q119jwxdY6XkclwJO 0/Nv7/MAgOiHqOFIhXxdg9mAJDj67P//ghZleikekpg9ETTAMgDIbS/f5zI82kmgbz7klV/nLI1C AAAAAAAA --Apple-Mail-A76167CF-E5FD-4FA8-A992-ECD7D77717C4-- From stpeter@stpeter.im Wed Jun 27 15:16: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 6A45321F8657 for ; Wed, 27 Jun 2012 15:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4H5QwohNKPvo for ; Wed, 27 Jun 2012 15:16:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF5E21F8611 for ; Wed, 27 Jun 2012 15:16:21 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.179.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1B1A44005A; Wed, 27 Jun 2012 16:34:18 -0600 (MDT) Message-ID: <4FEB8631.60703@stpeter.im> Date: Wed, 27 Jun 2012 16:16:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Bradley References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> <4FEB3060.1040805@ninebynine.org> <1340818030.8183.YahooMailNeo@web31806.mail.mud.yahoo.com> <047501cd54ae$c6848a30$538d9e90$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436656BCF0@TK5EX14MBXC283.redmond.corp.microsoft.com> <049e01cd54b0$89925ba0$9cb712e0$@packetizer.com> <6AF4CA7B-A7BC-47C7-8781-63DA7F4DB42D@ve7jtb.com> In-Reply-To: <6AF4CA7B-A7BC-47C7-8781-63DA7F4DB42D@ve7jtb.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 22:16:23 -0000 On 6/27/12 4:13 PM, John Bradley wrote: > It is the W3C TAG that is the most likely to raise a blocking objection. Folks, we're into pure speculation here. In any case, the W3C TAG has no role in the IETF Standards Process. If individuals who currently serve on the W3C TAG wish to raise concerns during IETF Last Call, they are free to do so. Peter -- Peter Saint-Andre https://stpeter.im/ From sm@resistor.net Wed Jun 27 16:55: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 4EC3311E814B for ; Wed, 27 Jun 2012 16:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 f2WnbQ4MXcOC for ; Wed, 27 Jun 2012 16:55:33 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5F411E8151 for ; Wed, 27 Jun 2012 16:55:33 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5RNtSoN027369; Wed, 27 Jun 2012 16:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340841333; bh=bEkHwmxTec5ruoEUYQzH/ju1bumryHW6wSrX0MkOOjs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FA/V2haIRcFQsYvkNv3xZQT7lDjfa9Xxa/TGu7pk2eNFQiSsS/rQhP2zIdP9BDBQ2 taOhVr/Esvd3knPVjG2R0m/D+ZJyVOhLOhRzpUHPF0o9Cdv8yPBlN1Fx8xHRk5fBKo luJ1qq1SWaZ686yqu9zIzVRkKLtIjzcElZIO+FYE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1340841333; i=@resistor.net; bh=bEkHwmxTec5ruoEUYQzH/ju1bumryHW6wSrX0MkOOjs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xfLLDGJRDIF89CbIOGpUlhVWvdiJ2NLkrpbQn8nsku8yeDYF9Bd/7l8ahkivbqARt yPOp+UI7ayCJokluUlWRYv+vJn6LZ6HB6JZ7VrCw5WSSvx/m3IRhMS/7zxEhHKa0gu 9ApLw40XfLkq2DZgM9mU0cwyIj3jUzsuyH6hGzCQ= Message-Id: <6.2.5.6.2.20120627163004.08f6ad50@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 Jun 2012 16:50:44 -0700 To: "Paul E. Jones" From: SM In-Reply-To: <047501cd54ae$c6848a30$538d9e90$@packetizer.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> <4FEB3060.1040805@ninebynine.org> <1340818030.8183.YahooMailNeo@web31806.mail.mud.yahoo.com> <047501cd54ae$c6848a30$538d9e90$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 23:55:38 -0000 Hi Paul, At 14:49 27-06-2012, Paul E. Jones wrote: >Moving it to a separate document should not be necessary. We can >publish the WF RFC with the "acct" URI scheme and work to get URI >reviewer approval in parallel. Is URI reviewer approval required >first? I don't think so. Graham suggested that having it agreed in >a standards-track RFC carries a lot of weight. If the draft is on-track as an IETF RFC, the URI review should not be a problem. Graham already suggested the easy path. If you completed the steps to request a URI review, it's not worth worrying about that if the draft is making progress. A DISCUSS from the an IESG member is not the end of the world. It's merely a question which can be answered with a little effort. The ADs actually ask questions which we all know should be answered. We prefer to hand-wave them though. :-) If an author get a few good reviews for a draft, the last stages are easier. If an author only wants reviews from people who will agree with him/her, the last stages can seem like an unsurmountable effort. Regards, -sm From derhoermi@gmx.net Wed Jun 27 17:37: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 80D0D21F85FD for ; Wed, 27 Jun 2012 17:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.528 X-Spam-Level: X-Spam-Status: No, score=-4.528 tagged_above=-999 required=5 tests=[AWL=-1.929, 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 3L4Ueytc7KPY for ; Wed, 27 Jun 2012 17:37:48 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2784B21F85F6 for ; Wed, 27 Jun 2012 17:37:47 -0700 (PDT) Received: (qmail invoked by alias); 28 Jun 2012 00:37:46 -0000 Received: from dslb-094-223-203-200.pools.arcor-ip.net (EHLO HIVE) [94.223.203.200] by mail.gmx.net (mp002) with SMTP; 28 Jun 2012 02:37:46 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX195jvRegZJ57omJ61GRUb3bM35J9q33KP3AYg3ZkW bqVNL8xaddlrMl From: Bjoern Hoehrmann To: SM Date: Thu, 28 Jun 2012 02:37:45 +0200 Message-ID: <5d8nu71haq67135l28h9nbotmm31v1avvb@hive.bjoern.hoehrmann.de> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> <4FEB3060.1040805@ninebynine.org> <1340818030.8183.YahooMailNeo@web31806.mail.mud.yahoo.com> <047501cd54ae$c6848a30$538d9e90$@packetizer.com> <6.2.5.6.2.20120627163004.08f6ad50@resistor.net> In-Reply-To: <6.2.5.6.2.20120627163004.08f6ad50@resistor.net> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 00:37:52 -0000 * SM wrote: >At 14:49 27-06-2012, Paul E. Jones wrote: >>Moving it to a separate document should not be necessary. We can >>publish the WF RFC with the "acct" URI scheme and work to get URI >>reviewer approval in parallel. Is URI reviewer approval required >>first? I don't think so. Graham suggested that having it agreed in >>a standards-track RFC carries a lot of weight. > >If the draft is on-track as an IETF RFC, the URI review should not be >a problem. Graham already suggested the easy path. If you completed >the steps to request a URI review, it's not worth worrying about that >if the draft is making progress. I believe for proposals in Standards Track documents, as is the case here, the process consists of asking for review on the uri-review list and addressing any feedback there. Anything else, like asking the ex- pert reviewer whether they approve or coordinating IANA registration, would be done by the IESG or otherwise happen automatically after the IESG is asked to consider the document for publication. A request for review has been posted to the uri-review list, so if there is anything else Paul has to initiate, could you spell that out? -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From sm@resistor.net Wed Jun 27 18:22: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 A585611E80CA for ; Wed, 27 Jun 2012 18:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 INTPG-Aa4qwA for ; Wed, 27 Jun 2012 18:22: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 B53A811E80F7 for ; Wed, 27 Jun 2012 18:22:39 -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 q5S1MVX2007295; Wed, 27 Jun 2012 18:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340846556; bh=uPRZba5L/nElYcsY4GHZPPhf9b6Yn2+R4Bfsarr6hR4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=yULtGUxWcnuYkt3vAhh8/cfDKco5yTQHUZYOvnHCA3V78TLKfS9A4yEM9BOFLXnEa zr6890a1vq6J35Of1wUPc/nusBGtCP5P7chaazhq7rkezwUwd4urzUBPFtnKeSM5LL 6fKrupmw6iG1kKKZoa/lYC+bnJhGJ4a+K3EDTxZk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1340846556; i=@resistor.net; bh=uPRZba5L/nElYcsY4GHZPPhf9b6Yn2+R4Bfsarr6hR4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JQ0DPcv+i926SitJrk096TU21F8WfwiMCe9vclamcKRnkly41GRMUOxL/x8ZdfBKt lK2b7wE21JT4/vigAehJk4GrG1Zxo0ADjXtQWmxCo+cMVxpPzutYeidtHRedsqAUWG U6/HgNTE6ZM9tmXSQBE5tQ2k4DcZ6989cvwrWVrM= Message-Id: <6.2.5.6.2.20120627174303.08c69f10@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 Jun 2012 18:22:13 -0700 To: Bjoern Hoehrmann From: SM In-Reply-To: <5d8nu71haq67135l28h9nbotmm31v1avvb@hive.bjoern.hoehrmann.d e> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> <4FEB3060.1040805@ninebynine.org> <1340818030.8183.YahooMailNeo@web31806.mail.mud.yahoo.com> <047501cd54ae$c6848a30$538d9e90$@packetizer.com> <6.2.5.6.2.20120627163004.08f6ad50@resistor.net> <5d8nu71haq67135l28h9nbotmm31v1avvb@hive.bjoern.hoehrmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 01:22:43 -0000 Hi Bjoern, At 17:37 27-06-2012, Bjoern Hoehrmann wrote: >I believe for proposals in Standards Track documents, as is the case >here, the process consists of asking for review on the uri-review list >and addressing any feedback there. Anything else, like asking the ex- Graham commented on that in a message at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06377.html >pert reviewer whether they approve or coordinating IANA registration, >would be done by the IESG or otherwise happen automatically after the >IESG is asked to consider the document for publication. A request for IANA asks some administrative questions about the registration request. The document shepherd responds. Sometimes the author or the WG Chair takes up the task. This is usually during the IESG Evaluation stage. >review has been posted to the uri-review list, so if there is anything >else Paul has to initiate, could you spell that out? He has done what BCP 35 requests the registrant to do. As there weren't any comments, there's no problem to be solved. BTW, you know about URI reviews better than me. :-) Regards, -sm From derhoermi@gmx.net Wed Jun 27 20:01: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 D4AFB21F855D for ; Wed, 27 Jun 2012 20:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.287 X-Spam-Level: X-Spam-Status: No, score=-4.287 tagged_above=-999 required=5 tests=[AWL=-1.688, 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 TVfn5n73GrZS for ; Wed, 27 Jun 2012 20:01:53 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 78C6E21F855B for ; Wed, 27 Jun 2012 20:01:52 -0700 (PDT) Received: (qmail invoked by alias); 28 Jun 2012 03:01:51 -0000 Received: from dslb-094-223-203-200.pools.arcor-ip.net (EHLO HIVE) [94.223.203.200] by mail.gmx.net (mp016) with SMTP; 28 Jun 2012 05:01:51 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+PsGg6yh6PBLywLB0v+oapCYJElA4CKkW4+xdi7e ZEImaC2RMQtxs8 From: Bjoern Hoehrmann To: Andy Newton Date: Thu, 28 Jun 2012 05:01:51 +0200 Message-ID: References: <4AB1590B-710F-4EF2-B1B5-A1BA7A877BBE@hxr.us> In-Reply-To: <4AB1590B-710F-4EF2-B1B5-A1BA7A877BBE@hxr.us> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] URNBIS needs your eyeballs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2012 03:01:54 -0000 * Andy Newton wrote: >So if you have a few moments, your review of these drafts and the URNBIS >work in general would be much appreciated. Otherwise, I'm told, IETF >executives are considering selling URNBIS to a pharmaceutical outfit >wishing to market sedative hypnotics. (Such requests would be much easier to act upon if they came with some description of what to look for, what has changed, and so on.) -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From James.H.Manger@team.telstra.com Wed Jun 27 21:21: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 E9B1C11E8186 for ; Wed, 27 Jun 2012 21:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpzjudqHFCzA for ; Wed, 27 Jun 2012 21:21:54 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id C8D2911E80A4 for ; Wed, 27 Jun 2012 21:21:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,489,1336312800"; d="scan'208";a="84780080" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 28 Jun 2012 14:21:50 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6755"; a="73805920" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbni.tcif.telstra.com.au with ESMTP; 28 Jun 2012 14:21:50 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Thu, 28 Jun 2012 14:21:49 +1000 From: "Manger, James H" To: Joe Hildebrand , Mark Nottingham , IETF Apps Discuss Date: Thu, 28 Jun 2012 14:21:48 +1000 Thread-Topic: #3: json-pointer escape characters Thread-Index: Ac1UNFVQzgwqj024L0i4i2zwjhYVlgAosieQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 04:21:55 -0000 VGhlICJiZXN0IiBzeW50YXggZm9yIGEgSlNPTiBwb2ludGVyIGlzIGEgSlNPTiBhcnJheTogbm8g bmV3IGVzY2FwaW5nOyBhbmQgcmVmZXJlbmNlcyB0byBhbiBvYmplY3QgZWxlbWVudCBvciBhcnJh eSBpdGVtIGFyZSBlYXNpbHkgZGlzdGluZ3Vpc2hlZCAodXNpbmcgYSBzdHJpbmcgb3IgYSBudW1i ZXIgcmVzcGVjdGl2ZWx5KS4gVGhpcyBpcyBzdWl0YWJsZSBmb3IgY2FycnlpbmcgYSBwb2ludGVy IGluIGEgSlNPTiBkb2N1bWVudC4gRXhhbXBsZXM6DQoNCiAgWyJmb28iLDBdDQogIFsiYS9iIl0N CiAgWyJpXFxqIl0NCg0KSXQgaXMgcHJldHR5IGF3ZnVsIGZvciBwdXR0aW5nIGEgcG9pbnRlciBp bnRvIGEgVVJJIGZyYWdtZW50LCBob3dldmVyLg0KDQogICMlNUIlMjJmb28lMjIsMCU1Qg0KDQoN CkEgc3ludGF4IHdpdGggb25lIGxheWVyIG9mICUtZXNjYXBpbmcgaXMgdGhlb3JldGljYWxseSBw b3NzaWJsZSBzaW5jZSBhIFVSSSBmcmFnbWVudCBhbGxvd3MgLyBhbmQgJTJGIGFzIHNlcGFyYXRl IHRoaW5ncy4gSG93ZXZlciwgaXQgZG9lcyBjbGFzaCB3aXRoIEFQSXMuIEZvciBpbnN0YW5jZSwg dGhlIGphdmEubmV0LlVSSShzY2hlbWUsIGhvc3QsIHBhdGgsIGZyYWdtZW50KSBjb25zdHJ1Y3Rv ciB3aWxsIG5vdCBsZXQgeW91IGdlbmVyYXRlIOKApiMvYSUyRmIuIFBhc3MgaW4gIi9hJTJGYiIg YW5kIHlvdSBnZXQgIuKApiMvYSUyNTJGYiIuDQoNCg0KRG91YmxlICUtZXNjYXBpbmcgd291bGQg d29yayAoMXN0IGxheWVyIGluIHBvaW50ZXIgY29kZSwgMm5kIGxheWVyIGluIFVSSSBmcmFnbWVu dCBjb2RlKS4gSXQncyBqdXN0IHRoYXQgZG91YmxlIGVzY2FwaW5nIHNlZW1zIHZlcnkgbGlrZWx5 IHRvIGNvbmZ1c2UgZGV2ZWxvcGVycyAobWluZCB5b3UsIGFsbCBlc2NhcGluZyBjb25mdXNlcyku IFdvdWxkIGl0IGJlIHN1ZmZpY2llbnQgZm9yIHRoZSBwb2ludGVyIGNvZGUganVzdCB0byBkbyBy ZXBsYWNlQWxsKCIlMltmRl0iLCIvIikucmVwbGFjZUFsbCgiJTI1IiwiJSIpIG9yIHdvdWxkIGl0 IGhhdmUgdG8gY29wZSB3aXRoIGFyYml0cmFyeSBvdGhlciBieXRlcyBiZWluZyB1bm5lY2Vzc2Fy aWx5IGVzY2FwZWQ/DQoNCg0KQSBxdWljayB3ZWIgc2VhcmNoIHJldmVhbGVkIGhhbGYtYS1kb3pl biBpbXBsZW1lbnRhdGlvbnMgWzEtNl0gaW4gdmFyaW91cyBsYW5ndWFnZXMgb2YgYW4gZWFybHkg dmVyc2lvbiBvZiB0aGUgSlNPTiBwb2ludGVyIHNwZWMgdGhhdCB1c2VkICUtZXNjYXBlcy4gVGhl eSBhbGwgc3BsaXQgdGhlIHBvaW50ZXIgb24gJy8nLCB0aGVuIGRlY29kZSBlYWNoIHNlZ21lbnQu DQoNClRoaXMgc2ltcGxlIGFwcHJvYWNoIG5vIGxvbmdlciB3b3JrcyB3aXRoIHRoZSBjdXJyZW50 IEpTT04gcG9pbnRlciBzcGVjLiBzcGxpdCgiLyIpIGZhaWxzIGFzIGEgIi8iIG1heSBiZSBhIGRl bGltaXRlciwgYnV0IG1heSBhbHNvIGJlIHBhcnQgb2YgYW4gIl4vIiBlc2NhcGUgc2VxdWVuY2Uu IFRvIG1hdGNoIG9ubHkgZGVsaW1pdGVycyByZXF1aXJlcyBhIHJlZ3VsYXIgZXhwcmVzc2lvbiB3 aXRoIGEgcG90ZW50aWFsbHkgdW5saW1pdGVkIGFtb3VudCBvZiAibG9vay1iZWhpbmQiIHRvIHNl ZSBpZiB0aGVyZSBhcmUgYW4gb2RkIG51bWJlciBvZiBwcmVjZWRpbmcgY2FyZXRzOiAoPzwhW15e XSg/OlxeXF4pKlxeKS8uIEphdmEgKHYxLjYpLCBmb3IgZXhhbXBsZSwgZG9lcyBub3Qgc3VwcG9y dCB1bmxpbWl0ZWQgbG9vay1iZWhpbmQuICg/PCFbXl5dKD86XF5cXil7MCw5OX1cXikvIGlzIGFu IGFwcHJveGltYXRpb24gdGhhdCBkb2VzIHdvcmsuDQoNCg0KU3dpdGNoaW5nIHRvIH4wIGFuZCB+ MSBhcyBlc2NhcGVzIGZvciB+IGFuZCAvIHdvdWxkIGFsbG93IHNwbGl0KCIvIikgdG8gd29yaywg Zm9sbG93ZWQgYnkgcmVwbGFjZUFsbCgifjEiLCIvIikucmVwbGFjZUFsbCgifjAiLCJ+IikuIENy ZWF0aW5nIGEgcG9pbnRlciBpcyBhbHNvIGVhc3k6IHJlcGxhY2VBbGwoIn4iLCAifjAiKS5yZXBs YWNlQWxsKCIvIiwgIn4xIikgdGhlbiBqb2luIHRoZSBwYXJ0cy4gIn4iIGFsc28gZG9lc24ndCBu ZWVkIHRvIGJlICUtZXNjYXBlZCBpbiBhIFVSSS4gSSBhc3N1bWUgbW9zdCBsYW5ndWFnZXMgaGF2 ZSBzcGxpdCgpIGFuZCByZXBsYWNlQWxsKCkgZnVuY3Rpb25zLg0KDQoNClsxXSBodHRwczovL2dp dGh1Yi5jb20vamFubC9ub2RlLWpzb25wb2ludGVyDQpbMl0gaHR0cHM6Ly9naXRodWIuY29tL3N0 ZWZhbmtvZWdsL3B5dGhvbi1qc29uLXBvaW50ZXIvYmxvYi9tYXN0ZXIvanNvbnBvaW50ZXIucHkN ClszXSBodHRwczovL2dpdGh1Yi5jb20vcmFwaGFlbHN0b2x0L3BocC1qc29ucG9pbnRlci9ibG9i L21hc3Rlci9zcmMvSnNvblBvaW50ZXIvSnNvblBvaW50ZXIucGhwDQpbNF0gaHR0cDovL3NvdXJj ZXMuZm9yZ2Vyb2NrLm9yZy9icm93c2UvfnJhdyxyPTMwMy9jb21tb25zL2pzb24tZmx1ZW50L3Ry dW5rL3NyYy9tYWluL2phdmEvb3JnL2Zvcmdlcm9jay9qc29uL2ZsdWVudC9Kc29uUG9pbnRlci5q YXZhDQpbNV0gaHR0cDovL3B5ZG9jLm5ldC9qc29ucG9pbnRlci8wLjEvanNvbnBvaW50ZXINCls2 XSDigKYNCg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From melvincarvalho@gmail.com Thu Jun 28 00:28:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C16A21F85EA for ; Thu, 28 Jun 2012 00:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Swnl-HNHjAw1 for ; Thu, 28 Jun 2012 00:28:36 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A22C221F85F3 for ; Thu, 28 Jun 2012 00:28:35 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1407152vbb.31 for ; Thu, 28 Jun 2012 00:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SLhG3uFe30uPZYGlqwaKyo99tdQ3c8JZv9/GcJ5zHKc=; b=LhmGzAW8PaxcB5ucJBAuLpyatq5X+7JzooSDT2KjePz6T7F92zoOZ9HLl84LmLw9ks tSY4BH/nl5aOXgk0iT+d7tHmtzwmEaNbrDqrPCpEQM0HRnIurX+ck5X5Qj8jxOLvmbdh OINF+b4jjUT4N8sDyrOsIZJ8XnmySqqFqBmuRUKcqFv1SLS9waRKJRFmg0YkEaugJVjc p3FiaeDjqINzj/O7cyBxRK67m/DUQaYoeFk+wggtKUzCR4awNPnDSjkdb1ZZKgKGDd16 UdLsL7UCm2lHpJ1GiC2XJW4G0PKMXhheluhBfNY7UV517UNQaEhAcAochGwLZC212Nlj oqFA== MIME-Version: 1.0 Received: by 10.220.218.141 with SMTP id hq13mr638109vcb.8.1340868514960; Thu, 28 Jun 2012 00:28:34 -0700 (PDT) Received: by 10.52.166.102 with HTTP; Thu, 28 Jun 2012 00:28:34 -0700 (PDT) In-Reply-To: <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> Date: Thu, 28 Jun 2012 09:28:34 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=14dae9cfc83086567704c383479e Cc: apps-discuss@ietf.org, "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 07:28:37 -0000 --14dae9cfc83086567704c383479e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 27 June 2012 22:43, Paul E. Jones wrote: > I submitted a query to the uri-review list on June 18. So far, there have > been no comments on the list.**** > > ** ** > > I do not see a reason why the URI review could not be concluded fairly > quickly regardless of where it is documented.**** > > ** ** > > Now, should the URI review process result in rejecting =93acct=94 then we= have > to scramble to come up with an alternative. It cannot simply be left to > speculation. We need a concrete and predictable way of constructing URIs > that refer to user accounts. How do I query a Twitter user=92s account? > Flickr? Google+? (Don=92t get me started about the Facebook deciding the= ir > email address was my preferred email address...) > Should acct: be rejected, we can simply use mailto: as per SWD. Similarly you could simply use ?acct=3Duser@host as has been suggested. This would possibly be an improvement in any case. acct: is a 'nice to have' but not necessary for a discovery protocol, imho. It's a slight weakness of XRD that it doesnt have a query language (like SPARQL) that makes things more challenging. Perhaps one day it will have. Nevertheless, SWD has proven that the problem CAN be solved without a new uri scheme. Twitter, Facebook, Flikr and Google Plus all use HTTP URIs to describe their user accounts. This is best practice on the web, and recommended in Linked Data Principles [1] which is the dominant discovery mechanism on the Web today. The gap in linked data, which I hope Webfinger can address, is a common discovery pattern (using well-known locations) for email addresses. If Twitter or Facebook and others have not asked for yet another way to identify users, I am unsure why this use case is in scope. Do note that Facebook already have a first class discovery system in the Open Graph Protocol. I believe they say in the IETF, "A spec is not finished when there's nothing left to put in, a spec is finished when there's nothing left to take out." If acct: was rejected or removed, I think we have a ways to fallback, in fact, I think WebFinger would be a stronger specification for it. [1] http://www.w3.org/DesignIssues/LinkedData.html > **** > > ** ** > > Paul**** > > ** ** > > *From:* apps-discuss-bounces@ietf.org [mailto: > apps-discuss-bounces@ietf.org] *On Behalf Of *Mike Jones > *Sent:* Tuesday, June 26, 2012 11:18 AM > *To:* William Mills; Melvin Carvalho; Murray S. Kucherawy > > *Cc:* apps-discuss@ietf.org > *Subject:* Re: [apps-discuss] The acct: scheme question**** > > ** ** > > Yes, there=92s a significant advantage. It allows the acct: scheme to be > approved (or rejected) quickly so that we will know whether it is safe fo= r > WebFinger and other specifications to use it. That approval/rejection ca= n > then happen in parallel with refining the discovery specification.**** > > ** ** > > Otherwise, we could be in a position where we think we have a final > discovery specification, only to learn that it can=92t go forward because= of > objections to the acct: scheme from the W3C and possibly others. It woul= d > be much better for us to know whether that is the case up front.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* William Mills [mailto:wmills@yahoo-inc.com] > *Sent:* Tuesday, June 26, 2012 8:07 AM > *To:* Mike Jones; Melvin Carvalho; Murray S. Kucherawy > *Cc:* apps-discuss@ietf.org > *Subject:* Re: [apps-discuss] The acct: scheme question**** > > ** ** > > Is there any advantage to breaking it out? The WF draft depends on it an= d > so can't finalize until acct: does, right?**** > > ** ** > > Will one get done more quickly than the other?**** > > ** ** > ------------------------------ > > *From:* Mike Jones > *To:* Melvin Carvalho ; Murray S. Kucherawy < > msk@cloudmark.com> > *Cc:* "apps-discuss@ietf.org" > *Sent:* Tuesday, June 26, 2012 6:20 AM > *Subject:* Re: [apps-discuss] The acct: scheme question**** > > ** ** > > Yes, I believe that the acct: scheme should be considered separately from > discovery, in its own document.**** > > **** > > -- Mike**** > > **** > > *From:* apps-discuss-bounces@ietf.org > [mailto:apps-discuss-bounces@ietf.org] *On Behalf Of *Melvin Carvalho > *Sent:* Tuesday, June 26, 2012 5:06 AM > *To:* Murray S. Kucherawy > *Cc:* apps-discuss@ietf.org > *Subject:* Re: [apps-discuss] The acct: scheme question**** > > **** > > **** > > On 22 May 2012 09:22, Murray S. Kucherawy wrote:**** > > As we prepare to bring webfinger into appsawg, it looks a lot like there= =92s > substantial discussion just on the point of the proposed =93acct:=94 sche= me.** > ** > > **** > > So, a question for those tracking the discussion: Is this a big enough > topic that it should be split into its own document? This would be a > useful thing to decide as we figure out how to handle the work once it > enters working group mode.**** > > **** > > (This by itself has me wondering if we should revisit the conversation > about whether webfinger needs its own working group, but I=92ll leave it = to > Barry and Pete to make that call.)**** > > > There has been some discussion of this here and on other lists, and the > consensus I think is for people to follow the process at : > > . > > I think the current state of play is that webfinger can be used with any > URI type e.g. mailto: http: acct: etc. acct: is recommended in the RFC. = * > *** > > **** > > -MSK**** > > > _______________________________________________ > 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**** > > --14dae9cfc83086567704c383479e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 27 June 2012 22:43, Paul E. Jones <paulej@packetizer.com> wrote:

I submitted a query to the uri-review list o= n June 18. So far, there have been no comments on the list.

=A0<= /p>

I do not see a reason = why the URI review could not be concluded fairly quickly regardless of wher= e it is documented.

=A0<= /p>

Now, should the URI re= view process result in rejecting =93acct=94 then we have to scramble to com= e up with an alternative.=A0 It cannot simply be left to speculation.=A0 We= need a concrete and predictable way of constructing URIs that refer to use= r accounts.=A0 How do I query a Twitter user=92s account?=A0 Flickr? Google= +?=A0 (Don=92t get me started about the Facebook deciding their email addre= ss was my preferred email address...)


Should acct: be rejected, we can simply u= se mailto: as per SWD.=A0 Similarly you could simply use ?acct=3Duser@host = as has been suggested.=A0 This would possibly be an improvement in any case= .=A0 acct: is a 'nice to have' but not necessary for a discovery pr= otocol, imho.=A0 It's a slight weakness of XRD that it doesnt have a qu= ery language (like SPARQL) that makes things more challenging.=A0 Perhaps o= ne day it will have.=A0 Nevertheless, SWD has proven that the problem CAN b= e solved without a new uri scheme.

Twitter, Facebook, Flikr and Google Plus all use HTTP URIs to describe = their user accounts.=A0 This is best practice on the web, and recommended i= n Linked Data Principles [1] which is the dominant discovery mechanism on t= he Web today.=A0 The gap in linked data, which I hope Webfinger can address= , is a common discovery pattern (using well-known locations) for email addr= esses.=A0 If Twitter or Facebook and others have not asked for yet another = way to identify users, I am unsure why this use case is in scope.=A0 Do not= e that Facebook already have a first class discovery system in the Open Gra= ph Protocol.

I believe they say in the IETF, "A spec is not finished when there= 's nothing left to put in, a spec is finished when there's nothing = left to take out."=A0 If acct: was rejected or removed, I think we hav= e a ways to fallback, in fact, I think WebFinger would be a stronger specif= ication for it.

[1] http://w= ww.w3.org/DesignIssues/LinkedData.html
=A0

=A0

Paul

=A0<= /p>

From: ap= ps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Be= half Of Mike Jones
Sent: Tuesday, June 26, 2012 11:18 AM
To: William Mills; M= elvin Carvalho; Murray S. Kucherawy


Cc: apps-di= scuss@ietf.org
Subject: Re: [apps-discuss] The acct: scheme question<= /div>

=A0

Yes= , there=92s a significant advantage.=A0 It allows the acct: scheme to be ap= proved (or rejected) quickly so that we will know whether it is safe for We= bFinger and other specifications to use it.=A0 That approval/rejection can = then happen in parallel with refining the discovery specification.

=A0<= /p>

Otherwise, we could be= in a position where we think we have a final discovery specification, only= to learn that it can=92t go forward because of objections to the acct: sch= eme from the W3C and possibly others.=A0 It would be much better for us to = know whether that is the case up front.

=A0<= /p>

=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=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 -- Mike

=A0<= /p>

From: William = Mills [m= ailto:wmills@yahoo-inc.com]
Sent: Tuesday, June 26, 2012 8:07 AM
To: Mike Jones; Melvi= n Carvalho; Murray S. Kucherawy
Cc: apps-discuss@ietf.org
Subject: = Re: [apps-discuss] The acct: scheme question

=A0

Is there any advantage to breaking it o= ut?=A0 The WF draft depends on it and so can't finalize until acct: doe= s, right?

=A0

Will one get= done more quickly than the other?

=A0

From: Mike Jones <Michael.Jones@microsoft.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>; Murray S. Kucherawy <= ;msk@cloudmark.com>
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Sent: Tuesday= , June 26, 2012 6:20 AM
Subject: Re: [apps-discuss] The acct: scheme question

=A0

Yes, I believe that the acct= : scheme should be considered separately from discovery, in its own documen= t.

=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=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 -- Mike

=A0

From: apps-d= iscuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Melvin Carvalho
Sent: Tuesday, June 26, 2012 5:06 AM
To: Murray S. Kuchera= wy
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] The acct: = scheme question

= =A0

=A0<= /span>

On = 22 May 2012 09:22, Murray S. Kucherawy <msk@cloudmark.com> wrote:

As we prepare to bring webfinger into appsawg, it looks a lot like = there=92s substantial discussion just on the point of the proposed =93acct:= =94 scheme.

= =A0

So, a question for those tracking the discussion:= =A0 Is this a big enough topic that it should be split into its own documen= t?=A0 This would be a useful thing to decide as we figure out how to handle= the work once it enters working group mode.

= =A0

(This by itself has me wondering if we should rev= isit the conversation about whether webfinger needs its own working group, = but I=92ll leave it to Barry and Pete to make that call.)


There has been some discu= ssion of this here and on other lists, and the consensus I think is for peo= ple to follow the process at :

<uri-review= @ietf.org>.

I think the current state of play is that webfing= er can be used with any URI type e.g. mailto: http: acct: etc. acct: is rec= ommended in the RFC.=A0

=A0

-MSK


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

=A0

_______________________________________________
apps-discuss mailing li= st
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--14dae9cfc83086567704c383479e-- From melvincarvalho@gmail.com Thu Jun 28 03:09: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 29A6E21F8734 for ; Thu, 28 Jun 2012 03:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.058, 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 O2QLZzn2jNCA for ; Thu, 28 Jun 2012 03:09:19 -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 AC3BF11E8118 for ; Wed, 27 Jun 2012 16:21:49 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1205493vcq.31 for ; Wed, 27 Jun 2012 16:21: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; bh=q8cpfw9MCNSl4EKfNNsrI8UY2NxxZjs8WBOTvNOsEbU=; b=sR6cNTzMKyV54QRs9XCcq3+lSsTIQ29MgaW0pRy7PjK3cj5mQvfOJd525z0Nz3issT Hf/j/6mYMG41CXPc1vlKlCXLiF45EfHvu5p1fZWhFikFX76hAhSazi1O6OJF6h6jzoar b3nFoPHBc33MwwrrcmkZ6/UEVD1dD8P5l34YmmnN0nec+XNexQ0n+PPQeQd/RTOLEtfe kSwoPoEknagaoY0Pj8AWR1U7ml3kplN5UJ9YZpC9VRn3JxCrOtcYIcRl2UFy6ZSt7+4O eAYUe9m551wFaDCZpQgG3+4+lVRbO0emgq1uj7VYP90IliEhgjcrK0rthI9wtHZP6u8w 7YjQ== MIME-Version: 1.0 Received: by 10.220.150.131 with SMTP id y3mr15591741vcv.42.1340839309071; Wed, 27 Jun 2012 16:21:49 -0700 (PDT) Received: by 10.52.166.102 with HTTP; Wed, 27 Jun 2012 16:21:48 -0700 (PDT) In-Reply-To: <048801cd54af$a7be9ef0$f73bdcd0$@packetizer.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE9BFF9.9060403@stpeter.im> <035988BC-A9BC-4397-8593-D5F84710ECF3@ve7jtb.com> <4FE9C9D4.5060106@stpeter.im> <49510B16-56BF-4445-8865-4FE3CF6ED99C@ve7jtb.com> <042501cd54a4$f0b054b0$d210fe10$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436656BAA3@TK5EX14MBXC283.redmond.corp.microsoft.com> <048801cd54af$a7be9ef0$f73bdcd0$@packetizer.com> Date: Thu, 28 Jun 2012 01:21:48 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d043be156b7d48204c37c7a3b Cc: apps-discuss@ietf.org, "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:09:21 -0000 --f46d043be156b7d48204c37c7a3b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 27 June 2012 23:56, Paul E. Jones wrote: > Mike,**** > > ** ** > > I would still like to at least *try* to keep these together. The =93acct= =94 > URI is a WebFinger URI, so I think it=92s best to keep them together. It > does not seem that approval of the RFC is contingent on the approval of t= he > URI scheme. It could be registered provisionally at first. But, I think > it would be approved given that it is already in use and the fact that > folks agree to go forward with the document.**** > > ** ** > > If folks are absolutely opposed to the URI scheme and wish to hold up > WebFinger over it, then we could consider splitting it. I don=92t hear t= hat, > though. I think folks see the value. The only concern is whether approv= al > of the URI scheme might hold up approval of the RFC. That does not seem = to > be a problem, but perhaps I=92m wrong.**** > > ** ** > > In any case, I=92d prefer to split it out only if we absolutely had to. > I could be mistaken, but my impression was that more were in favor of the acct: URI scheme having it's own document, than not. Is there a way in which consensus can be established, on this issue? > **** > > ** ** > > Paul**** > > ** ** > > *From:* Mike Jones [mailto:Michael.Jones@microsoft.com] > *Sent:* Wednesday, June 27, 2012 4:44 PM > *To:* Paul E. Jones; 'John Bradley'; 'Peter Saint-Andre' > > *Cc:* apps-discuss@ietf.org; 'Murray S. Kucherawy' > *Subject:* RE: [apps-discuss] The acct: scheme question**** > > ** ** > > If we separate them, the WebFinger draft would continue to have a > normative dependency on the Acct draft. But practically then the Acct > draft could go up for working group last call and then IETF last call > essentially immediately after the draft is produced and we=92d get a clea= r > up/down standards decision sooner, rather than later.**** > > ** ** > > If you don=92t have the time to be editor for that draft, I=92m willing t= o do > so. It won=92t take more than a few hours to tease apart.**** > > ** ** > > -- Mike**= * > * > > ** ** > > *From:* apps-discuss-bounces@ietf.org > [mailto:apps-discuss-bounces@ietf.org] *On Behalf Of *Paul E. Jones > *Sent:* Wednesday, June 27, 2012 1:39 PM > *To:* 'John Bradley'; 'Peter Saint-Andre' > *Cc:* apps-discuss@ietf.org; 'Murray S. Kucherawy' > *Subject:* Re: [apps-discuss] The acct: scheme question**** > > ** ** > > John,**** > > ** ** > > That=92s correct, but not a function of the WebFinger draft, but one of R= FC > 6415. The URI template accepts URIs, not bits and pieces of URIs.**** > > ** ** > > We had discussed long ago to use only =93paulej@packetizer.com=94, for > example, but the group decided to use URIs and =93acct=94 was the preferr= ed URI > scheme to refer to user accounts.**** > > ** ** > > What I=92ve been doing was trying to document the agreements various folk= s > had reached on WebFinger. Don=92t shoot the messenger. That said, I don= =92t > see a good reason to backtrack at this point. The =93acct=94 URI scheme = is out > in the wild, its use has a limited scope and specific purpose, etc.**** > > ** ** > > If we were to separate them, we would have the question thrust upon us of > =93what URI scheme do I use to refer to paulej=92s Twitter account?=94 I= t=92s not > mailto. It should not be http. I do agree with the group who reached th= e > consensus before that =93acct=94 is a reasonable way forward. Nobody was= in > love with =93acct=94, but nothing else worked better.**** > > ** ** > > Paul**** > > ** ** > > *From:* apps-discuss-bounces@ietf.org > [mailto:apps-discuss-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Tuesday, June 26, 2012 11:12 AM > *To:* Peter Saint-Andre > *Cc:* apps-discuss@ietf.org; Murray S. Kucherawy > *Subject:* Re: [apps-discuss] The acct: scheme question**** > > ** ** > > The "resource" parameter is currently a fully qualified URI, and that is > normalized to acct:**** > > ** ** > > The template paramater {uri} also precludes relative URI as near as I can > tell.**** > > ** ** > > Perhaps Paul can correct me, but I think that the request.**** > > ** ** > > GET /.well-known/host-meta.json?resource=3Dfoo@bar.com HTTP/1.1**** > > Host: bar.com**** > > ** ** > > Is not allowed by the spec, or be interoperable. The goal of SWD was t= o > make the above (slightly different syntax same idea) work.**** > > ** ** > > There are a lot of places in the spec where the acct: uri and normalizing > things to it are baked in.**** > > ** ** > > There are likely also issues with host-meta as that is where the template > is defined.**** > > ** ** > > Paul's likely reaction will be that separating them is not trivial, and h= e > may be correct in that.**** > > ** ** > > On the other hand it is probably the right thing to do, even if it touche= s > a bunch of things.**** > > ** ** > > John B.**** > > ** ** > > On 2012-06-26, at 10:40 AM, Peter Saint-Andre wrote:**** > > ** ** > > On 6/26/12 8:37 AM, John Bradley wrote:**** > > The current spec requires normalization of bare identifiers i.e. > foo@bar.com to acct:foo@bar.com.**** > > That would also need to change if we separate the specs.**** > > > In what way would it need to change? > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > **** > > ** ** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d043be156b7d48204c37c7a3b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 27 June 2012 23:56, Paul E. Jones <paulej@packetizer.com> wrote:

Mike,

=A0

I would still like to at least try to = keep these together.=A0 The =93acct=94 URI is a WebFinger URI, so I think i= t=92s best to keep them together.=A0 It does not seem that approval of the = RFC is contingent on the approval of the URI scheme.=A0 It could be registe= red provisionally at first.=A0 But, I think it would be approved given that= it is already in use and the fact that folks agree to go forward with the = document.

=A0<= /p>

If folks are absolutel= y opposed to the URI scheme and wish to hold up WebFinger over it, then we = could consider splitting it.=A0 I don=92t hear that, though.=A0 I think fol= ks see the value.=A0 The only concern is whether approval of the URI scheme= might hold up approval of the RFC.=A0 That does not seem to be a problem, = but perhaps I=92m wrong.

=A0<= /p>

In any case, I=92d pre= fer to split it out only if we absolutely had to.


I could be mistaken, but my impression wa= s that more were in favor of the acct: URI scheme having it's own docum= ent, than not.=A0 Is there a way in which consensus can be established, on = this issue?=A0
=A0

=A0<= /p>

Paul

=A0<= /p>

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Wednesday, June 27, 2012 4:44 PM
To: Paul E. Jones; = 'John Bradley'; 'Peter Saint-Andre'


Cc: apps-discuss@ietf.org; 'Murray S. Kucherawy'
Subject: RE: [apps-discuss] The acct: scheme question

=A0

If we sep= arate them, the WebFinger draft would continue to have a normative dependen= cy on the Acct draft.=A0 But practically then the Acct draft could go up fo= r working group last call and then IETF last call essentially immediately a= fter the draft is produced and we=92d get a clear up/down standards decisio= n sooner, rather than later.

=A0<= /p>

If you don=92t have th= e time to be editor for that draft, I=92m willing to do so.=A0 It won=92t t= ake more than a few hours to tease apart.

=A0<= /p>

=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=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: apps-discuss-bo= unces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf= Of Paul E. Jones
Sent: Wednesday, June 27, 2012 1:39 PM
To: 'John Bradl= ey'; 'Peter Saint-Andre'
Cc: apps-discuss@ietf.org; 'Murray S= . Kucherawy'
Subject: Re: [apps-discuss] The acct: scheme question<= /span>

=A0

John,

=A0<= /p>

That=92s correct, but = not a function of the WebFinger draft, but one of RFC 6415.=A0 The URI temp= late accepts URIs, not bits and pieces of URIs.

=A0<= /p>

We had discussed long = ago to use only =93paulej@packetizer.com=94, for example, but the group decided to use = URIs and =93acct=94 was the preferred URI scheme to refer to user accounts.=

=A0<= /p>

What I=92ve been doing= was trying to document the agreements various folks had reached on WebFing= er.=A0 Don=92t shoot the messenger.=A0 That said, I don=92t see a good reas= on to backtrack at this point.=A0 The =93acct=94 URI scheme is out in the w= ild, its use has a limited scope and specific purpose, etc.

=A0<= /p>

If we were to separate= them, we would have the question thrust upon us of =93what URI scheme do I= use to refer to paulej=92s Twitter account?=94=A0 It=92s not mailto.=A0 It= should not be http.=A0 I do agree with the group who reached the consensus= before that =93acct=94 is a reasonable way forward.=A0 Nobody was in love = with =93acct=94, but nothing else worked better.

=A0<= /p>

Paul

=A0<= /p>

From: ap= ps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]= On Behalf Of John Bradley
Sent: Tuesday, June 26, 2012 11:12 AM
To: Peter Saint-Andr= e
Cc: = apps-discuss@ietf.org; Murray S. Kucherawy
Subject: Re: [apps= -discuss] The acct: scheme question

=A0

The "resource" parameter is currently a fully qualified URI, = and that is normalized to acct:

=A0

The template paramater {uri} also preclud= es relative URI as near as I can tell.

=A0

Perha= ps Paul can correct me, =A0but I think that the request.

=A0

GET =
/.well-known/host-meta.json?resource=3Dfoo@bar.com HTTP/1.1
Ho=
st: bar.com<=
/pre>

=A0

Is not allowed by the spec, or be interoperable. =A0 =A0The = goal of SWD was to make the above (slightly different syntax same idea) wor= k.

=A0

There are a lot of places in the spec where the acct: uri an= d normalizing things to it are baked in.

=A0

There are likely als= o issues with host-meta as that is where the template is defined.=

=A0

<= p class=3D"MsoNormal"> Paul's likely reaction will be that separating them is not trivial, and= he may be correct in that.

=A0

On the other han= d it is probably the right thing to do, even if it touches a bunch of thing= s.

=A0

John B.

<= u>=A0

On 2012-06-26, at 10:4= 0 AM, Peter Saint-Andre wrote:

=A0

On 6/26/12= 8:37 AM, John Bradley wrote:

The c= urrent spec requires normalization of bare identifiers i.e. foo@bar.com to acct:foo@bar.com.

That would also need to change if we separate the specs.

In what way would it need to change?

Peter

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

=

=A0

<= /div>

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


--f46d043be156b7d48204c37c7a3b-- From internet-drafts@ietf.org Thu Jun 28 03:09:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E6921F8579; Thu, 28 Jun 2012 03:09:59 -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 RJAwRDJYfiQq; Thu, 28 Jun 2012 03:09:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7923511E8124; Wed, 27 Jun 2012 17:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120628003003.4399.35384.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2012 17:30:03 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-received-state-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:09:59 -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 : Indicating Email Handling States in Trace Fields Author(s) : D. Crocker Murray S. Kucherawy Filename : draft-ietf-appsawg-received-state-04.txt Pages : 12 Date : 2012-06-27 Abstract: This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queueing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-received-state There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-received-state-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-received-state-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From GK@ninebynine.org Thu Jun 28 04:31: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 4261821F84DE for ; Thu, 28 Jun 2012 04:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 rP3VwcoZGgDc for ; Thu, 28 Jun 2012 04:31:58 -0700 (PDT) Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1C85421F84F2 for ; Thu, 28 Jun 2012 04:31:49 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1SkCwt-0006vW-1Q; Thu, 28 Jun 2012 12:31:47 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SkCwt-0003h1-0L; Thu, 28 Jun 2012 12:31:47 +0100 Message-ID: <4FEC3B4F.80607@ninebynine.org> Date: Thu, 28 Jun 2012 12:09:03 +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: Melvin Carvalho , "Paul E. Jones" , apps-discuss@ietf.org References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 11:31:59 -0000 On 28/06/2012 08:28, Melvin Carvalho wrote: > Should acct: be rejected, we can simply use mailto: as per SWD. Similarly > you could simply use ?acct=user@host as has been suggested. Since my comments with reviewer hat on have been cited, I feel I should summarize my personal feelings about the specification of the acct: scheme. *Reviewer hat OFF* Roughly, I think the acct: scheme does provide a useful, possibly minor, purpose that is not served by other URI schemes, and as such it has reasonable claim to meet the bar for registering a new scheme. But I think the description of the acct: scheme in the WebFinger document does a poor job of explaining this; i.e. I think there is a document quality issue here around the acct: scheme registration/specification. I've had private exchanges with one of the document editors, but I don't think my suggestions have been reflected in the current draft. In summary, what I think is not as clear as it should be in the scheme registration includes: * what does an acct URI identify * how are acct URIs allocated; what's the assignment delegation structure? * how should an acct: URI be dereferenced? (e.g. if one were used as a link in a web page, how should it be handled?). I suspect that most of this information can be inferred if one has a detailed knowledge of WebFinger protocol, but for an average Joe web developer I don't think that's really helpful. I don't think this is a sufficiently important issue for me to engage more actively with the discussion. #g -- From paulej@packetizer.com Thu Jun 28 07:37: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 AEF8721F8512 for ; Thu, 28 Jun 2012 07:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGOhKyYnT2GS for ; Thu, 28 Jun 2012 07:37:25 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DF3C621F8503 for ; Thu, 28 Jun 2012 07:37:24 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q5SEbKG1016461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2012 10:37:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1340894242; bh=7wFsQ5GxzY/R/fC0YjJ6R0Qqmm8zY1uElSLp2Gyz3FA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=WPgXNsu6r/3jTiv0hq1NIC7J3Z9fPyOhbpoSjaCGctxHYzFJhV//9qO7tLIGzb7Kr vbWFRNib2sq1CdyyS2nggCOJ6n3fhSF9ISeEQyntRsi6kEK7Il4BctLjxHo/z42vOe IVkOJkU7pFI/CbexAd6f2QaWvfkhy0Iib+w27r3g= From: "Paul E. Jones" To: "'Melvin Carvalho'" References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> In-Reply-To: Date: Thu, 28 Jun 2012 10:37:29 -0400 Message-ID: <05b701cd553b$8cc82210$a6586630$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05B8_01CD551A.05B6F740" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHACExhZgXedi2je/bJAOmWfz8jRwJIaUzKAl3mCNAA4XnPygFMoDK7Aaa5ChoBPL+df5bcnSFg Content-Language: en-us Cc: apps-discuss@ietf.org, "'Murray S. Kucherawy'" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 14:37:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05B8_01CD551A.05B6F740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Melvin, Just to the below point, it is the common discovery pattern that acct addresses. A service provider might identify users in any number of ways, but people need a well-defined and predictable way of using WebFinger. Plus, they need an ID that has been proven to be understood by the average user. If I see a twitter ID like "paulej", I should be able to safely assume that I can discover information via WF using acct:paulej@twitter.com. Users will likely not enter the "acct:" part, but that's fine. They often do not enter "http://", either. The reason I say that identifying Twitter, Facebook, Flickr, or other users is in scope is that, regardless if those services publish via WebFinger or not, the approach taken to discovery given a username and a domain name should be consistent across the web. Things like Open Graph are fine, but we need something consistent across the web for simple, consistent discovery of information related to a URI. Paul Twitter, Facebook, Flikr and Google Plus all use HTTP URIs to describe their user accounts. This is best practice on the web, and recommended in Linked Data Principles [1] which is the dominant discovery mechanism on the Web today. The gap in linked data, which I hope Webfinger can address, is a common discovery pattern (using well-known locations) for email addresses. If Twitter or Facebook and others have not asked for yet another way to identify users, I am unsure why this use case is in scope. Do note that Facebook already have a first class discovery system in the Open Graph Protocol. ------=_NextPart_000_05B8_01CD551A.05B6F740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Melvin,

 

Just to the below point, it is the common discovery pattern that acct = addresses.  A service provider might identify users  in any = number of ways, but people need a well-defined and predictable way of = using WebFinger.  Plus, they need an ID that has been proven to be = understood by the average user.  If I see a twitter ID like = “paulej”, I should be able to safely assume that I can = discover information via WF using acct:paulej@twitter.com.  Users = will likely not enter the “acct:” part, but that’s = fine.  They often do not enter “http://”, = either.

 

The reason I say that identifying Twitter, Facebook, Flickr, or other = users is in scope is that, regardless if those services publish via = WebFinger or not, the approach taken to discovery given a username and a = domain name should be consistent across the web.

 

Things like Open Graph are fine, but we need something consistent = across the web for simple, consistent discovery of information related = to a URI.

 

Paul

 

Twitter, Facebook, Flikr and Google Plus = all use HTTP URIs to describe their user accounts.  This is best = practice on the web, and recommended in Linked Data Principles [1] which = is the dominant discovery mechanism on the Web today.  The gap in = linked data, which I hope Webfinger can address, is a common discovery = pattern (using well-known locations) for email addresses.  If = Twitter or Facebook and others have not asked for yet another way to = identify users, I am unsure why this use case is in scope.  Do note = that Facebook already have a first class discovery system in the Open = Graph Protocol.

 

------=_NextPart_000_05B8_01CD551A.05B6F740-- From ht@inf.ed.ac.uk Thu Jun 28 07:58: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 56FD721F8598 for ; Thu, 28 Jun 2012 07:58:15 -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 mQIwCJ3Sc1fm for ; Thu, 28 Jun 2012 07:58:14 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2269A21F8593 for ; Thu, 28 Jun 2012 07:58:13 -0700 (PDT) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q5SEvlMc024931; Thu, 28 Jun 2012 15:57:52 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q5SEvlOY012386; Thu, 28 Jun 2012 15:57:47 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q5SEvlFl009370; Thu, 28 Jun 2012 15:57:47 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q5SEvkdn009366; Thu, 28 Jun 2012 15:57:46 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John Bradley References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4FEA6677.3020705@it.aoyama.ac.jp> <6.2.5.6.2.20120626224534.0a8b4298@resistor.net> <4FEB3060.1040805@ninebynine.org> <1340818030.8183.YahooMailNeo@web31806.mail.mud.yahoo.com> <047501cd54ae$c6848a30$538d9e90$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436656BCF0@TK5EX14MBXC283.redmond.corp.microsoft.com> <049e01cd54b0$89925ba0$9cb712e0$@packetizer.com> <6AF4CA7B-A7BC-47C7-8781-63DA7F4DB42D@ve7jtb.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 28 Jun 2012 15:57:46 +0100 In-Reply-To: <6AF4CA7B-A7BC-47C7-8781-63DA7F4DB42D@ve7jtb.com> (John Bradley's message of "Wed, 27 Jun 2012 18:13:27 -0400") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 14:58:15 -0000 John Bradley writes: > It is the W3C TAG that is the most likely to raise a blocking objection. As the informal TAG liaison here, I should make clear that the TAG has no _official_ standing from which to "raise a blocking objection". _In extremis_ the TAG chair might make an appeal on some IETF list wrt some issue of architectural concern, or might contact his/her opposite number on the IAB, or might feed something in to the official W3C/IETF liaison call. There has been no formal TAG discussion of the acct: matter to date. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ht@inf.ed.ac.uk Thu Jun 28 08:04: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 095E021F85C9 for ; Thu, 28 Jun 2012 08:04:58 -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 nWvBAsJ08pNB for ; Thu, 28 Jun 2012 08:04:57 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC8021F85C6 for ; Thu, 28 Jun 2012 08:04:57 -0700 (PDT) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q5SF3h01027870; Thu, 28 Jun 2012 16:03:43 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q5SF3ile012743; Thu, 28 Jun 2012 16:03:44 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q5SF3i0A009478; Thu, 28 Jun 2012 16:03:44 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q5SF3hHF009474; Thu, 28 Jun 2012 16:03:43 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Graham Klyne References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 28 Jun 2012 16:03:43 +0100 In-Reply-To: <4FEC3B4F.80607@ninebynine.org> (Graham Klyne's message of "Thu, 28 Jun 2012 12:09:03 +0100") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: apps-discuss@ietf.org, "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:04:58 -0000 Graham Klyne writes: > I've had private exchanges with one of the document editors, but I > don't think my suggestions have been reflected in the current draft. > In summary, what I think is not as clear as it should be in the scheme > registration includes: > * what does an acct URI identify > * how are acct URIs allocated; what's the assignment delegation structure? > * how should an acct: URI be dereferenced? (e.g. if one were used as > a link in a web page, how should it be handled?). Hear, hear. My primary reason for preferring a separate draft is/was precisely that this would make the gaps in the current proposal more obvious -- that is, make it clearer what was needed to assess the acct: proposal _as a proposal in its own right_. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From pbryan@anode.ca Thu Jun 28 08:38: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 9DC7F21F8582 for ; Thu, 28 Jun 2012 08:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 jlFTabULWwAm for ; Thu, 28 Jun 2012 08:38:05 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF6A21F8505 for ; Thu, 28 Jun 2012 08:38:05 -0700 (PDT) Received: from [10.126.22.210] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 17BD56158; Thu, 28 Jun 2012 15:38:04 +0000 (UTC) From: "Paul C. Bryan" To: "Manger, James H" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="=-bSKXDT+bjocK2B8E7wVk" Date: Thu, 28 Jun 2012 08:37:59 -0700 Message-ID: <1340897879.2393.9.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Mark Nottingham , IETF Apps Discuss , Joe Hildebrand Subject: Re: [apps-discuss] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:38:07 -0000 --=-bSKXDT+bjocK2B8E7wVk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit After my initial visceral reaction against this suggestion, I've come around to really like it. +1 Paul On Thu, 2012-06-28 at 14:21 +1000, Manger, James H wrote: > The "best" syntax for a JSON pointer is a JSON array: no new escaping; > and references to an object element or array item are easily > distinguished (using a string or a number respectively). This is > suitable for carrying a pointer in a JSON document. Examples: > > ["foo",0] > ["a/b"] > ["i\\j"] > > It is pretty awful for putting a pointer into a URI fragment, however. > > #%5B%22foo%22,0%5B > > > A syntax with one layer of %-escaping is theoretically possible since > a URI fragment allows / and %2F as separate things. However, it does > clash with APIs. For instance, the java.net.URI(scheme, host, path, > fragment) constructor will not let you generate …#/a%2Fb. Pass in "/a% > 2Fb" and you get "…#/a%252Fb". > > > Double %-escaping would work (1st layer in pointer code, 2nd layer in > URI fragment code). It's just that double escaping seems very likely > to confuse developers (mind you, all escaping confuses). Would it be > sufficient for the pointer code just to do replaceAll("% > 2[fF]","/").replaceAll("%25","%") or would it have to cope with > arbitrary other bytes being unnecessarily escaped? > > > A quick web search revealed half-a-dozen implementations [1-6] in > various languages of an early version of the JSON pointer spec that > used %-escapes. They all split the pointer on '/', then decode each > segment. > > This simple approach no longer works with the current JSON pointer > spec. split("/") fails as a "/" may be a delimiter, but may also be > part of an "^/" escape sequence. To match only delimiters requires a > regular expression with a potentially unlimited amount of > "look-behind" to see if there are an odd number of preceding carets: > (? unlimited look-behind. (? that does work. > > > Switching to ~0 and ~1 as escapes for ~ and / would allow split("/") > to work, followed by replaceAll("~1","/").replaceAll("~0","~"). > Creating a pointer is also easy: replaceAll("~", "~0").replaceAll("/", > "~1") then join the parts. "~" also doesn't need to be %-escaped in a > URI. I assume most languages have split() and replaceAll() functions. > > > [1] https://github.com/janl/node-jsonpointer > [2] > https://github.com/stefankoegl/python-json-pointer/blob/master/jsonpointer.py > [3] > https://github.com/raphaelstolt/php-jsonpointer/blob/master/src/JsonPointer/JsonPointer.php > [4] > http://sources.forgerock.org/browse/~raw,r=303/commons/json-fluent/trunk/src/main/java/org/forgerock/json/fluent/JsonPointer.java > [5] http://pydoc.net/jsonpointer/0.1/jsonpointer > [6] … > > > -- > James Manger > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-bSKXDT+bjocK2B8E7wVk Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit After my initial visceral reaction against this suggestion, I've come around to really like it.

+1

Paul

On Thu, 2012-06-28 at 14:21 +1000, Manger, James H wrote:
The "best" syntax for a JSON pointer is a JSON array: no new escaping; and references to an object element or array item are easily distinguished (using a string or a number respectively). This is suitable for carrying a pointer in a JSON document. Examples:

["foo",0]
["a/b"]
["i\\j"]

It is pretty awful for putting a pointer into a URI fragment, however.

#%5B%22foo%22,0%5B


A syntax with one layer of %-escaping is theoretically possible since a URI fragment allows / and %2F as separate things. However, it does clash with APIs. For instance, the java.net.URI(scheme, host, path, fragment) constructor will not let you generate …#/a%2Fb. Pass in "/a%2Fb" and you get "…#/a%252Fb".


Double %-escaping would work (1st layer in pointer code, 2nd layer in URI fragment code). It's just that double escaping seems very likely to confuse developers (mind you, all escaping confuses). Would it be sufficient for the pointer code just to do replaceAll("%2[fF]","/").replaceAll("%25","%") or would it have to cope with arbitrary other bytes being unnecessarily escaped?


A quick web search revealed half-a-dozen implementations [1-6] in various languages of an early version of the JSON pointer spec that used %-escapes. They all split the pointer on '/', then decode each segment.

This simple approach no longer works with the current JSON pointer spec. split("/") fails as a "/" may be a delimiter, but may also be part of an "^/" escape sequence. To match only delimiters requires a regular expression with a potentially unlimited amount of "look-behind" to see if there are an odd number of preceding carets: (?<![^^](?:\^\^)*\^)/. Java (v1.6), for example, does not support unlimited look-behind. (?<![^^](?:\^\^){0,99}\^)/ is an approximation that does work.


Switching to ~0 and ~1 as escapes for ~ and / would allow split("/") to work, followed by replaceAll("~1","/").replaceAll("~0","~"). Creating a pointer is also easy: replaceAll("~", "~0").replaceAll("/", "~1") then join the parts. "~" also doesn't need to be %-escaped in a URI. I assume most languages have split() and replaceAll() functions.


[1] https://github.com/janl/node-jsonpointer
[2] https://github.com/stefankoegl/python-json-pointer/blob/master/jsonpointer.py
[3] https://github.com/raphaelstolt/php-jsonpointer/blob/master/src/JsonPointer/JsonPointer.php
[4] http://sources.forgerock.org/browse/~raw,r=303/commons/json-fluent/trunk/src/main/java/org/forgerock/json/fluent/JsonPointer.java
[5] http://pydoc.net/jsonpointer/0.1/jsonpointer
[6] …


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

--=-bSKXDT+bjocK2B8E7wVk-- From iesg-secretary@ietf.org Thu Jun 28 08:52: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 662FC21F8547; Thu, 28 Jun 2012 08:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqNiZB-gwXRb; Thu, 28 Jun 2012 08:52:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E6F21F8442; Thu, 28 Jun 2012 08:52:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120628155205.20974.33837.idtracker@ietfa.amsl.com> Date: Thu, 28 Jun 2012 08:52:05 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (Indicating Email Handling States in Trace Fields) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:52:06 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Indicating Email Handling States in Trace Fields' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queueing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-received-state/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-received-state/ballot/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Thu Jun 28 09:21: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 3700221F85CF; Thu, 28 Jun 2012 09:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 FhUNjw2xgGII; Thu, 28 Jun 2012 09:21:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2254721F8559; Thu, 28 Jun 2012 09:21:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120628162148.13815.19599.idtracker@ietfa.amsl.com> Date: Thu, 28 Jun 2012 09:21:48 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-05.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, 28 Jun 2012 16:21:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Forwarded HTTP Extension Author(s) : Andreas Petersson Martin Nilsson Filename : draft-ietf-appsawg-http-forwarded-05.txt Pages : 15 Date : 2012-06-28 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-http-forwarded-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From andy@hxr.us Thu Jun 28 09: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 6F08521F8526 for ; Thu, 28 Jun 2012 09:52:18 -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 MZFuqwdigO1X for ; Thu, 28 Jun 2012 09:52:17 -0700 (PDT) Received: from mail-yw0-f42.google.com (mail-yw0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id C030821F8513 for ; Thu, 28 Jun 2012 09:52:16 -0700 (PDT) Received: by yhfq11 with SMTP id q11so2495162yhf.15 for ; Thu, 28 Jun 2012 09:52:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=oojn50VSrG01bkv3U8uTy0q+lfGM7+XVlF0995o814A=; b=nfY2JJfESe/YNm7lt8ZgBFYSxzCsmlCIyQTnH1yHCUDDuvZVr9eT+G2z5AjSG3bOCN acxmkAeq9rLagSdK9UvpF2WG/mJZhLR6oFHnay6jb5ycDZoxkTuDRl2sS9IUWUqDIN+J 9ZVF03cteb5eYOJKPsIhc1p9+f+yWY4x0HIXQGyUtKDcRhHOF4wJoELnyKkGpRoffxXv 8WCjaheaCk4pP5A1liv0jqP8lLPrqJxdoyyeuYtaz9iSRWqm3J1HgoWKgLLeHceBGc0k 1riQl4nbqXqP2EJUznenSpjWm4nxnaRZNSkOhfUGBuejlRI6x9HgcDS0J8Bs4TE+nZnZ 2lSQ== Received: by 10.236.143.35 with SMTP id k23mr4518737yhj.72.1340902336173; Thu, 28 Jun 2012 09:52:16 -0700 (PDT) Received: from ?IPv6:2001:500:4:15::49? ([2001:500:4:15::49]) by mx.google.com with ESMTPS id y8sm5293001anj.11.2012.06.28.09.52.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jun 2012 09:52:15 -0700 (PDT) Message-ID: <4FEC8BA7.5060801@hxr.us> Date: Thu, 28 Jun 2012 12:51:51 -0400 From: Andy Newton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <4AB1590B-710F-4EF2-B1B5-A1BA7A877BBE@hxr.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm3LyJ2jP+CF4k/1qHS6nbL2e2+pqbTGuYhv4PQWArmDEPwPzHCzGcF7kkjzox7bYjOJDWf Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] URNBIS needs your eyeballs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2012 16:52:19 -0000 On 06/27/2012 11:01 PM, Bjoern Hoehrmann wrote: > (Such requests would be much easier to act upon if they came with some > description of what to look for, what has changed, and so on.) Each draft has text embedded noting raised issues and potential changes, in addition to an appendix describing the substantive differences between the draft and the RFC being revised. -andy From stpeter@stpeter.im Thu Jun 28 09:53: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 E973321F8449 for ; Thu, 28 Jun 2012 09:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 H-iarRlEqnZJ for ; Thu, 28 Jun 2012 09:53:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id ECC2921F8540 for ; Thu, 28 Jun 2012 09:53:06 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8EE814005A; Thu, 28 Jun 2012 11:11:05 -0600 (MDT) Message-ID: <4FEC8BF0.6070605@stpeter.im> Date: Thu, 28 Jun 2012 10:53:04 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Graham Klyne References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> In-Reply-To: <4FEC3B4F.80607@ninebynine.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:53:08 -0000 On 6/28/12 5:09 AM, Graham Klyne wrote: > On 28/06/2012 08:28, Melvin Carvalho wrote: >> Should acct: be rejected, we can simply use mailto: as per SWD. >> Similarly >> you could simply use ?acct=user@host as has been suggested. > > Since my comments with reviewer hat on have been cited, I feel I should > summarize my personal feelings about the specification of the acct: scheme. > > *Reviewer hat OFF* > > Roughly, I think the acct: scheme does provide a useful, possibly minor, > purpose that is not served by other URI schemes, and as such it has > reasonable claim to meet the bar for registering a new scheme. But I > think the description of the acct: scheme in the WebFinger document does > a poor job of explaining this; i.e. I think there is a document quality > issue here around the acct: scheme registration/specification. > > I've had private exchanges with one of the document editors, but I don't > think my suggestions have been reflected in the current draft. In > summary, what I think is not as clear as it should be in the scheme > registration includes: > * what does an acct URI identify > * how are acct URIs allocated; what's the assignment delegation structure? > * how should an acct: URI be dereferenced? (e.g. if one were used as a > link in a web page, how should it be handled?). > > I suspect that most of this information can be inferred if one has a > detailed knowledge of WebFinger protocol, but for an average Joe web > developer I don't think that's really helpful. > > I don't think this is a sufficiently important issue for me to engage > more actively with the discussion. Graham, I think you're right about the fact that these matters are underspecified. I hereby offer to propose some text, and will do that in the next few days. Peter -- Peter Saint-Andre https://stpeter.im/ From mnot@mnot.net Thu Jun 28 14:44: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 1D69821F8616 for ; Thu, 28 Jun 2012 14:44:59 -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 zsGuPBSXZol5 for ; Thu, 28 Jun 2012 14:44:58 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 14BB821F8615 for ; Thu, 28 Jun 2012 14:44:58 -0700 (PDT) Received: from [10.5.66.24] (unknown [72.32.115.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7F51322E1F4; Thu, 28 Jun 2012 17:44:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Mark Nottingham In-Reply-To: <1340897879.2393.9.camel@pbryan-wsl.internal.salesforce.com> Date: Fri, 29 Jun 2012 07:44:45 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> <1340897879.2393.9.camel@pbryan-wsl.internal.salesforce.com> To: Paul C. Bryan X-Mailer: Apple Mail (2.1278) Cc: IETF Apps Discuss , Joe Hildebrand Subject: Re: [apps-discuss] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 21:44:59 -0000 Let's see how it looks in the examples we just inserted. { "foo": ["bar", "baz"], "": 0 "a/b": 1, "c%d": 2, "e^f": 3, "g|h": 4, "i\\j": 5, "k\"l": 6, " ": 7 } In JSON strings: =20 "" // the whole document "/foo" ["bar", "baz"] "/foo/0" "bar" "/" 0 "/a~1b" 1 "/c%d" 2 "/e^f" 3 "/g|h" 4 "/i\\j" 5 "/k\"l" 6 " " 7 and in URIs fragments: # // the whole document #/foo ["bar", "baz"] #/foo/0 "bar" #/ 0 #/a~1b 1 #/c%25d 2 #/e%5Ef 3 #/g%7Ch 4 #/i%5Cj 5 #/k%22l 6 #/%20 7 Of course, we don't have any ~ examples, but it does seem cleaner in = both encodings. On 29/06/2012, at 1:37 AM, Paul C. Bryan wrote: > After my initial visceral reaction against this suggestion, I've come = around to really like it. >=20 > +1 >=20 > Paul >=20 > On Thu, 2012-06-28 at 14:21 +1000, Manger, James H wrote: >> The "best" syntax for a JSON pointer is a JSON array: no new = escaping; and references to an object element or array item are easily = distinguished (using a string or a number respectively). This is = suitable for carrying a pointer in a JSON document. Examples: >>=20 >> ["foo",0] >> ["a/b"] >> ["i\\j"] >>=20 >> It is pretty awful for putting a pointer into a URI fragment, = however. >>=20 >> #%5B%22foo%22,0%5B >>=20 >>=20 >> A syntax with one layer of %-escaping is theoretically possible since = a URI fragment allows / and %2F as separate things. However, it does = clash with APIs. For instance, the java.net.URI(scheme, host, path, = fragment) constructor will not let you generate =85#/a%2Fb. Pass in = "/a%2Fb" and you get "=85#/a%252Fb". >>=20 >>=20 >> Double %-escaping would work (1st layer in pointer code, 2nd layer in = URI fragment code). It's just that double escaping seems very likely to = confuse developers (mind you, all escaping confuses). Would it be = sufficient for the pointer code just to do = replaceAll("%2[fF]","/").replaceAll("%25","%") or would it have to cope = with arbitrary other bytes being unnecessarily escaped? >>=20 >>=20 >> A quick web search revealed half-a-dozen implementations [1-6] in = various languages of an early version of the JSON pointer spec that used = %-escapes. They all split the pointer on '/', then decode each segment. >>=20 >> This simple approach no longer works with the current JSON pointer = spec. split("/") fails as a "/" may be a delimiter, but may also be part = of an "^/" escape sequence. To match only delimiters requires a regular = expression with a potentially unlimited amount of "look-behind" to see = if there are an odd number of preceding carets: (?>=20 >>=20 >> Switching to ~0 and ~1 as escapes for ~ and / would allow split("/") = to work, followed by replaceAll("~1","/").replaceAll("~0","~"). Creating = a pointer is also easy: replaceAll("~", "~0").replaceAll("/", "~1") then = join the parts. "~" also doesn't need to be %-escaped in a URI. I assume = most languages have split() and replaceAll() functions. >>=20 >>=20 >> [1] https://github.com/janl/node-jsonpointer >> [2] = https://github.com/stefankoegl/python-json-pointer/blob/master/jsonpointer= .py >> [3] = https://github.com/raphaelstolt/php-jsonpointer/blob/master/src/JsonPointe= r/JsonPointer.php >> [4] = http://sources.forgerock.org/browse/~raw,r=3D303/commons/json-fluent/trunk= /src/main/java/org/forgerock/json/fluent/JsonPointer.java >> [5] http://pydoc.net/jsonpointer/0.1/jsonpointer >> [6] =85 >>=20 >>=20 >> -- >> James Manger >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 -- Mark Nottingham http://www.mnot.net/ From martin.thomson@gmail.com Thu Jun 28 15:31:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F71911E80E1 for ; Thu, 28 Jun 2012 15:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 qgVr6RbBO3gy for ; Thu, 28 Jun 2012 15:31:04 -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 5518021F85EA for ; Thu, 28 Jun 2012 15:31:04 -0700 (PDT) Received: by bkty8 with SMTP id y8so2715750bkt.31 for ; Thu, 28 Jun 2012 15:31:03 -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=8mt36m026sdv4ZqVHaXwGdO+g6/PdD6R1ln3Ue6zKrs=; b=jjWDc1qxEdTJdZDNXcl30GEdQkjDmhH2lEWIIKmRMCjVtJGwx/MiGHEoFHLD3JA1d/ A0oqo/7SvLcP/6DW+2AK+Z2dMpTymKQ15ey88qJ5c5rTYx870R837XR/iOhYRDKJI98A +bCjL+neD2PW1+CU0SqOjnxtY/JflZBRWe7vleDfmH2COjEGTfEt+KdmW/gCG88ILuwg HfCKv4jtT4eQsRZ6M1wxyDzjofn35J8LF4kPLgkP/knRFbOpeyg9jimAHhHLgoaxVIBJ ndpI/EOyccn+HSO/AwsGVq+EIADcYOme8UQQcXg5DibB6VF6YNXI6Uz5HDStHFXVfmJ1 sjMw== MIME-Version: 1.0 Received: by 10.204.128.149 with SMTP id k21mr2096746bks.42.1340922663357; Thu, 28 Jun 2012 15:31:03 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Thu, 28 Jun 2012 15:31:03 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> <1340897879.2393.9.camel@pbryan-wsl.internal.salesforce.com> Date: Thu, 28 Jun 2012 15:31:03 -0700 Message-ID: From: Martin Thomson To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss , Joe Hildebrand Subject: Re: [apps-discuss] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 22:31:05 -0000 On 28 June 2012 14:44, Mark Nottingham wrote: > Of course, we don't have any ~ examples, but it does seem cleaner in both encodings. As a quoting character, ~ is a good choice. I might offer that 0 and 1 are strange choices for the next character, but I wont offer an alternative except to note that double-escape is the more commonly used method for escaping the escape character. From pbryan@anode.ca Thu Jun 28 15:36: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 936F011E80E1 for ; Thu, 28 Jun 2012 15:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 Otn3S5zRxEBn for ; Thu, 28 Jun 2012 15:36:12 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id E683011E80D7 for ; Thu, 28 Jun 2012 15:36:11 -0700 (PDT) Received: from [10.126.22.210] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 40C146471; Thu, 28 Jun 2012 22:36:11 +0000 (UTC) From: "Paul C. Bryan" To: Martin Thomson In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> <1340897879.2393.9.camel@pbryan-wsl.internal.salesforce.com> Content-Type: multipart/alternative; boundary="=-nbt4DMo3+Y0wzCk1pk1r" Date: Thu, 28 Jun 2012 15:36:09 -0700 Message-ID: <1340922969.2393.13.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Mark Nottingham , Joe Hildebrand , IETF Apps Discuss Subject: Re: [apps-discuss] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 22:36:12 -0000 --=-nbt4DMo3+Y0wzCk1pk1r Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit True, ~~ would just as good to escape ~ instead of ~0... Paul On Thu, 2012-06-28 at 15:31 -0700, Martin Thomson wrote: > On 28 June 2012 14:44, Mark Nottingham wrote: > > Of course, we don't have any ~ examples, but it does seem cleaner in both encodings. > > As a quoting character, ~ is a good choice. I might offer that 0 and > 1 are strange choices for the next character, but I wont offer an > alternative except to note that double-escape is the more commonly > used method for escaping the escape character. --=-nbt4DMo3+Y0wzCk1pk1r Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit True, ~~ would just as good to escape ~ instead of ~0...

Paul

On Thu, 2012-06-28 at 15:31 -0700, Martin Thomson wrote: 
On 28 June 2012 14:44, Mark Nottingham <mnot@mnot.net> wrote:
> Of course, we don't have any ~ examples, but it does seem cleaner in both encodings.

As a quoting character, ~ is a good choice.  I might offer that 0 and
1 are strange choices for the next character, but I wont offer an
alternative except to note that double-escape is the more commonly
used method for escaping the escape character.

--=-nbt4DMo3+Y0wzCk1pk1r-- From James.H.Manger@team.telstra.com Thu Jun 28 17:19: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 C830411E808D for ; Thu, 28 Jun 2012 17:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKX8J0xEVnNq for ; Thu, 28 Jun 2012 17:19:55 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7A711E80C2 for ; Thu, 28 Jun 2012 17:19:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,495,1336312800"; d="scan'208";a="78878289" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 29 Jun 2012 10:19:52 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6756"; a="73943523" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbni.tcif.telstra.com.au with ESMTP; 29 Jun 2012 10:19:52 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Fri, 29 Jun 2012 10:19:51 +1000 From: "Manger, James H" To: "Paul C. Bryan" , Martin Thomson Date: Fri, 29 Jun 2012 10:19:49 +1000 Thread-Topic: [apps-discuss] #3: json-pointer escape characters Thread-Index: Ac1Vfm9BGJWiBvkmSJWckQW/ETSRWQACrbQQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114F730FACE@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> <1340897879.2393.9.camel@pbryan-wsl.internal.salesforce.com> <1340922969.2393.13.camel@pbryan-wsl.internal.salesforce.com> In-Reply-To: <1340922969.2393.13.camel@pbryan-wsl.internal.salesforce.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Mark Nottingham , IETF Apps Discuss , Joe Hildebrand Subject: Re: [apps-discuss] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 00:19:55 -0000 Pj4gQXMgYSBxdW90aW5nIGNoYXJhY3RlciwgfiBpcyBhIGdvb2QgY2hvaWNlLiAgSSBtaWdodCBv ZmZlciB0aGF0IDAgYW5kDQo+PiAxIGFyZSBzdHJhbmdlIGNob2ljZXMgZm9yIHRoZSBuZXh0IGNo YXJhY3RlciwgYnV0IEkgd29udCBvZmZlciBhbg0KPj4gYWx0ZXJuYXRpdmUgZXhjZXB0IHRvIG5v dGUgdGhhdCBkb3VibGUtZXNjYXBlIGlzIHRoZSBtb3JlIGNvbW1vbmx5DQo+PiB1c2VkIG1ldGhv ZCBmb3IgZXNjYXBpbmcgdGhlIGVzY2FwZSBjaGFyYWN0ZXIuDQoNCj4gVHJ1ZSwgfn4gd291bGQg anVzdCBhcyBnb29kIHRvIGVzY2FwZSB+IGluc3RlYWQgb2YgfjAuLi4NCg0KTm8uDQoNClVzaW5n ICJ+fiIgdG8gZXNjYXBlICJ+IiBtZWFucyBhICJ+IiBpbiBhIHBvaW50ZXIgY2FuIGJlDQplaXRo ZXIgYW4gZXNjYXBlciBvciBhbiBlc2NhcGVlIC0tIGFuZCB5b3UgaGF2ZSB0byBjb3VudA0KYSBw b3RlbnRpYWxseSBpbmRlZmluaXRlIG51bWJlciBvZiBwcmVjZWRpbmcgIn4iJ3MgdG8NCmRldGVy bWluZSB0aGUgYW5zd2VyLiBUaGF0IGp1c3QgbWFrZXMgcGFyc2luZyBhbmQgbWF0Y2hpbmcNCndp dGggYSByZWdleCBoYXJkZXIuDQoNClRoZSBuYW1lcyBpbiB0aGUgZm9sbG93aW5nIDIgcG9pbnRl cnMgZW5kIGluICIxIiBvciAiLyIuDQpXaGljaCBpcyB3aGljaD8NCg0KIC9+fn5+fn5+fn5+fn5+ fn5+fn5+fjENCiAvfn5+fn5+fn5+fn5+fn5+fn5+fjENCg0KSXQgaXMgbXVjaCBtb3JlIG9idmlv dXMgaWYgd2UgdXNlICJ+MCIgYXMgdGhlIGVzY2FwZSBmb3IgIn4iLg0KDQogL34wfjB+MH4wfjB+ MH4wfjB+MH4wMQ0KIC9+MH4wfjB+MH4wfjB+MH4wfjB+MQ0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoN Cg== From ec429@cantab.net Thu Jun 28 17:56:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A6311E80A2 for ; Thu, 28 Jun 2012 17:56:11 -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=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0lwM6XF0AeP for ; Thu, 28 Jun 2012 17:56:10 -0700 (PDT) Received: from hyena.aluminati.org (hyena.aluminati.org [64.22.123.221]) by ietfa.amsl.com (Postfix) with ESMTP id 4055B11E809F for ; Thu, 28 Jun 2012 17:56:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hyena.aluminati.org (Postfix) with ESMTP id C9F4422F12 for ; Fri, 29 Jun 2012 01:56:09 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at hyena.aluminati.org Authentication-Results: hyena.aluminati.org (amavisd-new); dkim=pass header.i=@cantab.net Received: from hyena.aluminati.org ([127.0.0.1]) by localhost (hyena.aluminati.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeFsby2-fpDn for ; Fri, 29 Jun 2012 01:56:09 +0100 (BST) Received: from pichi.aluminati.org (pichi.aluminati.org [10.0.16.50]) by hyena.aluminati.org (Postfix) with ESMTP id 7191522BFE for ; Fri, 29 Jun 2012 01:56:09 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by pichi.aluminati.org (Postfix) with ESMTP id 483B3161E0A0 for ; Fri, 29 Jun 2012 01:56:09 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cantab.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=postfix; t= 1340931369; bh=eKVTUxVhXzNv0wPveRZt6xoI++W0zsSulABSKVb5xYo=; b=I JAzYIlhxUDUENsyrivGQ9kZyU3drEsQhQjsHK8KU44hXGwBm5GcVRTNmKnfPWZLz l4m+dPHXMnvScj3iNzYOPKItCc9CxhCqfhXlhWsTSR9tVsoF0/elF9bGCOLaz+wy l3Nd5bexjPmOkAGeX/Ha+gHpTiKztzv/oX54uTJh5U= X-Virus-Scanned: Debian amavisd-new at aluminati.org Received: from pichi.aluminati.org ([127.0.0.1]) by localhost (pichi.aluminati.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-jmS8ZGgNs6 for ; Fri, 29 Jun 2012 01:56:09 +0100 (BST) Received: from [131.111.202.32] (tg2.aluminati.org [10.0.7.178]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pichi.aluminati.org (Postfix) with ESMTPSA id F40E4161E099 for ; Fri, 29 Jun 2012 01:56:07 +0100 (BST) Message-ID: <4FECFD26.7090207@cantab.net> Date: Fri, 29 Jun 2012 01:56:06 +0100 From: Edward Cree User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> <1340897879.2393.9.camel@pbryan-wsl.internal.salesforce.com> <1340922969.2393.13.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114F730FACE@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F730FACE@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 00:56:11 -0000 On 29/06/12 01:19, Manger, James H wrote: >>> As a quoting character, ~ is a good choice. I might offer that 0 and >>> 1 are strange choices for the next character >> True, ~~ would just as good to escape ~ instead of ~0... > No. > > Using "~~" to escape "~" means a "~" in a pointer can be > either an escaper or an escapee -- and you have to count > a potentially indefinite number of preceding "~"'s to > determine the answer. 0 and 1 are still strange choices, though; it might be better to use 'descriptive' single letters, perhaps ~s for a slash and either ~t for 't'ilde or ~e for 'e'scape. However, "~t" might be a confusing choice as "\t" usually means 't'ab. Of course, a regex is in any case the Wrong way to unescape a string, but it's not our job to tell implementers what to do. -- Edward Cree From James.H.Manger@team.telstra.com Thu Jun 28 18:21: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 B97CC11E810B for ; Thu, 28 Jun 2012 18:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.058 X-Spam-Level: X-Spam-Status: No, score=-1.058 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5U1IGv21+pA for ; Thu, 28 Jun 2012 18:21:18 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8192811E80A2 for ; Thu, 28 Jun 2012 18:21:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,495,1336312800"; d="scan'208";a="80046924" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 29 Jun 2012 11:21:15 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6756"; a="82109118" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcavi.tcif.telstra.com.au with ESMTP; 29 Jun 2012 11:21:16 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Fri, 29 Jun 2012 11:21:15 +1000 From: "Manger, James H" To: Edward Cree , "apps-discuss@ietf.org" Date: Fri, 29 Jun 2012 11:21:13 +1000 Thread-Topic: [apps-discuss] #3: json-pointer escape characters Thread-Index: Ac1Vkf7UwIJioXF1QhW6k4e3NkbU3AAAiWXw Message-ID: <255B9BB34FB7D647A506DC292726F6E114F73F4253@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> <1340897879.2393.9.camel@pbryan-wsl.internal.salesforce.com> <1340922969.2393.13.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114F730FACE@WSMSG3153V.srv.dir.telstra.com> <4FECFD26.7090207@cantab.net> In-Reply-To: <4FECFD26.7090207@cantab.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 01:21:19 -0000 RWR3YXJkLA0KDQo+IE9mIGNvdXJzZSwgYSByZWdleCBpcyBpbiBhbnkgY2FzZSB0aGUgV3Jvbmcg d2F5IHRvIHVuZXNjYXBlIGEgc3RyaW5nLA0KPiBidXQgaXQncyBub3Qgb3VyIGpvYiB0byB0ZWxs IGltcGxlbWVudGVycyB3aGF0IHRvIGRvLg0KDQpXaHkgaXMgdXNpbmcgYSByZWd1bGFyIGV4cHJl c3Npb24gdGhlIFdyb25nIHdheSB0byB1bmVzY2FwZSBhIHN0cmluZz8NCklzIGl0IGJlY2F1c2Ug dGhlIHNpbXBsZXN0IGltcGxlbWVudGF0aW9uIHVzZXMgYSBzZXBhcmF0ZSBwYXNzIG92ZXIgdGhl IHdob2xlIHN0cmluZyBmb3IgZWFjaCBlc2NhcGUgc2VxdWVuY2UsIHdoaWNoIGlzIGluZWZmaWNp ZW50Pw0KDQpTdWdnZXN0aW5nIGEgUmlnaHQgd2F5IHRvIGltcGxlbWVudGVycyBpcyBwYXJ0IG9m IHRoZSBqb2Igb2YgYSBzdGFuZGFyZC4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From ec429@cantab.net Thu Jun 28 19:31: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 DD9AE21F864A for ; Thu, 28 Jun 2012 19:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.001, 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 619CywFcrSnv for ; Thu, 28 Jun 2012 19:31:38 -0700 (PDT) Received: from hyena.aluminati.org (hyena.aluminati.org [64.22.123.221]) by ietfa.amsl.com (Postfix) with ESMTP id D813221F8649 for ; Thu, 28 Jun 2012 19:31:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hyena.aluminati.org (Postfix) with ESMTP id 893531FC96; Fri, 29 Jun 2012 03:31:37 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at hyena.aluminati.org Authentication-Results: hyena.aluminati.org (amavisd-new); dkim=pass header.i=@cantab.net Received: from hyena.aluminati.org ([127.0.0.1]) by localhost (hyena.aluminati.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LTwN5RkyEQz; Fri, 29 Jun 2012 03:31:37 +0100 (BST) Received: from pichi.aluminati.org (pichi.aluminati.org [10.0.16.50]) by hyena.aluminati.org (Postfix) with ESMTP id DA65F1FC38; Fri, 29 Jun 2012 03:31:36 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by pichi.aluminati.org (Postfix) with ESMTP id B4144161E09E; Fri, 29 Jun 2012 03:31:36 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cantab.net; h= content-type:content-type:in-reply-to:references:subject:subject :mime-version:user-agent:from:from:date:date:message-id:received :received; s=postfix; t=1340937096; bh=8PEIeV+fad8UPjO3w+PxRjjlI DxOL5cF+lt1/eossDs=; b=KffFARXl8c6+qkZLrOf7RXyHydOf1L3ADs6tRL7Pa icFgsReY+ahUAi2P0iAj6EuOqxHs5sv7oYTRWSmXfZfF6/tDnSNsNezjwV3ClyF/ iE8X0/yUKh+6sT2vUCYKs9AhhK4ofeRBQCsPChcvSBCW/WhxKmvRnlu6t4JupoBh yU= X-Virus-Scanned: Debian amavisd-new at aluminati.org Received: from pichi.aluminati.org ([127.0.0.1]) by localhost (pichi.aluminati.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duqzbIo-ktE5; Fri, 29 Jun 2012 03:31:36 +0100 (BST) Received: from [131.111.202.32] (tg2.aluminati.org [10.0.7.178]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pichi.aluminati.org (Postfix) with ESMTPSA id 96131161E099; Fri, 29 Jun 2012 03:31:33 +0100 (BST) Message-ID: <4FED1384.5000204@cantab.net> Date: Fri, 29 Jun 2012 03:31:32 +0100 From: Edward Cree User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> <1340897879.2393.9.camel@pbryan-wsl.internal.salesforce.com> <1340922969.2393.13.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114F730FACE@WSMSG3153V.srv.dir.telstra.com> <4FECFD26.7090207@cantab.net> <255B9BB34FB7D647A506DC292726F6E114F73F4253@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F73F4253@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="------------050609080205020709050900" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 02:31:39 -0000 This is a multi-part message in MIME format. --------------050609080205020709050900 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 29/06/12 02:21, Manger, James H wrote: > Edward, >> Of course, a regex is in any case the Wrong way to unescape a string, >> but it's not our job to tell implementers what to do. > Why is using a regular expression the Wrong way to unescape a string? > Is it because the simplest implementation uses a separate pass over the whole string for each escape sequence, which is inefficient? No, it's because a regular expression engine is needless complexity, as well as its troubles with things like the "~~" scheme. IMHO the Right way to unescape (or, for that matter, escape) a string is to run a state machine along it. This is efficient, it can handle many escape sequences in a single pass, the set of escapes can be encoded once in a table and used by both the escaping and unescaping functions (thus preserving SPOT) which is hard to do with a regex based approach. But do enlighten me if I'm missing something. To clarify, by "run a state machine along it" I mean something like this: char c; bool esc=false; while((c=inputString.getCharacter())) { if(esc) { switch(c) { case '~' outputString.appendCharacter('~'); break; case '1' outputString.appendCharacter('/'); break; default: outputString.appendCharacter(c); break; } esc=false; } else if(c=='~') esc=true; else outputString.appendCharacter(c); } This has no problem dealing with "~~~~~~~~~~~~~~~~~~~~~~~~1", because it doesn't need to backtrack. It's also likely to have less overhead than a regex. -- Edward Cree --------------050609080205020709050900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 29/06/12 02:21, Manger, James H wrote: 
Edward,

Of course, a regex is in any case the Wrong way to unescape a string,
but it's not our job to tell implementers what to do.

Why is using a regular expression the Wrong way to unescape a string?
Is it because the simplest implementation uses a separate pass over the whole string for each escape sequence, which is inefficient?
No, it's because a regular expression engine is needless complexity, as well as its troubles with things like the "~~" scheme.
IMHO the Right way to unescape (or, for that matter, escape) a string is to run a state machine along it.  This is efficient, it can handle many escape sequences in a single pass, the set of escapes can be encoded once in a table and used by both the escaping and unescaping functions (thus preserving SPOT) which is hard to do with a regex based approach.
But do enlighten me if I'm missing something.

To clarify, by "run a state machine along it" I mean something like this:
char c;
bool esc=false;
while((c=inputString.getCharacter()))
{
    if(esc)
    {
        switch(c)
        {
            case '~'
                outputString.appendCharacter('~');
            break;
            case '1'
                outputString.appendCharacter('/');
            break;
            default:
                outputString.appendCharacter(c);
            break;
        }
        esc=false;
    }
    else if(c=='~')
        esc=true;
    else
        outputString.appendCharacter(c);
}
This has no problem dealing with "~~~~~~~~~~~~~~~~~~~~~~~~1", because it doesn't need to backtrack.  It's also likely to have less overhead than a regex.
--
Edward Cree
--------------050609080205020709050900-- From duerst@it.aoyama.ac.jp Fri Jun 29 01:44: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 28AB121F8712 for ; Fri, 29 Jun 2012 01:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.2 X-Spam-Level: X-Spam-Status: No, score=-98.2 tagged_above=-999 required=5 tests=[AWL=-1.191, BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.292, 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 9iwSLZUEnHJH for ; Fri, 29 Jun 2012 01:44:03 -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 619C521F8656 for ; Fri, 29 Jun 2012 01:44:02 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q5T8hreQ016528 for ; Fri, 29 Jun 2012 17:43:53 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 136e_3724_8e48621a_c1c6_11e1_a9b7_001d096c5782; Fri, 29 Jun 2012 17:43:52 +0900 Received: from [IPv6:::1] ([133.2.210.1]:51625) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 29 Jun 2012 17:43:56 +0900 Message-ID: <4FED6AC2.7070104@it.aoyama.ac.jp> Date: Fri, 29 Jun 2012 17:43:46 +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 CC: apps-discuss@ietf.org References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE9BFF9.9060403@stpeter.im> <035988BC-A9BC-4397-8593-D5F84710ECF3@ve7jtb.com> <4FE9C9D4.5060106@stpeter.im> <49510B16-56BF-4445-8865-4FE3CF6ED99C@ve7jtb.com> <042501cd54a4$f0b054b0$d210fe10$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436656BAA3@TK5EX14MBXC283.redmond.corp.microsoft.com> <048801cd54af$a7be9ef0$f73bdcd0$@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 08:44:04 -0000 On 2012/06/28 8:21, Melvin Carvalho wrote: > I could be mistaken, but my impression was that more were in favor of the > acct: URI scheme having it's own document, than not. Is there a way in > which consensus can be established, on this issue? A few days/weeks, the WG chairs have asked us what we'd prefer to do. It's now up to the WG chairs to tell us which way they want the thing to proceed. Based on the feedback I have seen, it could go either way. I think the most important thing now is for the chairs to make a decision, so that people can go back to work on the document(s) and can stop discussing procedural stuff. Regards, Martin. From wmills@yahoo-inc.com Fri Jun 29 08:01: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 AB51121F876D for ; Fri, 29 Jun 2012 08:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[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 KYiU4mTG-svM for ; Fri, 29 Jun 2012 08:01:56 -0700 (PDT) Received: from nm13-vm2.bullet.mail.ne1.yahoo.com (nm13-vm2.bullet.mail.ne1.yahoo.com [98.138.91.89]) by ietfa.amsl.com (Postfix) with SMTP id A847321F8697 for ; Fri, 29 Jun 2012 08:01:55 -0700 (PDT) Received: from [98.138.90.50] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jun 2012 15:01:52 -0000 Received: from [98.138.89.173] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jun 2012 15:01:52 -0000 Received: from [127.0.0.1] by omp1029.mail.ne1.yahoo.com with NNFMP; 29 Jun 2012 15:01:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 212908.7428.bm@omp1029.mail.ne1.yahoo.com Received: (qmail 24285 invoked by uid 60001); 29 Jun 2012 15:01:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1340982111; bh=3ApnxexcyYLWVu1MrhL6DnOUxG0ZdGCQwQfcbu+QBrk=; 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=j5kQtSGvWcqZj4T0FsqUFQrF0gfJ2JjMB4Z96VyUsHbas4yqmUkCi224NYGtz4Zrm1E36KIeJJlTt1rSzmQu7Me4warn9UF8QSrXPtg6oW9uDjsbfZEpnW7D/QDyoWewhKuCAxfqYS5SygBrFcuy6CTjFYTVhEH6VgdYrGmA1K4= 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=DMsrMw+q037jHKT1IsxfJ5AO9+BdfxVKP5savsjpDxtmswldXnvkv79qX8KnKyJUHLkZdphFiyZXVIN64DlIHMjESGmdR7s1IrwvrbpQHF8BIjLMh6/FVP1UxoGR0pnuzNdYJCy0kskNRv+6D7fvRRa3zRYvmhZkHrPYQKsWjw8=; X-YMail-OSG: .0a2Sv4VM1lbj_UnPlM.hDnHS5CyAa5LAycVTRnu9k5UhQX ZtGIZEglyTKOx1sBvqg1Uxn.me9zak6oFBpjnYrJOWTiwPwMArqnL0Ezd9Sd CuBDhV2hGQcDzv3slRglMltsa7uAMYvUQAk6mwdq9SVmFDQxPF4Hlf6AiWyT 5U8nG9yetUDabx4Vhjf3OYJTMekrADLTXaoK82ZMGNGM08VOWj1JYrP4S1sh YoRqjVji1LxjbEXj3LOeGILkuqWoN7N7XYa_iWMSrlIk3z3HHxmSN6RYpjfo Q6_YD1T6pZz1M1IMt2fYcn_ebkzBPMy7_T2gfNLL3h5lKdeReOp4dZr8sCW3 RcynBn2SaDjQlnXM2inDeGtoCQGkRYF9_aqNpefw5rX64V_bK41DUIkwTVjY dqRdt5vHBY6WSKQfd7wi93azPT5Pb_aku2Gw- Received: from [162.119.128.125] by web31802.mail.mud.yahoo.com via HTTP; Fri, 29 Jun 2012 08:01:51 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> <1340897879.2393.9.camel@pbryan-wsl.internal.salesforce.com> <1340922969.2393.13.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114F730FACE@WSMSG3153V.srv.dir.telstra.com> Message-ID: <1340982111.16871.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Fri, 29 Jun 2012 08:01:51 -0700 (PDT) From: William Mills To: "Manger, James H" , "Paul C. Bryan" , Martin Thomson In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F730FACE@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-975504908-1340982111=:16871" Cc: Mark Nottingham , Joe Hildebrand , IETF Apps Discuss Subject: Re: [apps-discuss] #3: json-pointer escape characters 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: Fri, 29 Jun 2012 15:01:57 -0000 ---1036955950-975504908-1340982111=:16871 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Edward's later message, and specifically about what he's calli= ng backtracking.=A0 Unescaping SHOULD be a single pass through the sting, a= nd specifically a an escape character rendered into the result string shoul= d never then be evaluated in a new escape sequence.=A0 The example I would = choose here is HTML, "The & character may be represented in HTML as &am= p;amp;.".=A0 If you follow the implicit logic of your question you would en= d up with "The & character may be represented in HTML as &.", which is wron= g.=A0 =0A=0A=0A-bill=0A=0A=0A=0A=0A>________________________________=0A> Fr= om: "Manger, James H" =0A>To: Paul C. Brya= n ; Martin Thomson =0A>Cc: Mark= Nottingham ; IETF Apps Discuss ; Joe= Hildebrand =0A>Sent: Thursday, June 28, 2012 5:19 PM= =0A>Subject: Re: [apps-discuss] #3: json-pointer escape characters=0A> =0A>= >> As a quoting character, ~ is a good choice.=A0 I might offer that 0 and= =0A>>> 1 are strange choices for the next character, but I wont offer an=0A= >>> alternative except to note that double-escape is the more commonly=0A>>= > used method for escaping the escape character.=0A>=0A>> True, ~~ would ju= st as good to escape ~ instead of ~0...=0A>=0A>No.=0A>=0A>Using "~~" to esc= ape "~" means a "~" in a pointer can be=0A>either an escaper or an escapee = -- and you have to count=0A>a potentially indefinite number of preceding "~= "'s to=0A>determine the answer. That just makes parsing and matching=0A>wit= h a regex harder.=0A>=0A>The names in the following 2 pointers end in "1" o= r "/".=0A>Which is which?=0A>=0A>/~~~~~~~~~~~~~~~~~~~~1=0A>/~~~~~~~~~~~~~~~= ~~~~1=0A>=0A>It is much more obvious if we use "~0" as the escape for "~".= =0A>=0A>/~0~0~0~0~0~0~0~0~0~01=0A>/~0~0~0~0~0~0~0~0~0~1=0A>=0A>--=0A>James = Manger=0A>=0A>_______________________________________________=0A>apps-discu= ss mailing list=0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/li= stinfo/apps-discuss=0A>=0A>=0A> ---1036955950-975504908-1340982111=:16871 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with Edward's later message, and specifically about what he's cal= ling backtracking.  Unescaping SHOULD be a single pass through the sti= ng, and specifically a an escape character rendered into the result string = should never then be evaluated in a new escape sequence.  The example = I would choose here is HTML, "The &amp; character may be represented in= HTML as &amp;amp;.".  If you follow the implicit logic of your qu= estion you would end up with "The & character may be repre= sented in HTML as &.", which is wrong. 

=
-bill

From: "Manger, James H" <James.H.M= anger@team.telstra.com>
To: Paul C. Bryan <pbryan@anode.ca>; Martin Thomson <martin.t= homson@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>; IETF Apps Discuss <apps-discus= s@ietf.org>; Joe Hildebrand <jhildebr@cisco.com>
Sent: Thursday, June 28, 2012 5:19 PM<= br> Subject: Re: [apps-dis= cuss] #3: json-pointer escape characters

=0A>>= As a quoting character, ~ is a good choice.  I might offer that 0 and=
>> 1 are strange choices for the next character, but I wont offer= an
>> alternative except to note that double-escape is the more c= ommonly
>> used method for escaping the escape character.

&= gt; True, ~~ would just as good to escape ~ instead of ~0...

No.
=
Using "~~" to escape "~" means a "~" in a pointer can be
either an e= scaper or an escapee -- and you have to count
a potentially indefinite n= umber of preceding "~"'s to
determine the answer. That just makes parsin= g and matching
with a regex harder.

The names in the following 2 = pointers end in "1" or "/".
Which is which?

/~~~~~~~~~~~~~~~~~~~= ~1
/~~~~~~~~~~~~~~~~~~~1

It is much more obvious if we use "~0" = as the escape for "~".

/~0~0~0~0~0~0~0~0~0~01
/~0~0~0~0~0~0~0~0= ~0~1

--
James Manger

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


---1036955950-975504908-1340982111=:16871-- From pbryan@anode.ca Fri Jun 29 08:44:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24ECA21F87A0 for ; Fri, 29 Jun 2012 08:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OpSxBAC-1a1 for ; Fri, 29 Jun 2012 08:44:37 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6C30121F879F for ; Fri, 29 Jun 2012 08:44:37 -0700 (PDT) Received: from [10.126.22.210] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 82EA86158; Fri, 29 Jun 2012 15:44:35 +0000 (UTC) From: "Paul C. Bryan" To: "Manger, James H" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F73F4253@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> <1340897879.2393.9.camel@pbryan-wsl.internal.salesforce.com> <1340922969.2393.13.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114F730FACE@WSMSG3153V.srv.dir.telstra.com> <4FECFD26.7090207@cantab.net> <255B9BB34FB7D647A506DC292726F6E114F73F4253@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="=-Su8CUpfEZuwrp/fQo0kC" Date: Fri, 29 Jun 2012 08:44:30 -0700 Message-ID: <1340984670.31848.0.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] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 15:44:38 -0000 --=-Su8CUpfEZuwrp/fQo0kC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I wouldn't say wrong, but I would say inefficient. Paul On Fri, 2012-06-29 at 11:21 +1000, Manger, James H wrote: > Edward, > > > Of course, a regex is in any case the Wrong way to unescape a string, > > but it's not our job to tell implementers what to do. > > Why is using a regular expression the Wrong way to unescape a string? > Is it because the simplest implementation uses a separate pass over the whole string for each escape sequence, which is inefficient? > > Suggesting a Right way to implementers is part of the job of a standard. > > -- > James Manger > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-Su8CUpfEZuwrp/fQo0kC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit I wouldn't say wrong, but I would say inefficient.

Paul

On Fri, 2012-06-29 at 11:21 +1000, Manger, James H wrote: 
Edward,

> Of course, a regex is in any case the Wrong way to unescape a string,
> but it's not our job to tell implementers what to do.

Why is using a regular expression the Wrong way to unescape a string?
Is it because the simplest implementation uses a separate pass over the whole string for each escape sequence, which is inefficient?

Suggesting a Right way to implementers is part of the job of a standard.

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

--=-Su8CUpfEZuwrp/fQo0kC-- From pbryan@anode.ca Fri Jun 29 08:46: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 A0FAA21F87B7 for ; Fri, 29 Jun 2012 08:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLxZIG8A-oL1 for ; Fri, 29 Jun 2012 08:46:17 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 78D4621F87A7 for ; Fri, 29 Jun 2012 08:46:17 -0700 (PDT) Received: from [10.126.22.210] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 90B6D6483; Fri, 29 Jun 2012 15:46:16 +0000 (UTC) From: "Paul C. Bryan" To: "Manger, James H" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F730FACE@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F730F2BA@WSMSG3153V.srv.dir.telstra.com> <1340897879.2393.9.camel@pbryan-wsl.internal.salesforce.com> <1340922969.2393.13.camel@pbryan-wsl.internal.salesforce.com> <255B9BB34FB7D647A506DC292726F6E114F730FACE@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="=-OC/HbV/XwA5TU5X68ZZv" Date: Fri, 29 Jun 2012 08:46:15 -0700 Message-ID: <1340984775.31848.2.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Mark Nottingham , IETF Apps Discuss , Joe Hildebrand Subject: Re: [apps-discuss] #3: json-pointer escape characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 15:46:18 -0000 --=-OC/HbV/XwA5TU5X68ZZv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I'll concede that ~0 is easier for humans and regular expression parsers to process than ~~, so I'll retract any suggestion that it should be so. On Fri, 2012-06-29 at 10:19 +1000, Manger, James H wrote: > >> As a quoting character, ~ is a good choice. I might offer that 0 and > >> 1 are strange choices for the next character, but I wont offer an > >> alternative except to note that double-escape is the more commonly > >> used method for escaping the escape character. > > > True, ~~ would just as good to escape ~ instead of ~0... > > No. > > Using "~~" to escape "~" means a "~" in a pointer can be > either an escaper or an escapee -- and you have to count > a potentially indefinite number of preceding "~"'s to > determine the answer. That just makes parsing and matching > with a regex harder. > > The names in the following 2 pointers end in "1" or "/". > Which is which? > > /~~~~~~~~~~~~~~~~~~~~1 > /~~~~~~~~~~~~~~~~~~~1 > > It is much more obvious if we use "~0" as the escape for "~". > > /~0~0~0~0~0~0~0~0~0~01 > /~0~0~0~0~0~0~0~0~0~1 > > -- > James Manger > --=-OC/HbV/XwA5TU5X68ZZv Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit I'll concede that ~0 is easier for humans and regular expression parsers to process than ~~, so I'll retract any suggestion that it should be so.

On Fri, 2012-06-29 at 10:19 +1000, Manger, James H wrote: 
>> As a quoting character, ~ is a good choice.  I might offer that 0 and
>> 1 are strange choices for the next character, but I wont offer an
>> alternative except to note that double-escape is the more commonly
>> used method for escaping the escape character.

> True, ~~ would just as good to escape ~ instead of ~0...

No.

Using "~~" to escape "~" means a "~" in a pointer can be
either an escaper or an escapee -- and you have to count
a potentially indefinite number of preceding "~"'s to
determine the answer. That just makes parsing and matching
with a regex harder.

The names in the following 2 pointers end in "1" or "/".
Which is which?

 /~~~~~~~~~~~~~~~~~~~~1
 /~~~~~~~~~~~~~~~~~~~1

It is much more obvious if we use "~0" as the escape for "~".

 /~0~0~0~0~0~0~0~0~0~01
 /~0~0~0~0~0~0~0~0~0~1

--
James Manger

--=-OC/HbV/XwA5TU5X68ZZv-- From alexey.melnikov@isode.com Fri Jun 29 11:29: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 0350121F8812 for ; Fri, 29 Jun 2012 11:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.386, 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 NLjIJfjikkBh for ; Fri, 29 Jun 2012 11:29:35 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 254DE21F87AE for ; Fri, 29 Jun 2012 11:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1340994559; d=isode.com; s=selector; i=@isode.com; bh=JIMT2PJfoTYp7AUrrdLwVzLl7ZXhyfSEIV+qfj1WF3Y=; 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=BZMVbADWFxLY7TYTZI2BaH9ZiOcM577cAfCIjvEnrpn2C7ligmKUFN/wNRUhTAbrIKt4vr Cupw5oL3i+QSXRkVNXSv1LAswIwqMOs0fsstwDxrqBf0H6EjR6N9RYTcE05bxelpZ9bM0E +yhwX8CID8t9c4OpfdDDwGKbU7XhJ9o=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 29 Jun 2012 19:29:19 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FEDF40F.8020903@isode.com> Date: Fri, 29 Jun 2012 19:29:35 +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" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Status of "Spam reporting using IMAP: SREP" draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 18:29:36 -0000 Dear WG participants, Some time ago WG chairs have issues acceptance call for: http://tools.ietf.org/html/draft-ordogh-spam-reporting-using-imap-02 I think WG Chairs failed to emphasize that RIM filed an IPR declaration on the document: https://datatracker.ietf.org/ipr/1609/ Chairs would like to confirm that the WG is still interested in working on the document in presence of this IPR declaration. Thank you, Alexey, as an APPSAWG co-chair From johnl@iecc.com Fri Jun 29 21:22: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 8B5D121F8621 for ; Fri, 29 Jun 2012 21:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.048 X-Spam-Level: X-Spam-Status: No, score=-111.048 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 YPDm9TL24nkk for ; Fri, 29 Jun 2012 21:22:28 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A067D21F8620 for ; Fri, 29 Jun 2012 21:22:28 -0700 (PDT) Received: (qmail 68429 invoked from network); 30 Jun 2012 04:22:27 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 30 Jun 2012 04:22:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fee7f02.xn--btvx9d.k1206; i=johnl@user.iecc.com; bh=I76Wn8/lxwEBQp3PKmFK59ZExkxAZbYaSA5tp9JM2Qs=; b=tSC1wHb07yCnhoK45Dy27mYzr0ewymhSA8IfpU7Fnh5GMg0vVSrgM4zlCAejkRP0OekhsxwoIpfJ+xt0y9WjGNwL6bSpSXjo+i4m/t22kdZZCrVNVbBVO6cX0rNdKc7+KpUgOFrbdnFqyrkvzOR+j/yOrk3noJiWiqSLaef80Q8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fee7f02.xn--btvx9d.k1206; olt=johnl@user.iecc.com; bh=I76Wn8/lxwEBQp3PKmFK59ZExkxAZbYaSA5tp9JM2Qs=; b=RWnZi3ZN5v7ft4kHtxzJ8X2TKqlT/YA6Afx5MvVn5XuPE8vQer8EHC1REie9WAZ0s8iz5IODKF16mx+jmrkk5aKfGlbCk6ouZA06yBN0HeuYG89aDoqsPFHeYxE9jCCrc7izkfaDsSvtUHgbKDHeDC9+5916L3Y2rC6fvALd+Jk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 30 Jun 2012 04:22:04 -0000 Message-ID: <20120630042204.53311.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <4FEDF40F.8020903@isode.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Status of "Spam reporting using IMAP: SREP" draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 04:22:29 -0000 >Chairs would like to confirm that the WG is still interested in working >on the document in presence of this IPR declaration. Hmmn. The patent application is unpublished so we don't know what it says, nor whether a patent will ever be issued. RIM offers a RAND license, not necessarily a free one. The current draft is (to my taste) overly complicated; if we end up publishing something, it will probably cut out a fair amount of what's in the draft, so it's quite possible that whatever the patent application covers wouldn't end up in an RFC. The fundamental idea, send a notification to a host telling it that a message in its store is or isn't spam, would seem to me to be unpatentable due to a mountain of prior art. Overall summary: who the heck knows. Anyone else? R's, John From john-ietf@jck.com Sat Jun 30 03:52: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 927E921F85F2 for ; Sat, 30 Jun 2012 03:52:35 -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 EIAJZwwBN9xs for ; Sat, 30 Jun 2012 03:52:35 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id DCDD821F847F for ; Sat, 30 Jun 2012 03:52:34 -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 1SkvBJ-000BzT-T0; Sat, 30 Jun 2012 06:45:37 -0400 Date: Sat, 30 Jun 2012 06:52:26 -0400 From: John C Klensin To: Alexey Melnikov , apps-discuss@ietf.org Message-ID: <5262EBFB8764EFA9D178ED9F@JcK-HP8200.jck.com> In-Reply-To: <4FEDF40F.8020903@isode.com> References: <4FEDF40F.8020903@isode.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] Status of "Spam reporting using IMAP: SREP" draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 10:52:35 -0000 --On Friday, June 29, 2012 19:29 +0100 Alexey Melnikov wrote: > Dear WG participants, > Some time ago WG chairs have issues acceptance call for: > > http://tools.ietf.org/html/draft-ordogh-spam-reporting-using-i > map-02 > > I think WG Chairs failed to emphasize that RIM filed an IPR > declaration on the document: > > https://datatracker.ietf.org/ipr/1609/ > > Chairs would like to confirm that the WG is still interested > in working on the document in presence of this IPR declaration. IANAL, but... (1) I have no idea what "subject to rights of reciprocity and suspension or termination for assertion against a third party" means in practice. In particular, not being a lawyer, I have no idea if RIM is asserting that they would revoke the license to practice the claimed invention if someone asserted any IPR claim against RIM or only one associated with this particular technology. I am not asking for an interpretation here, or a discussion of that language. But I am anxious about our taking on an individual draft that is claimed to be encumbered especially since... (2) This says it is an unpublished application, which means that participants in the IETF have way to examine exactly what is being claimed and hence no basis to evaluate those claims. Unless someone not associated with RIM can successfully argue that it is urgent to process this work in the IETF, I would prefer to defer it until either the licensing language is crystal clear (even to non-specialists), the final claims can be examined, or, preferably, both. Just IMO, of course. john From john@jlc.net Sat Jun 30 06:06: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 8BBB721F862A for ; Sat, 30 Jun 2012 06:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 Yey2a6pI1rC6 for ; Sat, 30 Jun 2012 06:06:54 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 00EE821F861E for ; Sat, 30 Jun 2012 06:06:53 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5174433C21; Sat, 30 Jun 2012 09:06:54 -0400 (EDT) Date: Sat, 30 Jun 2012 09:06:54 -0400 From: John Leslie To: Alexey Melnikov Message-ID: <20120630130654.GA70253@verdi> References: <4FEDF40F.8020903@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FEDF40F.8020903@isode.com> User-Agent: Mutt/1.4.1i Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Status of "Spam reporting using IMAP: SREP" draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 13:06:54 -0000 Alexey Melnikov wrote: > > Some time ago WG chairs have issues acceptance call for: > http://tools.ietf.org/html/draft-ordogh-spam-reporting-using-imap-02 > > I think WG Chairs failed to emphasize that RIM filed an IPR declaration > on the document: > > https://datatracker.ietf.org/ipr/1609/ > > Chairs would like to confirm that the WG is still interested in working > on the document in presence of this IPR declaration. I find myself put off by the "Right to Sell" section of the disclosure, where they ask each buyer of a "product or service implementing any such patent claims" to agree to terms including "supension or termination" Myself, I wouldn't put much effort into this with that hanging over my head. :^( -- John Leslie From johnl@iecc.com Sat Jun 30 08:27: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 38E8F21F848B for ; Sat, 30 Jun 2012 08:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.078 X-Spam-Level: X-Spam-Status: No, score=-111.078 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 ZFjOSQ9vfQzJ for ; Sat, 30 Jun 2012 08:27:46 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E151621F8480 for ; Sat, 30 Jun 2012 08:27:45 -0700 (PDT) Received: (qmail 62370 invoked from network); 30 Jun 2012 15:27:46 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 30 Jun 2012 15:27:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fef1af2.xn--yuvv84g.k1206; i=johnl@user.iecc.com; bh=sU0wCZ/s8yiZkjaQXqCsuAo5iqFj/vQtPUIWFU/Vwps=; b=okWjAfF/DQFl1YHsJVpQ/xTrl8OT7ZvXgVOStocag6npy9e/O5/toWErxQFsPFLXRyG/Klh0RIKa5YAg9cxwuDsfpuBc+d0qF/mAL8TAZUm8ioAyLNT9GS3vNaKFNdd/xhMf3h0lOuSx0h0y9gtTb6KWEy09la1B0EFk8Alz9k8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fef1af2.xn--yuvv84g.k1206; olt=johnl@user.iecc.com; bh=sU0wCZ/s8yiZkjaQXqCsuAo5iqFj/vQtPUIWFU/Vwps=; b=3PS9tVlLjGbcsBDClUrsjUMsNYztf4tZTWawWSMslUYAcHwRnhfo8uXEELSkfETjxMF23OkW3h/Zh3yntNbb50QJNENU0bd1kM3Qvb/gBMZWOhT+dFeqcx/HilT0PBMF00SDm+Qu2gfAACXrVW+mhopBTe5GeeyfjCyr/IIQ2E0= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 30 Jun 2012 15:27:24 -0000 Message-ID: <20120630152724.17119.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <5262EBFB8764EFA9D178ED9F@JcK-HP8200.jck.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Status of "Spam reporting using IMAP: SREP" draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 15:27:47 -0000 >(1) I have no idea what "subject to rights of reciprocity and >suspension or termination for assertion against a third party" >means in practice. In particular, not being a lawyer, I have no >idea if RIM is asserting that they would revoke the license to >practice the claimed invention if someone asserted any IPR claim >against RIM or only one associated with this particular >technology. More likely the latter, but ... >Unless someone not associated with RIM can successfully argue >that it is urgent to process this work in the IETF, I would >prefer to defer it until either the licensing language is >crystal clear (even to non-specialists), the final claims can be >examined, or, preferably, both. The application will be published in December. Perhaps we can revisit it then. If anyone from RIM thinks it's more urgent, they can of course try and persuade the company to publish it now, but given what's going on at RIM, I wouldn't hold my breath. Worst case scenario: a patent is granted, RIM continues its downward spiral and the patent portfolio is sold to a someone like Intellectual Ventures who say "IPR disclosure? What's that? We never made one." R's, John From john-ietf@jck.com Sat Jun 30 13:11: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 7EA2721F85DB for ; Sat, 30 Jun 2012 13:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 DhPaX++k0mIw for ; Sat, 30 Jun 2012 13:11:41 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id C964521F846D for ; Sat, 30 Jun 2012 13:11:41 -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 1Sl3uR-000CwD-3R; Sat, 30 Jun 2012 16:04:47 -0400 Date: Sat, 30 Jun 2012 16:11:36 -0400 From: John C Klensin To: John Levine , apps-discuss@ietf.org Message-ID: In-Reply-To: <20120630152724.17119.qmail@joyce.lan> References: <20120630152724.17119.qmail@joyce.lan> 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] Status of "Spam reporting using IMAP: SREP" draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 20:11:42 -0000 --On Saturday, June 30, 2012 15:27 +0000 John Levine wrote: >> (1) I have no idea what "subject to rights of reciprocity and >> suspension or termination for assertion against a third party" >> means in practice. In particular, not being a lawyer, I have >> no idea if RIM is asserting that they would revoke the >> license to practice the claimed invention if someone asserted >> any IPR claim against RIM or only one associated with this >> particular technology. > > More likely the latter, but ... But, as you presumably know, some companies have written "reciprocity" clauses that basically take the position that any challenge to anything in their patent portfolio revokes all rights and licenses. I won't make likelihood estimates, but we need to understand that the language appears to be ambiguous on that matter. >> Unless someone not associated with RIM can successfully argue >> that it is urgent to process this work in the IETF, I would >> prefer to defer it until either the licensing language is >> crystal clear (even to non-specialists), the final claims can >> be examined, or, preferably, both. > > The application will be published in December. Perhaps we can > revisit it then. If anyone from RIM thinks it's more urgent, > they can of course try and persuade the company to publish it > now, but given what's going on at RIM, I wouldn't hold my > breath. At the risk of repeating myself, I would be unhappy about the IETF's moving ahead with this without either clarity about the proposed licensing terms, clarity about the claims, or both. Examining the question after the application is published (whether that is December or, under some special arrangement, sooner) would seem reasonable as long as it is understood that such a examination should not be taken as an automatic "yes" then. > Worst case scenario: a patent is granted, RIM continues its > downward spiral and the patent portfolio is sold to a someone > like Intellectual Ventures who say "IPR disclosure? What's > that? We never made one." While I don't think we need to engage in that sort of speculation to reach a conclusion about what the WG should do today, I cannot disagree with your scenario analysis. john From johnl@taugh.com Sat Jun 30 13:18: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 5712721F85D6 for ; Sat, 30 Jun 2012 13:18:33 -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 h7OKrDibQKeP for ; Sat, 30 Jun 2012 13:18:32 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 88C5321F8554 for ; Sat, 30 Jun 2012 13:18:32 -0700 (PDT) Received: (qmail 49215 invoked from network); 30 Jun 2012 20:18:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=c03e.4fef5f19.k1206; bh=VzntxGsmAzzO22f8VNdGViIq+pgudS/r99XznRRD+Hg=; b=ePuhIwKqPrSFl/j7QyrVNJRnxFD3Jyhf0SRkWhM14HdsGmSMvstDEKpI49DwbmiEI8g8J7lY5oUyy9OLrzFcCwq5zXk5e6EzAbb6de55h0vBE27RGaOM0A3teQcvzTk8CB8C98L3kIb48QI46gL+vHs3fsvl3U4U8iC3QMWhTkA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=c03e.4fef5f19.k1206; bh=VzntxGsmAzzO22f8VNdGViIq+pgudS/r99XznRRD+Hg=; b=zSUmBhVJon+YNtBM9Cx/bn/BNS1PjNdKwax2Kj+XcyJku9IbQkL64Ld4uqZPsVwPtb0bgwfEyG6pKY7oNCjT/KTlxTPi2Tc6B+RAifFt5E9MMDGyxTp4K0HgggAJz4dtgtL0WP96vORPtvsBa+B7/PoT3qYDcb1AxGRA7s5jy1M= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 30 Jun 2012 20:18:11 -0000 Date: 30 Jun 2012 16:18:32 -0400 Message-ID: From: "John R Levine" To: "John C Klensin" In-Reply-To: References: <20120630152724.17119.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: John Levine , apps-discuss@ietf.org Subject: Re: [apps-discuss] Status of "Spam reporting using IMAP: SREP" draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 20:18:33 -0000 >> More likely the latter, but ... > > But, as you presumably know, some companies have written > "reciprocity" clauses that basically take the position that any > challenge to anything in their patent portfolio revokes all > rights and licenses. Quite true. I would want to see the license they're offering before coming to any conclusions, but that's pointless until we know what the patent application covers. > At the risk of repeating myself, I would be unhappy about the > IETF's moving ahead with this without either clarity about the > proposed licensing terms, clarity about the claims, or both. > Examining the question after the application is published > (whether that is December or, under some special arrangement, > sooner) would seem reasonable as long as it is understood that > such a examination should not be taken as an automatic "yes" > then. Right. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From stpeter@stpeter.im Sat Jun 30 20:09: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 D473121F855F for ; Sat, 30 Jun 2012 20:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.01 X-Spam-Level: X-Spam-Status: No, score=-102.01 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, SARE_TOWRITE=1.05, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzNS5DPS4G3r for ; Sat, 30 Jun 2012 20:09:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 24B2D21F84B3 for ; Sat, 30 Jun 2012 20:09:04 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.179.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A36074005A; Sat, 30 Jun 2012 21:27:12 -0600 (MDT) Message-ID: <4FEFBF51.5000905@stpeter.im> Date: Sat, 30 Jun 2012 21:09:05 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Graham Klyne References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> In-Reply-To: <4FEC8BF0.6070605@stpeter.im> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 03:09:05 -0000 On 6/28/12 10:53 AM, Peter Saint-Andre wrote: > On 6/28/12 5:09 AM, Graham Klyne wrote: >> On 28/06/2012 08:28, Melvin Carvalho wrote: >>> Should acct: be rejected, we can simply use mailto: as per SWD. >>> Similarly >>> you could simply use ?acct=user@host as has been suggested. >> >> Since my comments with reviewer hat on have been cited, I feel I should >> summarize my personal feelings about the specification of the acct: scheme. >> >> *Reviewer hat OFF* >> >> Roughly, I think the acct: scheme does provide a useful, possibly minor, >> purpose that is not served by other URI schemes, and as such it has >> reasonable claim to meet the bar for registering a new scheme. But I >> think the description of the acct: scheme in the WebFinger document does >> a poor job of explaining this; i.e. I think there is a document quality >> issue here around the acct: scheme registration/specification. >> >> I've had private exchanges with one of the document editors, but I don't >> think my suggestions have been reflected in the current draft. In >> summary, what I think is not as clear as it should be in the scheme >> registration includes: >> * what does an acct URI identify >> * how are acct URIs allocated; what's the assignment delegation structure? >> * how should an acct: URI be dereferenced? (e.g. if one were used as a >> link in a web page, how should it be handled?). >> >> I suspect that most of this information can be inferred if one has a >> detailed knowledge of WebFinger protocol, but for an average Joe web >> developer I don't think that's really helpful. >> >> I don't think this is a sufficiently important issue for me to engage >> more actively with the discussion. > > Graham, I think you're right about the fact that these matters are > underspecified. I hereby offer to propose some text, and will do that in > the next few days. I went beyond proposing text and decided to write a standalone I-D: http://datatracker.ietf.org/doc/draft-saintandre-acct-uri/ Graham, I think that text answers the questions you posed, hopefully in an accurate way. Feedback is welcome. Peter -- Peter Saint-Andre https://stpeter.im/ From Michael.Jones@microsoft.com Sat Jun 30 20: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 F389421F84CD for ; Sat, 30 Jun 2012 20:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.708 X-Spam-Level: X-Spam-Status: No, score=-4.708 tagged_above=-999 required=5 tests=[AWL=0.841, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_TOWRITE=1.05] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ms+k5Xg7omNH for ; Sat, 30 Jun 2012 20:35:29 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id EB7E921F84A0 for ; Sat, 30 Jun 2012 20:35:28 -0700 (PDT) Received: from mail252-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Sun, 1 Jul 2012 03:33:37 +0000 Received: from mail252-tx2 (localhost [127.0.0.1]) by mail252-tx2-R.bigfish.com (Postfix) with ESMTP id DF7391B4072D; Sun, 1 Jul 2012 03:33:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(zzbb2dI98dI9371I542M1432I1418Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail252-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail252-tx2 (localhost.localdomain [127.0.0.1]) by mail252-tx2 (MessageSwitch) id 1341113614944162_31485; Sun, 1 Jul 2012 03:33:34 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.238]) by mail252-tx2.bigfish.com (Postfix) with ESMTP id D9F0F800045; Sun, 1 Jul 2012 03:33:34 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 1 Jul 2012 03:33:34 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Sun, 1 Jul 2012 03:35:26 +0000 From: Mike Jones To: Peter Saint-Andre , Graham Klyne Thread-Topic: [apps-discuss] The acct: scheme question Thread-Index: Ac0367W7uVNJxgK+Tf6qpowkmE64wgbqGMQAAAKM2jAAA8N6gAAAR9EQAD2/6AAAFom7AAAHs0aAAAwDwAAAehjTgAAA6cLw Date: Sun, 1 Jul 2012 03:35:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366570258@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <9452079D1A51524AA5749AD23E00392812B6B6@exch-mbx901.corp.cloudmark.com> <4E1F6AAD24975D4BA5B168042967394366568E4F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1340723227.60315.YahooMailNeo@web31801.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366568FF8@TK5EX14MBXC283.redmond.corp.microsoft.com> <043201cd54a5$79f2e170$6dd8a450$@packetizer.com> <4FEC3B4F.80607@ninebynine.org> <4FEC8BF0.6070605@stpeter.im> <4FEFBF51.5000905@stpeter.im> In-Reply-To: <4FEFBF51.5000905@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "apps-discuss@ietf.org" , "Murray S. Kucherawy" Subject: Re: [apps-discuss] The acct: scheme question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 03:35:30 -0000 Bravo!!! -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Peter Saint-Andre Sent: Saturday, June 30, 2012 8:09 PM To: Graham Klyne Cc: apps-discuss@ietf.org; Murray S. Kucherawy Subject: Re: [apps-discuss] The acct: scheme question On 6/28/12 10:53 AM, Peter Saint-Andre wrote: > On 6/28/12 5:09 AM, Graham Klyne wrote: >> On 28/06/2012 08:28, Melvin Carvalho wrote: >>> Should acct: be rejected, we can simply use mailto: as per SWD.=20 >>> Similarly >>> you could simply use ?acct=3Duser@host as has been suggested. >> >> Since my comments with reviewer hat on have been cited, I feel I=20 >> should summarize my personal feelings about the specification of the acc= t: scheme. >> >> *Reviewer hat OFF* >> >> Roughly, I think the acct: scheme does provide a useful, possibly=20 >> minor, purpose that is not served by other URI schemes, and as such=20 >> it has reasonable claim to meet the bar for registering a new scheme. =20 >> But I think the description of the acct: scheme in the WebFinger=20 >> document does a poor job of explaining this; i.e. I think there is a=20 >> document quality issue here around the acct: scheme registration/specifi= cation. >> >> I've had private exchanges with one of the document editors, but I=20 >> don't think my suggestions have been reflected in the current draft. =20 >> In summary, what I think is not as clear as it should be in the=20 >> scheme registration includes: >> * what does an acct URI identify >> * how are acct URIs allocated; what's the assignment delegation structur= e? >> * how should an acct: URI be dereferenced? (e.g. if one were used as=20 >> a link in a web page, how should it be handled?). >> >> I suspect that most of this information can be inferred if one has a=20 >> detailed knowledge of WebFinger protocol, but for an average Joe web=20 >> developer I don't think that's really helpful. >> >> I don't think this is a sufficiently important issue for me to engage=20 >> more actively with the discussion. >=20 > Graham, I think you're right about the fact that these matters are=20 > underspecified. I hereby offer to propose some text, and will do that=20 > in the next few days. I went beyond proposing text and decided to write a standalone I-D: http://datatracker.ietf.org/doc/draft-saintandre-acct-uri/ Graham, I think that text answers the questions you posed, hopefully in an = accurate way. Feedback is welcome. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss