From nobody Mon Mar 2 09:42:47 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8105D1A885F for ; Mon, 2 Mar 2015 09:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9rH_UDnEfIY for ; Mon, 2 Mar 2015 09:42:42 -0800 (PST) Received: from nm30-vm1.bullet.mail.ne1.yahoo.com (nm30-vm1.bullet.mail.ne1.yahoo.com [98.138.90.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214E91A87EF for ; Mon, 2 Mar 2015 09:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1425318161; bh=ObZXe4u5G4kbuC9n//213LePhX+88DYj7Fj1TiMew6s=; h=In-Reply-To:References:From:Date:Subject:To:From:Subject; b=bJIQBjN5oxpF3iuoO9IPlvW92nIHANlxm5/5FxzVqEr//4MJaXR1xaXlX2ScdMkrBECWKnULlxzLxB0DtjcvPDPWHwrrQ3KXbL8LPl1IDfDPCZHg1RjduD9twspcS5T564GvUDEZWmr3m1P0w4ETzUf0GQrq8jFgEXK3SdROzhP1j319+moPe3FcgiwDT32RzLHkEIWcIHJegeuJh/EFXmtPC9o7bhKCAWcE9+oiXPPe2SsFyJcdbiqJCBQL52g0EAso6svwORyhOmDSeX+3IwcejMmhgzRq1kbyAxC1mBw9EMJ30gU2xU3BLcphfrDmKviz2JKJJ4hiTlNm8jQoyw== Received: from [98.138.100.114] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 02 Mar 2015 17:42:41 -0000 Received: from [98.138.84.42] by tm105.bullet.mail.ne1.yahoo.com with NNFMP; 02 Mar 2015 17:42:41 -0000 Received: from [127.0.0.1] by smtp110.mail.ne1.yahoo.com with NNFMP; 02 Mar 2015 17:42:41 -0000 X-Yahoo-Newman-Id: 268715.70681.bm@smtp110.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ICtuACUVM1m8Lw7JZCYdYZBvDn..iVtX.0v2xVYlIf8Yerx hW7lfvpenYOxQmTj5.hnUyvgGlaunbp5grKIR90S1DUtqQdEJNyVFuVqn75F Z1M1wonTe4bCWEBMFo5wUHIV7zbLfgymwvLaY5WR9fYvDzNQbzqeMFEPmk3Z RZINI8Q7aP1B9fQExQ_N90CN7XNAuRMJAdiLTRkYEpjKdmLl4F.kORwlA5AL r8TDNwjvZphAXKTWgXISZHtlf0LR6HBN.vArs5eIftAkTK_EMbb7tlTYrXSo Jd2C8MjiHikYjgO8IYH0IlBsFzsAp4sIiGF6R6jcBsD_5CwcYd98Ex7l7mmE hDzP3enb79ilDAsbGsNjt9Qx9WK_0JkvsTTEej8Fd50LXpKr5.tx_lUGT8Bv iSRkuq2gqO11g9N0JnTq.HBpWqRzRstqWk4fOAZezN.sGm51HiXV35V4EAVU EqSIlD4jjDJqJfKu59lGXPq6ox.VWsjzn7LGW9RCS2lfZQREC0aS3t80A299 iUHDhxKBcT3ftRbfNDXrpK.7s2rLeFvDITrrG_bLNc05SzQvK4CDHwIJsb8J AVOJsAvt2rJUHa5EwP3TGXXaw9gCmQlW8MUeqaqdolvnp6EQuf3a7Nw1.kbr Yc7jA4FVRGYuYgYpEpVMatqgXeNXOyfO2tFbC055Kfm2DwzweFJwB.ofoYEw FbRmGNX6pHLXzNC2KZZ._u.nUvsRaEhP9wJilM6rloMiLIYITFLfIOr8t2fG 02RvsbIlHS..BcAuh5cMFeJupE6M2wY_KfkbwgMmIjeqRf0iAgtRVtXVgKWX LdLiCCJj5tYSd53ckzax7n7sCJ_4IUfzVKk_X9kZ7kyHm0vP8HyEl_wS5DIH Xju8Ifs77RRtFkQCMAktkjR1z6w-- X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- Received: by lbiw7 with SMTP id w7so31686526lbi.9 for ; Mon, 02 Mar 2015 09:42:39 -0800 (PST) X-Gm-Message-State: ALoCoQnzBYsswZJWsXYYx7RTRGRmQzBE7+zDrp/63VCb1LqYJFLyvr3eyc4vnV1J9XeXAimC94lF X-Received: by 10.112.198.1 with SMTP id iy1mr25659871lbc.13.1425318159119; Mon, 02 Mar 2015 09:42:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.136.212 with HTTP; Mon, 2 Mar 2015 09:42:17 -0800 (PST) In-Reply-To: <20150302172347.19316.85751.idtracker@ietfa.amsl.com> References: <20150302172347.19316.85751.idtracker@ietfa.amsl.com> From: mike amundsen Date: Mon, 2 Mar 2015 12:42:17 -0500 Message-ID: To: media-types@ietf.org Content-Type: multipart/alternative; boundary=001a11c341ac91136f051051bec4 Archived-At: Subject: [media-types] Fwd: New Version Notification for draft-amundsen-richardson-foster-alps-01.txt X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 17:42:45 -0000 --001a11c341ac91136f051051bec4 Content-Type: text/plain; charset=UTF-8 The updated I-D for ALPS was just posted it to the IETF tracker (see details below). I've also updated the web site[0] . We're looking for any/all comments and feedback. Feel free to discuss on the ALPS list[1] or here, and to open/update issues in github[2] for the next round of changes. -- cheers. [0] http://alps.io/spec/index.html [1] https://groups.google.com/forum/?fromgroups=#!forum/alps-io [2] https://github.com/alps-io/spec/issues mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund ---------- Forwarded message ---------- From: Date: Mon, Mar 2, 2015 at 12:23 PM Subject: New Version Notification for draft-amundsen-richardson-foster-alps-01.txt To: Mike Amundsen , Leonard Richardson < leonardr@segfault.org>, "Mark W. Foster" A new version of I-D, draft-amundsen-richardson-foster-alps-01.txt has been successfully submitted by Mike Amundsen and posted to the IETF repository. Name: draft-amundsen-richardson-foster-alps Revision: 01 Title: Application-Level Profile Semantics (ALPS) Document date: 2015-02-28 Group: Individual Submission Pages: 27 URL: http://www.ietf.org/internet-drafts/draft-amundsen-richardson-foster-alps-01.txt Status: https://datatracker.ietf.org/doc/draft-amundsen-richardson-foster-alps/ Htmlized: http://tools.ietf.org/html/draft-amundsen-richardson-foster-alps-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-amundsen-richardson-foster-alps-01 Abstract: This document describes ALPS, a data format for defining simple descriptions of application-level semantics, similar in complexity to HTML microformats. An ALPS document can be used as a profile to explain the application semantics of a document with an application- agnostic media type (such as HTML, HAL, Collection+JSON, Siren, etc.). This increases the reusability of profile documents across media types. Editorial Note (To be removed by RFC Editor) Distribution of this document is unlimited. Comments should be sent to the IETF Media-Types mailing list (see [1]). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a11c341ac91136f051051bec4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The updated I= -D for ALPS was just posted it to the IETF tracker (see details below).=C2= =A0I've also update= d the web site[0] .=C2=A0

We're looking fo= r any/all comments and feedback. Feel free to discuss on the ALPS list[1] o= r here, and to open/update issues in github[2] for the next round of change= s.=C2=A0
=



---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
D= ate: Mon, Mar 2, 2015 at 12:23 PM
Subject: New Version Notification for = draft-amundsen-richardson-foster-alps-01.txt
To: Mike Amundsen <mca@amundsen.com>, Leonard Richardson= <leonardr@segfault.org>= , "Mark W. Foster" <mwf@fos= rias.com>



A new version of I-D, draft-amundsen-richardson-foster-alps-01.txt
has been successfully submitted by Mike Amundsen and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-amundsen-richardson-fos= ter-alps
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application-Level Profile Semantic= s (ALPS)
Document date:=C2=A0 2015-02-28
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 27
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-amundsen-richardson-foster= -alps-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /datatracker.ietf.org/doc/draft-amundsen-richardson-foster-alps/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.iet= f.org/html/draft-amundsen-richardson-foster-alps-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-amundsen-richardson-foster-alps-= 01

Abstract:
=C2=A0 =C2=A0This document describes ALPS, a data format for defining simpl= e
=C2=A0 =C2=A0descriptions of application-level semantics, similar in comple= xity to
=C2=A0 =C2=A0HTML microformats.=C2=A0 An ALPS document can be used as a pro= file to
=C2=A0 =C2=A0explain the application semantics of a document with an applic= ation-
=C2=A0 =C2=A0agnostic media type (such as HTML, HAL, Collection+JSON, Siren= ,
=C2=A0 =C2=A0etc.).=C2=A0 This increases the reusability of profile documen= ts across
=C2=A0 =C2=A0media types.

Editorial Note (To be removed by RFC Editor)

=C2=A0 =C2=A0Distribution of this document is unlimited.=C2=A0 Comments sho= uld be sent
=C2=A0 =C2=A0to the IETF Media-Types mailing list (see [1]).




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

The IETF Secretariat


--001a11c341ac91136f051051bec4-- From nobody Tue Mar 3 03:38:28 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BD71A01E7 for ; Tue, 3 Mar 2015 03:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chhgatO6vVJl for ; Tue, 3 Mar 2015 03:38:26 -0800 (PST) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCC11A01AE for ; Tue, 3 Mar 2015 03:38:26 -0800 (PST) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YSl9c-0005ru-qd; Tue, 03 Mar 2015 11:38:24 +0000 Received: from oerc-dynamic-220.oerc.ox.ac.uk ([129.67.194.220]) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YSl9c-0009b8-K4; Tue, 03 Mar 2015 11:38:24 +0000 Message-ID: <54F59D36.9050000@ninebynine.org> Date: Tue, 03 Mar 2015 11:38:30 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: mike amundsen , media-types@ietf.org References: <20150302172347.19316.85751.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [media-types] Fwd: New Version Notification for draft-amundsen-richardson-foster-alps-01.txt X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 11:38:28 -0000 Hi, Reviewing: http://tools.ietf.org/id/draft-amundsen-richardson-foster-alps-01.html I'm just taking a quick skim here, and offer some immediate comments (I've yet to fully grasp the big picture). ... Sect 1.4 "This URL SHOULD be assumed to be dereferencable." reads oddly (making a normative statement about an assumption?). Maybe just "This URL SHOULD be dereferencable."? ... Sect 2.2.2: missing {...} around "alps" content? { "alps : "doc" : { "value" : "..." }, ... } (cf. sect 2.3.3.1) ... 2.2.7.3. Link Relation Values and 'id' or 'name' I see a problem here. It's all very well to say "If the resulting link relation type is the same as a registered relation type, the descriptor MUST not change the meaning of the IANA relation type.". But an implementer cannot know what new relation types will be implemented in future. An application that is conformant at the time of implementation may be rendered non-conformant by subsequent IANA registrations. I think this is not consistent with progressing the notion of "software engineering on the scale of decades" which I'm guessing is a motivation for this work. One possible approach might be to require any non-registered value to be a URI or URI reference, and introduce a distinguishable prefix for local ids. (e.g. use fragment syntax such as '#idvalue' or a common URN prefix such as 'urn:ietf:alps:id:idvalue'. I'm not suggesting these as specific solutions as I don't yet understand enough of the scope of what you're proposing, just as examples of alternative approaches to contemplate.) ... Section 2.2.12 I'm not understanding what you mean by the description of type="semantic". The examples given (html.span and html.input) aren't helping in this respect. My guess is that some kind of introduction to the kind of hypermedia model your basing this upon is needed. I think there's a lot of tacit knowledge permeating the spec that needs to be surfaced for those who aren't in tune with your approach. ... Section 4. I think the media type registrations should reference the fragment id interpretation (sect 2.2.7.2). ... HTH #g -- On 02/03/2015 17:42, mike amundsen wrote: > The updated I-D for ALPS was just posted it to the IETF tracker (see > details below). I've also updated the web site[0] . > > We're looking for any/all comments and feedback. Feel free to discuss on > the ALPS list[1] or here, and to open/update issues in github[2] for the > next round of changes. > > -- cheers. > > [0] http://alps.io/spec/index.html > [1] https://groups.google.com/forum/?fromgroups=#!forum/alps-io > [2] https://github.com/alps-io/spec/issues > > > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://linkedin.com/in/mamund > > > > ---------- Forwarded message ---------- > From: > Date: Mon, Mar 2, 2015 at 12:23 PM > Subject: New Version Notification for > draft-amundsen-richardson-foster-alps-01.txt > To: Mike Amundsen , Leonard Richardson < > leonardr@segfault.org>, "Mark W. Foster" > > > > A new version of I-D, draft-amundsen-richardson-foster-alps-01.txt > has been successfully submitted by Mike Amundsen and posted to the > IETF repository. > > Name: draft-amundsen-richardson-foster-alps > Revision: 01 > Title: Application-Level Profile Semantics (ALPS) > Document date: 2015-02-28 > Group: Individual Submission > Pages: 27 > URL: > http://www.ietf.org/internet-drafts/draft-amundsen-richardson-foster-alps-01.txt > Status: > https://datatracker.ietf.org/doc/draft-amundsen-richardson-foster-alps/ > Htmlized: > http://tools.ietf.org/html/draft-amundsen-richardson-foster-alps-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-amundsen-richardson-foster-alps-01 > > Abstract: > This document describes ALPS, a data format for defining simple > descriptions of application-level semantics, similar in complexity to > HTML microformats. An ALPS document can be used as a profile to > explain the application semantics of a document with an application- > agnostic media type (such as HTML, HAL, Collection+JSON, Siren, > etc.). This increases the reusability of profile documents across > media types. > > Editorial Note (To be removed by RFC Editor) > > Distribution of this document is unlimited. Comments should be sent > to the IETF Media-Types mailing list (see [1]). > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > From nobody Tue Mar 3 17:01:40 2015 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EEF1A89AB for ; Tue, 3 Mar 2015 17:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4p3q4h-Q7f4 for ; Tue, 3 Mar 2015 17:01:35 -0800 (PST) Received: from nm22-vm3.bullet.mail.ne1.yahoo.com (nm22-vm3.bullet.mail.ne1.yahoo.com [98.138.91.152]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0931A88E7 for ; Tue, 3 Mar 2015 17:01:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1425430894; bh=P6/i8RJ46s2weGaSehw67N4PTuso6hKEz6gI21+h5YY=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From:Subject; b=sHtThEyMNEGovVFWOD0koajfrng0IcTaMU6a/MGvHU6RObMgEvmrH19yiNpueoO4RobtxlL4kLx8LySUQoC8cg6E6MAQM61c6/iiXKTLVMXEhm+7AZ8EosIrOImR8ToWSzEOGb/EAfkOxG/6g3UYyQabPG3DcpKHgXSn1ffRwNuNnvEurqqQ5joaNZ09lNuEHCfPWpysAPlIr/HR490YN9FFfyeF73qChFYnsCjBLFjIVuv1loHVWN4qhuR3UanTAt1ScLFhlMVzasMEVjh9qdk17Fg2VcI+R8yGeFASKEmKgCG8xVipZxOhL3/O1jEbAiKCFG5yYcWKKuCjSjYagA== Received: from [98.138.100.102] by nm22.bullet.mail.ne1.yahoo.com with NNFMP; 04 Mar 2015 01:01:34 -0000 Received: from [98.138.84.40] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 04 Mar 2015 01:01:34 -0000 Received: from [127.0.0.1] by smtp108.mail.ne1.yahoo.com with NNFMP; 04 Mar 2015 01:01:34 -0000 X-Yahoo-Newman-Id: 769311.95322.bm@smtp108.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: KpHHpTgVM1krfu99.ViAKEM8vvcHDXkYalKkNtmANZBq5bn xlkyrGboMLTFUHmEU_QHupXOMeLprHogS9_EB.4ZhpsvJp8SiiowE_t5o0ZU aDF4Qd1Wu2RKow1gCzm7AZA9ln3gGr00CrolK0D2Zrg6J_W_eOzXXE9JKZsy r5ryYNFucddgezVymQacgDRrXBO1wVTO_JxO963b7dMgzDRwAGfcnNhuogaB oiYmrNb8qmR3zxoGyWu9i3T_aNR7qj18CsJKHrc8OvxVhOJN1lBadnU5mA63 gZGlD2ELfbvoRYxBwIRIoZfkqT__LIHr49KYs9pjsmhCPQ5R_7C1TDD6ZZ.f zEroR0rAC4B.a_KkM6DCYuP7l2c5fnT5yZKn1IsE1hDuGVpWoV3ICQgnszmR uUQ6haaWb2_sYJDvaWzleGHhWB.Kz9O5fzb4d3nECv1sGxdntRxp0LoPjhfA VKC9_t1SVXY7OfHdsj9A6zAswfpqu3rK3IiKqjgEI3zNBMFCrvGzbJr4Bl3c ldDO.Qy.jjg9JOO1rP8yZu2YXdFyBj2mRBLNgSooRgcjmSkZZ7q.75yIJtp. 25j6bdW.TXpkeO6EP7ZvEIed5F6I2IxkYKn4BHVZvdLYNjyp8sozSVHMhjkz ehnhPx7Bu3MFTSNvdRoK0Cxy7V4s6aIGVPpx7OZ840HtxFfxNKNauqVVM93n v1WulNpufPdRkJxhi3pSC2j0Q5jA1LvDry9TzHQyRPgSvy553LFWyWPeATku xE_7UOiX9pb867SP57Fgf8PkXSXckKOQEDQhDWV3MYCG6AKVBoS98Qf4wadb g9OvOWu7jVQq9jxNE_TCp.oSFr_ukq_1coRTU_4amtJRk6PwnD9E40pt7hmC sYIalH43V7ij1eG.VQnqBcuR56uI0GoT5Fbjc8EQ8EeM6DDD3gHzKpADscxa vUyijuMKZN4FDwdPkBb4sKABC X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- Received: by labhs14 with SMTP id hs14so41232089lab.1 for ; Tue, 03 Mar 2015 17:01:32 -0800 (PST) X-Gm-Message-State: ALoCoQlUjM+sJpKsQ+/8jaQdJD3IMWElOHj4Xnrug4h3Gj5cP07v/uTRTGIF/CAv1mMhC50DLS3w X-Received: by 10.112.85.165 with SMTP id i5mr1299352lbz.7.1425430892825; Tue, 03 Mar 2015 17:01:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.136.212 with HTTP; Tue, 3 Mar 2015 17:01:12 -0800 (PST) In-Reply-To: <54F59D36.9050000@ninebynine.org> References: <20150302172347.19316.85751.idtracker@ietfa.amsl.com> <54F59D36.9050000@ninebynine.org> From: mike amundsen Date: Tue, 3 Mar 2015 20:01:12 -0500 Message-ID: To: Graham Klyne Content-Type: multipart/alternative; boundary=001a11345cbe04ee5f05106bfee4 Archived-At: Cc: media-types@ietf.org, "alps-io@googlegroups.com" Subject: Re: [media-types] Fwd: New Version Notification for draft-amundsen-richardson-foster-alps-01.txt X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 01:01:38 -0000 --001a11345cbe04ee5f05106bfee4 Content-Type: text/plain; charset=UTF-8 Graham: thanks for the review. all good stuff. comments inline .... mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund On Tue, Mar 3, 2015 at 6:38 AM, Graham Klyne wrote: > Hi, > > Reviewing: > http://tools.ietf.org/id/draft-amundsen-richardson-foster-alps-01.html > > I'm just taking a quick skim here, and offer some immediate comments (I've > yet to fully grasp the big picture). > > ... > > Sect 1.4 > > "This URL SHOULD be assumed to be dereferencable." reads oddly (making a > normative statement about an assumption?). > > Maybe just "This URL SHOULD be dereferencable."? > +1 > > ... > > Sect 2.2.2: missing {...} around "alps" content? > > { "alps : "doc" : { "value" : "..." }, ... } > > (cf. sect 2.3.3.1) > yep -- good catch > > ... > > 2.2.7.3. Link Relation Values and 'id' or 'name' > > I see a problem here. It's all very well to say "If the resulting link > relation type is the same as a registered relation type, the descriptor > MUST not change the meaning of the IANA relation type.". > > But an implementer cannot know what new relation types will be implemented > in future. An application that is conformant at the time of implementation > may be rendered non-conformant by subsequent IANA registrations. I think > this is not consistent with progressing the notion of "software engineering > on the scale of decades" which I'm guessing is a motivation for this work. > > One possible approach might be to require any non-registered value to be a > URI or URI reference, and introduce a distinguishable prefix for local > ids. (e.g. use fragment syntax such as '#idvalue' or a common URN prefix > such as 'urn:ietf:alps:id:idvalue'. I'm not suggesting these as specific > solutions as I don't yet understand enough of the scope of what you're > proposing, just as examples of alternative approaches to contemplate.) > > ... > right - our *intent* is to mimic advice from 6906[1]: "A profile MUST NOT change the semantics of the resource representation when processed without profile knowledge..." in this case, the intent is to say that an ALPS document MUST NOT change the semantics of an existing registered Link Relation Value." Also, using 5988-style URIs for non-reg'd values is a good one. We're totally on board for that. So that challenge here is to properly convey the idea that reg'd values MUST NOT be redefined. this certainly works "at the scale of decades", right? [1] https://tools.ietf.org/html/rfc6906#section-3 > Section 2.2.12 > > I'm not understanding what you mean by the description of > type="semantic". The examples given (html.span and html.input) aren't > helping in this respect. > > My guess is that some kind of introduction to the kind of hypermedia model > your basing this upon is needed. I think there's a lot of tacit knowledge > permeating the spec that needs to be surfaced for those who aren't in tune > with your approach. > > good observation. we need some expository material maybe. in ALPS documents, descriptors can describe actions (type="safe", "idempotent", or "unsafe") or descriptors can describe state values (type="semantic"). the idea here is make it clear that both actions and data elements are described in an ALPS document and it it clear which is which. I'll work up some content that addresses this in the Motivation section. > ... > > Section 4. > > I think the media type registrations should reference the fragment id > interpretation (sect 2.2.7.2). > yep - again, good catch. > > ... > > HTH > yes, it does. thanks. > > #g > -- > > > > > On 02/03/2015 17:42, mike amundsen wrote: > >> The updated I-D for ALPS was just posted it to the IETF tracker (see >> details below). I've also updated the web site[0] . >> >> We're looking for any/all comments and feedback. Feel free to discuss on >> the ALPS list[1] or here, and to open/update issues in github[2] for the >> next round of changes. >> >> -- cheers. >> >> [0] http://alps.io/spec/index.html >> [1] https://groups.google.com/forum/?fromgroups=#!forum/alps-io >> [2] https://github.com/alps-io/spec/issues >> >> >> mamund >> +1.859.757.1449 >> skype: mca.amundsen >> http://amundsen.com/blog/ >> http://twitter.com/mamund >> https://github.com/mamund >> http://linkedin.com/in/mamund >> >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Mon, Mar 2, 2015 at 12:23 PM >> Subject: New Version Notification for >> draft-amundsen-richardson-foster-alps-01.txt >> To: Mike Amundsen , Leonard Richardson < >> leonardr@segfault.org>, "Mark W. Foster" >> >> >> >> A new version of I-D, draft-amundsen-richardson-foster-alps-01.txt >> has been successfully submitted by Mike Amundsen and posted to the >> IETF repository. >> >> Name: draft-amundsen-richardson-foster-alps >> Revision: 01 >> Title: Application-Level Profile Semantics (ALPS) >> Document date: 2015-02-28 >> Group: Individual Submission >> Pages: 27 >> URL: >> http://www.ietf.org/internet-drafts/draft-amundsen- >> richardson-foster-alps-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-amundsen-richardson-foster-alps/ >> Htmlized: >> http://tools.ietf.org/html/draft-amundsen-richardson-foster-alps-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-amundsen-richardson-foster-alps-01 >> >> Abstract: >> This document describes ALPS, a data format for defining simple >> descriptions of application-level semantics, similar in complexity to >> HTML microformats. An ALPS document can be used as a profile to >> explain the application semantics of a document with an application- >> agnostic media type (such as HTML, HAL, Collection+JSON, Siren, >> etc.). This increases the reusability of profile documents across >> media types. >> >> Editorial Note (To be removed by RFC Editor) >> >> Distribution of this document is unlimited. Comments should be sent >> to the IETF Media-Types mailing list (see [1]). >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> media-types mailing list >> media-types@ietf.org >> https://www.ietf.org/mailman/listinfo/media-types >> >> > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > --001a11345cbe04ee5f05106bfee4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Graham:

thanks for the review. all good= stuff.

comments inline ....

<= div class=3D"gmail_extra">

On Tue, Mar 3, 2015 at 6:38 AM, Graham Klyne= <gk@ninebynine.org> wrote:
Hi,

Reviewing:
http://tools.ietf.org/id/draft-amundsen-ri= chardson-foster-alps-01.html

I'm just taking a quick skim here, and offer some immediate comments (I= 've yet to fully grasp the big picture).

...

Sect 1.4

"This URL SHOULD be assumed to be dereferencable." reads oddly (m= aking a normative statement about an assumption?).

Maybe just "This URL SHOULD be dereferencable."?
=

+1=C2=A0

...

Sect 2.2.2: missing {...} around "alps" content?

{ "alps : "doc" : { "value" : "..." }, .= .. }

(cf. sect 2.3.3.1)
=C2=A0
yep -- good catch<= /div>

...

2.2.7.3. Link Relation Values and 'id' or 'name'

I see a problem here.=C2=A0 It's all very well to say "If the resu= lting link relation type is the same as a registered relation type, the des= criptor MUST not change the meaning of the IANA relation type.".

But an implementer cannot know what new relation types will be implemented = in future.=C2=A0 An application that is conformant at the time of implement= ation may be rendered non-conformant by subsequent IANA registrations.=C2= =A0 I think this is not consistent with progressing the notion of "sof= tware engineering on the scale of decades" which I'm guessing is a= motivation for this work.

One possible approach might be to require any non-registered value to be a = URI or URI reference, and introduce a distinguishable prefix for local ids.= =C2=A0 (e.g. use fragment syntax such as '#idvalue' or a common URN= prefix such as 'urn:ietf:alps:id:idvalue'.=C2=A0 I'm not sugge= sting these as specific solutions as I don't yet understand enough of t= he scope of what you're proposing, just as examples of alternative appr= oaches to contemplate.)

...

right - our *intent* is to mimic ad= vice from 6906[1]: "A p= rofile MUST NOT change the semantics of the=C2=A0resource representation when processed without = profile knowledge..." in this case, the intent is to say that an ALPS = document MUST NOT change the semantics of an existing registered Link Relat= ion Value." Also,=C2=A0using 5= 988-style URIs for non-reg'd values is a good one. We're totally on= board for that.=C2=A0
So that challenge here= is to properly convey the idea that reg'd values MUST NOT be redefined= . this certainly works "at the scale of decades", right?

[1] https://tools.ietf.org/html/rfc6906#section-3=C2=A0



Section 2.2.12

I'm not understanding what you mean by the description of type=3D"= semantic".=C2=A0 The examples given (html.span and html.input) aren= 9;t helping in this respect.

My guess is that some kind of introduction to the kind of hypermedia model = your basing this upon is needed.=C2=A0 I think there's a lot of tacit k= nowledge permeating the spec that needs to be surfaced for those who aren&#= 39;t in tune with your approach.


good observation. we need some exposit= ory material maybe. in ALPS documents, descriptors can describe actions (ty= pe=3D"safe", "idempotent", or "unsafe") or de= scriptors can describe state values (type=3D"semantic"). the idea= here is make it clear that both actions and data elements are described in= an ALPS document and it it clear which is which.=C2=A0

I'll work up some content that addresses this in the Motivation s= ection.
=C2=A0
...

Section 4.

I think the media type registrations should reference the fragment id inter= pretation (sect 2.2.7.2).

yep - again, = good catch.
=C2=A0

...

HTH

yes, it does. thanks.
=C2= =A0

#g
--




On 02/03/2015 17:42, mike amundsen wrote:
The updated I-D for ALPS was just posted it to the IETF tracker (see
details below). I've also updated the web site[0] .

We're looking for any/all comments and feedback. Feel free to discuss o= n
the ALPS list[1] or here, and to open/update issues in github[2] for the next round of changes.

-- cheers.

[0]=C2=A0 http= ://alps.io/spec/index.html
[1] https://groups.google.com/forum/?fromgroups=3D#= !forum/alps-io
[2] ht= tps://github.com/alps-io/spec/issues


mamund
= +1.859.757.1449
skype: mca.amundsen
http://amundsen.com= /blog/
http://twitter.com/= mamund
https://github.com/= mamund
http://linkedin= .com/in/mamund



---------- Forwarded message ----------
From: <int= ernet-drafts@ietf.org>
Date: Mon, Mar 2, 2015 at 12:23 PM
Subject: New Version Notification for
draft-amundsen-richardson-foster-alps-01.txt
To: Mike Amundsen <mca@amundsen.com>, Leonard Richardson <
leonardr@segfaul= t.org>, "Mark W. Foster" <mwf@fosrias.com>



A new version of I-D, draft-amundsen-richardson-foster-alps-01.txt has been successfully submitted by Mike Amundsen and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-amundsen-richardson-= foster-alps
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application-Level Profile Semantic= s (ALPS)
Document date:=C2=A0 2015-02-28
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 27
URL:
http://www.ietf.org/internet-dra= fts/draft-amundsen-richardson-foster-alps-01.txt
Status:
https://datatracker.ietf.org/doc/draft-am= undsen-richardson-foster-alps/
Htmlized:
http://tools.ietf.org/html/draft-amundsen-ric= hardson-foster-alps-01
Diff:
http://www.ietf.org/rfcdiff?url2=3Ddr= aft-amundsen-richardson-foster-alps-01

Abstract:
=C2=A0 =C2=A0 This document describes ALPS, a data format for defining simp= le
=C2=A0 =C2=A0 descriptions of application-level semantics, similar in compl= exity to
=C2=A0 =C2=A0 HTML microformats.=C2=A0 An ALPS document can be used as a pr= ofile to
=C2=A0 =C2=A0 explain the application semantics of a document with an appli= cation-
=C2=A0 =C2=A0 agnostic media type (such as HTML, HAL, Collection+JSON, Sire= n,
=C2=A0 =C2=A0 etc.).=C2=A0 This increases the reusability of profile docume= nts across
=C2=A0 =C2=A0 media types.

Editorial Note (To be removed by RFC Editor)

=C2=A0 =C2=A0 Distribution of this document is unlimited.=C2=A0 Comments sh= ould be sent
=C2=A0 =C2=A0 to the IETF Media-Types mailing list (see [1]).




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

The IETF Secretariat



_______________________________________________
media-types mailing list
media-types@ietf.= org
https://www.ietf.org/mailman/listinfo/media-types


_______________________________________________
media-types mailing list
media-types@ietf.= org
https://www.ietf.org/mailman/listinfo/media-types

--001a11345cbe04ee5f05106bfee4--