From seb@serialseb.com Thu Jan 7 06:40:49 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7E73A6853 for ; Thu, 7 Jan 2010 06:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpaNOdefPffp for ; Thu, 7 Jan 2010 06:40:46 -0800 (PST) Received: from blu0-omc3-s32.blu0.hotmail.com (blu0-omc3-s32.blu0.hotmail.com [65.55.116.107]) by core3.amsl.com (Postfix) with ESMTP id D8D593A6810 for ; Thu, 7 Jan 2010 06:40:45 -0800 (PST) Received: from BLU102-DS6 ([65.55.116.74]) by blu0-omc3-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 06:40:44 -0800 X-Originating-IP: [78.105.1.95] X-Originating-Email: [seb@serialseb.com] Message-ID: From: "Sebastien Lambla" To: Subject: 2047 in 2388: encoded words in multipart/form-data Date: Thu, 7 Jan 2010 14:40:43 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0288_01CA8FA7.64685530" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqPp2QtSI++PVvuQdOnMM1eioennA== Content-Language: en-gb X-OriginalArrivalTime: 07 Jan 2010 14:40:44.0358 (UTC) FILETIME=[64999E60:01CA8FA7] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 14:42:40 -0000 ------=_NextPart_000_0288_01CA8FA7.64685530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, There seems to be an issue with 2388 describing multipart/form-data. It says that the field name (aka the name= parameter) has to be encoded using 2047 when containing non-ascii characters. As I understand it, the filename parameter itself is to be encoded with 2231, and 2047 specifically states that it is not to be used in parameters. So there's a clash between 2047 and 2388, which should probably be addressed. In the mean-time, I'd like to know if anyone has been known to use 2047 for parameters? I've quickly tested browser implementations, and they simply pass back the UTF-8 code points I've provided in the markup, which I find very surprising. How do people deal with such code-points in the headers? Thanks, Sebastien Lambla ------=_NextPart_000_0288_01CA8FA7.64685530 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

There seems to be an issue with 2388 describing multipart/form-data. It says that the field name (aka the name=3D = parameter) has to be encoded using 2047 when containing non-ascii characters. As I = understand it, the filename parameter itself is to be encoded with 2231, and 2047 specifically states that it is not to be used in = parameters.

 

So there’s a clash between 2047 and 2388, = which should probably be addressed. In the mean-time, I’d like to know if = anyone has been known to use 2047 for parameters?

 

I’ve quickly tested browser implementations, = and they simply pass back the UTF-8 code points I’ve provided in the = markup, which I find very surprising. How do people deal with such code-points in the headers?

 

Thanks,

 

Sebastien Lambla

 

------=_NextPart_000_0288_01CA8FA7.64685530-- From A.Hoenes@TR-Sys.de Mon Jan 11 07:09:16 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29E693A67E9; Mon, 11 Jan 2010 07:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.604 X-Spam-Level: X-Spam-Status: No, score=0.604 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMWPv667ggSI; Mon, 11 Jan 2010 07:09:15 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 5281A3A67A7; Mon, 11 Jan 2010 07:09:13 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA165432522; Mon, 11 Jan 2010 16:08:42 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA08192; Mon, 11 Jan 2010 16:08:36 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201001111508.QAA08192@TR-Sys.de> Subject: Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues To: lars.eggert@nokia.com Date: Mon, 11 Jan 2010 16:08:36 +0100 (MEZ) In-Reply-To: from Lars Eggert at Jan "11, " 2010 "02:46:22" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: port-srv-reg@ietf.org, apps-discuss@ietf.org, tsvwg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 15:09:16 -0000 Lars, please read on and do not respond again without taking into account the whole explanations given. At Mon, 11 Jan 2010 14:46:22 +0200, Lars Eggert wrote: > On 2010-1-11, at 14:27, ah@tr-sys.de wrote: >> ... >> (2) >> It also should be pointed out that in the most recent predraft >> I've seen (December 2, 2009 version), there still is no possibility >> in the proposed registration template to distinguish between >> a request for a Well Known port number without a proposed value and >> a request for a Registered Port without a proposed port number -- >> both have to supply "Port Number: ANY". > > And that's on purpose: for both regions of the port number space, > requesters may (but need not) suggest a number Agreed so far. But that's not been the question here. Please do not ignore the second part of the complete explanation from my original message! Here is the part you snipped off: (cf. http://www.IETF.ORG/mail-archive/web/port-srv-reg/current/msg00386.html) >> The distinction is clear whenever a value is proposed (requested?). >> In the past, I already had proposed (at least twice) to introduce >> something like "ANY-WELL-KNOWN" as an alternative meta-value for >> the Port Number field to make it clear to IANA what is requested. >> Alternatively, a distinct field "Port Range" could be added to >> the Registration template for this purpose. If no specific port number is specified in the request to IANA, how can IANA determine which port *range* to use for the assignment ? That's the question for which I see no answer in the text of Section 8.1 (unless it has been changed since we have been provided with a working copy dated Dec. 2). The two alternate proposals I made for the registration template were: a) admit for "Port Number" the following three answers: - a specific port number - "ANY-WELL-KNOWN" if the request is for a port in the 1-1023 range, without a specific preferred value - "ANY" if the request is for a port in the 1k-48k range without a specific preferred value b) leave the "Port Number" field 'as is', but add a "Port Range" field ( or maybe Well-Known Port: Yes/No ) >> (3) >> Furthermore, to make sensible use of Service Names w/o assigned >> port number, the Transport Protocol(s) field should not be made >> optional (as in the predraft I got), but mandatory; otherwise >> the clarified rules for SRV owner naming would lack a fundament. > > Why? A service name is a name for a service, and not for a > service/transport combination. > > Lars Simply because service discovery is (service+protocol)-specific. That's why (RFC 2052 and then its successor) RFC 2782 makes use of combined Service Prefixes in the owner names of DNS SRV records. Again, you have snipped of the lines saying so: >> (The need for having registered {Service Name, Protocol} pairs was >> the main reason for the original Service Prefix registry proposal.) That's been explained at length in our original draft, and it is explained again in draft-gudmundsson-dnsext-srv-clarify-00 : DNS admins need the list of "reasonable" Service Prefixes (built from supported {Service Nmae, Protocol} pairs) they should allow without additional clarification in the zones they provide. Prospective clients need to know for which names they can reasonably try to look up SRV records, without wasting resources and time (note that each DNS query can only contain a single question, for a single owner name). tsvwg-iana-ports departs from the previous paradigm to register any port number for *all* transport protocols at once, with good reasons. The same reasons hold for services without assigned port numbers. The Service Name alone does not lead to a reasonable Service Prefix, just like the local-part of a mailbox does not suffice for a globally useful email address -- the RHS (domain) part is needed as well. I understood (also from what has been reported from Hiroshima) that you did not like the standalone IANA registry of valid Service Prefixes proposed in draft-gudmundsson-dns-srv-iana-registry, based on the argument that the unified Service Names and Port Numbers registry will provide that information anyway. We have accepted this argument. But if that precondition will not be satisfied, these arguments against draft-gudmundsson-dns-srv-iana-registry would be moot and that draft would perhaps need to be resurrected. To restate, once more: In order to avoid the need for a standalone registry for DNS SRV Service Prefixes, Service Names in the unified Service Names and Port Numbers registry *must* be linked to the relevant Protocol information. Kind regards, Alfred Hnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From lars.eggert@nokia.com Wed Jan 13 00:39:45 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28163A685A; Wed, 13 Jan 2010 00:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGbOEVqRMJJr; Wed, 13 Jan 2010 00:39:45 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id CF8AC3A67D7; Wed, 13 Jan 2010 00:39:44 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0D8dYmS023699; Wed, 13 Jan 2010 02:39:41 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 10:39:19 +0200 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 10:39:18 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0D8dHKd031873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jan 2010 10:39:17 +0200 Subject: Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-34--550580193; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <201001111508.QAA08192@TR-Sys.de> Date: Wed, 13 Jan 2010 10:39:04 +0200 Message-Id: <54E3D339-1E62-4BD1-9AA0-80F3C348724F@nokia.com> References: <201001111508.QAA08192@TR-Sys.de> To: =?iso-8859-1?Q?Alfred_H=CEnes?= , Joe Touch X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Wed, 13 Jan 2010 10:39:10 +0200 (EET) X-OriginalArrivalTime: 13 Jan 2010 08:39:18.0531 (UTC) FILETIME=[E5518530:01CA942B] X-Nokia-AV: Clean Cc: "port-srv-reg@ietf.org" , "apps-discuss@ietf.org" , "tsvwg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 08:39:45 -0000 --Apple-Mail-34--550580193 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, responding to Alfred and Joe in one go. On 2010-1-11, at 17:08, ah@tr-sys.de wrote: > If no specific port number is specified in the request to IANA, > how can IANA determine which port *range* to use for the assignment ? >=20 > That's the question for which I see no answer in the text of > Section 8.1 (unless it has been changed since we have been > provided with a working copy dated Dec. 2). I checked and the text says: If the text "ANY" is specified, IANA will choose a suitable number from the Registered Ports range. So in order to get a Well Known port, the applicant has to specify which = one. That's OK, because you need to pass IETF Review anyway, which means = you need a draft, and all requests for the Well Known range I've ever = seen had already picked their port. On 2010-1-11, at 17:06, Joe Touch wrote: > Lars Eggert wrote: >> On 2010-1-11, at 14:27, ah@tr-sys.de wrote: >>> Paraphrased from collected wisdom: >>> "allocate" or "assign" : ... >>> "register" : >>=20 >> I'd like to hear if IANA is of the same opinion. My impression was = that assign =3D register. >=20 > There's a third variant, and it isn't covered above: >=20 > requester usually proposes a code point, and IANA > can either approve it or propose a different one. > IANA usually confirms the requester's acceptance > of the code point offered. Maybe I'm dense, but I don't understand how that is a third option. = Either IANA views "registered" and "assigned" as synonyms or they don't = :-) >>> (3) >>> Furthermore, to make sensible use of Service Names w/o assigned >>> port number, the Transport Protocol(s) field should not be made >>> optional (as in the predraft I got), but mandatory; otherwise >>> the clarified rules for SRV owner naming would lack a fundament. >>=20 >> Why? A service name is a name for a service, and not for a = service/transport combination. >=20 > IMO, this basically treats SRV names as old port numbers were treated = - > i.e., ask for a name, get ALL transports. That's how port number > assignments were done until recently, where now only the needed > transport is assigned. >=20 > So IMO a service means something only relative to a transport. = However, > it'd be useful to require the transport be specified only if the same > name would mean different things for different transports. Do we ever > see that happening? Right. Or, in other words, if you have a service name, it's yours for = all transports, just as ports used to be. (There are so many service = names that we can burn combinations that aren't used, and limit = interactions with IANA.) Lars= --Apple-Mail-34--550580193 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDExMzA4MzkwNVowIwYJKoZIhvcNAQkEMRYEFDCoZfxRUIQxe/HWaEWtX3ypbx2+MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDtubYqlNwvPgfrqUbbnuAggSuYPx5WUru4fvt1ts3OgssapT8s/OfRYOQzRfhtKP89Iybv AwWsQNxVydELxVA/nV9/WvWl5WgT4tG46sqvH2ePwz0CPTYr2QBb4u+QAL9Qo8C8Cnf0AxzMAJDO GAbICJcnr85B0Lt4gsBpzvUqDsJlU4m60aeeN/t6Nc+lOs43MpDL9c02LqbJQPgLulv45+pb7Kbr ZtIYf46QGJn7ojy5vNjSv00dI3I5LjzafZE8CQhi3lGclBr0TxJzWrg2sPRynGm+qNXwsH2i1wGV tsxCfFyd0Y7wjTYAF8IFSvwwJmR67woRlgb7g95STwppAAAAAAAA --Apple-Mail-34--550580193-- From touch@ISI.EDU Wed Jan 13 06:51:01 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20633A67DA; Wed, 13 Jan 2010 06:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZW3v2YJf1dTx; Wed, 13 Jan 2010 06:51:00 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id C0B9D3A6837; Wed, 13 Jan 2010 06:50:57 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o0DEo7T5021722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Jan 2010 06:50:08 -0800 (PST) Message-ID: <4B4DDD9E.8040009@isi.edu> Date: Wed, 13 Jan 2010 06:50:06 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues References: <201001111508.QAA08192@TR-Sys.de> <54E3D339-1E62-4BD1-9AA0-80F3C348724F@nokia.com> In-Reply-To: <54E3D339-1E62-4BD1-9AA0-80F3C348724F@nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: o0DEo7T5021722 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= , "port-srv-reg@ietf.org" , "apps-discuss@ietf.org" , "tsvwg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 14:51:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Eggert wrote: > Hi, > > responding to Alfred and Joe in one go. > > On 2010-1-11, at 17:08, ah@tr-sys.de wrote: >> If no specific port number is specified in the request to IANA, >> how can IANA determine which port *range* to use for the assignment ? >> >> That's the question for which I see no answer in the text of >> Section 8.1 (unless it has been changed since we have been >> provided with a working copy dated Dec. 2). > > I checked and the text says: > > If the text "ANY" is specified, IANA will choose > a suitable number from the Registered Ports range. > > So in order to get a Well Known port, the applicant has to specify > which one. That's OK, because you need to pass IETF Review anyway, which > means you need a draft, and all requests for the Well Known range I've > ever seen had already picked their port. I think that IANA would be glad to pick a Well Known port number if the applicant doesn't care, though (see below). As you've seen in other cases, the text on the current IANA forms and web pages may not have been chosen to be so specific. > On 2010-1-11, at 17:06, Joe Touch wrote: >> Lars Eggert wrote: >>> On 2010-1-11, at 14:27, ah@tr-sys.de wrote: >>>> Paraphrased from collected wisdom: >>>> "allocate" or "assign" : > ... >>>> "register" : >>> I'd like to hear if IANA is of the same opinion. My impression was that assign = register. >> There's a third variant, and it isn't covered above: >> >> requester usually proposes a code point, and IANA >> can either approve it or propose a different one. >> IANA usually confirms the requester's acceptance >> of the code point offered. > > Maybe I'm dense, but I don't understand how that is a third option. > Either IANA views "registered" and "assigned" as synonyms or they don't :-) I think they do. The two variants you gave were also different in how the code point was picked, though - the third option is in that aspect: (as you listed): - IANA picks the code point - requester usually picks the code point if IANA disagrees, then IANA asks the requester to pick a different one ^^^^^^^^^^^^^^^^^^^^^^^ I was suggesting that: - requester usually picks the code point if IANA disagrees, then IANA proposes an alternate and asks for confirmation ^^^^^^^^^^^^^^^^^^^^^^^^^^ The difference is what happens when IANA doesn't like the suggested code point. I don't think it matters much who suggests the alternate, but in practice it's usually IANA that does the suggesting. Maybe it's OK to say: an different code point is selected until agreed >>>> (3) >>>> Furthermore, to make sensible use of Service Names w/o assigned >>>> port number, the Transport Protocol(s) field should not be made >>>> optional (as in the predraft I got), but mandatory; otherwise >>>> the clarified rules for SRV owner naming would lack a fundament. >>> >>> Why? A service name is a name for a service, and not for a service/transport combination. >> >> IMO, this basically treats SRV names as old port numbers were treated - >> i.e., ask for a name, get ALL transports. That's how port number >> assignments were done until recently, where now only the needed >> transport is assigned. >> >> So IMO a service means something only relative to a transport. However, >> it'd be useful to require the transport be specified only if the same >> name would mean different things for different transports. Do we ever >> see that happening? > > Right. Or, in other words, if you have a service name, it's yours for > all transports, just as ports used to be. (There are so many service > names that we can burn combinations that aren't used, and limit > interactions with IANA.) Agreed - you claimed that a service name is for a service, not a service/transport combo. I think it's worth nothing that a service is *always* indicated as a service/transport combo, and that a service name is intended for all current and future transports - the port number or other code points (DCCP extras?) can vary on a per transport basis, though. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAktN3Z0ACgkQE5f5cImnZrumdwCglZOJxgIwQImN3h1H165/7RZk I2UAoL/7JHydkRONeHUL/PyvxBkc7FiH =ya+9 -----END PGP SIGNATURE----- From A.Hoenes@TR-Sys.de Wed Jan 13 09:12:21 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28893A69C6; Wed, 13 Jan 2010 09:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.53 X-Spam-Level: X-Spam-Status: No, score=0.53 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUIwOA-mXF-Y; Wed, 13 Jan 2010 09:12:17 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id AE56D3A69C5; Wed, 13 Jan 2010 09:12:12 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA177192715; Wed, 13 Jan 2010 18:11:55 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA11649; Wed, 13 Jan 2010 18:11:53 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201001131711.SAA11649@TR-Sys.de> Subject: Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues To: lars.eggert@nokia.com, touch@isi.edu Date: Wed, 13 Jan 2010 18:11:52 +0100 (MEZ) In-Reply-To: <54E3D339-1E62-4BD1-9AA0-80F3C348724F@nokia.com> from Lars Eggert at Jan "13, " 2010 "10:39:04" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: port-srv-reg@ietf.org, apps-discuss@ietf.org, tsvwg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 17:12:21 -0000 Lars Eggert wrote today: > Hi, > > responding to Alfred and Joe in one go. > > On 2010-1-11, at 17:08, ah@tr-sys.de wrote: >> If no specific port number is specified in the request to IANA, >> how can IANA determine which port *range* to use for the assignment ? >> >> That's the question for which I see no answer in the text of >> Section 8.1 (unless it has been changed since we have been >> provided with a working copy dated Dec. 2). > > I checked and the text says: > > If the text "ANY" is specified, IANA will choose > a suitable number from the Registered Ports range. > > So in order to get a Well Known port, the applicant has to specify > which one. That's OK, because you need to pass IETF Review anyway, > which means you need a draft, and all requests for the Well Known > range I've ever seen had already picked their port. > > > On 2010-1-11, at 17:06, Joe Touch wrote: >> Lars Eggert wrote: >>> On 2010-1-11, at 14:27, ah@tr-sys.de wrote: >>>> Paraphrased from collected wisdom: >>>> "allocate" or "assign" : > ... >>>> "register" : >>> >>> I'd like to hear if IANA is of the same opinion. My impression >>> was that assign = register. >> >> There's a third variant, and it isn't covered above: >> >> requester usually proposes a code point, and IANA >> can either approve it or propose a different one. >> IANA usually confirms the requester's acceptance >> of the code point offered. > > Maybe I'm dense, but I don't understand how that is a third option. > Either IANA views "registered" and "assigned" as synonyms or they > don't :-) OOOPS! Back to square one! No! To 'register' is not a synonym for 'assign'. Please note, folks, the difference in the case of IANA comes with the tense. Once IANA *has performed* the job, all those code points are "registered", for sure. However, the difference lies in what IANA has done beforehand. (The same terms apply to functions that IANA does not perform any more because control has passed to ICANN and subsidiaries.) When it comes to what IANA is being requested to do, it's always been, and still is, a huge difference between "assign" and "register" ! To "register" means to archive and give a signature on the act, not to operate in any way on the content. In civil life, you will have the registrar in the city hall *register* the name you gave to your baby child. It will be the name you have chosen, and nothing else. In case of IANA, for instance, media types are being *registered*: the requester gives the type/subtype name; if there ever is a problem with the rules (or a name collision), IANA comes back and advises, and gives the requester a second try. That's what we expect for Service Names in the future. For many other IANA requests, things are different; IANA owns a name space and manages it in a way that should make code point grabbing difficult and ensures that the code point cannot be used before IANA has performed the *assignment* of the code point and then registered the picked value. Im civil life, there are similar operations. A new company will apply for a tax number (VAT ID, or the like), and it will be *assigned* and handed out to the company -- and of course, it will be registered at the tax office after the assignment has been performed. In the U.S., you will be assigned a social security number; again, you can't choose the value you like. etc. etc. ... In the case of protocol parameters, typically a mnemonic name is specified for the item to be registered and IANA *assigns* the code point only, i.e. the actual operation is a combination of code point assignment and registration. Examples: DHCP Option codes, RADIUS or Diameter Attributes, TLV type codes in various routing protocols, TCP option kind codes, Object identifiers in the SMI IETF-OID tree branches for MIB modules, SMI enterprise numbers, DNS resource record types, TLS cipher suites, IPsec and IKE transform IDs, etc... The most well-known case for a name space that clearly only holds code points that are being *assigned* are IP addresses (or network prefixes, for qualifying entities). So please do not continue to mess up fundamentally different concepts; it still holds that: "register" != "assign" ! To make that evident again, from an at-large Internet perspective: You might want to *register* a domain name, for example; and to do that you go to a "registrar", not an "assigner", true? You will have chosen the name -- maybe with advise --, and you submit that name. When there's something wrong, the registrar will come back and tell you to choose another name; he will never generate a name (at will, in collation order, at random, ...) and *assign* it to you, isn't it? However, if you are willing to pay an appropriate fee, you might want to ask your ISP to *allocate* you one (or more) permanent IP address(es) for use on your residential access line. The ISP never accept a request to *register* a given IP address that you have chosen. For completeness: There's a third important term for IANA/ICANN action: to "allocate". Sometimes IANA has been authorized to *allocate* on request small parts of a managed namespace to a WG, a protocol, or some specified particular purpose. By allocating such parts of a namespace, IANA transfers (or "delegates") the right (and duty) to *assign* code points from within the subspace to the requester of the allocation. For instance, from time to time multicast address blocks get "allocated", or special purpose IP prefixes get "allocated". The most popular past precedent were RFC 1918 private IP addresses. Or, there is an OID branch for protocol and algorithm objects "allocated" or "delegated" from IANA to the PKIX WG. So please stay with the precise terms and do not confuse IANA actions to "allocate", to "assign", and to "register" ! These are three very different actions. > >>>> (3) >>>> Furthermore, to make sensible use of Service Names w/o assigned >>>> port number, the Transport Protocol(s) field should not be made >>>> optional (as in the predraft I got), but mandatory; otherwise >>>> the clarified rules for SRV owner naming would lack a fundament. >>> >>> Why? A service name is a name for a service, and not for a >>> service/transport combination. >> >> IMO, this basically treats SRV names as old port numbers were treated - >> i.e., ask for a name, get ALL transports. That's how port number >> assignments were done until recently, where now only the needed >> transport is assigned. Why making that silly distinction? >From a service discovery perspective, it does not matter whether or not there is an assigned (default) port number for the service. Registering different information does not help; it confuses. There should only be SRV RRs for supported combinations. You give the perspective of migration to service discovery in your draft. So why going back in that case to the past methods you have recognized as being inappropriate in the 'classical' case? >> >> So IMO a service means something only relative to a transport. However, >> it'd be useful to require the transport be specified only if the same >> name would mean different things for different transports. Do we ever >> see that happening? > > Right. Or, in other words, if you have a service name, it's yours for > all transports, just as ports used to be. (There are so many service > names that we can burn combinations that aren't used, and limit > interactions with IANA.) > > Lars No. I strongly oppose. You have made good progress for port numbers, by having IANA only register a service for the specific transport protocols used. The same expectation holds for services without an assigned port number. The entity managing a zone with SRV resource records does not want to admit nonsensical owner names. One of the primary purposes of the proposed independent Service Prefix registry was to give just that list to admins. You have insisted on a unified registry, and we have accepted, because we have been assured that the requirements spelled out multiple times before IETF 76 in Hiroshima would mostly be fulfilled by the unified registry. You also have insisted on only using transport protocols registered with a service for service discovery DNS name construction. That's why we are working on advice for RFC authors, WGs, and other SDOs, on how to migrate previously documented use cases of SRV records not adhering to these restrictions to other naming schemes following these rules. Therefore, as agreed upon in Hiroshima, our "SRV Clarify" draft, http://tools.ietf.org/html/draft-gudmundsson-dnsext-srv-clarify-00 spells out that the Service Prefix in the owner name of SRV records MUST be constructed from the entries in the unified Service Names and Port Numbers registry: - the Service Label is to be constructed from the Service Name in the entry, and - the Protocol Label is to be built from the transport Protocol name in the registry entry (by prefixing an underscore to the supported protocol acronym, currently 4 choices). We also have repeatedly asked for an optional per-entry tag indicating the support of dynamic service discovery via DNS SRV records. To repeat: Not having the proper protocol name associated with the Service Name -- independent of whether or not there is an assigned (default) port number -- would make the registry useless for those who want to make use of it to determine which Service Prefixes should be admitted in DNS zones routinely. Operators do not want to maintain myriads of nonsensical records. The registry MUST contain the information to help keeping that number manageable. If it doesn't, private lists will resurrect, or the need to revive draft-gudmundsson-dns-srv-iana-registry might be determined as necessary to obtain a useful registry for service discovery. If you want our support for tsvwg-iana-ports, as we had committed, please fulfill the most important requirements from the service discovery perspective, as spelled out repeatedly. ** The only names that appear in the unified registry without the ** information on supported protocols should be the "roadblocker" ** dummy entries you want to have for reserving particular names. ** At least each proper service, but much prefrably each ** service/transport combination, should carry an optional flag ** indicating use for DNS SRV based service discovery. ** The registration template must allow to set/clear that flag. ** In populating the new registry, only documented use of service ** discovery should have that flag set (take the list from ** draft-gudmundsson-dns-srv-iana-registry-04 and the private ** service discovery list intended to be imported), unless the ** owner of the entry indicates otherwise. ** Preferably, documents specifying service discovery should be ** tagged in the References of registry entries to indicate that ** fact, and to distinguish such refs from specifications of the ** application protocol. Kind regards, Alfred Hnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From touch@ISI.EDU Wed Jan 13 19:31:59 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92543A6814; Wed, 13 Jan 2010 19:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2BU4ScKhRN4; Wed, 13 Jan 2010 19:31:58 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id B363C3A67F2; Wed, 13 Jan 2010 19:31:58 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o0E3Uc56012084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Jan 2010 19:30:39 -0800 (PST) Message-ID: <4B4E8FDD.2050509@isi.edu> Date: Wed, 13 Jan 2010 19:30:37 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= Subject: Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues References: <201001131711.SAA11649@TR-Sys.de> In-Reply-To: <201001131711.SAA11649@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MailScanner-ID: o0E3Uc56012084 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: apps-discuss@ietf.org, port-srv-reg@ietf.org, tsvwg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 03:31:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alfred � wrote: ... >>> There's a third variant, and it isn't covered above: >>> >>> requester usually proposes a code point, and IANA >>> can either approve it or propose a different one. >>> IANA usually confirms the requester's acceptance >>> of the code point offered. >> Maybe I'm dense, but I don't understand how that is a third option. >> Either IANA views "registered" and "assigned" as synonyms or they >> don't :-) > > OOOPS! > > Back to square one! > > No! To 'register' is not a synonym for 'assign'. The "third option" is whether IANA suggests the alternate or the requester does. ... > When it comes to what IANA is being requested to do, it's always been, > and still is, a huge difference between "assign" and "register" ! > > > To "register" means to archive and give a signature on the act, > not to operate in any way on the content. IANA ends up registering what the requester agrees to. Sometimes IANA suggests a number, sometimes they don't. It's never binding anyway, so it's never an "assignment", regardless. It's always a "registration". However, IANA does sometimes suggest. I wasn't sure whether that was worth mentioning, but it does happen, and doesn't seem inappropriate. ... >>>>> (3) >>>>> Furthermore, to make sensible use of Service Names w/o assigned >>>>> port number, the Transport Protocol(s) field should not be made >>>>> optional (as in the predraft I got), but mandatory; otherwise >>>>> the clarified rules for SRV owner naming would lack a fundament. >>>> Why? A service name is a name for a service, and not for a >>>> service/transport combination. >>> IMO, this basically treats SRV names as old port numbers were treated - >>> i.e., ask for a name, get ALL transports. That's how port number >>> assignments were done until recently, where now only the needed >>> transport is assigned. > > Why making that silly distinction? It's an issue as to whether you would register an SRV name: JOE-NAME or JOE-NAME TCP JOE-NAME UDP I have no idea why you would want to do the latter, except to know that if you got "_JOE-NAME._DCCP" in an SRV it must be an error. ... > No. I strongly oppose. > > You have made good progress for port numbers, by having IANA only > register a service for the specific transport protocols used. > > The same expectation holds for services without an assigned port number. > The entity managing a zone with SRV resource records does not want to > admit nonsensical owner names. One of the primary purposes of the > proposed independent Service Prefix registry was to give just that > list to admins. > > You have insisted on a unified registry, and we have accepted, because > we have been assured that the requirements spelled out multiple times > before IETF 76 in Hiroshima would mostly be fulfilled by the unified > registry. > > You also have insisted on only using transport protocols registered > with a service for service discovery DNS name construction. That's why > we are working on advice for RFC authors, WGs, and other SDOs, on how > to migrate previously documented use cases of SRV records not adhering > to these restrictions to other naming schemes following these rules. > > Therefore, as agreed upon in Hiroshima, our "SRV Clarify" draft, > http://tools.ietf.org/html/draft-gudmundsson-dnsext-srv-clarify-00 > spells out that the Service Prefix in the owner name of SRV records > MUST be constructed from the entries in the unified Service Names and > Port Numbers registry: > - the Service Label is to be constructed from the Service Name > in the entry, and > - the Protocol Label is to be built from the transport Protocol > name in the registry entry (by prefixing an underscore to the > supported protocol acronym, currently 4 choices). > > We also have repeatedly asked for an optional per-entry tag indicating > the support of dynamic service discovery via DNS SRV records. > > To repeat: Not having the proper protocol name associated with the > Service Name -- independent of whether or not there is an assigned > (default) port number -- would make the registry useless for those > who want to make use of it to determine which Service Prefixes > should be admitted in DNS zones routinely. Can you clarify what this means? I.e., does this mean you WANT to specify the valid protocols for each service name? JOE-NAME TCP If so, why is this necessary? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAktOj90ACgkQE5f5cImnZrtK4gCg8jboAUAR+F/rVtTDTJVavwGr WdEAoPu7jGFc3LijZREjHAarArGSufML =7og/ -----END PGP SIGNATURE----- From ogud@ogud.com Thu Jan 14 06:13:18 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583F13A67D9; Thu, 14 Jan 2010 06:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqE3FUAX4Vn9; Thu, 14 Jan 2010 06:13:15 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 365363A6874; Thu, 14 Jan 2010 06:13:15 -0800 (PST) Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0EEDBDD076210; Thu, 14 Jan 2010 09:13:11 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <201001141413.o0EEDBDD076210@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 14 Jan 2010 09:13:09 -0500 To: Lars Eggert From: Olafur Gudmundsson Subject: Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues In-Reply-To: <54E3D339-1E62-4BD1-9AA0-80F3C348724F@nokia.com> References: <201001111508.QAA08192@TR-Sys.de> <54E3D339-1E62-4BD1-9AA0-80F3C348724F@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 X-Mailman-Approved-At: Thu, 14 Jan 2010 08:51:45 -0800 Cc: "port-srv-reg@ietf.org" , "apps-discuss@ietf.org" , "tsvwg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 14:13:20 -0000 At 03:39 13/01/2010, Lars Eggert wrote: > > IMO, this basically treats SRV names as old port numbers were treated - > > i.e., ask for a name, get ALL transports. That's how port number > > assignments were done until recently, where now only the needed > > transport is assigned. > > > > So IMO a service means something only relative to a transport. However, > > it'd be useful to require the transport be specified only if the same > > name would mean different things for different transports. Do we ever > > see that happening? > >Right. Or, in other words, if you have a service name, it's yours >for all transports, just as ports used to be. (There are so many >service names that we can burn combinations that aren't used, and >limit interactions with IANA.) > >Lars The important point is: Each service is going to have one or more transports that are "preferred", these preferences need to be noted in the registry. (this point applies both to port allocations and service names). See section 5.1 of http://tools.ietf.org/html/draft-gudmundsson-dnsext-srv-clarify-00 for proposed search order when priority order is not known. Olafur From wleggette@cleversafe.com Thu Jan 14 14:57:59 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661F73A69FE for ; Thu, 14 Jan 2010 14:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0gNqacjWDVD for ; Thu, 14 Jan 2010 14:57:58 -0800 (PST) Received: from p01c12o141.mxlogic.net (p01c12o141.mxlogic.net [208.65.145.64]) by core3.amsl.com (Postfix) with ESMTP id 74CB83A6908 for ; Thu, 14 Jan 2010 14:57:55 -0800 (PST) Received: from unknown [216.166.12.180] by p01c12o141.mxlogic.net(mxl_mta-6.4.0-2) with SMTP id 071af4b4.0.41431.00-018.90048.p01c12o141.mxlogic.net (envelope-from ); Thu, 14 Jan 2010 15:57:56 -0700 (MST) X-MXL-Hash: 4b4fa1741ad36de2-ab7c887bc0a202435d446eefbcf54bcfa397a5af Received: from AUSP01VMBX09.collaborationhost.net ([10.2.8.161]) by AUSP01MHUB05.collaborationhost.net ([10.2.8.172]) with mapi; Thu, 14 Jan 2010 16:57:17 -0600 From: Wesley Leggette To: "apps-discuss@ietf.org" Date: Thu, 14 Jan 2010 16:57:16 -0600 Subject: Application protocol for distributed storage Thread-Topic: Application protocol for distributed storage Thread-Index: AcqVbOqxwns9LsEcAk6HpAbmV18PYQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010011101)] X-MAIL-FROM: X-SOURCE-IP: [(unknown)] X-AnalysisOut: [v=1.0 c=1 a=knPwKXuL5WkA:10 a=38uLcFpo6nJaFUi5eYvXHw==:17 ] X-AnalysisOut: [a=6EL--oQu468aMw3h_-AA:9 a=AftecF8DkgGDhvfmA3D65tuvZ08A:4] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 22:57:59 -0000 Hello, My company is interested in submitting an I-D for our network distributed storage protocol. At this point, we're thinking of dividing our efforts int= o multiple parts: * An on-the-wire application protocol from client to storage servers. * A security protocol. * A data processing method and storage format for client data stored on storage servers. I'm not entirely clear which working group(s) I should attempt to work with= . Any pointers would be helpful. Our application and products as a whole get into the "cloud storage" area, but we would like to focus on a smaller subset (just the network protocol) to begin with. However, if there are any working groups within IETF that focus on remote or distributed storage that would be interesting to know as well. Thanks, Wesley Leggette Cleversafe, Inc. From alexey.melnikov@isode.com Thu Jan 14 15:05:54 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8C9A3A6A08 for ; Thu, 14 Jan 2010 15:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YixADtAMM8Be for ; Thu, 14 Jan 2010 15:05:53 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 7A1043A6890 for ; Thu, 14 Jan 2010 15:05:53 -0800 (PST) Received: from [172.16.2.141] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 14 Jan 2010 23:05:49 +0000 Message-ID: <4B4FA328.3030205@isode.com> Date: Thu, 14 Jan 2010 23:05:12 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Wesley Leggette Subject: Re: Application protocol for distributed storage References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Song Haibin , "'Woundy, Richard'" , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 23:05:54 -0000 Wesley Leggette wrote: >Hello, > > Hi Wesley, >My company is interested in submitting an I-D for our network distributed >storage protocol. At this point, we're thinking of dividing our efforts into >multiple parts: > >* An on-the-wire application protocol from client to storage servers. >* A security protocol. >* A data processing method and storage format for client data stored on >storage servers. > >I'm not entirely clear which working group(s) I should attempt to work with. >Any pointers would be helpful. > > >Our application and products as a whole get into the "cloud storage" area, >but we would like to focus on a smaller subset (just the network protocol) >to begin with. However, if there are any working groups within IETF that >focus on remote or distributed storage that would be interesting to know as >well. > > This looks similar to the DECADE BOF that IETF had in Hiroshima. I am hoping this would become a WG soon. (I've CCed the BOF co-chairs). Regards, Alexey -- IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address From wleggette@cleversafe.com Thu Jan 14 20:03:35 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22AC73A6839 for ; Thu, 14 Jan 2010 20:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60Py8YVjeglj for ; Thu, 14 Jan 2010 20:03:28 -0800 (PST) Received: from p01c11o144.mxlogic.net (p01c11o144.mxlogic.net [208.65.144.67]) by core3.amsl.com (Postfix) with ESMTP id 8AD083A6869 for ; Thu, 14 Jan 2010 20:03:26 -0800 (PST) Received: from unknown [216.166.12.72] by p01c11o144.mxlogic.net(mxl_mta-6.4.0-2) with SMTP id b09ef4b4.0.30542.00-008.67618.p01c11o144.mxlogic.net (envelope-from ); Thu, 14 Jan 2010 21:03:25 -0700 (MST) X-MXL-Hash: 4b4fe90d76f4a058-870a753ceb2e8b478b79eedae203d206bd08c0ac Received: from AUSP01MHUB08.collaborationhost.net (10.2.8.243) by AUSP01MHUB50.collaborationhost.net (10.2.10.3) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 14 Jan 2010 22:02:36 -0600 Received: from AUSP01VMBX09.collaborationhost.net ([10.2.8.161]) by AUSP01MHUB08.collaborationhost.net ([10.2.8.243]) with mapi; Thu, 14 Jan 2010 22:02:36 -0600 From: Wesley Leggette To: Song Haibin , Alexey Melnikov Date: Thu, 14 Jan 2010 22:02:34 -0600 Subject: Re: Application protocol for distributed storage Thread-Topic: Application protocol for distributed storage Thread-Index: AcqVbiE7OCPdRj/vRb2EHDqL4aDIkAAJIr0QAAE5OKI= Message-ID: In-Reply-To: <001b01ca9594$b31e0d30$180ca40a@china.huawei.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010011101)] X-MAIL-FROM: X-SOURCE-IP: [(unknown)] X-AnalysisOut: [v=1.0 c=1 a=MTH7pjUJw3YA:10 a=jM3uHZP82BWpxjlUuN2t4A==:17 ] X-AnalysisOut: [a=lxMegurXAAAA:8 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8 a=APQWW] X-AnalysisOut: [o9-AAAA:8 a=-KQH23QPpn71XOgk3tIA:9 a=vau61xqyUtO3OMRnbYcA:] X-AnalysisOut: [7 a=3LG5Mhg0szsNDuX_NGmb-Yw3UpkA:4 a=ZInJwY_DxTsA:10 a=hVN] X-AnalysisOut: [Vvb_tba4A:10 a=hPjdaMEvmhQA:10 a=cat5K2ZOYqEA:10 a=lZB815d] X-AnalysisOut: [zVvQA:10 a=PgELOIaYKjrb5hYf:21 a=4PUYU-2-NHJJn8Or:21] Cc: "Woundy, Richard" , IETF Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 04:03:35 -0000 The DECADE work is interesting, but it is not specifically what we are working on. Our system, I'm sure, uses some of the same principals, but we are focusing on hosted systems. Sort of a "hosted P2P" if you will. So while our system [1] will address dynamic peer environments, it is not our main concern because our storage nodes are assumed to be available in the usual case. Instead, we are interested in using IDAs[2] to enhance availability, reliability, and security. [1] http://www.cleversafe.com/ However, DECADE does seem very interesting. There are some people in my company that may be interested in participating in that if it gets going. Wesley Leggette Cleversafe, Inc. On 1/14/10 21:41, "Song Haibin" wrote: > Hi Wesley, >=20 > I'm very glad to get this email from Alexey. The link below is about the = BOF > information at IETF 76 meeting. > http://trac.tools.ietf.org/bof/trac/wiki/decade >=20 > And we have been trying to narrow down the protocol scope to resource > control and negotiation of transport protocol as we have discussed in the > mailing list. You could read about the latest thread here: > http://www.ietf.org/mail-archive/web/decade/current/threads.html#00106. >=20 > Please let me know if it is the work that you are interested. >=20 > Xie Xie, > Haibin >=20 >=20 >> -----Original Message----- >> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] >> Sent: Friday, January 15, 2010 7:05 AM >> To: Wesley Leggette >> Cc: apps-discuss@ietf.org; 'Woundy, Richard'; Song Haibin >> Subject: Re: Application protocol for distributed storage >>=20 >> Wesley Leggette wrote: >>=20 >>> Hello, >>>=20 >>>=20 >> Hi Wesley, >>=20 >>> My company is interested in submitting an I-D for our network >>> distributed storage protocol. At this point, we're thinking >> of dividing >>> our efforts into multiple parts: >>>=20 >>> * An on-the-wire application protocol from client to storage servers. >>> * A security protocol. >>> * A data processing method and storage format for client >> data stored on >>> storage servers. >>>=20 >>> I'm not entirely clear which working group(s) I should >> attempt to work with. >>> Any pointers would be helpful. >>>=20 >>>=20 >>> Our application and products as a whole get into the "cloud storage" >>> area, but we would like to focus on a smaller subset (just >> the network >>> protocol) to begin with. However, if there are any working groups >>> within IETF that focus on remote or distributed storage that >> would be >>> interesting to know as well. >>>=20 >>>=20 >> This looks similar to the DECADE BOF that IETF had in >> Hiroshima. I am hoping this would become a WG soon. >> (I've CCed the BOF co-chairs). >>=20 >> Regards, >> Alexey >>=20 >> -- >> IETF Application Area Director, >> Internet Messaging Team Lead, >> JID: same as my email address >>=20 >>=20 >=20 >=20 From magnus.westerlund@ericsson.com Fri Jan 15 02:01:39 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF79A3A682A; Fri, 15 Jan 2010 02:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xc9XjNjHPfKs; Fri, 15 Jan 2010 02:01:39 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 745693A6816; Fri, 15 Jan 2010 02:01:35 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-e6-4b503cfb57b8 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 99.23.04178.BFC305B4; Fri, 15 Jan 2010 11:01:31 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 11:01:31 +0100 Received: from [147.214.183.147] ([147.214.183.147]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 11:01:30 +0100 Message-ID: <4B503CFA.4010107@ericsson.com> Date: Fri, 15 Jan 2010 11:01:30 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Olafur Gudmundsson Subject: Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues References: <201001111508.QAA08192@TR-Sys.de> <54E3D339-1E62-4BD1-9AA0-80F3C348724F@nokia.com> <201001141413.o0EEDBDD076210@stora.ogud.com> In-Reply-To: <201001141413.o0EEDBDD076210@stora.ogud.com> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Jan 2010 10:01:31.0000 (UTC) FILETIME=[B6200F80:01CA95C9] X-Brightmail-Tracker: AAAAAA== Cc: "apps-discuss@ietf.org" , "port-srv-reg@ietf.org" , "tsvwg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 10:01:40 -0000 Olafur Gudmundsson skrev 2010-01-14 15:13: > At 03:39 13/01/2010, Lars Eggert wrote: > >> > IMO, this basically treats SRV names as old port numbers were treated - >> > i.e., ask for a name, get ALL transports. That's how port number >> > assignments were done until recently, where now only the needed >> > transport is assigned. >> > >> > So IMO a service means something only relative to a transport. However, >> > it'd be useful to require the transport be specified only if the same >> > name would mean different things for different transports. Do we ever >> > see that happening? >> >> Right. Or, in other words, if you have a service name, it's yours for >> all transports, just as ports used to be. (There are so many service >> names that we can burn combinations that aren't used, and limit >> interactions with IANA.) >> >> Lars > > The important point is: > Each service is going to have one or more transports that are "preferred", > these preferences need to be noted in the registry. > (this point applies both to port allocations and service names). > > See section 5.1 of > http://tools.ietf.org/html/draft-gudmundsson-dnsext-srv-clarify-00 > > for proposed search order when priority order is not known. > I thought this was going to be covered in the reference that explains how the SRV is used with service X. I think that is the most appropriate place to indicate which protocols are expected to be supported and for which usages which is the most appropriate. >From the Service name registry point of view this is not needed information. However, I agree that for the user of the service name it is clearly of interest. But as I said before, it is service specific. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From aaron@serendipity.cx Fri Jan 15 05:55:10 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B4B428C0D6 for ; Fri, 15 Jan 2010 05:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qikMW0dBwDkj for ; Fri, 15 Jan 2010 05:55:09 -0800 (PST) Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by core3.amsl.com (Postfix) with ESMTP id BE28C3A6AC0 for ; Fri, 15 Jan 2010 05:55:09 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by slice.serendipity.cx (Postfix) with ESMTPSA id A9BB01100FC for ; Fri, 15 Jan 2010 05:59:45 -0800 (PST) Received: by pwi20 with SMTP id 20so298178pwi.29 for ; Fri, 15 Jan 2010 05:55:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.49.11 with SMTP id w11mr1662332waw.183.1263563705312; Fri, 15 Jan 2010 05:55:05 -0800 (PST) In-Reply-To: References: From: Aaron Stone Date: Fri, 15 Jan 2010 05:54:44 -0800 Message-ID: <1629dc8c1001150554k63795722h43f0c1b67f621329@mail.gmail.com> Subject: Re: Application protocol for distributed storage To: Wesley Leggette Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 13:55:10 -0000 On Thu, Jan 14, 2010 at 2:57 PM, Wesley Leggette wrote: > Hello, > > My company is interested in submitting an I-D for our network distributed > storage protocol. At this point, we're thinking of dividing our efforts into > multiple parts: > > * An on-the-wire application protocol from client to storage servers. > * A security protocol. > * A data processing method and storage format for client data stored on > storage servers. > > I'm not entirely clear which working group(s) I should attempt to work with. > Any pointers would be helpful. > > > Our application and products as a whole get into the "cloud storage" area, > but we would like to focus on a smaller subset (just the network protocol) > to begin with. However, if there are any working groups within IETF that > focus on remote or distributed storage that would be interesting to know as > well. Take a look at the memcached binary protocol: http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol It's binary, so not typical of IETF protocols, but it's got good extensibility and excellent client/server interop in many existing deployments, including a number of truly enormous deployments. There are some flags and reserved bits already present to indicate the type of data being stored. There are no implementations yet of any server-side data processing methods, but the bytes are there for this direction of growth. What it doesn't have is much in the way of security. There's precious little interest in this because memcached itself, as a cache, is decidedly not secured in the interest of being really really fast. That's not to say that it isn't possible to build a security mechanism, but it has to be absolutely optional to gain any traction with the memcached community. Cheers, Aaron From ogud@ogud.com Fri Jan 15 06:39:30 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C3D3A6AC1; Fri, 15 Jan 2010 06:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NuLDF3V8gTo; Fri, 15 Jan 2010 06:39:30 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 5B48D28C0F7; Fri, 15 Jan 2010 06:39:30 -0800 (PST) Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0FEdOYi085542; Fri, 15 Jan 2010 09:39:24 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <201001151439.o0FEdOYi085542@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 15 Jan 2010 09:39:02 -0500 To: Magnus Westerlund , Olafur Gudmundsson From: Olafur Gudmundsson Subject: Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues In-Reply-To: <4B503CFA.4010107@ericsson.com> References: <201001111508.QAA08192@TR-Sys.de> <54E3D339-1E62-4BD1-9AA0-80F3C348724F@nokia.com> <201001141413.o0EEDBDD076210@stora.ogud.com> <4B503CFA.4010107@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Cc: "apps-discuss@ietf.org" , "port-srv-reg@ietf.org" , "tsvwg@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 14:39:30 -0000 At 05:01 15/01/2010, Magnus Westerlund wrote: >Olafur Gudmundsson skrev 2010-01-14 15:13: > > At 03:39 13/01/2010, Lars Eggert wrote: > > > >> > IMO, this basically treats SRV names as old port numbers were treated - > >> > i.e., ask for a name, get ALL transports. That's how port number > >> > assignments were done until recently, where now only the needed > >> > transport is assigned. > >> > > >> > So IMO a service means something only relative to a transport. However, > >> > it'd be useful to require the transport be specified only if the same > >> > name would mean different things for different transports. Do we ever > >> > see that happening? > >> > >> Right. Or, in other words, if you have a service name, it's yours for > >> all transports, just as ports used to be. (There are so many service > >> names that we can burn combinations that aren't used, and limit > >> interactions with IANA.) > >> > >> Lars > > > > The important point is: > > Each service is going to have one or more transports that are "preferred", > > these preferences need to be noted in the registry. > > (this point applies both to port allocations and service names). > > > > See section 5.1 of > > http://tools.ietf.org/html/draft-gudmundsson-dnsext-srv-clarify-00 > > > > for proposed search order when priority order is not known. > > > >I thought this was going to be covered in the reference that explains >how the SRV is used with service X. I think that is the most appropriate >place to indicate which protocols are expected to be supported and for >which usages which is the most appropriate. > > >From the Service name registry point of view this is not needed >information. However, I agree that for the user of the service name it >is clearly of interest. But as I said before, it is service specific. > >Cheers > >Magnus Westerlund What Alfred and I envision (and apps people correct me if I'm wrong): The SRV update document specifies a default order of transports to use, the registry in the Notes field[1] stores transports in priority order for a service if different from default. If a service does not envision using SRV then that should be noted. The document/application for service lists the priority order when different from the default. [1] We can add a special column to the Service registry for transport list. Olafur From michelle.cotton@icann.org Fri Jan 15 08:12:33 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B9B3A6B0C; Fri, 15 Jan 2010 08:12:33 -0800 (PST) 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.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBr6-vyEJAM6; Fri, 15 Jan 2010 08:12:33 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 18A403A6B08; Fri, 15 Jan 2010 08:12:33 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Fri, 15 Jan 2010 08:12:30 -0800 From: Michelle Cotton To: "apps-discuss@ietf.org" , "dnsop@ietf.org" , "tsvwg@ietf.org" Date: Fri, 15 Jan 2010 08:16:01 -0800 Subject: New version of document for review Thread-Topic: New version of document for review Thread-Index: AcqV/gdJ7RnGH+msSkqdlFrKEw4FTQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C775D4C11F7D2michellecottonicannorg_" MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 16:12:33 -0000 --_000_C775D4C11F7D2michellecottonicannorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Attn: TSVWG Working Group, DNSOPS Working Group and APPS AREA Working Group There is a new version of the Internet Assigned Numbers Authority (IANA) Pr= ocedures for the Management of the Transport Protocol Port Number and Service Name Registry document: draft-ietf-tsvwg-iana-ports-04.txt Please review and send comments. Your feedback is much appreciated. Thank you, Michelle Cotton (on behalf of the ports teams) --_000_C775D4C11F7D2michellecottonicannorg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New version of document for review Attn: TSVWG Working Group, DNSOPS Working Group and APPS AREA Working= Group

There is a new version of the
Internet Assigned Numb= ers Authority (IANA) Procedures for the Management
of the Transport Protocol Port Number and Service Name Registry document:

draft-ietf-tsvwg-iana-ports-04.txt

Please review and send comments.  Your feedback is much appreciated.
Thank you,

Michelle Cotton
(on behalf of the ports teams)

--_000_C775D4C11F7D2michellecottonicannorg_-- From melodysong@huawei.com Thu Jan 14 19:42:21 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6763A6A1B for ; Thu, 14 Jan 2010 19:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xErPpvOPHidj for ; Thu, 14 Jan 2010 19:42:20 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3B1233A68C7 for ; Thu, 14 Jan 2010 19:42:20 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KW9008BVRM68A@szxga03-in.huawei.com> for apps-discuss@ietf.org; Fri, 15 Jan 2010 11:42:07 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KW9009NVRM64Z@szxga03-in.huawei.com> for apps-discuss@ietf.org; Fri, 15 Jan 2010 11:42:06 +0800 (CST) Received: from s64081a ([10.164.12.24]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KW900GFERLYNO@szxml04-in.huawei.com> for apps-discuss@ietf.org; Fri, 15 Jan 2010 11:42:06 +0800 (CST) Date: Fri, 15 Jan 2010 11:41:57 +0800 From: Song Haibin Subject: RE: Application protocol for distributed storage In-reply-to: <4B4FA328.3030205@isode.com> To: 'Alexey Melnikov' , 'Wesley Leggette' Message-id: <001b01ca9594$b31e0d30$180ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcqVbiE7OCPdRj/vRb2EHDqL4aDIkAAJIr0Q X-Mailman-Approved-At: Fri, 15 Jan 2010 08:30:38 -0800 Cc: "'Woundy, Richard'" , apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 03:42:21 -0000 Hi Wesley, I'm very glad to get this email from Alexey. The link below is about the BOF information at IETF 76 meeting. http://trac.tools.ietf.org/bof/trac/wiki/decade And we have been trying to narrow down the protocol scope to resource control and negotiation of transport protocol as we have discussed in the mailing list. You could read about the latest thread here: http://www.ietf.org/mail-archive/web/decade/current/threads.html#00106. Please let me know if it is the work that you are interested. Xie Xie, Haibin > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Sent: Friday, January 15, 2010 7:05 AM > To: Wesley Leggette > Cc: apps-discuss@ietf.org; 'Woundy, Richard'; Song Haibin > Subject: Re: Application protocol for distributed storage > > Wesley Leggette wrote: > > >Hello, > > > > > Hi Wesley, > > >My company is interested in submitting an I-D for our network > >distributed storage protocol. At this point, we're thinking > of dividing > >our efforts into multiple parts: > > > >* An on-the-wire application protocol from client to storage servers. > >* A security protocol. > >* A data processing method and storage format for client > data stored on > >storage servers. > > > >I'm not entirely clear which working group(s) I should > attempt to work with. > >Any pointers would be helpful. > > > > > >Our application and products as a whole get into the "cloud storage" > >area, but we would like to focus on a smaller subset (just > the network > >protocol) to begin with. However, if there are any working groups > >within IETF that focus on remote or distributed storage that > would be > >interesting to know as well. > > > > > This looks similar to the DECADE BOF that IETF had in > Hiroshima. I am hoping this would become a WG soon. > (I've CCed the BOF co-chairs). > > Regards, > Alexey > > -- > IETF Application Area Director, > Internet Messaging Team Lead, > JID: same as my email address > > From A.Hoenes@TR-Sys.de Fri Jan 15 10:41:04 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752A63A67AF; Fri, 15 Jan 2010 10:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwVljKIYx4AW; Fri, 15 Jan 2010 10:41:02 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 42F5D3A67EE; Fri, 15 Jan 2010 10:41:00 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA188320842; Fri, 15 Jan 2010 19:40:42 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA14644; Fri, 15 Jan 2010 19:40:39 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201001151840.TAA14644@TR-Sys.de> Subject: Re: [tsvwg] [port-srv-reg] "assigned" ( vs. "registered"), and relates issues To: touch@isi.edu, magnus.westerlund@ericsson.com Date: Fri, 15 Jan 2010 19:40:39 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: tsvwg@ietf.org, apps-discuss@ietf.org, port-srv-reg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 18:41:04 -0000 Replying to Joe and Magnus at once: Magnus Westerlund wrote: > I thought this was going to be covered in the reference that explains > how the SRV is used with service X. I think that is the most appropriate > place to indicate which protocols are expected to be supported and for > which usages which is the most appropriate. The registry serves to compile the information on services in a concise form useful for many audiences. You cannot defer the task of information extraction from the basic application-specific documents to each and every user of the registry. Of course, the many details and nuances will be in the specs. But following the same argument, oh, we would arrive at: "The default port number assigned to a service are specified in the specification document(s) of the application, so the port numbers and supported protocols need not be listed either in the registry, it suffices to point to the references there. You are encouraged to collect yourself the information you need." :-) Our document (draft-gudmundsson-dnsext-srv-clarify) is based on {service name, transport protocol} pairs registered in the subject registry. If we cannot draw the information about transport protocols supported by a service from the Service Names and Port Numbers registry, we would be back at the need for an independent, specific SRV Service Prefix registry, which you wanted to trade in, in favor of improved content in your registry. > > From the Service name registry point of view this is not needed > information. However, I agree that for the user of the service name it > is clearly of interest. But as I said before, it is service specific. I do not see the point. You have come to the conclusion that for the purpose of the registry, the transport protocol matters (as before), and that new applications shall not be registered automatically for all such protocols -- the set of which might well grow in the future --, and listing improper, unsupported {protocol, port number} pairs for any service is confusing, and in effect detrimental to the purpose of a registry. So where's the difference between an application with a default port number assigned by IANA and/or port numbers assigned locally? What matters in any case is that, whether or not you use default port numbers, users of the registry list want a one-stop shop for the most important information. And this is always the {service, protocol} pair, with (default) port numbers drawn from the registry and/or acquired from local information. It it important that such local information is taken into account if and only if applicable, to avoid overhead at all levels. The presentation of precise basic information in the registry should be the fundament for making decisions on whether local information is to be taken into account, in the 'canonical' case; of cause, exceptions will exist, but to a much more manageable extent. The application context must know which protocols are supported, and clients should not be misled to make definitely useless DNS lookups if either SRV support is not specified altogether, or information can only be expected reasonably for specific transports of a service. For instance, a firewall admin can take the default port numbers from the registry where assigned, but he must be made aware of the support for local service port assignment and dynamic service discovery in order to acquire the relevant information. If the unified registry pretends service discovery support for all services (by not tagging its applicability), these folks must resort again to private lists. Do you really want that? Or do you expect them to look at the thousands of references in the registry (I hope there will be!) to make the determination? Joe Touch wrote: [[ reordering a bit for clarity ]] >>[AH] ... >> To repeat: Not having the proper protocol name associated with the >> Service Name -- independent of whether or not there is an assigned >> (default) port number -- would make the registry useless for those >> who want to make use of it to determine which Service Prefixes >> should be admitted in DNS zones routinely. > > Can you clarify what this means? I.e., does this mean you WANT to > specify the valid protocols for each service name? > > JOE-NAME TCP Yes, of course, but with the appropriate reference for each entry! The registry should serve as a repository of what has been specified, in order to be useful, isn't it? Each entry has to be meaningful, or else it will be subject to elimination in the garbage collection passes you plan to be performed on the registry periodically. The assignment of a default port number to a service and its subsequent presentation in the registry is entirely orthogonal to the set of supported transport protocols. And equally, the support of dynamic service discovery is orthogonal to the set of protocols, and in principle, on whether or not a default port is assigned -- evidently, the combination of "no default port" and "no service discovery" is special, it should be used for reserved names (placeholders) and deprecated entries being phased out only. > > If so, why is this necessary? See above. For the same reasons that you describe in tsvwg-ian-ports for the case where a default port number for a service is assigned. You want to indicate a firewall admin to not open a hole for JOE-NAME/sctp unless that's defined, and service discovery folks should be pointed to what service prefixes should be admitted routinely if requested. And, besides, applying the same rules in an orthogonal manner should make registry operations more regular and consistent. The only difference between a request to IANA that seeks for a registration without assignment of a default port number and applying for a default port number as well should be to say so in the latter case, but leaving the port number item empty in the registration template in the former case. That should not change any other rules. Note that DCCP Service Code assignment is also independent from and orthogonal to default port number assignment. > ... > > It's an issue as to whether you would register an SRV name: > > JOE-NAME > > or > JOE-NAME TCP > JOE-NAME UDP > > I have no idea why you would want to do the latter, except to > know that if you got "_JOE-NAME._DCCP" in an SRV it must be an > error. > > ... Exactly; and for DCCP, you would need a Service code entry, independent of whether or not you have an assigned default port#. I do not have an idea why that is questionable. I guess, after all your strong opposition against draft-gudmundsson-dns-srv-iana-registry-04, that you had studied that draft, and that you now have read draft-gudmundsson-dnsext-srv-clarify-00. We have not received comments from you so far indicating that something there was unclear, ambiguous, or underspecified. If it is in your opinion, please speak. I recall: The assumption that any service making use of DNS SRV based service discovery must have the appropriate transport protocols registered with the service name if such registry shall make sense at all, has never been challenged before, it was self-evident. Let's study a concrete multi-stage example, following my expectation on reasonable and useful registry content and behavior. The current Port Numbers registry contains the selected entries: ----snip---- smtp 25/tcp Simple Mail Transfer smtp 25/udp Simple Mail Transfer # Jon Postel # submission 587/tcp Submission submission 587/udp Submission # [RFC4409] # pop3 110/tcp Post Office Protocol - Version 3 pop3 110/udp Post Office Protocol - Version 3 # Marshall Rose # pop3s 995/tcp pop3 protocol over TLS/SSL (was spop3) pop3s 995/udp pop3 protocol over TLS/SSL (was spop3) # Gordon Mangione # imap 143/tcp Internet Message Access Protocol imap 143/udp Internet Message Access Protocol # Mark Crispin # imaps 993/tcp imap4 protocol over TLS/SSL imaps 993/udp imap4 protocol over TLS/SSL ----snip---- After the installation of the Service Names and Port Numbers registry, I expect to see something like shown below (note the deletion of nonsensical UDP transport and the inclusion of useful references, and the import that you plan of 'mail' from the RFC 952 / WKS registry): ----snip---- smtp 25/tcp Simple Mail Transfer [RFC5321] mail 25/tcp legacy alias for SMTP -- DEPRECATED # # from legacy database # submission 587/tcp Message Submission [RFC4409] # pop3 110/tcp Post Office Protocol - Version 3 [RFC1939] # pop3s 995/tcp POP3 protocol over TLS [RFC1939],[RFC2592] # imap 143/tcp Internet Message Access Protocol [RFC3501] # imaps 993/tcp IMAP4 protocol over TLS [RFC3501],[RFC2592] ----snip---- Some time in the future, the following entries might be added by an Experimental RFC "IMAPv4 Multi-Stream Operation over SCTP", say RFC uuuu: ----snip---- imap 143/sctp Internet Message Access Protocol [RFCuuuu] # imaps 993/sctp IMAP4 protocol over TLS [RFCuuuu] # ----snip---- After the approval for publication and IANA processing of draft-daboo-srv-email (that adds, among other things, port agility in support of multiple server instances per host at an ISP) as say, RFC ssss, the above registry entries get amended as follows (assuming, as an exercise, no IMAP SCTP support added yet because that's Experimental and/or the authors have not been aware of that variant) and, assuming the currently discussed "umbrella service", 'email' gets accepted, a new entry. Also assume the 'mail' Service Name has been subject to registry maintenance action to phase it out. ----snip---- smtp 25/tcp * Simple Mail Transfer [RFC5321], # [RFCssss]* mail legacy alias for SMTP -- DEPRECATED # # from legacy database # submission 587/tcp * Message Submission [RFC4409], # [RFCssss]* pop3 110/tcp * Post Office Protocol - Version 3 [RFC1939], # [RFCssss]* pop3s 995/tcp * POP3 protocol over TLS [RFC1939],[RFC2592], # [RFCssss]* imap 143/tcp * Internet Message Access Protocol [RFC3501], # [RFCssss]* imap 143/sctp Internet Message Access Protocol [RFCuuuu] # imaps 993/tcp * IMAP4 protocol over TLS [RFC3501],[RFC2592] # [RFCssss]* imaps 993/sctp IMAP4 protocol over TLS [RFCuuuu] # email tcp * email umbrella service [RFCssss]* ... ... Footnote: (*) indicates support for dynamic service discovery via DNS SRV, see [RFC2782] and [RFC-srv-clarify], and the references specifying its use. ----snip---- Later on, say RFC vvvv is the Standards Track version successor of (the then obsoleted) RFC uuuu, and it at the same time specifies service discovery for multi-thread IMAP4 over SCTP, the following result will be obtained: ----snip---- smtp 25/tcp * Simple Mail Transfer [RFC5321], # [RFCssss]* submission 587/tcp * Message Submission [RFC4409], # [RFCssss]* pop3 110/tcp * Post Office Protocol - Version 3 [RFC1939], # [RFCssss]* pop3s 995/tcp * POP3 protocol over TLS [RFC1939],[RFC2592], # [RFCssss]* imap 143/tcp * Internet Message Access Protocol [RFC3501], # [RFCssss]* imap 143/sctp* Internet Message Access Protocol [RFCvvvv]* # imaps 993/tcp * IMAP4 protocol over TLS [RFC3501],[RFC2592] # [RFCssss]* imaps 993/sctp* IMAP4 protocol over TLS [RFCvvvv]* # email tcp * email umbrella service [RFCssss]* email sctp* email umbrella service [RFCvvvv]* ... ... Footnote: [... <> ...] ----snip---- To formalize the concept, let me try a strawman abstract pseudocode data type model description of the registry content: srvport-reg SEQUENCE OF srvport-entry, PRIMARY-INDEX srvport-entry.service-name, ALTERNATE-INDEX SEQUENCE { srvport-entry.default-port; srvport-entry.service-name; }; srvport-entry SEQUENCE { service-name name-label; default-port UINT16; /* 0 means None */ description STRING OPTIONAL; registrant reg-clerical; status reg-status; tcp-entry protocol-info{tcp} OPTIONAL; udp-entry protocol-info{udp} OPTIONAL; dccp-entry SEQUENCE { common-entry protocol-info{dccp}; service-code DccpSrvCode_type; } OPTIONAL; sctp-entry protocol-info{sctp} OPTIONAL; ... /* extensible for future protocols */ }; protocol-info(&&proto) SEQUENCE { protocol protocol-type ::= &&proto; for-srv srv-flag; description STRING DEFAULT srvport_entry.description; /* inherited from entry by default */ note STRING; status reg-status DEFAULT srvport-entry.reg-status; /* inherited from entry by default */ refs SEQUENCE of ref-entry; }; ref-entry SEQUENCE { ref-anchor anchor-type; for-srv srv-flag; } name-label Case-Insensitive-STRING[15]; protocol-type ENUM { tcp(6), udp(17), dccp(33), sctp(132) }; DccpSrvCode_type ... ; srv-flag BOOLEAN; /* TRUE for service discovery */ reg-clerical ... ; /* add administrative details, timestamp for entry, by whom, last change stamp, by whom, or whole history of the entry including pointers to archived documents */ anchor-type ... ; /* pointer to bibliographic entry or registrant email address */ Kind regards, Alfred Hnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From richard_woundy@cable.comcast.com Fri Jan 15 14:20:19 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34413A68FA for ; Fri, 15 Jan 2010 14:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.163 X-Spam-Level: X-Spam-Status: No, score=-8.163 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klSgtxOnpbW0 for ; Fri, 15 Jan 2010 14:20:18 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 007EF3A68AE for ; Fri, 15 Jan 2010 14:20:17 -0800 (PST) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.67930508; Fri, 15 Jan 2010 17:20:08 -0500 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 17:20:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Application protocol for distributed storage Date: Fri, 15 Jan 2010 17:20:07 -0500 Message-ID: <8A82D1BFEDDE7E4597978355239BBBCBB58858@PACDCEXCMB06.cable.comcast.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Application protocol for distributed storage Thread-Index: AcqVbiE7OCPdRj/vRb2EHDqL4aDIkAAJIr0QAAE5OKIAJU1FwA== References: <001b01ca9594$b31e0d30$180ca40a@china.huawei.com> From: "Woundy, Richard" To: "Wesley Leggette" , "Song Haibin" , "Alexey Melnikov" X-OriginalArrivalTime: 15 Jan 2010 22:20:09.0067 (UTC) FILETIME=[E5C06BB0:01CA9630] X-Mailman-Approved-At: Fri, 15 Jan 2010 14:46:33 -0800 Cc: "Woundy, Richard" , IETF Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 22:20:19 -0000 Wesley, >Instead, we are interested in using IDAs[2] You didn't supply a reference for IDAs, but I suspect this is what you meant: . It seems that you are storing slices of data across distributed storage locations, (1) to maximize storage efficiency and (2) to minimize data exposure if one or more storage servers are compromised. If so, I agree you do seem to be trying to solve a slightly different problem than Decade's. At the same time, there is some potential areas of commonality, particular in the case of data control and transport protocols. >From : "If your application is housing your metadata, and only object storage is required, the Simple Object interface can be accessed with either a Java SDK, or HTTP/REST API. Simple PUT, GET, DELETE commands allow your applications to access digital content, and the resulting object ID is stored directly within the application." From : "dsNet systems can be accessed in numerous ways. Today we offer iSCSI and a straight block interface, soon to come releases support FTP, NFS, CIFS (SMB) and webDAV, making your data universally accessible to any application you might conceive for it. Our authentication systems are also pluggable through PAM (Pluggable Authentication Modules)." Since your company already sells a product, I am curious about which interoperability problems you are trying to solve (or avoid) by posting your internet-drafts. Are you enabling any third-party client to leverage your cloud storage? Could other cloud storage vendors leverage the same network protocols? Are there any patents that the IETF should be aware of, e.g. ? -- Rich -----Original Message----- From: Wesley Leggette [mailto:wleggette@cleversafe.com]=20 Sent: Thursday, January 14, 2010 11:03 PM To: Song Haibin; Alexey Melnikov Cc: IETF Apps Discuss; Woundy, Richard Subject: Re: Application protocol for distributed storage The DECADE work is interesting, but it is not specifically what we are working on. Our system, I'm sure, uses some of the same principals, but we are focusing on hosted systems. Sort of a "hosted P2P" if you will. So while our system [1] will address dynamic peer environments, it is not our main concern because our storage nodes are assumed to be available in the usual case. Instead, we are interested in using IDAs[2] to enhance availability, reliability, and security. [1] http://www.cleversafe.com/ However, DECADE does seem very interesting. There are some people in my company that may be interested in participating in that if it gets going. Wesley Leggette Cleversafe, Inc. On 1/14/10 21:41, "Song Haibin" wrote: > Hi Wesley, >=20 > I'm very glad to get this email from Alexey. The link below is about the BOF > information at IETF 76 meeting. > http://trac.tools.ietf.org/bof/trac/wiki/decade >=20 > And we have been trying to narrow down the protocol scope to resource > control and negotiation of transport protocol as we have discussed in the > mailing list. You could read about the latest thread here: > http://www.ietf.org/mail-archive/web/decade/current/threads.html#00106. >=20 > Please let me know if it is the work that you are interested. >=20 > Xie Xie, > Haibin >=20 >=20 >> -----Original Message----- >> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] >> Sent: Friday, January 15, 2010 7:05 AM >> To: Wesley Leggette >> Cc: apps-discuss@ietf.org; 'Woundy, Richard'; Song Haibin >> Subject: Re: Application protocol for distributed storage >>=20 >> Wesley Leggette wrote: >>=20 >>> Hello, >>>=20 >>>=20 >> Hi Wesley, >>=20 >>> My company is interested in submitting an I-D for our network >>> distributed storage protocol. At this point, we're thinking >> of dividing >>> our efforts into multiple parts: >>>=20 >>> * An on-the-wire application protocol from client to storage servers. >>> * A security protocol. >>> * A data processing method and storage format for client >> data stored on >>> storage servers. >>>=20 >>> I'm not entirely clear which working group(s) I should >> attempt to work with. >>> Any pointers would be helpful. >>>=20 >>>=20 >>> Our application and products as a whole get into the "cloud storage" >>> area, but we would like to focus on a smaller subset (just >> the network >>> protocol) to begin with. However, if there are any working groups >>> within IETF that focus on remote or distributed storage that >> would be >>> interesting to know as well. >>>=20 >>>=20 >> This looks similar to the DECADE BOF that IETF had in >> Hiroshima. I am hoping this would become a WG soon. >> (I've CCed the BOF co-chairs). >>=20 >> Regards, >> Alexey >>=20 >> -- >> IETF Application Area Director, >> Internet Messaging Team Lead, >> JID: same as my email address >>=20 >>=20 >=20 >=20 From wleggette@cleversafe.com Fri Jan 15 15:30:00 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EC413A6959 for ; Fri, 15 Jan 2010 15:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjJ8HlIwXjtN for ; Fri, 15 Jan 2010 15:29:59 -0800 (PST) Received: from p01c11o143.mxlogic.net (p01c11o143.mxlogic.net [208.65.144.66]) by core3.amsl.com (Postfix) with ESMTP id 9AACB3A6898 for ; Fri, 15 Jan 2010 15:29:59 -0800 (PST) Received: from unknown [216.166.12.178] (EHLO p01c11o143.mxlogic.net) by p01c11o143.mxlogic.net(mxl_mta-6.4.0-2) with ESMTP id 57af05b4.afab8b90.20200.00-402.50726.p01c11o143.mxlogic.net (envelope-from ); Fri, 15 Jan 2010 16:29:57 -0700 (MST) X-MXL-Hash: 4b50fa75710bb9ae-575d5141f2491908d2bdd79c310ad751eb2bfed1 Received: from unknown [216.166.12.178] by p01c11o143.mxlogic.net(mxl_mta-6.4.0-2) with SMTP id 74af05b4.0.19786.00-015.50573.p01c11o143.mxlogic.net (envelope-from ); Fri, 15 Jan 2010 16:29:12 -0700 (MST) X-MXL-Hash: 4b50fa487f1459a1-df3ff9b4b75b82e8b720926074e05e1ba2470790 Received: from AUSP01VMBX09.collaborationhost.net ([10.2.8.161]) by AUSP01MHUB04.collaborationhost.net ([10.2.0.189]) with mapi; Fri, 15 Jan 2010 17:28:49 -0600 From: Wesley Leggette To: "Woundy, Richard" , Song Haibin , Alexey Melnikov Date: Fri, 15 Jan 2010 17:28:46 -0600 Subject: Re: Application protocol for distributed storage Thread-Topic: Application protocol for distributed storage Thread-Index: AcqVbiE7OCPdRj/vRb2EHDqL4aDIkAAJIr0QAAE5OKIAJU1FwAADbV9N Message-ID: In-Reply-To: <8A82D1BFEDDE7E4597978355239BBBCBB58858@PACDCEXCMB06.cable.comcast.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010011101)] X-MAIL-FROM: X-SOURCE-IP: [216.166.12.178] X-AnalysisOut: [v=1.0 c=1 a=MTH7pjUJw3YA:10 a=N0rcUYRaQg3G+2kUXxmxxA==:17 ] X-AnalysisOut: [a=1XWaLZrsAAAA:8 a=XG-gC1jSuKMWvT8tolUA:9 a=odjqluwSjd3LzR] X-AnalysisOut: [4NRA6G-HTpL1QA:4] Cc: IETF Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 23:30:00 -0000 >=20 > Since your company already sells a product, I am curious about which > interoperability problems you are trying to solve (or avoid) by posting > your internet-drafts. Are you enabling any third-party client to > leverage your cloud storage? Could other cloud storage vendors leverage > the same network protocols? Yes, our ultimate goal is to allow any third-party client to leverage our storage product. As the cloud storage market is fairly new and very fragmented, we feel it would be beneficial to at least get something out there for discussion. While we wouldn't be so bold as to assume everybody will just implement our protocol, we feel it has many advantages and want to make it possible for others to leverage it. Further, we are not completely opposed to making changes to our protocol an= d products, but what I'm getting from these exchanges is that the first step is to publish what we have and then to see what interest there is from that= . >=20 > Are there any patents that the IETF should be aware of, e.g. > ? There are several patents that we will have to disclose. I am vaguely familiar with the IETF IPR rules, but I will have to fully familiarize myself with them before saying more. Wesley Leggette Cleversafe, Inc. From Nicolas.Williams@sun.com Fri Jan 15 15:59:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567B93A6844 for ; Fri, 15 Jan 2010 15:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.025 X-Spam-Level: X-Spam-Status: No, score=-6.025 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqbNGPzhdUHF for ; Fri, 15 Jan 2010 15:59:27 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 43C2D3A6405 for ; Fri, 15 Jan 2010 15:59:27 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o0FNxOCp020854 for ; Fri, 15 Jan 2010 23:59:24 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id o0FNxNl3056644 for ; Fri, 15 Jan 2010 16:59:23 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o0FNiOWC009170; Fri, 15 Jan 2010 17:44:24 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o0FNiNBQ009169; Fri, 15 Jan 2010 17:44:23 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 15 Jan 2010 17:44:23 -0600 From: Nicolas Williams To: Aaron Stone Subject: Re: Application protocol for distributed storage Message-ID: <20100115234422.GM1061@Sun.COM> References: <1629dc8c1001150554k63795722h43f0c1b67f621329@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1629dc8c1001150554k63795722h43f0c1b67f621329@mail.gmail.com> User-Agent: Mutt/1.5.7i Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 23:59:28 -0000 On Fri, Jan 15, 2010 at 05:54:44AM -0800, Aaron Stone wrote: > Take a look at the memcached binary protocol: > http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol > > It's binary, so not typical of IETF protocols, but it's got good > extensibility and excellent client/server interop in many existing > deployments, including a number of truly enormous deployments. Whoa. I can think of a large number of "binary" Internet protocols, at every layer in the stack (not including layers 8 and 9 :) that the IETF has protocols for. E.g., - SSHv2, TLS, NFS, iSCSI, ... - DNS, LDAP, ... - Kerberos, PKIX, ... - TCP, UDP, SCTP - IP itself (v4 and v6) Many encoding schemes are used, from custom schemes (e.g., in SSHv2), bits-on-the-wire (e.g., IP), line-oriented text with escapes (e.g., HTTP), XDR (NFS), various ASN.1 encoding rules (mostly BER and CER), XML, etcetera. Yes, we also have net-ascii-type protocols (HTTP, FTP, IMAP, ...). I suspect those are actually in the minority, though some are so widely used and so notable that one might think that net-ascii is the rule -- it just isn't. Nico -- From john-ietf@jck.com Sat Jan 16 06:31:31 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B886B3A6908 for ; Sat, 16 Jan 2010 06:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDs-m30sLNcD for ; Sat, 16 Jan 2010 06:31:31 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 9BEF73A687B for ; Sat, 16 Jan 2010 06:31:30 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1NW9gQ-000PpE-6k; Sat, 16 Jan 2010 09:31:22 -0500 Date: Sat, 16 Jan 2010 09:31:20 -0500 From: John C Klensin To: Wesley Leggette Subject: Re: Application protocol for distributed storage Message-ID: <4C1F08AD46704B49C435ED75@PST.JCK.COM> In-Reply-To: References: 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: "Woundy, Richard" , IETF Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 14:31:31 -0000 --On Friday, January 15, 2010 17:28 -0600 Wesley Leggette wrote: >... > Yes, our ultimate goal is to allow any third-party client to > leverage our storage product. As the cloud storage market is > fairly new and very fragmented, we feel it would be beneficial > to at least get something out there for discussion. > > While we wouldn't be so bold as to assume everybody will just > implement our protocol, we feel it has many advantages and > want to make it possible for others to leverage it. > > Further, we are not completely opposed to making changes to > our protocol and products, but what I'm getting from these > exchanges is that the first step is to publish what we have > and then to see what interest there is from that. > >> Are there any patents that the IETF should be aware of, e.g. >> ? > > There are several patents that we will have to disclose. I am > vaguely familiar with the IETF IPR rules, but I will have to > fully familiarize myself with them before saying more. Wesley, Speaking only for myself, but with the perspective of some years in the IETF community... Yes, you should put your ideas into an Internet Draft and get it posted. We are all better off talking about a description of something, ideally a description that would be good enough to build interoperable implementations from, than with a description of a description and the need to do detective work on your web site, even though Richard has done an impressive (to me) job of that. But --and, again, this is just personal opinion-- I think you will not get very far in convincing the IETF to evaluate, publish, or adopt you work unless at least one, and preferably both, of the following conditions are met: (i) Your document shows a clear awareness of the alternatives that are already out there and critically describes the relative strengths and weaknesses of your approach for the applications you think relevant. (ii) At least implementation of a client, and ideally implementation of alternate servers, should not require any sort of complex and/or expensive licensing. When established and deployed alternatives exist, the IETF is only very rarely willing to invest energy in a new protocol whose main value seems to be to improve one company's profitability and, correctly or not, IPR encumbrances and licensing requirements are often interpreted that way. regards, john From eburger@standardstrack.com Sun Jan 17 08:59:45 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5093A67FB for ; Sun, 17 Jan 2010 08:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXLkyrQgz1h2 for ; Sun, 17 Jan 2010 08:59:45 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 19CDB3A67AA for ; Sun, 17 Jan 2010 08:59:45 -0800 (PST) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.199]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1NWYTS-0004hI-QW; Sun, 17 Jan 2010 08:59:39 -0800 Message-Id: From: Eric Burger To: Wesley Leggette In-Reply-To: <4C1F08AD46704B49C435ED75@PST.JCK.COM> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Application protocol for distributed storage Date: Sun, 17 Jan 2010 11:59:34 -0500 References: <4C1F08AD46704B49C435ED75@PST.JCK.COM> X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: IETF Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 16:59:46 -0000 To jck's point, see, e.g., . If the purpose of your IPR is to protect people who implement the IPR, royalty free, life is going to be good. There are bad people out there that might try to assert IPR against an open standard. A filing like MSCML protects 3rd-parties from such assertions. In this case, you will be seen as a good guy. However, if the purpose of your IPR is to get royalties or to block competitive services that fully implement the IETF (hopefully your stuff gets that far), then the community will probably not even start work or, worse yet, will start work and then excoriate you as well as CleverSafe. You would get put into the Very Bad Guy doghouse. P.S., say hi to Chris G. for me. -- - Eric On Jan 16, 2010, at 9:31 AM, John C Klensin wrote: > > > --On Friday, January 15, 2010 17:28 -0600 Wesley Leggette > wrote: > >> ... >> Yes, our ultimate goal is to allow any third-party client to >> leverage our storage product. As the cloud storage market is >> fairly new and very fragmented, we feel it would be beneficial >> to at least get something out there for discussion. >> >> While we wouldn't be so bold as to assume everybody will just >> implement our protocol, we feel it has many advantages and >> want to make it possible for others to leverage it. >> >> Further, we are not completely opposed to making changes to >> our protocol and products, but what I'm getting from these >> exchanges is that the first step is to publish what we have >> and then to see what interest there is from that. >> >>> Are there any patents that the IETF should be aware of, e.g. >>> ? >> >> There are several patents that we will have to disclose. I am >> vaguely familiar with the IETF IPR rules, but I will have to >> fully familiarize myself with them before saying more. > > Wesley, > > Speaking only for myself, but with the perspective of some years > in the IETF community... > > Yes, you should put your ideas into an Internet Draft and get it > posted. We are all better off talking about a description of > something, ideally a description that would be good enough to > build interoperable implementations from, than with a > description of a description and the need to do detective work > on your web site, even though Richard has done an impressive (to > me) job of that. > > But --and, again, this is just personal opinion-- I think you > will not get very far in convincing the IETF to evaluate, > publish, or adopt you work unless at least one, and preferably > both, of the following conditions are met: > > (i) Your document shows a clear awareness of the > alternatives that are already out there and critically > describes the relative strengths and weaknesses of your > approach for the applications you think relevant. > > (ii) At least implementation of a client, and ideally > implementation of alternate servers, should not require > any sort of complex and/or expensive licensing. When > established and deployed alternatives exist, the IETF is > only very rarely willing to invest energy in a new > protocol whose main value seems to be to improve one > company's profitability and, correctly or not, IPR > encumbrances and licensing requirements are often > interpreted that way. > > regards, > john > > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From magnus.westerlund@ericsson.com Mon Jan 18 04:14:21 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE043A6921; Mon, 18 Jan 2010 04:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GXHIYWhKuOB; Mon, 18 Jan 2010 04:14:20 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id A94753A6767; Mon, 18 Jan 2010 04:14:19 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-f0-4b54509745c0 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id EE.BC.04178.790545B4; Mon, 18 Jan 2010 13:14:15 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 13:14:14 +0100 Received: from [147.214.183.147] ([147.214.183.147]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 13:14:14 +0100 Message-ID: <4B545096.4020300@ericsson.com> Date: Mon, 18 Jan 2010 13:14:14 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= Subject: Re: [tsvwg] [port-srv-reg] "assigned" ( vs. "registered"), and relates issues References: <201001151840.TAA14644@TR-Sys.de> In-Reply-To: <201001151840.TAA14644@TR-Sys.de> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 18 Jan 2010 12:14:14.0775 (UTC) FILETIME=[C024F070:01CA9837] X-Brightmail-Tracker: AAAAAA== Cc: port-srv-reg@ietf.org, tsvwg@ietf.org, apps-discuss@ietf.org, touch@isi.edu X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 12:14:21 -0000 Hi Alfred, I have now read draft-gudmundsson-dnsext-srv-clarify-00 again. Me personally hasn't really digged into the issues that you bring up in your document, I don't think I am alone in this. Thus, I think it would be jumping to conclusions that there are agreement on your suggested approach simple because you haven't received comments on them yet. >From the perspective of trying to advance draft-ietf-tsvwg-iana-ports, we do come down to trying to find the reasonable interface between our documents. On the issue of the protocol label for a given service name. I find it reasonable that your document do extended the registry with an additional column that enumerates any non-default protocol label order. I get the impression that you want this to be described in draft-ietf-tsvwg-iana-ports due to that it should be included in any service name registration request. I had hoped that we could avoid normative dependencies from IANA ports towards draft-gudmundsson-dnsext-srv-clarify. This to enable draft-ietf-tsvwg-iana-ports to be approved and published as soon as possible. >From my perspective I see three ways forward: 1. We write nothing about the protocol label in regards to Service name registrations and lets draft-gudmundsson-dnsext-srv-clarify update the Registration RFC. 2. We include some text about the need to specify protocol label priority list unless the default one (also included listed in draft-ietf-tsvwg-iana-ports) but pushing of the explanation about the issues to your document using a normative reference. 3. We fudge something together in the middle trying to avoid a normative reference. I think I am leaning towards 1 personally even if it has some obvious downside in that the registration rules information will not be contained to a single document. However, I think IANA's registration template can clearly make it clear to applicants that you need to read things in both. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From mnot@mnot.net Mon Jan 18 20:15:41 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69733A6A48 for ; Mon, 18 Jan 2010 20:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=-2.667, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5Q1ydHqv+SK for ; Mon, 18 Jan 2010 20:15:40 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 9873D3A67E4 for ; Mon, 18 Jan 2010 20:15:40 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.153.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A4F20509DC; Mon, 18 Jan 2010 23:15:29 -0500 (EST) Subject: Re: draft-nottingham-http-link-relation-07 progress Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343787E67BFA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 19 Jan 2010 15:15:26 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <609386AF-6A84-44CC-86AD-6B9BEC5F00A0@mnot.net> References: <5FFC5BD4-0CC6-4168-B91D-5D26E1402DC1@mnot.net> <4B1BF8FA.2080201@gmx.de> <78E6189B-66D1-4E38-9F89-31E33ACECD55@mnot.net> <90C41DD21FB7C64BB94121FBBC2E72343787C35074@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343787E67BFA@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 04:15:41 -0000 I generally agree with all of this, and think it can mostly be derived = from the spec + current practice + web architecture, so I think we're = OK. On 30/12/2009, at 5:43 PM, Eran Hammer-Lahav wrote: > I like this. This is where I think we are: >=20 > -- Use a URI relation type when: >=20 > * Don't want or cannot engage the community for the purpose of = registering a relation type > * Using an internal or experimental relation type (similar to the = original purpose of the X- HTTP headers) > * Defining a short-lived relation type (e.g. something for an event)=20= > * Do not want to involve IANA / IETF in the process or politics of = your standard > * You like URIs better >=20 > -- Use a "trademark-quality" registered short relation type for (i.e. = a relation type that is unique, not a trivial word, and unlikely to mean = something else): >=20 > * A narrowly defined relation type > * Protocol specific > * Restricted in the media type of the linked resource > * Restricted in link cardinality in the same place or multiple places = (HTTP Header, HTML element, etc.) > * Use for other purposes will break something >=20 > -- Use a generic term registered short relation type: >=20 > * Generally applicable across context, protocols > * Meaning is aligned with common expectations of technical people > * Can have specialized processing rules of meaning in some cases = without breaking something >=20 > Are these examples right? I don't think we need to have them in the = spec, but it would be great if we can offer the DE's something to work = with (as well as the wider community to better understand how they = should use this process). >=20 > EHL >=20 >=20 >> -----Original Message----- >> From: Mark Nottingham [mailto:mnot@mnot.net] >> Sent: Tuesday, December 29, 2009 3:26 PM >> To: Eran Hammer-Lahav >> Cc: Julian Reschke; Apps Discuss >> Subject: Re: draft-nottingham-http-link-relation-07 progress >>=20 >>=20 >> On 14/12/2009, at 6:05 PM, Eran Hammer-Lahav wrote: >>=20 >>> Maybe some recommendation in the spec about naming conventions? >> Something along the lines of non-novel names should not be used for = very >> narrow cases. >>=20 >>=20 >> How about (after the other requirements on relation names): >>=20 >> They SHOULD be appropriate to the specificity of the relation; i.e., = if the >> semantics are highly specific to a particular application, the name = should >> reflect that, so that more general names are available for less = specific use. >>=20 >>=20 >> -- >> Mark Nottingham http://www.mnot.net/ >=20 -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Mon Jan 18 21:31:37 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055B03A692D for ; Mon, 18 Jan 2010 21:31:37 -0800 (PST) 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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOVpbzEcNsTC for ; Mon, 18 Jan 2010 21:31:36 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 0679D3A67AE for ; Mon, 18 Jan 2010 21:31:36 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.153.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BB9AE509DA; Tue, 19 Jan 2010 00:31:25 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) Subject: Fwd: New Version Notification - draft-nottingham-http-link-header-07.txt From: Mark Nottingham Date: Tue, 19 Jan 2010 16:31:22 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100119053002.5CD613A683B@core3.amsl.com> To: HTTP Working Group X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 05:31:37 -0000 Begin forwarded message: > From: Internet-Draft@ietf.org > Date: 19 January 2010 4:30:02 PM AEDT > To: mnot@pobox.com, = draft-nottingham-http-link-header@tools.ietf.org,lisa.dusseault@gmail.com > Subject: New Version Notification - = draft-nottingham-http-link-header-07.txt=20 >=20 > New version (-07) has been submitted for = draft-nottingham-http-link-header-07.txt. > = http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-07.t= xt > Sub state has been changed to AD Follow up from New Id Needed >=20 > Diff from previous version: > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-link-header-07 >=20 > IETF Secretariat. -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Tue Jan 19 04:28:01 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4EA93A68D9 for ; Tue, 19 Jan 2010 04:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.574 X-Spam-Level: X-Spam-Status: No, score=-5.574 tagged_above=-999 required=5 tests=[AWL=-2.975, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzObRwsLKetq for ; Tue, 19 Jan 2010 04:28:00 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 390093A6A75 for ; Tue, 19 Jan 2010 04:27:59 -0800 (PST) Received: (qmail invoked by alias); 19 Jan 2010 12:27:54 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp003) with SMTP; 19 Jan 2010 13:27:54 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18W/QBRMV0WhZiZSUUKjUQtJDGur3XYCyAY5L9tf8 TZz8qBsk3TuJVy Message-ID: <4B55A549.7040904@gmx.de> Date: Tue, 19 Jan 2010 13:27:53 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: IETF Apps Discuss , HTTP Working Group Subject: FYI: I-D Action:draft-reschke-rfc2231-in-http-08.txt References: <20100119113001.B5DD23A686C@core3.amsl.com> In-Reply-To: <20100119113001.B5DD23A686C@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54000000000000004 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 12:28:01 -0000 Hi, I have updated the draft with feedback I got during the informal "last call" that ended yesterday (I added a statement about the relation RFC 2388, and added information about existing implementations). See diffs at . Next, I'll send a publication request to the Apps Area Directors. Best regards, Julian Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Application of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP) Header Fields > Author(s) : J. Reschke > Filename : draft-reschke-rfc2231-in-http-08.txt > Pages : 14 > Date : 2010-01-19 > > By default, message header field parameters in Hypertext Transfer > Protocol (HTTP) messages can not carry characters outside the ISO- > 8859-1 character set. RFC 2231 defines an escaping mechanism for use > in Multipurpose Internet Mail Extensions (MIME) headers. This > document specifies a profile of that encoding suitable for use in > HTTP header fields. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-reschke-rfc2231-in-http-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From cfinss@dial.pipex.com Wed Jan 20 01:29:32 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72D53A680C; Wed, 20 Jan 2010 01:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8Mwl7VGyZzS; Wed, 20 Jan 2010 01:29:32 -0800 (PST) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 9DC263A67D9; Wed, 20 Jan 2010 01:29:31 -0800 (PST) X-Trace: 320761961/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.217/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.217 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQGAKtbVks+vGnZ/2dsb2JhbACCUi6FKoh5xVoKhCwE X-IronPort-AV: E=Sophos;i="4.49,309,1262563200"; d="scan'208";a="320761961" X-IP-Direction: IN Received: from 1cust217.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.217]) by smtp.pipex.tiscali.co.uk with SMTP; 20 Jan 2010 09:29:21 +0000 Message-ID: <001701ca99aa$a75906c0$0601a8c0@allison> From: "tom.petch" To: "Michelle Cotton" , , References: Subject: Re: [tsvwg] New version of document for review Date: Wed, 20 Jan 2010 09:28:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 09:29:32 -0000 Michele You said that feedback would be appreciated:-) I have a problem with this I-D in that it would appear to make no distinction between allocation and assignment, and would seem to include registration in the mix as well, at least at times, while hinting that whatever these may be, ownership is something else. In the limited context of transport identifiers, this may not cause confusion but in closely allied registries, allocation and assignment are fundamentally different processes and those who interchange the two are confused and cause confusion. If, as I suspect, you are using the terms interchangeably, then at the very least you need a terminology section as 1.1 to say that the two (or three) terms are used interchangeably, but for myself, I would regard this as inadequate. Really, you should choose one and eliminate the other(s) with a brief note to say that historically, both were used but as of now, a........ is the correct term. More fundamentally, this I-D is largely about a bureaucratic process without stating clearly, IMO, what the point of this process is, except to generate bureaucracy (and confusion over this would appear to have triggered some discussion recently on the tsvwg list). The I-D should state up front, not hint at it in section 7, just why this bureaucracy should exist, of what benefit it would be bureaucracy is to the IETF etc. The I-D argues for improving the bureacracy, not for why it should exist. Tom Petch ----- Original Message ----- From: "Michelle Cotton" To: ; ; Sent: Friday, January 15, 2010 5:16 PM Subject: [tsvwg] New version of document for review Attn: TSVWG Working Group, DNSOPS Working Group and APPS AREA Working Group There is a new version of the Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Transport Protocol Port Number and Service Name Registry document: draft-ietf-tsvwg-iana-ports-04.txt Please review and send comments. Your feedback is much appreciated. Thank you, Michelle Cotton (on behalf of the ports teams) From julian.reschke@gmx.de Wed Jan 20 03:01:27 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CEF63A6984 for ; Wed, 20 Jan 2010 03:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.512 X-Spam-Level: X-Spam-Status: No, score=-5.512 tagged_above=-999 required=5 tests=[AWL=-2.913, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzKgl0yMmJhb for ; Wed, 20 Jan 2010 03:01:25 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3F0413A68ED for ; Wed, 20 Jan 2010 03:01:24 -0800 (PST) Received: (qmail invoked by alias); 20 Jan 2010 11:01:19 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp036) with SMTP; 20 Jan 2010 12:01:19 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/KdbQjqo/K0UxRYGhuHsdbFN8bYX2gkbhXJZwrNR u9I0joe6KRSdps Message-ID: <4B56E27D.800@gmx.de> Date: Wed, 20 Jan 2010 12:01:17 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Apps Discuss Subject: Re: Fwd: New Version Notification - draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55000000000000004 Cc: "public-html@w3.org" , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 11:01:27 -0000 Thanks, Mark. I'd like to make sure that everybody is aware that these are past-LC changes, and they *are* significant; see : o Allowed multiple spaces between relation types. o Relaxed requirements for registered relations. o Removed Defining New Link Serialisations appendix. o Added Field registry. o Added registry XML format. o Changed registration procedure to use mailing list(s), giving the Designated Experts more responsibility for the smooth running of the registry. o Loosened prohibition against media-specific relation types to SHOULD NOT. o Disallowed registration of media-specific relation types (can still be used as extension types). o Clarified that parsers are responsible for resolving relative URIs. o Fixed ABNF for extended-initial-value. o Fixed title* parameter quoting in example. o Added notes for registered relations that lack a reference. o Added hreflang parameter. o Clarified status of 'rev'. o Removed advice to use @profile in HTML4. o Clarified what multiple *title and hreflang attributes mean. o Disallowed multiple type, rel and title attributes. o Removed text about absolute URI form of registered relations. o Required registered relations to conform to sgml-name (now just rel-relation-type). o Required registered relations to be lowercase. o Made comparison of extension relations case insensitive. o Clarified requirements on registered relation types regarding media types, etc. o Allowed applications to ignore links with anchor parameters if they're concerned. o Made 'rev' text a bit less confusing. o Extension relation URIs SHOULD be all-lowercase. o Added media parameter. o Required applications to specifically call out use of anchor parameter. Thus everybody who's interested in this specification should review these changes as soon as possible. Best regards, Julian Mark Nottingham wrote: > > Begin forwarded message: > >> From: Internet-Draft@ietf.org >> Date: 19 January 2010 4:30:02 PM AEDT >> To: mnot@pobox.com, draft-nottingham-http-link-header@tools.ietf.org,lisa.dusseault@gmail.com >> Subject: New Version Notification - draft-nottingham-http-link-header-07.txt >> >> New version (-07) has been submitted for draft-nottingham-http-link-header-07.txt. >> http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-07.txt >> Sub state has been changed to AD Follow up from New Id Needed >> >> Diff from previous version: >> http://tools.ietf.org/rfcdiff?url2=draft-nottingham-http-link-header-07 >> >> IETF Secretariat. > > > -- > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From masinter@adobe.com Wed Jan 20 14:42:18 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A758828C0D8 for ; Wed, 20 Jan 2010 14:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbZ9TwPxZ5-s for ; Wed, 20 Jan 2010 14:42:17 -0800 (PST) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by core3.amsl.com (Postfix) with ESMTP id 24A8C3A6877 for ; Wed, 20 Jan 2010 14:42:17 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKS1eGwczm9SWCr3tU/5Fw6bHZ1EjV+iBf@postini.com; Wed, 20 Jan 2010 14:42:13 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id o0KMYP18029877; Wed, 20 Jan 2010 14:34:25 -0800 (PST) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id o0KMfjf9008950; Wed, 20 Jan 2010 14:41:54 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Wed, 20 Jan 2010 14:41:45 -0800 From: Larry Masinter To: Adam Barth , Ian Hickson Date: Wed, 20 Jan 2010 14:41:43 -0800 Subject: comments on draft-abarth-mime-sniff-03 Thread-Topic: comments on draft-abarth-mime-sniff-03 Thread-Index: AcqaIb0iX+pEgQYkQxG7tIvGiF6OfQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 22:42:18 -0000 Although this document was discussed a while back in httpbis, it seems to address non HTTP sniffing as well.=20 I'll send notes to http-wg, html-wg, www-tag to move discussion here (as advised). Several W3C specs are advancing using this document=20 as a normative reference (including HTML), so getting=20 this reviewed should be timely. The document should note the venue for discussion. I admit I haven't chased down the archives on the previous discussion of this, and maybe I've gotten some things wrong, but the current draft is already 4 months old. (Compared to other drafts the authors are updating regularly.)=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D All or nothing: Whenever possible, user agents should avoid employing a content sniffing algorithm. The normative advice seems to apply to roles other than "user agents"; whether or not there is a user isn't really relevant. Secondly, it's not clear the scope of the "should avoid" or whether this is really intended to be normative. I'll assume that it is. However, if a user agent does employ a content sniffing algorithm, the user agent should use the algorithm in this document exactly The algorithm isn't exact (more below). And think this is the wrong normative advice. Implementations SHOULD NOT sniff labeled content, and MUST NOT sniff any way beyond the ways=20 explicitly allowed here, and when they do sniff, should opt into sniffing on a situation by situation, type by type basis. The application of sniffing should be reserved=20 for situations where the implementor has sufficient reason to believe that there is sufficient existing=20 deployed content that would not function as expected=20 if sniffing were not implemented, and these situations should be encouraged to be as fine a granularity as the implementor needs. This normative advice should not require updating as the deployed content evolves. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D TERMINOLOGY "resource" This document seems to have the same use of "resource" to talk about what is fetched and not just the source from which it is fetched, as discussed in HTML-WG at length: http://www.w3.org/html/wg/tracker/issues/81 =20 For example For HTTP resources, only the last Content-Type HTTP header, if any, contributes any type information; the official type=20 of the resource is then the value of that header,=20 interpreted as described by the HTTP specifications. =20 But HTTP specification cited says is: The "Content-Type" entity-header field indicates the media type of the entity-body.=20 not applying "media type" to the resource but as metadata of the response. For example, instead of using "resource" inconsistently, this sentence might say: For HTTP resources ... the official media type of the representation is obtained from the value ... since of course, the same HTTP resource might return different representations depending on accept headers. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Malformed content-type information vs. missing content-type=20 I think the cases where content-type information supplied is malformed should be treated differently than the cases where content-type information is missing. In particular, it should be possible and allowed to raise an error if content-type information is malformed, even when sniffing is performed on well-formed, but incorrect,=20 content-type. That is, the "opt-in" behavior could allow an implementation to sniff when no content-type, but not sniff when there is a malformed content-type. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Contextual application There are many different contexts of use of MIME labeled material in the web, and the opt-in behavior for sniffing should be allowed to be contextualized. For example, one might opt in to sniffing for but opt out of sniffing a script or rel link and opt in when doing a GET on the main body of a web page. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D multiple content-type headers are malformed: > For HTTP resources, only the last Content-Type HTTP header, > if any, contributes any type information =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A message with more than one content-type header should be treated as malformed. If the Content-Type HTTP header is present but the value of the last such header cannot be=20 interpreted as described by the HTTP=20 specifications (e.g. because its value doesn't=20 contain a U+002F SOLIDUS ('/') character), then the resource has no type information (even=20 if there are multiple Content-Type HTTP headers and one of the other ones is syntactically correct). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The "algorithm for extracting an encoding ...." =20 Note: The above algorithm is a willful violation of the HTTP specification. [RFC2616] The word "encoding" is confusing, since HTTP uses content-encoding and this is actually talking=20 about what HTTP calls "charset". The HTML algorithm for 'sniffing' a charset when one is explicitly supplied but is changed by HTML -- that isn't part of this draft? It is HTML only? It seems to be part of the same family of "sniffing" and should be reviewed with the same scrutiny, moving it either into this document or to a parallel one. (Perhaps someone can raise this as a bug in the HTML spec.) The nature of the "willful violation"=20 (I.e., how it is different) and the=20 justification for the "willful violation"=20 should be included. I can't fathom any justification for it. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D file extensions: Note: It is essential that file extensions are not used for determining the media type for resources fetched over HTTP because file extensions can often by supplied by malicious parties. "Often" is dubious. How can file extensions be supplied more often than content-type headers? What is the security threat?=20 For resources fetched over most other protocols, e.g.=20 FTP, there is no type information. "most other protocols" is imprecise. Does this apply to imap? data:? There seems to be some attempt to define this for RSS? Is it the protocol or the scheme that=20 determines the method, or both? I also don't think this matches implementations for FTP, aren't file extension used frequently to determine content-type? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Waiting (section 5) 1. The user agent MAY wait for 512 or more bytes of the resource to be available. 2. Let /stream length/ be the smaller of either 512 or the number of bytes already available. *This* document doesn't define "available" or what it means to "wait" or really have much to do with what most of this document is about. I think the choice here is that type sniffing apparently can work on whatever prefix the agent chooses to give it, from anywhere from 0 to 512 bytes. If it chooses to send 0 bytes, this is equivalent for turning off MIME sniffing completely=20 (since there is nothing to sniff). I'd think that the behavior of "how to sniff" should start out with what the inputs are (the first N bytes of some data from a response). Note that the n bytes are not the bytes of the actual traffic over the wire, but the bytes resulting from undoing any content-encoded. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Adding new types: " User agents may support additional types if desired, by implicitly adding to the above table." This makes no sense and is a disaster for interoperability.=20 The only reason why we have badly deployed content is that user agents "sniffed" new types. If the deployed infrastructure doesn't deploy new kinds of sniffing, then people won't distribute content. This is a harmful escalating path and encouraging implementations to add to the table is disruptive and harmful. Don't do it. From algermissen1971@mac.com Wed Jan 20 23:38:35 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D723A67C1 for ; Wed, 20 Jan 2010 23:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=-3.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EdeJkjVWIxn for ; Wed, 20 Jan 2010 23:38:34 -0800 (PST) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by core3.amsl.com (Postfix) with ESMTP id 686703A68D6 for ; Wed, 20 Jan 2010 23:38:34 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.2.102] ([84.144.108.75]) by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KWL00FM86IJ7Q10@asmtp019.mac.com> for discuss@apps.ietf.org; Wed, 20 Jan 2010 23:37:35 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1001200335 Message-id: From: Jan Algermissen To: Subbu Allamaraju In-reply-to: Subject: Re: New Version Notification - draft-nottingham-http-link-header-07.txt Date: Thu, 21 Jan 2010 08:37:30 +0100 References: <20100119053002.5CD613A683B@core3.amsl.com> X-Mailer: Apple Mail (2.936) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 07:38:35 -0000 On Jan 20, 2010, at 10:38 PM, Subbu Allamaraju wrote: > The usage of fields is not clear. Sec. 6.3 says that "entries in the > Link Relation Type Registry can be extended with application- > specific data". But the BNF in Sec. 5 does not specify fields. Could > you clarify the intent of fields? I understand fields to be meant as link relation specific parameters. Jan > > Subbu > > On Jan 18, 2010, at 9:31 PM, Mark Nottingham wrote: > >> >> >> Begin forwarded message: >> >>> From: Internet-Draft@ietf.org >>> Date: 19 January 2010 4:30:02 PM AEDT >>> To: mnot@pobox.com, draft-nottingham-http-link- >>> header@tools.ietf.org,lisa.dusseault@gmail.com >>> Subject: New Version Notification - draft-nottingham-http-link- >>> header-07.txt >>> >>> New version (-07) has been submitted for draft-nottingham-http- >>> link-header-07.txt. >>> http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-07.txt >>> Sub state has been changed to AD Follow up from New Id Needed >>> >>> Diff from previous version: >>> http://tools.ietf.org/rfcdiff?url2=draft-nottingham-http-link-header-07 >>> >>> IETF Secretariat. >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> > > ----------------------------------- Jan Algermissen, Consultant Mail: algermissen@acm.org Blog: http://www.nordsc.com/blog/ Work: http://www.nordsc.com/ ----------------------------------- From julian.reschke@gmx.de Thu Jan 21 04:36:17 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4013D3A6822 for ; Thu, 21 Jan 2010 04:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.405 X-Spam-Level: X-Spam-Status: No, score=-5.405 tagged_above=-999 required=5 tests=[AWL=-2.806, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwmWNh2yBNQE for ; Thu, 21 Jan 2010 04:36:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0C2EA3A680D for ; Thu, 21 Jan 2010 04:36:15 -0800 (PST) Received: (qmail invoked by alias); 21 Jan 2010 12:36:10 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp048) with SMTP; 21 Jan 2010 13:36:10 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19FtRFh4TpFAb4+ef5igaw6n7MYEVwIyEX6+rdCMN ChINwbuKU4gTN7 Message-ID: <4B584A36.2060803@gmx.de> Date: Thu, 21 Jan 2010 13:36:06 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Apps Discuss , HTTP Working Group Subject: Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard References: <20100121004451.43DC328C11B@core3.amsl.com> In-Reply-To: <20100121004451.43DC328C11B@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64000000000000001 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 12:36:17 -0000 (FYI) The IESG wrote: > The IESG has received a request from an individual submitter to consider > the following document: > > - 'Web Linking ' > as a 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 2010-02-17. 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. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-07.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14833&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From julian.reschke@gmx.de Thu Jan 21 04:53:41 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062873A6A5D for ; Thu, 21 Jan 2010 04:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.32 X-Spam-Level: X-Spam-Status: No, score=-5.32 tagged_above=-999 required=5 tests=[AWL=-2.721, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVcnza4ARa9Q for ; Thu, 21 Jan 2010 04:53:40 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BD7F73A6907 for ; Thu, 21 Jan 2010 04:53:39 -0800 (PST) Received: (qmail invoked by alias); 21 Jan 2010 12:53:33 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp062) with SMTP; 21 Jan 2010 13:53:33 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+NoSMQUBCNgTP50r69y9wfrIFqv0y5asWpBsghmG ZgLQ1TihBiI1+h Message-ID: <4B584E46.7000405@gmx.de> Date: Thu, 21 Jan 2010 13:53:26 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Apps Discuss , HTTP Working Group Subject: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> In-Reply-To: <4B56E27D.800@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57999999999999996 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 12:53:41 -0000 Hi, this is the first of several LC comments on draft-nottingham-http-link-header-07. Except for the purely editorial ones I'll be sending them in separate emails so that it's easier to track them. This is about the anchor parameter. The changes () say: o Allowed applications to ignore links with anchor parameters if they're concerned. The actual text changed from () By default, the context of a link conveyed in the Link header field is the IRI of the requested resource. When present, the anchor parameter overrides this with another URI, such as a fragment of this resource, or a third resource (i.e., when the anchor value is an absolute URI). If the anchor parameter's value is a relative URI, it MUST be resolved as per [RFC3986], Section 5. Note that any base URI from the body's content is not applied. to () When present and explicitly specified by use by an application, the anchor parameter overrides this with another URI, such as a fragment of this resource, or a third resource (i.e., when the anchor value is an absolute URI). If the anchor parameter's value is a relative URI, parsers MUST resolve it as per [RFC3986], Section 5. Note that any base URI from the body's content is not applied. So it appears that this change does not "allow applications to ignore", but "requires applications to specify how to process", so it's an "opt in", not an "opt out". That being said: what is an "application" in this context? What needs to be done to specify this? An example would be useful; for instance, it would be interesting what would need to say to specify the required processing of anchor. In general I think that making this somehow optional will be an interop disaster. Link header processing should be uniform and not depend on some out-of-band information. If the reason this was changed was because of missing support in those UAs that currently handle the "Link" header: let's file bugs. Best regards, Julian From julian.reschke@gmx.de Thu Jan 21 05:32:07 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC113A6829 for ; Thu, 21 Jan 2010 05:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.951 X-Spam-Level: X-Spam-Status: No, score=-4.951 tagged_above=-999 required=5 tests=[AWL=-2.952, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ4FtC5EVGKq for ; Thu, 21 Jan 2010 05:32:06 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E5F8A3A6765 for ; Thu, 21 Jan 2010 05:32:05 -0800 (PST) Received: (qmail invoked by alias); 21 Jan 2010 13:32:00 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp007) with SMTP; 21 Jan 2010 14:32:00 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+o+nBxb6OobgKXkUdph5JxgMPWqO/fP+AEKlZtBg KZJYI6y99zn6+d Message-ID: <4B58574B.4050204@gmx.de> Date: Thu, 21 Jan 2010 14:31:55 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Apps Discuss , HTTP Working Group Subject: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> In-Reply-To: <4B56E27D.800@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 13:32:07 -0000 Hi, says: o Clarified status of 'rev'. and also o Made 'rev' text a bit less confusing. I think it's still confusing... So the grammar in lists it as regular link parameter: link-param = ( ( "rel" "=" relation-types ) | ( "anchor" "=" <"> URI-Reference <"> ) | ( "rev" "=" relation-types ) | ( "hreflang" "=" Language-Tag ) | ( "media" "=" ( MediaDesc | <"> MediaDesc <"> ) ) | ( "title" "=" quoted-string ) | ( "title*" "=" enc2231-string ) | ( "type" "=" type-name "/" subtype-name ) | ( link-extension ) ) On the other hand, states: The relation type of a link is conveyed in the "rel" parameter's value. Note that the "rev" parameter has also been used by some formats, and MAY be accommodated as a link-extension, but its use is neither encouraged nor defined by this specification. So the ABNF defines it as parameter, but the prose claims it's not specified, and could be specified later on as extension. Speaking of which, how do I define an extension? Standards Track RFC updating this one, as there is no registry? Later on, in the section about HTML4 we find (): HTML4 also has a "rev" parameter for links that allows a link's relation to be reversed. The Link header does not define a corresponding "rev" parameter to allow the expression of these links in HTTP headers, due to the confusion this mechanism causes as well as conflicting interpretations (briefly, some hold that rev reverses the direction of the link, while others that it reverses the semantics of the relation itself). I have to admit that I'm still not sure what *in practice* the difference between reversing the link direction and reversing the link semantics actually is. (Example?) RFC 2068 delegates the definition to RFC 1866 (HTML 2) which says (): REV same as the REL attribute, but the semantics of the relationship are in the reverse direction. A link from A to B with REL="X" expresses the same relationship as a link from B to A with REV="X". An anchor may have both REL and REV attributes. This does not seem to contradict the latest HTML spec, which has in : The rel and rev attributes play complementary roles -- the rel attribute specifies a forward link and the rev attribute specifies a reverse link. Consider two documents A and B. Document A: Has exactly the same meaning as: Document B: Both attributes may be specified simultaneously. So my preference would be to actually define the rev parameter consistently with this, and then to discourage it's use due to the other good reasons we heard about that (such as HTML authors typing "rev" instead of "rel"). Related to that: if processing the anchor attribute was mandatory then any use of "rev" (under the definition above) could be rewritten with rel and anchor. Given a context IRI of A: Link: ; rev=foo should be equivalent to Link: ; rel=foo; anchor= right? Best regards, Julian From julian.reschke@gmx.de Thu Jan 21 05:48:01 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6EFE3A67AD for ; Thu, 21 Jan 2010 05:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.169 X-Spam-Level: X-Spam-Status: No, score=-5.169 tagged_above=-999 required=5 tests=[AWL=-2.570, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxOugJQk7SLb for ; Thu, 21 Jan 2010 05:48:00 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 08BD43A6807 for ; Thu, 21 Jan 2010 05:47:59 -0800 (PST) Received: (qmail invoked by alias); 21 Jan 2010 13:47:54 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp059) with SMTP; 21 Jan 2010 14:47:54 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX185x3hB8d05Q+aHOnq6s9sOYGwGmkOAzgcdKQomVc v72fk7cxbT9UD4 Message-ID: <4B585B06.1040704@gmx.de> Date: Thu, 21 Jan 2010 14:47:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Apps Discuss , HTTP Working Group Subject: parameter quoting - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> In-Reply-To: <4B56E27D.800@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.56999999999999995 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 13:48:01 -0000 Hi, a few comments regarding quoting of link parameters: defines the new parameters: | ( "hreflang" "=" Language-Tag ) | ( "media" "=" ( MediaDesc | <"> MediaDesc <"> ) ) "hreflang" and "media", so quoting is allowed for media, but it's not for hreflang. I think it's correct that valid language tags never require quoting, but I'm not sure that disallowing quoting is the right thing to do here. Which made have a closer look at existing parameters (sorry for not bringing this up earlier): | ( "type" "=" type-name "/" subtype-name ) I believe this *definitively* needs quoting, as "/" is a separator character in HTTP and thus can not appear in a token. Also, as this spec uses the RFC 2616 ABNF, we probably need to duplicate the statement from : "...Linear white space (LWS) MUST NOT be used between the type and subtype, ..." Best regards, Julian From julian.reschke@gmx.de Thu Jan 21 06:05:07 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76A3E28C162 for ; Thu, 21 Jan 2010 06:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.123 X-Spam-Level: X-Spam-Status: No, score=-5.123 tagged_above=-999 required=5 tests=[AWL=-2.524, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOP3p0TqiTmG for ; Thu, 21 Jan 2010 06:05:02 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4659128C161 for ; Thu, 21 Jan 2010 06:05:00 -0800 (PST) Received: (qmail invoked by alias); 21 Jan 2010 14:04:54 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp009) with SMTP; 21 Jan 2010 15:04:54 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX181QIhjHb81OFVG3g547045n+acyzcgVR7OSj1TuW G9wXToy9s15Bar Message-ID: <4B585EFF.2080104@gmx.de> Date: Thu, 21 Jan 2010 15:04:47 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Apps Discuss , HTTP Working Group Subject: editorial LC comments on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> In-Reply-To: <4B56E27D.800@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 14:05:07 -0000 Hi, below are some comments of editorial nature: Section 1., paragraph 3: OLD: Furthermore, an HTTP header-field for conveying typed links was defined in [RFC2068], but removed from [RFC2616], due to a lack of implementation experience. Since then, it has been implemented in some User-Agents (e.g., for stylesheets), and several additional use cases have surfaced. NEW: Furthermore, an HTTP header-field for conveying typed links was defined in Section 19.6.2.4 of [RFC2068], but removed from [RFC2616], due to a lack of implementation experience. Since then, it has been implemented in some User-Agents (e.g., for stylesheets), and several additional use cases have surfaced. (be nice to the reader and a bit more specific in the RFC 2068 reference) Section 2., paragraph 0: OLD: [[ Feedback is welcome on the ietf-http-wg@w3.org mailing list, although this is NOT a work item of the HTTPBIS WG. ]] Please either move into a front page note, or clearly mark this as something to be removed before publication. Section 2., paragraph 3: OLD: Additionally, the following rules are included from [RFC3986]: URI and URI-Reference; from [RFC4288]: type-name and subtype-name; from [W3C.REC-html401-19991224]: MediaDesc, and from [RFC4646]: Language- Tag. NEW: Additionally, the following rules are included from [RFC3986]: URI and URI-Reference; from [RFC4288]: type-name and subtype-name; from [W3C.REC-html401-19991224]: MediaDesc, and from [RFC5646]: Language- Tag. RFC 4646 was updated by RFC 5646. Section 4.1., paragraph 3: OLD: Registered relation types MUST NOT constrain the media type of the context IRI, and MUST NOT constrain the available representation media types of the target IRI. However, they MAY specify the behaviours and properties of the target resource (e.g., allowable methods, request and response media types which must be supported). Does "methods" refer to HTTP here? maybe clarify this. Section 4.1., paragraph 4: OLD: Additionally, specific applications of linking may have additional per-relation type attributes which are advantageous to register. For example, some link relations might not be appropriate to use in particular contexts, or might have common behaviour such as whether their content should be archived with the page. To accommodate this, new per-entry fields MAY be added to the registry, by registering them in the Link Relation Field Registry Section 6.3. NEW: Additionally, specific applications of linking may have additional per-relation type attributes which are advantageous to register. For example, some link relations might not be appropriate to use in particular contexts, or might have common behaviour such as whether their content should be archived with the page. To accommodate this, new per-entry fields MAY be added to the registry, by registering them in the Link Relation Field Registry (Section 6.3). (Missing brackets at the paragraph end) Section 5.4., paragraph 3: OLD: The "media" parameter, when present, is used to indicate intended destination medium or media for style information (see [W3C.REC-html401-19991224], Section 6.13. Note that this may be updated by [W3C.CR-css3-mediaqueries-20090915]). Its value MUST be quoted if it contains a semicolon (";") or comma (","), and there MUST NOT be more than one media parameter in a link-value. NEW: The "media" parameter, when present, is used to indicate intended destination medium or media for style information (see [W3C.REC-html401-19991224], Section 6.13). Note that this may be updated by [W3C.CR-css3-mediaqueries-20090915]). Its value MUST be quoted if it contains a semicolon (";") or comma (","), and there MUST NOT be more than one media parameter in a link-value. Missing closing bracket in HTML4 reference. Section 5.4., paragraph 5: OLD: The "title*" parameter MAY be used encode this label in a different character set, and/or contain language information as per [RFC2231]. When using the enc2231-string syntax, producers MUST NOT use a charset value other than 'ISO-8859-1' or 'UTF-8'. The "title*" parameter MAY appear more than once in a given link-value, but each occurrence MUST indicate a different language; occurrences after the first for a given language MUST be ignored by parsers. NEW: The "title*" parameter MAY be used to encode this label in a different character set, and/or contain language information as per [RFC2231]. When using the enc2231-string syntax, producers MUST NOT use a charset value other than 'ISO-8859-1' or 'UTF-8'. The "title*" parameter MAY appear more than once in a given link-value, but each occurrence MUST indicate a different language; occurrences after the first for a given language MUST be ignored by parsers. ...may be used *to* encode... Section 9.1., paragraph 9: OLD: [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", RFC 4646, September 2006. NEW: [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Section 9.2., paragraph 7: OLD: [W3C.CR-css3-mediaqueries-20090915] Glazman, D., Celik, T., Lie, H., and A. Kesteren, "Media Queries", World Wide Web Consortium CR CR-css3- mediaqueries-20090915, September 2009, . [W3C.REC-html401-19991224] Jacobs, I., Raggett, D., and A. Hors, "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, . [W3C.REC-rdfa-syntax-20081014] Adida, B., Pemberton, S., McCarron, S., and M. Birbeck, "RDFa in XHTML: Syntax and Processing", World Wide Web Consortium Recommendation REC-rdfa-syntax-20081014, October 2008, . [W3C.REC-xhtml-basic-20080729] Wugofski, T., Matsui, S., Baker, M., Yamakami, T., Ishikawa, M., and P. Stark, "XHTML[TM] Basic 1.1", World Wide Web Consortium Recommendation REC-xhtml-basic- 20080729, July 2008, . NEW: [W3C.CR-css3-mediaqueries-20090915] Glazman, D., Celik, T., Lie, H., and A. Kesteren, "Media Queries", W3C Candidate Recommendation CR-css3- mediaqueries-20090915, September 2009, . [W3C.REC-html401-19991224] Jacobs, I., Raggett, D., and A. Hors, "HTML 4.01 Specification", W3C Recommendation REC-html401-19991224, December 1999, . [W3C.REC-rdfa-syntax-20081014] Adida, B., Pemberton, S., McCarron, S., and M. Birbeck, "RDFa in XHTML: Syntax and Processing", W3C Recommendation REC-rdfa-syntax-20081014, October 2008, . [W3C.REC-xhtml-basic-20080729] Wugofski, T., Matsui, S., Baker, M., Yamakami, T., Ishikawa, M., and P. Stark, "XHTML Basic 1.1", W3C Recommendation REC-xhtml-basic-20080729, July 2008, . Please make the W3C references consistent: W3C instead of "Word Wide Web Consortium", and make sure the URIs use the current format (trailing slash). Optimally, also reduce the length of the anchor names (I'll be happy to supply diffs). Best regards, Julian From julian.reschke@gmx.de Thu Jan 21 06:23:17 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E074E3A680D for ; Thu, 21 Jan 2010 06:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.084 X-Spam-Level: X-Spam-Status: No, score=-5.084 tagged_above=-999 required=5 tests=[AWL=-2.485, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgHOSQQtK+X8 for ; Thu, 21 Jan 2010 06:23:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BED0E3A6774 for ; Thu, 21 Jan 2010 06:23:15 -0800 (PST) Received: (qmail invoked by alias); 21 Jan 2010 14:23:10 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp016) with SMTP; 21 Jan 2010 15:23:10 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+F1ohzBaaFUusGGPixPnQWfyBR9YnhxH4TOw2WWj ZKEXRQzsKlQOS1 Message-ID: <4B586349.5050405@gmx.de> Date: Thu, 21 Jan 2010 15:23:05 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Apps Discuss , HTTP Working Group Subject: exposing sensitive information in URIs - LC comments on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> In-Reply-To: <4B56E27D.800@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67000000000000004 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 14:23:18 -0000 Hi, finally a security related comment. During IETF LC for draft-brown-versioning-link-relations we got a comment from Eric Rescorla: "In general this mechanism seems sound but I'm not sure that the security considerations are entirely adequate. This mechanism lets you learn information about other versions of a resource even if you potentially don't have permission to view them directly. Consider a limiting case where each version of the resource had a name that contained the change set for that resource. E.g., http://example.com/versions/filename/_@line_50_+_FOO;@line_60_+_BAR/; In this case, seeing other parts of the version tree leaks information about those versions. I don't think that this is a problem for the draft, but it might be useful to mention that this feature has implications for name construction." I assume this is a concern that applies to the Link header in general. Best regards, Julian From julian.reschke@gmx.de Thu Jan 21 07:08:44 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B4FC3A697E for ; Thu, 21 Jan 2010 07:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.051 X-Spam-Level: X-Spam-Status: No, score=-5.051 tagged_above=-999 required=5 tests=[AWL=-2.452, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0lLYX+Mx+9k for ; Thu, 21 Jan 2010 07:08:43 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BC49228C111 for ; Thu, 21 Jan 2010 07:08:42 -0800 (PST) Received: (qmail invoked by alias); 21 Jan 2010 15:08:37 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp014) with SMTP; 21 Jan 2010 16:08:37 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/qQVFqGNLqDdK563aYOJ62waU+6ZvJAF1xqVOOUc 69+5pOjxXoShJ5 Message-ID: <4B586DF0.9010201@gmx.de> Date: Thu, 21 Jan 2010 16:08:32 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: mjb@asplake.co.uk Subject: Re: parameter quoting - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B585B06.1040704@gmx.de> <7a2269961001210701t15ea51cdmf48cc696282c44b6@mail.gmail.com> In-Reply-To: <7a2269961001210701t15ea51cdmf48cc696282c44b6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.70999999999999996 Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 15:08:44 -0000 Mike Burrows wrote: > Hi Julian (and all), > > Which made have a closer look at existing parameters (sorry for not > bringing this up earlier): > > | ( "type" "=" type-name "/" subtype-name ) > > I believe this *definitively* needs quoting, as "/" is a separator > character in HTTP and thus can not appear in a token. > > > But is 'type-name "/" subtype-name' a token? I didn't interpret as such > - in fact I assumed (perhaps erroneously) that it was in fact two tokens > separated by "/". > > Regards, > Mike > ... You are right, it's not. But, in general, parameter values either take tokens or quoted-strings, so a generic parser of HTTP parameters would fail to parse this correctly. Maybe that's not a big issue in practice, because people use custom parser per header field, but it would be good if we could avoid that. Best regards, Julian From asplake@googlemail.com Tue Jan 19 13:06:13 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC363A69BD for ; Tue, 19 Jan 2010 13:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vgWAnlxA5tJ for ; Tue, 19 Jan 2010 13:06:12 -0800 (PST) Received: from mail-pw0-f55.google.com (mail-pw0-f55.google.com [209.85.160.55]) by core3.amsl.com (Postfix) with ESMTP id 5DBF73A683D for ; Tue, 19 Jan 2010 13:06:12 -0800 (PST) Received: by pwj2 with SMTP id 2so2641505pwj.34 for ; Tue, 19 Jan 2010 13:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=g7uyeHfxAOD/BsFKZpbDpY9SzWIF3QRYdjwSbcD41CY=; b=tElQLP8bZ83Lwtjnp/5l3+cRJydRh/DEdqUd2kXcfXtVf9yt9gSyW3rYCtfQnxffjz RiIulsgrBvepAdUGxNf4oSTt9z8EDMuo0nf5wKEz8MI4rUB7DhuTWax4qY4q40qFXnHC eyfQDTxrrga9vRX5RX5wAwR0F6WQJGg0Hz4bo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=NH/p9ynprDkPHh0MAfJuZe+N0NOHIKPodsAyD+uKx/Ont7GK1mHobsmKUr/yEaKlmm 0rM5WRquegsIjPkntW7bEN9jcqiQg6K7DH+SQR4qnLMMXD2QstzbJh/CnDEB6hqnnw1T VCM8T9BRSUB9DywJnsQHkBMJEF3iDhdtZQMBE= MIME-Version: 1.0 Sender: asplake@googlemail.com Received: by 10.141.4.8 with SMTP id g8mr5330854rvi.182.1263935164422; Tue, 19 Jan 2010 13:06:04 -0800 (PST) In-Reply-To: References: <20100119053002.5CD613A683B@core3.amsl.com> Date: Tue, 19 Jan 2010 22:06:04 +0100 X-Google-Sender-Auth: 5f5973ff85a03e80 Message-ID: <7a2269961001191306i9bf78c1oe55f574166874944@mail.gmail.com> Subject: Re: New Version Notification - draft-nottingham-http-link-header-07.txt From: Mike Burrows To: Mark Nottingham Content-Type: multipart/alternative; boundary=000e0cd0eba27e9dbc047d8ad67f X-Mailman-Approved-At: Thu, 21 Jan 2010 08:13:56 -0800 Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mjb@asplake.co.uk List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 21:10:35 -0000 X-List-Received-Date: Tue, 19 Jan 2010 21:10:35 -0000 --000e0cd0eba27e9dbc047d8ad67f Content-Type: text/plain; charset=ISO-8859-1 Thanks, and nice timing - I've just ported my link header rubygem to Python - see http://pypi.python.org/pypi/LinkHeader/0.1 or http://bitbucket.org/asplake/link_header/. The Python version is rather smarter about when to quote attribute values (I should port this back to Ruby), but they are otherwise similar in functionality - parsing, formatting and conversion to/from json-friendly structures. Caveat: I've made no serious attempt (in either language) to parse title* attributes ("title*" "=" enc2231-string) but if anyone has need of them (or has any other feedback for that matter) please get in touch privately and I will see what I can do. Regards, Mike mjb@asplake.co.uk http://positiveincline.com http://twitter.com/asplake 2010/1/19 Mark Nottingham > > > Begin forwarded message: > > > From: Internet-Draft@ietf.org > > Date: 19 January 2010 4:30:02 PM AEDT > > To: mnot@pobox.com, draft-nottingham-http-link-header@tools.ietf.org, > lisa.dusseault@gmail.com > > Subject: New Version Notification - > draft-nottingham-http-link-header-07.txt > > > > New version (-07) has been submitted for > draft-nottingham-http-link-header-07.txt. > > > http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-07.txt > > Sub state has been changed to AD Follow up from New Id Needed > > > > Diff from previous version: > > http://tools.ietf.org/rfcdiff?url2=draft-nottingham-http-link-header-07 > > > > IETF Secretariat. > > > -- > Mark Nottingham http://www.mnot.net/ > > > > --000e0cd0eba27e9dbc047d8ad67f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, and nice timing - I've just ported my link header rubygem t= o Python - see
http:= //pypi.python.org/pypi/LinkHeader/0.1 or http://bitbucket.org/asplake/link_header/.

The Python version is rather smarter about when to quote attribute valu= es (I should port this back to Ruby), but they are otherwise similar in fun= ctionality - parsing, formatting and conversion to/from json-friendly struc= tures.

Caveat: I've made no serious attempt (in either language) to parse = title* attributes ("title*" "=3D" enc2231-string) but i= f anyone has need of them (or has any other feedback for that matter) pleas= e get in touch privately and I will see what I can do.

Regards,
Mike
= mjb@asplake.co.uk
http://posi= tiveincline.com
http://twitte= r.com/asplake


2010/1/19 Mark Nottingham <mnot@mnot.net>


Begin forwarded message:

> From: Internet-Draft@ietf.o= rg
> Date: 19 January 2010 4:30:02 PM AEDT
> To: mnot@pobox.com, draft-nottingham-ht= tp-link-header@tools.ietf.org,lisa.dusseault@gmail.com
> Subject: New Version Notification - draft-nottingham-http-link-header-= 07.txt
>
> New version (-07) has been submitted for draft-nottingham-http-link-he= ader-07.txt.
> http://www.ietf.org/internet-drafts/dr= aft-nottingham-http-link-header-07.txt
> Sub state has been changed to AD Follow up from New Id Needed
>
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=3Ddraf= t-nottingham-http-link-header-07
>
> IETF Secretariat.


--
Mark Nottingham =A0 =A0 = http://www.mnot.net/




--000e0cd0eba27e9dbc047d8ad67f-- From subbu@subbu.org Wed Jan 20 13:39:01 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA8028C105 for ; Wed, 20 Jan 2010 13:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkntY1TdFqk5 for ; Wed, 20 Jan 2010 13:39:00 -0800 (PST) Received: from mail-bw0-f212.google.com (mail-bw0-f212.google.com [209.85.218.212]) by core3.amsl.com (Postfix) with ESMTP id B1CB928C0D8 for ; Wed, 20 Jan 2010 13:38:59 -0800 (PST) Received: by bwz4 with SMTP id 4so6113990bwz.2 for ; Wed, 20 Jan 2010 13:38:52 -0800 (PST) Received: by 10.102.209.14 with SMTP id h14mr294410mug.25.1264023532004; Wed, 20 Jan 2010 13:38:52 -0800 (PST) Received: from wlanvpn-mc2e-246-145.corp.yahoo.com (nat-dip10.cfw-b-gci.corp.yahoo.com [209.131.62.145]) by mx.google.com with ESMTPS id 25sm1329363mul.50.2010.01.20.13.38.49 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Jan 2010 13:38:50 -0800 (PST) Subject: Re: New Version Notification - draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Subbu Allamaraju In-Reply-To: Date: Wed, 20 Jan 2010 13:38:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100119053002.5CD613A683B@core3.amsl.com> To: Mark Nottingham X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Thu, 21 Jan 2010 08:13:59 -0800 Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 21:39:01 -0000 The usage of fields is not clear. Sec. 6.3 says that "entries in the = Link Relation Type Registry can be extended with application-specific = data". But the BNF in Sec. 5 does not specify fields. Could you clarify = the intent of fields? Subbu On Jan 18, 2010, at 9:31 PM, Mark Nottingham wrote: >=20 >=20 > Begin forwarded message: >=20 >> From: Internet-Draft@ietf.org >> Date: 19 January 2010 4:30:02 PM AEDT >> To: mnot@pobox.com, = draft-nottingham-http-link-header@tools.ietf.org,lisa.dusseault@gmail.com >> Subject: New Version Notification - = draft-nottingham-http-link-header-07.txt=20 >>=20 >> New version (-07) has been submitted for = draft-nottingham-http-link-header-07.txt. >> = http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-07.t= xt >> Sub state has been changed to AD Follow up from New Id Needed >>=20 >> Diff from previous version: >> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-link-header-07 >>=20 >> IETF Secretariat. >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 From adam@adambarth.com Wed Jan 20 15:15:04 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D104B3A6992 for ; Wed, 20 Jan 2010 15:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.756 X-Spam-Level: X-Spam-Status: No, score=-0.756 tagged_above=-999 required=5 tests=[AWL=-1.234, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPDhdyMmBeDA for ; Wed, 20 Jan 2010 15:15:03 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id C117D3A6AA7 for ; Wed, 20 Jan 2010 15:15:03 -0800 (PST) Received: by pxi16 with SMTP id 16so4083820pxi.29 for ; Wed, 20 Jan 2010 15:14:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.247.10 with SMTP id u10mr441731wfh.132.1264029297074; Wed, 20 Jan 2010 15:14:57 -0800 (PST) In-Reply-To: References: From: Adam Barth Date: Wed, 20 Jan 2010 15:14:37 -0800 Message-ID: <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.com> Subject: Re: comments on draft-abarth-mime-sniff-03 To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 21 Jan 2010 08:14:01 -0800 Cc: Ian Hickson , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 23:15:04 -0000 Thanks Larry. These are great comments. I'll incorporate them when I next update the draft. To answer a couple of your questions: On Wed, Jan 20, 2010 at 2:41 PM, Larry Masinter wrote: > A message with more than one content-type header > should be treated as malformed. What does it mean to treat the response as malformed? I've seen examples of servers that blissfully send more than one Content-Type header. This document just describes how to process the responses without making a judge about whether the server is acting properly or not. > The "algorithm for extracting an encoding ...." [...] > The nature of the "willful violation" > (I.e., how it is different) and the > justification for the "willful violation" > should be included. I can't fathom any > justification for it. Charset sniffing is required to avoid ugly replacement characters from being shown to the user. Sad, but true. > file extensions: > > =A0Note: It is essential that file extensions > =A0are not used for determining the media type > =A0 for resources fetched over HTTP because > =A0file extensions can often by supplied by > =A0 malicious parties. > > =A0"Often" is dubious. How can file extensions be > supplied more often than =A0content-type headers? For example, the attacker can chose the file extension in most PHP installations because foo.php happily processes: http://example.com/foo.php/bar.qux > What is the security threat? The security threat is that if you treat an HTML file extension as evidence the server wants the response to be treated as text/html you will introduce XSS vulnerabilities into some large number of sites running PHP (among others). > I'd think that the behavior of "how to sniff" > should start out with what the inputs are > (the first N bytes of some data from a response). This business about waiting for 512 bytes has to do with a poor interaction between buffering for sniffing and Comet . Basically, if you wait forever for the 512 bytes you need to sniff completely, then you break things like chat in Gmail. For example, Gmail chat used to not work in Safari for this reason. However, always using the first chunk of data off the network to sniff means you'll get unpredictable results based on how exactly the response was chunked. Hence the advice to wait for 512 bytes but not a requirement to wait forever. Adam From david@dbooth.org Wed Jan 20 16:54:03 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABAFF3A6859 for ; Wed, 20 Jan 2010 16:54:03 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9y48827kwdR for ; Wed, 20 Jan 2010 16:54:02 -0800 (PST) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by core3.amsl.com (Postfix) with SMTP id A15743A6828 for ; Wed, 20 Jan 2010 16:54:02 -0800 (PST) Received: (qmail 34518 invoked from network); 21 Jan 2010 00:53:57 -0000 Received: from 184.49.60.155 (HELO ?184.49.60.155?) (184.49.60.155) by relay03.pair.com with SMTP; 21 Jan 2010 00:53:57 -0000 X-pair-Authenticated: 184.49.60.155 Subject: Comments on content sniffing algorithm draft-abarth-mime-sniff-03 From: David Booth To: apps-discuss Content-Type: text/plain; charset="UTF-8" Date: Wed, 20 Jan 2010 19:53:56 -0500 Message-ID: <1264035236.23097.29453.camel@dbooth-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 21 Jan 2010 08:14:00 -0800 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 00:54:03 -0000 Some comments on http://tools.ietf.org/html/draft-abarth-mime-sniff-03 1. This point is not a criticism of the sniffing algorithm proposed, but rather a comment on the way that the problem is described. I don't have a specific suggestion for rewording, so perhaps you should just take this first comment as food for thought. It bothers me to see HTML being called a "high-privilege media type" . . . "(and thus privileged to execute any scripts contained therein)". It isn't the basic HTML that is dangerous, it is JavaScript that has been embedded in HTML that is dangerous, just as Flash, ActiveX or any other scripting language may be embedded. Basic HTML is relatively safe. HTML is really just embedded in text, just as JavaScript is embedded in HTML, yet we don't think of plain text as a high-privilege media type because our content types distinguish plain text from text that "embeds" HTML. But they do not distinguish plain HTML from HTML that embeds JavaScript or other scripting languages. This forces us to paint plain HTML with the same security brush as we paint JavaScript, and this seems wrong. 2. Section 2 says "The algorithm for extracting an encoding from a Content-Type, given a string s, is as follows." But what exactly is string s? Where is s bound? Is s the Content-Type? 3. Section 3.1 says "the last step in this set of steps". I think it would be slightly clearer to say "step 9", though this is perhaps a minor stylistic issue. 4. There are several uses of the word "resource" that should be "entity body", as this is the term used in RFC2616 section 14.17: http://tools.ietf.org/html/rfc2616#section-14.17 5. Section 3.3 says "the last such header has bytes that exactly match". I suggest changing the word "has" to be more specific, as "has" often means "contains", and I do not think "contains" is what you meant. (For example, one might say "File x has the word 'Foo' in it".) 6. Section 3 defines the term /sniffed type/, which is either sniffed or the /official type/. This is a little misleading. I suggest distinguishing three terms: /sniffed type/, which really is the sniffed type; /official type/, as already defined; and /effective type/, which is determined by your algorithm based on either /sniffed type/ or /effective type/. 7. Section 3.4 says "jump to the unknown type step below", but it is not clear what step you mean. Since the steps are numbered, it would be better to give the target step number instead of "the unknown type step below". [After reading further] Oh, it looks like you may have meant to refer to Section 5. 8. Section 4.2 says "already available". After how much time or after what event? 9. Section 4.4. mentions "binary data bytes". Where is this term defined? I.e., how exactly are binary data bytes identified? -- David Booth, Ph.D. Cleveland Clinic (contractor) Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic. From asplake@googlemail.com Thu Jan 21 07:01:34 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250AF3A68F4 for ; Thu, 21 Jan 2010 07:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.976 X-Spam-Level: X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TBi5WaaVnwr for ; Thu, 21 Jan 2010 07:01:33 -0800 (PST) Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by core3.amsl.com (Postfix) with ESMTP id 0D5973A68DB for ; Thu, 21 Jan 2010 07:01:33 -0800 (PST) Received: by pzk33 with SMTP id 33so36961pzk.2 for ; Thu, 21 Jan 2010 07:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=hY6hgQUi60+YxbjD0DH4aim8wSWvpx22K8ZTdAGT4Q0=; b=lUhvcf7US+XMaDZzNBRb7z86JoA0rkrUSl4obM4D5sCTqkx3saIM2sHOakWHiNpkOX pkHC8jfgIQuWWJmNpcSpb3hhcK2AVYl4fpGJiRjZqJ0Nn0bxtbFQwPR0JH7dn7CbfVf+ jVxm2bcPEg35HX2qoiDXsDaMjSs/a9CtNe5zk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=pjKZIF4uIYFWMJaURLwb+6IPSHT92xnAF1QLhEs73d8Xl01twhqJljK3+HXJlK/GGQ HHTH+6NkyPJv+wtAh/vphb8ucR9TkCW9PuG1yzXzP92+Tu9GX7bptKgMfny4UWLcRpt2 GqwOZWN23y7YgGE104oVgLWIKwRIk9WsBI3DA= MIME-Version: 1.0 Sender: asplake@googlemail.com Received: by 10.141.12.10 with SMTP id p10mr1114613rvi.77.1264086085860; Thu, 21 Jan 2010 07:01:25 -0800 (PST) In-Reply-To: <4B585B06.1040704@gmx.de> References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B585B06.1040704@gmx.de> Date: Thu, 21 Jan 2010 16:01:25 +0100 X-Google-Sender-Auth: 9db4cf412d22c1fe Message-ID: <7a2269961001210701t15ea51cdmf48cc696282c44b6@mail.gmail.com> Subject: Re: parameter quoting - LC comment on draft-nottingham-http-link-header-07.txt From: Mike Burrows To: Julian Reschke Content-Type: multipart/alternative; boundary=000e0cd106121cfc6d047dadfa63 X-Mailman-Approved-At: Thu, 21 Jan 2010 08:13:58 -0800 Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mjb@asplake.co.uk List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 15:01:34 -0000 --000e0cd106121cfc6d047dadfa63 Content-Type: text/plain; charset=ISO-8859-1 Hi Julian (and all), Which made have a closer look at existing parameters (sorry for not bringing > this up earlier): > > | ( "type" "=" type-name "/" subtype-name ) > > I believe this *definitively* needs quoting, as "/" is a separator > character in HTTP and thus can not appear in a token. > But is 'type-name "/" subtype-name' a token? I didn't interpret as such - in fact I assumed (perhaps erroneously) that it was in fact two tokens separated by "/". Regards, Mike 2010/1/21 Julian Reschke > Hi, > > a few comments regarding quoting of link parameters: > > > defines the new parameters: > > | ( "hreflang" "=" Language-Tag ) > | ( "media" "=" ( MediaDesc | <"> MediaDesc <"> ) ) > > "hreflang" and "media", so quoting is allowed for media, but it's not for > hreflang. I think it's correct that valid language tags never require > quoting, but I'm not sure that disallowing quoting is the right thing to do > here. > > Which made have a closer look at existing parameters (sorry for not > bringing this up earlier): > > | ( "type" "=" type-name "/" subtype-name ) > > I believe this *definitively* needs quoting, as "/" is a separator > character in HTTP and thus can not appear in a token. > > Also, as this spec uses the RFC 2616 ABNF, we probably need to duplicate > the statement from < > http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.7>: > > "...Linear white space (LWS) MUST NOT be used between the type and subtype, > ..." > > Best regards, Julian > > > > > > > > --000e0cd106121cfc6d047dadfa63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Julian (and all),

Which made have a closer look at existing parameters (sorry for not bringin= g this up earlier):

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | ( "type" "=3D&quo= t; type-name "/" subtype-name )

I believe this *definitively* needs quoting, as "/" is a separato= r character in HTTP and thus can not appear in a token.

But is 'type-name "/" subtype-name' a token?=A0 I did= n't interpret as such - in fact I assumed (perhaps erroneously) that it= was in fact two tokens separated by "/".

Regards,
Mike=


2010/1/21 Julian Reschke <julian.reschke@gmx.de&g= t;
Hi,

a few comments regarding quoting of link parameters:

<http://tools.ietf.org/html/draft-nottingha= m-http-link-header-07#section-5> defines the new parameters:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | ( "hreflang" "=3D= " Language-Tag )
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | ( "media" "=3D&qu= ot; ( MediaDesc | <"> MediaDesc <"> ) )

"hreflang" and "media", so quoting is allowed for media= , but it's not for hreflang. I think it's correct that valid langua= ge tags never require quoting, but I'm not sure that disallowing quotin= g is the right thing to do here.

Which made have a closer look at existing parameters (sorry for not bringin= g this up earlier):

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | ( "type" "=3D&quo= t; type-name "/" subtype-name )

I believe this *definitively* needs quoting, as "/" is a separato= r character in HTTP and thus can not appear in a token.

Also, as this spec uses the RFC 2616 ABNF, we probably need to duplicate th= e statement from <http://greenbytes.de/tech/webdav/rfc2= 616.html#rfc.section.3.7>:

"...Linear white space (LWS) MUST NOT be used between the type and sub= type, ..."

Best regards, Julian








--000e0cd106121cfc6d047dadfa63-- From ogud@ogud.com Thu Jan 21 08:25:10 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C89728C169; Thu, 21 Jan 2010 08:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ih8ELz751f8; Thu, 21 Jan 2010 08:25:07 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id DCEA028C178; Thu, 21 Jan 2010 08:25:02 -0800 (PST) Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0LGOsxh009135; Thu, 21 Jan 2010 11:24:54 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <201001211624.o0LGOsxh009135@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 21 Jan 2010 11:24:49 -0500 To: Magnus Westerlund , Alfred =?iso-8859-1?Q?=EF=BF=BD?= From: Olafur Gudmundsson Subject: Re: [port-srv-reg] [tsvwg] "assigned" ( vs. "registered"), and relates issues In-Reply-To: <4B545096.4020300@ericsson.com> References: <201001151840.TAA14644@TR-Sys.de> <4B545096.4020300@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: port-srv-reg@ietf.org, apps-discuss@ietf.org, tsvwg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 16:25:10 -0000 Magnus, Can someone kill the signature on this list, it=20 messes up messages that are sent in base64 encoding like your messages, this is what they look like in my email reader. Comments on message at the end. At 07:14 18/01/2010, Magnus Westerlund wrote: >Hi Alfred, I have now read=20 >draft-gudmundsson-dnsext-srv-clarify-00 again.=20 >Me personally hasn't really digged into the=20 >issues that you bring up in your document, I=20 >don't think I am alone in this. Thus, I think it=20 >would be jumping to conclusions that there are=20 >agreement on your suggested approach simple=20 >because you haven't received comments on them=20 >yet. From the perspective of trying to advance=20 >draft-ietf-tsvwg-iana-ports, we do come down to=20 >trying to find the reasonable interface between=20 >our documents. On the issue of the protocol=20 >label for a given service name. I find it=20 >reasonable that your document do extended the=20 >registry with an additional column that=20 >enumerates any non-default protocol label order.=20 >I get the impression that you want this to be=20 >described in draft-ietf-tsvwg-iana-ports due to=20 >that it should be included in any service name=20 >registration request. I had hoped that we could=20 >avoid normative dependencies from IANA ports=20 >towards draft-gudmundsson-dnsext-srv-clarify.=20 >This to enable draft-ietf-tsvwg-iana-ports to be=20 >approved and published as soon as possible. From=20 >my perspective I see three ways forward: 1. We=20 >write nothing about the protocol label in=20 >regards to Service name registrations and lets=20 >draft-gudmundsson-dnsext-srv-clarify update the=20 >Registration RFC. 2. We include some text about=20 >the need to specify protocol label priority list=20 >unless the default one (also included listed in=20 >draft-ietf-tsvwg-iana-ports) but pushing of the=20 >explanation about the issues to your document=20 >using a normative reference. 3. We fudge=20 >something together in the middle trying to avoid=20 >a normative reference. I think I am leaning=20 >towards 1 personally even if it has some obvious=20 >downside in that the registration rules=20 >information will not be contained to a single=20 >document. However, I think IANA's registration=20 >template can clearly make it clear to applicants=20 >that you need to read things in both. Cheers=20 >Magnus Westerlund IETF Transport Area Director=20 >----------------------------------------------------------------------=20 >Multimedia Technologies, Ericsson Research=20 >EAB/TVM=20 >----------------------------------------------------------------------=20 >Ericsson AB | Phone +46 10=20 >7148287 F=C3=A4r=C3=B6gatan 6 | Mobile=20 >+46 73 0949079 SE-164 80 Stockholm, Sweden|=20 >mailto: magnus.westerlund@ericsson.com=20 >----------------------------------------------------------------------=20 >_______________________________________________=20 >Port-srv-reg mailing list Port-srv-reg@ietf.org=20 >https://www.ietf.org/mailman/listinfo/port-srv-reg References and updates: there are two issues draft-gudmundsson-dnsext-srv-clarify updates RFC2782 draft-ietf-tsvwg-iana-ports also updates RFC2782 Is it necessary that both update 2782 ? draft-gudmundsson-dnsext-srv-clarify has normative reference to draft-ietf-tsvwg-iana-ports and -ports- should have a Informational= reference to the first one. Both documents should be advanced at the same time IMHO, as they are complementary. -srv-clarify- is roughly complete, just pending resolving issues related to what document does what. I think the only action that -ports- is performing on 2782 is to link the registry (and restrict the length), that same action and more are performed in srv-clarify. We should work out exactly which document does what and where text and actions need to be moved around. I find it strange that by reading -ports- I do not get a any idea what the registry will look like, thus I can not judge if the registry is meeting expectations :-) Please update section 10 to include a list of columns in the registry and what the role of each column is. Here is what I think it should at least be included: Service name | Port number(s) | Transports (list) | Notes | Reference Reference can be RFC or the application Transports could be one column or multiple ones. If Transports is a single column then it can incorporate the priority order that we talk about in -srv-clarify- as that applies to ports usage as well. Any text/ideas related to the format of the registry should be in -ports- and we would prefer not the change the format of the registry, all we want= to is to explain how to use it. This is basically your suggestion #2. As soon as we see the format of the registry we=20 can crack out the third document in this series that takes actions on old RFC and registries to move the registrations into the new registry and close the sub-SRV registries that= have created due to the lack of real SRV registry. Olafur From touch@ISI.EDU Thu Jan 21 10:10:54 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34453A6AC6; Thu, 21 Jan 2010 10:10:54 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-OYuK1jBppr; Thu, 21 Jan 2010 10:10:49 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id C56A13A6AC9; Thu, 21 Jan 2010 10:10:49 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o0LI9ojf015580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jan 2010 10:09:51 -0800 (PST) Message-ID: <4B58986D.8020403@isi.edu> Date: Thu, 21 Jan 2010 10:09:49 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tom.petch" Subject: Re: [tsvwg] New version of document for review References: <001701ca99aa$a75906c0$0601a8c0@allison> In-Reply-To: <001701ca99aa$a75906c0$0601a8c0@allison> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD152810E8961EF350753150F" X-MailScanner-ID: o0LI9ojf015580 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Michelle Cotton , tsvwg@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 18:10:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD152810E8961EF350753150F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable tom.petch wrote: > Michele >=20 > You said that feedback would be appreciated:-) >=20 > I have a problem with this I-D in that it would appear to make no > distinction between allocation and assignment, and would seem to > include registration in the mix as well, at least at times, while hinti= ng that > whatever these may be, ownership is something else. In the limited con= text of > transport > identifiers, this may not cause confusion but in closely allied registr= ies, > allocation and assignment are fundamentally different processes and tho= se who > interchange the two are confused and cause confusion. >=20 > If, as I suspect, you are using the terms interchangeably, then at the = very > least you need a terminology section as 1.1 to say that the two (or thr= ee) terms > are used interchangeably, but for myself, I would regard this as inadeq= uate. > Really, you should choose one and eliminate the other(s) with a brief n= ote to > say that > historically, both were used but as of now, a........ is the correct te= rm. >=20 > More fundamentally, this I-D is largely about a bureaucratic process wi= thout > stating clearly, IMO, what the point of this process is, except to gene= rate > bureaucracy (and confusion over this would appear to have triggered som= e > discussion recently on the tsvwg list). The I-D should state up front,= not hint > at it in section 7, just why this bureaucracy should exist, of what ben= efit it > would be bureaucracy is to the IETF etc. The I-D argues for improving = the > bureacracy, not for why it should exist. FWIW, I thought the doc was already clear that the bureaucracy *already* exists, and this is an update to the existing procedures. The alternative is to continue to say "IANA figures it out" - which is basically how things work now, AFAICT. That's fine with me too. Joe --------------enigD152810E8961EF350753150F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAktYmG4ACgkQE5f5cImnZruIggCeK8m3zpycQmAVHNS4WWL5vDTs 9/kAoJzI2eooJgmqDtDh1U1bUFBLs91b =QOsD -----END PGP SIGNATURE----- --------------enigD152810E8961EF350753150F-- From mnot@mnot.net Thu Jan 21 16:43:33 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B0D3A6AEC for ; Thu, 21 Jan 2010 16:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.377 X-Spam-Level: X-Spam-Status: No, score=-4.377 tagged_above=-999 required=5 tests=[AWL=-1.778, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL3RWCnYI-Lo for ; Thu, 21 Jan 2010 16:43:32 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id AA5A93A67B7 for ; Thu, 21 Jan 2010 16:43:32 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.167.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6C93D22E253; Thu, 21 Jan 2010 19:43:21 -0500 (EST) Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B584E46.7000405@gmx.de> Date: Fri, 22 Jan 2010 11:43:18 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 00:43:33 -0000 On 21/01/2010, at 11:53 PM, Julian Reschke wrote: > So it appears that this change does not "allow applications to = ignore", but "requires applications to specify how to process", so it's = an "opt in", not an "opt out". Yes, sorry; forgot to (re-)update the changelog on that one. > That being said: what is an "application" in this context? What needs = to be done to specify this? An example would be useful; for instance, it = would be interesting what = would need to say to specify the required processing of anchor. Yes, it would. "Application" is intentionally a bit fuzzy, because while = some link relations are defined by their application, others have been = purposefully separated; e.g., "alternate" is used for a variety of = purposes. > In general I think that making this somehow optional will be an = interop disaster. Link header processing should be uniform and not = depend on some out-of-band information. >=20 > If the reason this was changed was because of missing support in those = UAs that currently handle the "Link" header: let's file bugs. It wasn't, and the link header parsing is the same; it's just the = interpretation that changes, depending on whether the application = expects the anchor parameter to be used. This was done because in many = (or even most) instances, it's very surprising to have a link from A to = B to be able to assert things about C, and have their semantics = automatically applied.=20 Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Thu Jan 21 16:53:48 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6DD3A67F6 for ; Thu, 21 Jan 2010 16:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.417 X-Spam-Level: X-Spam-Status: No, score=-4.417 tagged_above=-999 required=5 tests=[AWL=-1.818, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3Voe52+Snnt for ; Thu, 21 Jan 2010 16:53:47 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id AFEA43A67BD for ; Thu, 21 Jan 2010 16:53:47 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.167.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8E8B122E1F3; Thu, 21 Jan 2010 19:53:40 -0500 (EST) Subject: Re: parameter quoting - LC comment on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B586DF0.9010201@gmx.de> Date: Fri, 22 Jan 2010 11:53:37 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B585B06.1040704@gmx.de> <7a2269961001210701t15ea51cdmf48cc696282c44b6@mail.gmail.com> <4B586DF0.9010201@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group , mjb@asplake.co.uk X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 00:53:48 -0000 I agree in principle, but practically, it's almost a foregone conclusion = that people will produce these unquoted, and implementations will = consume them happily. I'd rather align with what is done in practice, = even if it does preclude using a generic parser... On 22/01/2010, at 2:08 AM, Julian Reschke wrote: > Mike Burrows wrote: >> Hi Julian (and all), >> Which made have a closer look at existing parameters (sorry for = not >> bringing this up earlier): >> | ( "type" "=3D" type-name "/" subtype-name ) >> I believe this *definitively* needs quoting, as "/" is a separator >> character in HTTP and thus can not appear in a token. >> But is 'type-name "/" subtype-name' a token? I didn't interpret as = such - in fact I assumed (perhaps erroneously) that it was in fact two = tokens separated by "/". >> Regards, >> Mike >> ... >=20 > You are right, it's not. But, in general, parameter values either take = tokens or quoted-strings, so a generic parser of HTTP parameters would = fail to parse this correctly. >=20 > Maybe that's not a big issue in practice, because people use custom = parser per header field, but it would be good if we could avoid that. >=20 > Best regards, Julian > _______________________________________________ > 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 Thu Jan 21 17:02:52 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E800228C116 for ; Thu, 21 Jan 2010 17:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.445 X-Spam-Level: X-Spam-Status: No, score=-4.445 tagged_above=-999 required=5 tests=[AWL=-1.846, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5nX93VhezZ8 for ; Thu, 21 Jan 2010 17:02:51 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 91E2128C10F for ; Thu, 21 Jan 2010 17:02:51 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.167.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 60B3322E247; Thu, 21 Jan 2010 20:02:45 -0500 (EST) Subject: Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B58574B.4050204@gmx.de> Date: Fri, 22 Jan 2010 12:02:42 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B58574B.4050204@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 01:02:53 -0000 On 22/01/2010, at 12:31 AM, Julian Reschke wrote: >=20 > So the grammar in = lists it as regular link parameter: >=20 > link-param =3D ( ( "rel" "=3D" relation-types ) > | ( "anchor" "=3D" <"> URI-Reference <"> ) > | ( "rev" "=3D" relation-types ) > | ( "hreflang" "=3D" Language-Tag ) > | ( "media" "=3D" ( MediaDesc | <"> MediaDesc <"> = ) ) > | ( "title" "=3D" quoted-string ) > | ( "title*" "=3D" enc2231-string ) > | ( "type" "=3D" type-name "/" subtype-name ) > | ( link-extension ) ) >=20 > On the other hand, = states: >=20 > The relation type of a link is conveyed in the "rel" parameter's > value. Note that the "rev" parameter has also been used by some > formats, and MAY be accommodated as a link-extension, but its use is > neither encouraged nor defined by this specification. >=20 > So the ABNF defines it as parameter, but the prose claims it's not = specified, and could be specified later on as extension. I'm happy to remove it from the BNF if that doesn't disturb the very = delicate consensus we have on this topic. Comments from others? > Speaking of which, how do I define an extension? Standards Track RFC = updating this one, as there is no registry? If you like. Practically speaking, I think many extensions will be used = without such registration, as they'll be specific to the format and/or = application in use -- which I think is just fine. > Later on, in the section about HTML4 we find = (): >=20 > HTML4 also has a "rev" parameter for links that allows a link's > relation to be reversed. The Link header does not define a > corresponding "rev" parameter to allow the expression of these links > in HTTP headers, due to the confusion this mechanism causes as well > as conflicting interpretations (briefly, some hold that rev reverses > the direction of the link, while others that it reverses the > semantics of the relation itself). >=20 > I have to admit that I'm still not sure what *in practice* the = difference between reversing the link direction and reversing the link = semantics actually is. (Example?) I can add a brief example for the latter. > So my preference would be to actually define the rev parameter = consistently with this, and then to discourage it's use due to the other = good reasons we heard about that (such as HTML authors typing "rev" = instead of "rel"). As previous discussed (quite a bit), HTML2 defines REV as having = reversed *semantics*, while HTML4 talks about it creating a "reverse = link" -- which are very different things. This feels like a rat hole to = me (thus my attempts to navigate around it). Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Thu Jan 21 17:05:27 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64DE128C122 for ; Thu, 21 Jan 2010 17:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.466 X-Spam-Level: X-Spam-Status: No, score=-4.466 tagged_above=-999 required=5 tests=[AWL=-1.867, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJBk2VmjsqrY for ; Thu, 21 Jan 2010 17:05:26 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 8CBDE28C116 for ; Thu, 21 Jan 2010 17:05:26 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.167.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0D36F22E1F3; Thu, 21 Jan 2010 20:05:20 -0500 (EST) Subject: Re: editorial LC comments on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B585EFF.2080104@gmx.de> Date: Fri, 22 Jan 2010 12:05:17 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B585EFF.2080104@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 01:05:27 -0000 Thanks! One note -=20 > Please make the W3C references consistent: W3C instead of "Word Wide = Web > Consortium", and make sure the URIs use the current format (trailing = slash). > Optimally, also reduce the length of the anchor names (I'll be happy = to > supply diffs). These refs are straight from xml.resource.org; probably the most = efficient way to solve this problem would be to work with them? Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Thu Jan 21 19:46:44 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8A93A680B for ; Thu, 21 Jan 2010 19:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.377 X-Spam-Level: X-Spam-Status: No, score=-4.377 tagged_above=-999 required=5 tests=[AWL=-1.778, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dorSDWz1iKWo for ; Thu, 21 Jan 2010 19:46:38 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 6BFE03A67F8 for ; Thu, 21 Jan 2010 19:46:38 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.167.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1BD0322E254; Thu, 21 Jan 2010 22:46:26 -0500 (EST) Subject: Re: New Version Notification - draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <7a2269961001191306i9bf78c1oe55f574166874944@mail.gmail.com> Date: Fri, 22 Jan 2010 14:46:23 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100119053002.5CD613A683B@core3.amsl.com> <7a2269961001191306i9bf78c1oe55f574166874944@mail.gmail.com> To: mjb@asplake.co.uk X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 03:46:45 -0000 Thanks, Mike; looks interesting.=20 I have a less functional implementation at = ; it would be interesting to compare = notes. Cheers, On 20/01/2010, at 8:06 AM, Mike Burrows wrote: >=20 > Thanks, and nice timing - I've just ported my link header rubygem to = Python - see http://pypi.python.org/pypi/LinkHeader/0.1 or = http://bitbucket.org/asplake/link_header/. >=20 > The Python version is rather smarter about when to quote attribute = values (I should port this back to Ruby), but they are otherwise similar = in functionality - parsing, formatting and conversion to/from = json-friendly structures. >=20 > Caveat: I've made no serious attempt (in either language) to parse = title* attributes ("title*" "=3D" enc2231-string) but if anyone has need = of them (or has any other feedback for that matter) please get in touch = privately and I will see what I can do. >=20 > Regards, > Mike > mjb@asplake.co.uk > http://positiveincline.com > http://twitter.com/asplake >=20 >=20 > 2010/1/19 Mark Nottingham >=20 >=20 > Begin forwarded message: >=20 > > From: Internet-Draft@ietf.org > > Date: 19 January 2010 4:30:02 PM AEDT > > To: mnot@pobox.com, = draft-nottingham-http-link-header@tools.ietf.org,lisa.dusseault@gmail.com > > Subject: New Version Notification - = draft-nottingham-http-link-header-07.txt > > > > New version (-07) has been submitted for = draft-nottingham-http-link-header-07.txt. > > = http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-07.t= xt > > Sub state has been changed to AD Follow up from New Id Needed > > > > Diff from previous version: > > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-link-header-07 > > > > IETF Secretariat. >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 >=20 -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Fri Jan 22 00:40:03 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957793A68BD for ; Fri, 22 Jan 2010 00:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.715 X-Spam-Level: X-Spam-Status: No, score=-3.715 tagged_above=-999 required=5 tests=[AWL=-1.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsifD+jVmA7c for ; Fri, 22 Jan 2010 00:40:02 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 44D5F3A68C4 for ; Fri, 22 Jan 2010 00:40:01 -0800 (PST) Received: (qmail invoked by alias); 22 Jan 2010 08:39:54 -0000 Received: from p508FD092.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.208.146] by mail.gmx.net (mp003) with SMTP; 22 Jan 2010 09:39:54 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/cYvsTgTPckoGVEok9U1wmU+v++m5qYLO7760+Tz 960JHN0nueQePi Message-ID: <4B596450.7020001@gmx.de> Date: Fri, 22 Jan 2010 09:39:44 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Mark Nottingham Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> In-Reply-To: <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57999999999999996 Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 08:40:03 -0000 Mark Nottingham wrote: > On 21/01/2010, at 11:53 PM, Julian Reschke wrote: > >> So it appears that this change does not "allow applications to ignore", but "requires applications to specify how to process", so it's an "opt in", not an "opt out". > > Yes, sorry; forgot to (re-)update the changelog on that one. > >> That being said: what is an "application" in this context? What needs to be done to specify this? An example would be useful; for instance, it would be interesting what would need to say to specify the required processing of anchor. > > Yes, it would. "Application" is intentionally a bit fuzzy, because while some link relations are defined by their application, others have been purposefully separated; e.g., "alternate" is used for a variety of purposes. OK, what needs to be done to specify this? >> In general I think that making this somehow optional will be an interop disaster. Link header processing should be uniform and not depend on some out-of-band information. >> >> If the reason this was changed was because of missing support in those UAs that currently handle the "Link" header: let's file bugs. > > It wasn't, and the link header parsing is the same; it's just the interpretation that changes, depending on whether the application expects the anchor parameter to be used. This was done because in many (or even most) instances, it's very surprising to have a link from A to B to be able to assert things about C, and have their semantics automatically applied. Both *parsing* and *processing* should be uniform. I'm ok with allowing recipients to *reject* (*) link headers that include the anchor parameter. On the other hand *ignoring* it needs to be a bug. Best regards, Julian (*) treat it as invalid From julian.reschke@gmx.de Fri Jan 22 01:02:29 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F823A68AA for ; Fri, 22 Jan 2010 01:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZifkVDbTesd for ; Fri, 22 Jan 2010 01:02:28 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 534B03A6835 for ; Fri, 22 Jan 2010 01:02:27 -0800 (PST) Received: (qmail invoked by alias); 22 Jan 2010 09:02:20 -0000 Received: from p508FD092.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.208.146] by mail.gmx.net (mp057) with SMTP; 22 Jan 2010 10:02:20 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/2I3deK2P2JxXm8RxJgwTgf+r4GPEGoCixzUBhCJ aBPPc169mveJ2I Message-ID: <4B59698C.60105@gmx.de> Date: Fri, 22 Jan 2010 10:02:04 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Mark Nottingham Subject: Re: parameter quoting - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B585B06.1040704@gmx.de> <7a2269961001210701t15ea51cdmf48cc696282c44b6@mail.gmail.com> <4B586DF0.9010201@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.70999999999999996 Cc: Apps Discuss , HTTP Working Group , mjb@asplake.co.uk X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 09:02:29 -0000 Mark Nottingham wrote: > I agree in principle, but practically, it's almost a foregone conclusion that people will produce these unquoted, and implementations will consume them happily. I'd rather align with what is done in practice, even if it does preclude using a generic parser... > ... I just did some testing with the two UAs I have that actually do something the the Link header; Firefox and Opera. Both process the type parameter both quoted and unquoted. So minimally the ABNF should allow both. That being said, given the little amount of deployment, I'd *much* prefer to make the ABNF consistent with generic parameter parsing, and potentially just add a statement that unquoted type parameters may occur in the wild (*) and may have to be accepted as well. Best regards, Julian (*) do they, outside of test cases? From julian.reschke@gmx.de Fri Jan 22 01:09:25 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC753A68F5 for ; Fri, 22 Jan 2010 01:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.869 X-Spam-Level: X-Spam-Status: No, score=-3.869 tagged_above=-999 required=5 tests=[AWL=-1.270, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQoZiGp8uUzo for ; Fri, 22 Jan 2010 01:09:24 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B6AA33A6915 for ; Fri, 22 Jan 2010 01:09:23 -0800 (PST) Received: (qmail invoked by alias); 22 Jan 2010 09:09:15 -0000 Received: from p508FD092.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.208.146] by mail.gmx.net (mp052) with SMTP; 22 Jan 2010 10:09:15 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/Lgw1mlkzLc+vtuMOyIOOzMgcirIgzRe92QAXvL/ fGsBDn1bUKVlOt Message-ID: <4B596B30.1030400@gmx.de> Date: Fri, 22 Jan 2010 10:09:04 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Mark Nottingham Subject: Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B58574B.4050204@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.56999999999999995 Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 09:09:25 -0000 Mark Nottingham wrote: > ... > I'm happy to remove it from the BNF if that doesn't disturb the very delicate consensus we have on this topic. Comments from others? > ... Optimally, it gets defined. Otherwise it should be clear through which path somebody else can define it. >> Speaking of which, how do I define an extension? Standards Track RFC updating this one, as there is no registry? > > If you like. Practically speaking, I think many extensions will be used without such registration, as they'll be specific to the format and/or application in use -- which I think is just fine. > >> Later on, in the section about HTML4 we find (): >> >> HTML4 also has a "rev" parameter for links that allows a link's >> relation to be reversed. The Link header does not define a >> corresponding "rev" parameter to allow the expression of these links >> in HTTP headers, due to the confusion this mechanism causes as well >> as conflicting interpretations (briefly, some hold that rev reverses >> the direction of the link, while others that it reverses the >> semantics of the relation itself). >> >> I have to admit that I'm still not sure what *in practice* the difference between reversing the link direction and reversing the link semantics actually is. (Example?) > > I can add a brief example for the latter. Please. >> So my preference would be to actually define the rev parameter consistently with this, and then to discourage it's use due to the other good reasons we heard about that (such as HTML authors typing "rev" instead of "rel"). > > As previous discussed (quite a bit), HTML2 defines REV as having reversed *semantics*, while HTML4 talks about it creating a "reverse link" -- which are very different things. This feels like a rat hole to me (thus my attempts to navigate around it). Again, HTML 2 defines it as: REV same as the REL attribute, but the semantics of the relationship are in the reverse direction. A link from A to B with REL="X" expresses the same relationship as a link from B to A with REV="X". An anchor may have both REL and REV attributes. () That totally sounds like "reverse link" to me. So, I really really think there's less confusion than some people claim. Best regards, Julian From subbu@subbu.org Fri Jan 22 10:19:46 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3A728C127 for ; Fri, 22 Jan 2010 10:19:46 -0800 (PST) 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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa0vblQVwGmz for ; Fri, 22 Jan 2010 10:19:45 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 41ABA3A6AA7 for ; Fri, 22 Jan 2010 10:19:45 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e21so30076fga.16 for ; Fri, 22 Jan 2010 10:19:38 -0800 (PST) Received: by 10.87.51.9 with SMTP id d9mr5401230fgk.35.1264184377526; Fri, 22 Jan 2010 10:19:37 -0800 (PST) Received: from ?192.168.0.196? (nat-dip6.cfw-a-gci.corp.yahoo.com [209.131.62.115]) by mx.google.com with ESMTPS id 15sm1433571fxm.2.2010.01.22.10.19.34 (version=SSLv3 cipher=RC4-MD5); Fri, 22 Jan 2010 10:19:36 -0800 (PST) Subject: Re: New Version Notification - draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Subbu Allamaraju In-Reply-To: Date: Fri, 22 Jan 2010 10:19:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0460AF05-93FE-41D1-8E7D-D2FE6889C1F9@subbu.org> References: <20100119053002.5CD613A683B@core3.amsl.com> To: Jan Algermissen , Mark Nottingham X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 18:19:46 -0000 You mean "link-extension" params? Subbu On Jan 20, 2010, at 11:37 PM, Jan Algermissen wrote: >=20 > On Jan 20, 2010, at 10:38 PM, Subbu Allamaraju wrote: >=20 >> The usage of fields is not clear. Sec. 6.3 says that "entries in the = Link Relation Type Registry can be extended with application-specific = data". But the BNF in Sec. 5 does not specify fields. Could you clarify = the intent of fields? >=20 > I understand fields to be meant as link relation specific parameters. >=20 > Jan >=20 >=20 >=20 >>=20 >> Subbu >>=20 >> On Jan 18, 2010, at 9:31 PM, Mark Nottingham wrote: >>=20 >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: Internet-Draft@ietf.org >>>> Date: 19 January 2010 4:30:02 PM AEDT >>>> To: mnot@pobox.com, = draft-nottingham-http-link-header@tools.ietf.org,lisa.dusseault@gmail.com >>>> Subject: New Version Notification - = draft-nottingham-http-link-header-07.txt >>>>=20 >>>> New version (-07) has been submitted for = draft-nottingham-http-link-header-07.txt. >>>> = http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-07.t= xt >>>> Sub state has been changed to AD Follow up from New Id Needed >>>>=20 >>>> Diff from previous version: >>>> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-link-header-07 >>>>=20 >>>> IETF Secretariat. >>>=20 >>>=20 >>> -- >>> Mark Nottingham http://www.mnot.net/ >>>=20 >>>=20 >>=20 >>=20 >=20 > ----------------------------------- > Jan Algermissen, Consultant >=20 > Mail: algermissen@acm.org > Blog: http://www.nordsc.com/blog/ > Work: http://www.nordsc.com/ > ----------------------------------- >=20 >=20 >=20 From algermissen1971@mac.com Fri Jan 22 13:53:32 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F213A6774 for ; Fri, 22 Jan 2010 13:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=-2.740, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYHvIqNSn2bB for ; Fri, 22 Jan 2010 13:53:31 -0800 (PST) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by core3.amsl.com (Postfix) with ESMTP id 48DA13A63EB for ; Fri, 22 Jan 2010 13:53:31 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.2.102] ([84.144.69.192]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KWO00AAZ4SLTY20@asmtp017.mac.com> for discuss@apps.ietf.org; Fri, 22 Jan 2010 13:53:13 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1001220247 Message-id: <62C36D7B-2385-47AB-8A92-DEA15A81B99E@mac.com> From: Jan Algermissen To: Subbu Allamaraju In-reply-to: <0460AF05-93FE-41D1-8E7D-D2FE6889C1F9@subbu.org> Subject: Re: New Version Notification - draft-nottingham-http-link-header-07.txt Date: Fri, 22 Jan 2010 22:53:08 +0100 References: <20100119053002.5CD613A683B@core3.amsl.com> <0460AF05-93FE-41D1-8E7D-D2FE6889C1F9@subbu.org> X-Mailer: Apple Mail (2.936) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 21:53:32 -0000 On Jan 22, 2010, at 7:19 PM, Subbu Allamaraju wrote: > You mean "link-extension" params? Hmm, no I am getting confused :-) I;d say link-extension == field. Mark? Jan > > Subbu > > On Jan 20, 2010, at 11:37 PM, Jan Algermissen wrote: > >> >> On Jan 20, 2010, at 10:38 PM, Subbu Allamaraju wrote: >> >>> The usage of fields is not clear. Sec. 6.3 says that "entries in >>> the Link Relation Type Registry can be extended with application- >>> specific data". But the BNF in Sec. 5 does not specify fields. >>> Could you clarify the intent of fields? >> >> I understand fields to be meant as link relation specific parameters. >> >> Jan >> >> >> >>> >>> Subbu >>> >>> On Jan 18, 2010, at 9:31 PM, Mark Nottingham wrote: >>> >>>> >>>> >>>> Begin forwarded message: >>>> >>>>> From: Internet-Draft@ietf.org >>>>> Date: 19 January 2010 4:30:02 PM AEDT >>>>> To: mnot@pobox.com, draft-nottingham-http-link-header@tools.ietf.org >>>>> ,lisa.dusseault@gmail.com >>>>> Subject: New Version Notification - draft-nottingham-http-link- >>>>> header-07.txt >>>>> >>>>> New version (-07) has been submitted for draft-nottingham-http- >>>>> link-header-07.txt. >>>>> http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-07.txt >>>>> Sub state has been changed to AD Follow up from New Id Needed >>>>> >>>>> Diff from previous version: >>>>> http://tools.ietf.org/rfcdiff?url2=draft-nottingham-http-link-header-07 >>>>> >>>>> IETF Secretariat. >>>> >>>> >>>> -- >>>> Mark Nottingham http://www.mnot.net/ >>>> >>>> >>> >>> >> >> ----------------------------------- >> Jan Algermissen, Consultant >> >> Mail: algermissen@acm.org >> Blog: http://www.nordsc.com/blog/ >> Work: http://www.nordsc.com/ >> ----------------------------------- >> >> >> > > ----------------------------------- Jan Algermissen, Consultant Mail: algermissen@acm.org Blog: http://www.nordsc.com/blog/ Work: http://www.nordsc.com/ ----------------------------------- From masinter@adobe.com Fri Jan 22 17:35:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2633A68F8 for ; Fri, 22 Jan 2010 17:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0axB+niF0Re for ; Fri, 22 Jan 2010 17:35:27 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by core3.amsl.com (Postfix) with ESMTP id 2121D3A67A3 for ; Fri, 22 Jan 2010 17:35:25 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKS1pSV2ndBWH7OJPASBf3ZTgCysUgCNfR@postini.com; Fri, 22 Jan 2010 17:35:23 PST Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id o0N1RX18027132; Fri, 22 Jan 2010 17:27:34 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id o0N1YX7p019897; Fri, 22 Jan 2010 17:35:16 -0800 (PST) Received: from nacas03.corp.adobe.com (10.8.189.121) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 22 Jan 2010 17:34:47 -0800 Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Fri, 22 Jan 2010 17:34:46 -0800 From: Larry Masinter To: Adam Barth Date: Fri, 22 Jan 2010 17:34:46 -0800 Subject: RE: comments on draft-abarth-mime-sniff-03 Thread-Topic: comments on draft-abarth-mime-sniff-03 Thread-Index: AcqaJmPgw4U9goOiQJu1785spbFnMABpDvCQ Message-ID: References: <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.com> In-Reply-To: <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ian Hickson , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 01:35:28 -0000 >> A message with more than one content-type header >> should be treated as malformed. > What does it mean to treat the response as malformed? I've seen > examples of servers that blissfully send more than one Content-Type > header. This document just describes how to process the responses > without making a judge about whether the server is acting properly or > not. Implementations should be allowed to not do sniffing when the content-type is malformed, even when they do sniffing when the content-type is missing, or specific kinds of sniffing when the content-type is supplied but just wrong. Malformed content is an indication of more serious site misconfiguration than the typical excuse that the default Apache installation used to label any file extension it didn't understand as "text/plain" rather than "application/octet string" >> The "algorithm for extracting an encoding ...." > [...] >> The nature of the "willful violation" >> (I.e., how it is different) and the >> justification for the "willful violation" >> should be included. I can't fathom any >> justification for it. > Charset sniffing is required to avoid ugly replacement characters from > being shown to the user. Sad, but true. I'm sorry, but the paragraphs preceding the discussion of "willful violation" seem to be talking about how to determine the value of the charset=3D MIME parameter, not about the=20 interpretation of the results. As I pointed out, this=20 document doesn't include the algorithm for charset sniffing, which still seems to be in the HTML4 document. If you mean by your disclaimer of a "willful violation" that you were doing charset sniffing, then moving that text from the HTML specification into this one (or, as I had also thought reasonable) a parallel one, would seem to be more reasonable. The reason for including an algorithm for parsing the MIME parameters that differs from the ordinary one requires more justification than you've supplied. >> file extensions: >> >> =A0Note: It is essential that file extensions >> =A0are not used for determining the media type >> =A0 for resources fetched over HTTP because >> =A0file extensions can often by supplied by >> =A0 malicious parties. > >> =A0"Often" is dubious. How can file extensions be >> supplied more often than =A0content-type headers? > For example, the attacker can chose the file extension in most PHP > installations because foo.php happily processes: > http://example.com/foo.php/bar.qux I suggest including this example in the security considerations section of the document. >> What is the security threat? > The security threat is that if you treat an HTML file extension as > evidence the server wants the response to be treated as text/html you > will introduce XSS vulnerabilities into some large number of sites > running PHP (among others). Yes, I think this belongs in the "security considerations" section of the document. >> I'd think that the behavior of "how to sniff" >> should start out with what the inputs are >> (the first N bytes of some data from a response). > This business about waiting for 512 bytes has to do with a poor > interaction between buffering for sniffing and Comet > . Basically, if you > wait forever for the 512 bytes you need to sniff completely, then you > break things like chat in Gmail. For example, Gmail chat used to not > work in Safari for this reason. However, always using the first chunk > of data off the network to sniff means you'll get unpredictable > results based on how exactly the response was chunked. Hence the > advice to wait for 512 bytes but not a requirement to wait forever. I'm just pointing out that the consequence is that sniffing is indeterminat= e, and that even if you have an implementation that claims that it sniffs, that it might not if the server responds slowly and your wait times out. This might even be an attack vector? (I'm not sure how, though). I don't think you've made clear the advantage of sniffing at all until you've received the entire message body, much less the first 512 bytes. Your example of gmail chat isn't convincing... I suppose the browser doesn't know that it's talking to a presumably sniffing-not-necessary site (Google), but the first 512 bytes of the response might not arrive in a timely fashion? Maybe you could explain this use case in more detail. Larry =20 From adam@adambarth.com Fri Jan 22 19:26:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524733A6782 for ; Fri, 22 Jan 2010 19:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[AWL=-1.168, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ0mwPM7P9Ml for ; Fri, 22 Jan 2010 19:26:13 -0800 (PST) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id BE1803A677D for ; Fri, 22 Jan 2010 19:26:13 -0800 (PST) Received: by pzk4 with SMTP id 4so1457891pzk.32 for ; Fri, 22 Jan 2010 19:26:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.202.14 with SMTP id z14mr155614wff.248.1264217167162; Fri, 22 Jan 2010 19:26:07 -0800 (PST) In-Reply-To: References: <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.com> From: Adam Barth Date: Fri, 22 Jan 2010 19:25:47 -0800 Message-ID: <7789133a1001221925sf1f55b8k31953828848f2787@mail.gmail.com> Subject: Re: comments on draft-abarth-mime-sniff-03 To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 23 Jan 2010 09:37:59 -0800 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 03:26:15 -0000 At a higher level, what do folks think about re-writing the draft in a more informative style instead of a normative style? A bunch of Larry's points boil down to the strengths of the normative requirements and the scope of the affected user agents. I certainly have no wish to ram sniffing down anyone's throats. I'd rather provide this document as a reference for folks who feel compelled to do content sniffing but who don't want to invest the year and a half of research that my colleagues and I invested to arrive at this algorithm. Some comments below. On Fri, Jan 22, 2010 at 5:34 PM, Larry Masinter wrote: > Malformed content is an indication of more serious site > misconfiguration than the typical excuse that the default > Apache installation used to label any file extension it > didn't understand as "text/plain" rather than > "application/octet string" To ground this discussion, here's a real-world example from Google News. Google News syndicates images from a bunch of news sources. For a while, instead of providing the content type of the images, the servers were providing the "magic numbers" that are found at the beginning of the images. Once we discovered the issue, we convinced the team to fix the issue. >> Charset sniffing is required to avoid ugly replacement characters from >> being shown to the user. =A0Sad, but true. > > I'm sorry, but the paragraphs preceding the discussion of > "willful violation" seem to be talking about how to determine > the value of the charset=3D MIME parameter, not about the > interpretation of the results. As I pointed out, this > document doesn't include the algorithm for charset > sniffing, which still seems to be in the HTML4 document. I presume you mean HTML5. > If you mean by your disclaimer of a "willful violation" that > you were doing charset sniffing, then moving that text from > the HTML specification into this one (or, as I had also > thought reasonable) a parallel one, would seem to be more > reasonable. The reason for including an algorithm for parsing > the MIME parameters that differs from the ordinary one requires > more justification than you've supplied. This text originated from the HTML5 specification. It's entirely possible it doesn't make sense without the surrounding context. I'll investigate. >>> file extensions: >>> >>> =A0Note: It is essential that file extensions >>> =A0are not used for determining the media type >>> =A0 for resources fetched over HTTP because >>> =A0file extensions can often by supplied by >>> =A0 malicious parties. >> >>> =A0"Often" is dubious. How can file extensions be >>> supplied more often than =A0content-type headers? > >> For example, the attacker can chose the file extension in most PHP >> installations because foo.php happily processes: > >> http://example.com/foo.php/bar.qux > > I suggest including this example in the security considerations section > of the document. Will do. >>> What is the security threat? > >> The security threat is that if you treat an HTML file extension as >> evidence the server wants the response to be treated as text/html you >> will introduce XSS vulnerabilities into some large number of sites >> running PHP (among others). > > Yes, I think this belongs in the "security considerations" section > of the document. Will do. >>> I'd think that the behavior of "how to sniff" >>> should start out with what the inputs are >>> (the first N bytes of some data from a response). > >> This business about waiting for 512 bytes has to do with a poor >> interaction between buffering for sniffing and Comet >> . =A0Basically, if you >> wait forever for the 512 bytes you need to sniff completely, then you >> break things like chat in Gmail. =A0For example, Gmail chat used to not >> work in Safari for this reason. =A0However, always using the first chunk >> of data off the network to sniff means you'll get unpredictable >> results based on how exactly the response was chunked. =A0Hence the >> advice to wait for 512 bytes but not a requirement to wait forever. > > I'm just pointing out that the consequence is that sniffing is indetermin= ate, > and that even if you have an implementation that claims that it sniffs, > that it might not if the server responds slowly and your wait times out. > This might even be an attack vector? (I'm not sure how, though). In reality, the sniffing algorithm is highly predictable. Although it's possible for the HTML heuristic to use all 512 bytes, it's extremely rare. In fact, in 97% of cases when the heuristic fires, the HTML tag begins at the first byte of the entity-body. It's also possible for the text-or-binary algorithm to consume all 512 bytes, but in most binary files, the first "non-text" character occurs well before the 512th byte. This is not an attack vector, that I'm aware of, because the default types you could force by truncating the sniffing buffer are "safe" (e.g., text/plain or application/octet-stream). > I don't think you've made clear the advantage of sniffing at all until > you've received the entire message body, much less the first 512 bytes. There's no reason to wait for the entire message body. The algorithm considers only the first 512 bytes. Also, waiting for the whole entity body would be disastrous to performance. In practice, waiting for the first 512 bytes is very cheap, so you might as well do it to make the algorithm 100% predictable. In some rare cases, it's expensive to wait, so the epsilon extra predictability isn't worth the cost, e.g., breaking Gmail chat. > Your example of gmail chat isn't convincing... Isn't convincing to whom? To you? It was convincing enough to the Safari team that they changed their sniffing algorithm in this regard to what's described in the document. > I suppose the browser > doesn't know that it's talking to a presumably sniffing-not-necessary > site (Google), but the first 512 bytes of the response might not arrive > in a timely fashion? In this case, the server was responding with a sniffable Content-Type and the first 512 bytes would never arrive. It sounds like you don't understand how Comet works. I'd encourage you to read the citation I provided before giving your opinion about things you don't understand: http://en.wikipedia.org/wiki/Comet_(programming) > Maybe you could explain this use case in more detail. The use case is as follows: 1) The server responds with a sniffable Content-Type and a chunked encoding= . 2) The server sends the first chunk (say of five bytes) and then blocks. 3) The client blocks waiting for the server to send more content. 4) ... time passes ... 5) The server sends the second chunk (say another five bytes) and then bloc= ks. Now, what the web site wants is that the first five bytes are delivered to the XMLHttpRequest API soon after they arrive from the server. Then, the web site wants the second five bytes to be delivered to the XMLHttpRequest API soon after they arrive from the server. This techniques, known as Comet, allows the web site to simulate a server data "push" and is why you're able to receive a Gmail chat message soon after your contact sends it. However, if the user agent blocks the response waiting for 512 bytes, those bytes will never arrive and you'll never get your chat messages. Of course, there are ways for the server to work around this issue by spamming the Comet channel with 512 bytes of junk at the beginning or specifying a non-sniffable media type. However, the reality is that most user agents won't wait forever for the 512 bytes needed for sniffing. Instead, they'll get board of waiting and deliver the bytes to the XMLHttpRequest API. Hence, server operators don't employ these workarounds, and if you're the lone user agent that doesn't behave this way (e.g., Safari), then Gmail chat doesn't work in your browser and your users are sad. Sad users stop using your browser and use another browser. All that is a long-winded way of saying that these things are in the draft for a reason. The sniffing algorithm is highly constrained by reality. Looking for philosophical purity in content sniffing is like trying to find a Newtonian explanation of Brownian motion. Adam From ian@hixie.ch Fri Jan 22 22:32:24 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3950D3A682A for ; Fri, 22 Jan 2010 22:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlRA4LugH3jA for ; Fri, 22 Jan 2010 22:32:23 -0800 (PST) Received: from looneymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 2EA4B3A6809 for ; Fri, 22 Jan 2010 22:32:22 -0800 (PST) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a1.g.dreamhost.com (Postfix) with ESMTP id 58B7415D78B; Fri, 22 Jan 2010 22:32:18 -0800 (PST) Date: Sat, 23 Jan 2010 06:32:18 +0000 (UTC) From: Ian Hickson To: Larry Masinter Subject: RE: comments on draft-abarth-mime-sniff-03 In-Reply-To: Message-ID: References: <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.com> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sat, 23 Jan 2010 09:37:59 -0800 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 06:32:24 -0000 On Fri, 22 Jan 2010, Larry Masinter wrote: > >> > >> A message with more than one content-type header should be treated as > >> malformed. > > > > What does it mean to treat the response as malformed? I've seen > > examples of servers that blissfully send more than one Content-Type > > header. This document just describes how to process the responses > > without making a judge about whether the server is acting properly or > > not. > > Implementations should be allowed to not do sniffing when the > content-type is malformed, even when they do sniffing when the > content-type is missing, or specific kinds of sniffing when the > content-type is supplied but just wrong. I strongly disagree. Getting reliably interoperable behaviour in all user agents trumps theoretical concerns about what is right or wrong, IMHO. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian@hixie.ch Fri Jan 22 22:41:25 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEB473A68EB for ; Fri, 22 Jan 2010 22:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beB20syBNI-r for ; Fri, 22 Jan 2010 22:41:21 -0800 (PST) Received: from looneymail-a4.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id BC67C3A68D3 for ; Fri, 22 Jan 2010 22:41:16 -0800 (PST) Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a4.g.dreamhost.com (Postfix) with ESMTP id ED0F6831F; Fri, 22 Jan 2010 22:41:09 -0800 (PST) Date: Sat, 23 Jan 2010 06:41:09 +0000 (UTC) From: Ian Hickson To: Adam Barth Subject: Re: comments on draft-abarth-mime-sniff-03 In-Reply-To: <7789133a1001221925sf1f55b8k31953828848f2787@mail.gmail.com> Message-ID: References: <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.com> <7789133a1001221925sf1f55b8k31953828848f2787@mail.gmail.com> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sat, 23 Jan 2010 09:37:59 -0800 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 06:41:26 -0000 On Fri, 22 Jan 2010, Adam Barth wrote: > > At a higher level, what do folks think about re-writing the draft in a > more informative style instead of a normative style? A bunch of Larry's > points boil down to the strengths of the normative requirements and the > scope of the affected user agents. I certainly have no wish to ram > sniffing down anyone's throats. I'd rather provide this document as a > reference for folks who feel compelled to do content sniffing but who > don't want to invest the year and a half of research that my colleagues > and I invested to arrive at this algorithm. I think all user agents should be required to behave the same, so that users and content creators can interchange them at will, leading to a healthier competitive landscape. To this end, I think the spec should be normative with no optional behaviour. I'm ok with allowing the sniffing to be skipped altogether, since that is equivalent to not implementing the spec. However, I'm not especially happy about allowing that, and I certainly do not think we should water down the requirements any more than that, _especially_ not on purely theoretical grounds. > All that is a long-winded way of saying that these things are in the > draft for a reason. The sniffing algorithm is highly constrained by > reality. Looking for philosophical purity in content sniffing is like > trying to find a Newtonian explanation of Brownian motion. Indeed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From anthonybryan@gmail.com Sun Jan 24 12:39:44 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B4B3A6958 for ; Sun, 24 Jan 2010 12:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDw4WsRX4OOH for ; Sun, 24 Jan 2010 12:39:42 -0800 (PST) Received: from mail-iw0-f178.google.com (mail-iw0-f178.google.com [209.85.223.178]) by core3.amsl.com (Postfix) with ESMTP id D0CBC3A6955 for ; Sun, 24 Jan 2010 12:39:42 -0800 (PST) Received: by iwn8 with SMTP id 8so2299590iwn.23 for ; Sun, 24 Jan 2010 12:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=9a1s47qwCOAhyIZV9hU4SWQTrWbGXIkhRACMbyIMQEo=; b=rrpmmOtzny8B46AuxPfYSvsPHXmeqVn/BQHpD2mR5U6BtnMyPczAog/lUoOmgTS8SU 1/MisU8IESmrlDDnqlsP/IAIS8L+Wiykyg9ik6I43uEj5BMSBHUiNBMyL/CeTqHneLEv 1gM57YfvYkY5FnRa4HgHd9Z69l3OF14BmQyV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Cg2PZ8GST2S1TSEPqW29+UKyXceDALOTd5uZK0QLHBXrS73aHCpVMCzPAjdYnPeSFS a7Hnf2ixzzN6oRtBj7/IyYpbC5/w23KkJi8lnuPaGOzaAtuEBM5xeJXMnhFUyxdAcf+M tPBlm1CwE+PRrxcdkCoXq1aalQU8THgHMc/hM= MIME-Version: 1.0 Received: by 10.231.143.148 with SMTP id v20mr3052190ibu.14.1264365583009; Sun, 24 Jan 2010 12:39:43 -0800 (PST) Date: Sun, 24 Jan 2010 15:39:42 -0500 Message-ID: Subject: Updating IANA "Operating System Names" registry From: Anthony Bryan To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 20:39:44 -0000 Hi, The IANA registry "Operating System Names" found at http://www.iana.org/assignments/operating-system-names is missing a few recent common OSes. LINUX-2.6 WINDOWS-NT-6 WINDOWS-NT-6.1 There's MACOS but not MACOS-10.0 or MACOS-X-10.0, MACOS-X-10.1, etc. I've been told the registry can be updated with an email, so I wanted to check if anyone had suggestions for other additions? (My ID http://tools.ietf.org/html/draft-bryan-metalink allows file publishers to list what OS a file is intended for). -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From phoffman@imc.org Sun Jan 24 14:29:10 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3C53A6993 for ; Sun, 24 Jan 2010 14:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvuvuoB9wnDR for ; Sun, 24 Jan 2010 14:29:09 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id A22A93A6991 for ; Sun, 24 Jan 2010 14:29:09 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0OMTAGm025539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Jan 2010 15:29:11 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 24 Jan 2010 14:29:08 -0800 To: Anthony Bryan , apps-discuss@ietf.org From: Paul Hoffman Subject: Re: Updating IANA "Operating System Names" registry Content-Type: text/plain; charset="us-ascii" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 22:29:10 -0000 At 3:39 PM -0500 1/24/10, Anthony Bryan wrote: >Hi, > >The IANA registry "Operating System Names" found at >http://www.iana.org/assignments/operating-system-names is missing a >few recent common OSes. > >LINUX-2.6 >WINDOWS-NT-6 >WINDOWS-NT-6.1 ...where "few" means "most". This registry is a complete mess. Linux is listed by kernel versions, not distro versions, but FreeBSD is only listed once. >(My ID http://tools.ietf.org/html/draft-bryan-metalink allows file >publishers to list what OS a file is intended for). Given the state of the registry and the number of people-hours that will be wasted on arguing what should and should not be in it, I suggest that simply removing "The IANA registry named "Operating System Names" defines values for OS types." and then letting the registry rot is probably a better use of everyone's time. From julian.reschke@gmx.de Mon Jan 25 05:16:43 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8703A69DB for ; Mon, 25 Jan 2010 05:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WqFGh40IpzU for ; Mon, 25 Jan 2010 05:16:42 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 37A1D3A69D2 for ; Mon, 25 Jan 2010 05:16:41 -0800 (PST) Received: (qmail invoked by alias); 25 Jan 2010 13:16:46 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp046) with SMTP; 25 Jan 2010 14:16:46 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/f4mcqNWPfvmomL60u6MUJpIQPLPfpwFSSzwQITe /1BLKrPrXbElKb Message-ID: <4B5D99BB.4050607@gmx.de> Date: Mon, 25 Jan 2010 14:16:43 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Adam Barth Subject: Re: comments on draft-abarth-mime-sniff-03 References: <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.com> <7789133a1001221925sf1f55b8k31953828848f2787@mail.gmail.com> In-Reply-To: <7789133a1001221925sf1f55b8k31953828848f2787@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.70999999999999996 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 13:16:43 -0000 Adam Barth wrote: > At a higher level, what do folks think about re-writing the draft in a > more informative style instead of a normative style? A bunch of > Larry's points boil down to the strengths of the normative > requirements and the scope of the affected user agents. I certainly > have no wish to ram sniffing down anyone's throats. I'd rather > provide this document as a reference for folks who feel compelled to > do content sniffing but who don't want to invest the year and a half > of research that my colleagues and I invested to arrive at this > algorithm. > ... Sounds good to me. In general, defining certain behaviors normatively is a good thing, but it doesn't need to be all-or-nothing. Also, throwing around MUSTs frequently doesn't help in practice; what's more important is to *convince* the reader that doing something is the right thing. More inline. For instance, as Larry mentioned, (1) missing Content-Type, (2) mislabeled Content-Type and (3) invalid Content-Type (multiple headers) are distinct cases with different underlying reasons, so requiring the same behavior may not always be the best approach. So having different sections define this, and allowing people to pick the right pieces might be a good idea here. Best regards, Julian From eran@hueniverse.com Mon Jan 25 09:03:12 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B753A6928 for ; Mon, 25 Jan 2010 09:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ7IlF5ZW6+e for ; Mon, 25 Jan 2010 09:03:11 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BBBC53A67E7 for ; Mon, 25 Jan 2010 09:03:11 -0800 (PST) Received: (qmail 17007 invoked from network); 25 Jan 2010 17:03:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jan 2010 17:03:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 25 Jan 2010 10:03:14 -0700 From: Eran Hammer-Lahav To: "apps-discuss@ietf.org" Date: Mon, 25 Jan 2010 10:03:17 -0700 Subject: Extension Relation Type Comparison - LC Comment on draft-nottingham-http-plink-header-07 Thread-Topic: Extension Relation Type Comparison - LC Comment on draft-nottingham-http-plink-header-07 Thread-Index: Acqd4Eo4LRnlQvASTFaLlM1IWqWzZg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343788056821@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 17:03:12 -0000 The current text about comparing extension relation types is unclear: When extension relation types are compared, they MUST be compared as URIs in a case-insensitive fashion, character-by-character. Because of this, all-lowercase URIs SHOULD be used for extension relations. What does it mean "compared as URIs"? It is clear that these two URIs would be deemed equivalent: http://example.com/rel/type HTTP://example.COM/rel/TYPE But are they also equivalent to: http://example.com:80/rel/type I would argue that normalizing URIs in this context is non-obvious and coun= ter-intuitive. We are not using URIs for the purpose of resolving them, but= only as a way to construct unique strings, using the URI format to define = authority and minting rules. I think we would be better off comparing extension relation types "as strin= gs in a case-insensitive fashion, character-by-character". EHL From narten@us.ibm.com Tue Jan 26 10:15:59 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4113A6882 for ; Tue, 26 Jan 2010 10:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIpUWaTFfUVV for ; Tue, 26 Jan 2010 10:15:58 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id 106663A6823 for ; Tue, 26 Jan 2010 10:15:58 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0QIEhId013599 for ; Tue, 26 Jan 2010 11:14:43 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o0QIFsMG047904 for ; Tue, 26 Jan 2010 11:15:55 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0QIFprJ002615 for ; Tue, 26 Jan 2010 11:15:51 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-48-40-124.mts.ibm.com [9.48.40.124]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o0QIFosH002556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 11:15:50 -0700 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id o0QIFnC8007603; Tue, 26 Jan 2010 13:15:49 -0500 Message-Id: <201001261815.o0QIFnC8007603@cichlid.raleigh.ibm.com> To: Anthony Bryan Subject: Re: Updating IANA "Operating System Names" registry In-reply-to: References: Comments: In-reply-to Anthony Bryan message dated "Sun, 24 Jan 2010 15:39:42 -0500." Date: Tue, 26 Jan 2010 13:15:49 -0500 From: Thomas Narten Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 18:15:59 -0000 > The IANA registry "Operating System Names" found at > http://www.iana.org/assignments/operating-system-names is missing a > few recent common OSes. More to the point, who uses this registry and who cares? It is old, and probably stopped serving a useful purpose years ago. What protocols make use of the registry? Absent a real usage, the registry should either be shutdown, or just quietly left alone. Thomas From stpeter@stpeter.im Tue Jan 26 10:32:19 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0183A685F for ; Tue, 26 Jan 2010 10:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+Ea3fz50gyg for ; Tue, 26 Jan 2010 10:32:18 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0833D3A680C for ; Tue, 26 Jan 2010 10:32:18 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3D8CF40329 for ; Tue, 26 Jan 2010 11:32:28 -0700 (MST) Message-ID: <4B5F3539.5060702@stpeter.im> Date: Tue, 26 Jan 2010 11:32:25 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: Updating IANA "Operating System Names" registry References: <201001261815.o0QIFnC8007603@cichlid.raleigh.ibm.com> In-Reply-To: <201001261815.o0QIFnC8007603@cichlid.raleigh.ibm.com> X-Enigmail-Version: 1.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050704030703020306050809" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 18:32:19 -0000 This is a cryptographically signed message in MIME format. --------------ms050704030703020306050809 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1/26/10 11:15 AM, Thomas Narten wrote: >> The IANA registry "Operating System Names" found at >> http://www.iana.org/assignments/operating-system-names is missing a >> few recent common OSes. >=20 > More to the point, who uses this registry and who cares? It is old, > and probably stopped serving a useful purpose years ago. >=20 > What protocols make use of the registry? >=20 > Absent a real usage, the registry should either be shutdown, or just > quietly left alone. +1. Who uses it, how extensively, and (these days) why? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050704030703020306050809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDEyNjE4MzIyNVowIwYJKoZIhvcNAQkEMRYEFBTzSUiME/eiif0axEdd uP42iTdhMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAHO0q7DfmGFAkce04RrrAI9wpMAozRXORCPxF5h9Y XTBKIgs5GsiYPovZDWzNx+QFzurEya8vaO9ZYbYcp1prSH9IeoOmrw91a0EZBzFmtee2LTzb K38d4ETHym/2/Y1l1A99xcddsC+bebGsK8iFiI+N5fru53mo7OT7+mAFRtsllRzlclxrQzgc huwl6EaP6Hc5YWwyDIBFp8weYonntG/E+CkGjn+GRvYd0RPAf14xU64qnxwpWdhcYEWOd+1E H3GivGMOckfExvdbZTmo7WCS9H0cM41LMkco0LE8M0YCTlyV5aCRCELSgK6dp0+2vVJkjSbM Mbx9d7tYyzL7ngAAAAAAAA== --------------ms050704030703020306050809-- From adam@adambarth.com Tue Jan 26 12:45:26 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F357D28C0F4 for ; Tue, 26 Jan 2010 12:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BExMQ-DQ+QNF for ; Tue, 26 Jan 2010 12:45:25 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 2613228C107 for ; Tue, 26 Jan 2010 12:45:25 -0800 (PST) Received: by pwi20 with SMTP id 20so3512423pwi.29 for ; Tue, 26 Jan 2010 12:45:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.7.25 with SMTP id 25mr5783300wfg.141.1264538734118; Tue, 26 Jan 2010 12:45:34 -0800 (PST) In-Reply-To: <4B5D99BB.4050607@gmx.de> References: <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.com> <7789133a1001221925sf1f55b8k31953828848f2787@mail.gmail.com> <4B5D99BB.4050607@gmx.de> From: Adam Barth Date: Tue, 26 Jan 2010 20:45:14 +0000 Message-ID: <7789133a1001261245o3c9f06e3h1ee91a9e0519e16@mail.gmail.com> Subject: Re: comments on draft-abarth-mime-sniff-03 To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 20:45:26 -0000 On Mon, Jan 25, 2010 at 1:16 PM, Julian Reschke wrote: > In general, defining certain behaviors normatively is a good thing, but it > doesn't need to be all-or-nothing. Also, throwing around MUSTs frequently > doesn't help in practice; what's more important is to *convince* the reader > that doing something is the right thing. More inline. Believe me, I'm doing a lot to convince the implementers directly. In fact, I'm going as far as sending them patches to align their behavior with the spec. > For instance, as Larry mentioned, (1) missing Content-Type, (2) mislabeled > Content-Type and (3) invalid Content-Type (multiple headers) are distinct > cases with different underlying reasons, so requiring the same behavior may > not always be the best approach. So having different sections define this, > and allowing people to pick the right pieces might be a good idea here. As I wrote to Larry, having more permutations is antithetical to our security and compatibility goals. Adam From adam@adambarth.com Tue Jan 26 12:47:04 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66FAA28C0F2 for ; Tue, 26 Jan 2010 12:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.75 X-Spam-Level: X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlupFUAez1DP for ; Tue, 26 Jan 2010 12:47:03 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id AFA733A68C5 for ; Tue, 26 Jan 2010 12:47:03 -0800 (PST) Received: by pwi20 with SMTP id 20so3513523pwi.29 for ; Tue, 26 Jan 2010 12:47:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.7.25 with SMTP id 25mr5784486wfg.141.1264538832508; Tue, 26 Jan 2010 12:47:12 -0800 (PST) In-Reply-To: <7789133a1001221925sf1f55b8k31953828848f2787@mail.gmail.com> References: <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.com> <7789133a1001221925sf1f55b8k31953828848f2787@mail.gmail.com> From: Adam Barth Date: Tue, 26 Jan 2010 20:46:52 +0000 Message-ID: <7789133a1001261246p5a0074bdof65a59a62969d148@mail.gmail.com> Subject: Re: comments on draft-abarth-mime-sniff-03 To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 20:47:04 -0000 On Sat, Jan 23, 2010 at 3:25 AM, Adam Barth wrote: > On Fri, Jan 22, 2010 at 5:34 PM, Larry Masinter wrote: >> I suggest including this example in the security considerations section >> of the document. > > Will do. Actually, I've just included the example inline in the text because the document doesn't have a separate security considerations section. In some sense, the entire document is one giant security considerations section. >>>> What is the security threat? >> >>> The security threat is that if you treat an HTML file extension as >>> evidence the server wants the response to be treated as text/html you >>> will introduce XSS vulnerabilities into some large number of sites >>> running PHP (among others). >> >> Yes, I think this belongs in the "security considerations" section >> of the document. > > Will do. This is explained in the introduction. Adam From adam@adambarth.com Tue Jan 26 12:51:18 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564CD3A699F for ; Tue, 26 Jan 2010 12:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.363 X-Spam-Level: X-Spam-Status: No, score=-1.363 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiw2j0+NeKHB for ; Tue, 26 Jan 2010 12:51:17 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id B8D783A692A for ; Tue, 26 Jan 2010 12:51:17 -0800 (PST) Received: by pwi20 with SMTP id 20so3516508pwi.29 for ; Tue, 26 Jan 2010 12:51:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.249.25 with SMTP id w25mr1602149wfh.15.1264539089161; Tue, 26 Jan 2010 12:51:29 -0800 (PST) From: Adam Barth Date: Tue, 26 Jan 2010 20:51:09 +0000 Message-ID: <7789133a1001261251r604ab579nb6a9bb708745023e@mail.gmail.com> Subject: New version of media type sniffing draft To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 20:51:18 -0000 I've uploaded a new version of the media type sniffing draft based on feedback received on this list an elsewhere: http://www.ietf.org/id/draft-abarth-mime-sniff-04.txt Adam From john-ietf@jck.com Wed Jan 27 01:07:14 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87813A691F for ; Wed, 27 Jan 2010 01:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11mSSJ0Camsb for ; Wed, 27 Jan 2010 01:07:13 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 9C4B63A676A for ; Wed, 27 Jan 2010 01:07:13 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Na3rr-000Gy2-2a; Wed, 27 Jan 2010 04:07:19 -0500 Date: Wed, 27 Jan 2010 04:07:18 -0500 From: John C Klensin To: Thomas Narten , Anthony Bryan Subject: Re: Updating IANA "Operating System Names" registry Message-ID: <67600F318C5C1A2DCFD4C503@PST.JCK.COM> In-Reply-To: <201001261815.o0QIFnC8007603@cichlid.raleigh.ibm.com> References: <201001261815.o0QIFnC8007603@cichlid.raleigh.ibm.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 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 09:07:15 -0000 --On Tuesday, January 26, 2010 13:15 -0500 Thomas Narten wrote: >> The IANA registry "Operating System Names" found at >> http://www.iana.org/assignments/operating-system-names is >> missing a few recent common OSes. > > More to the point, who uses this registry and who cares? It > is old, and probably stopped serving a useful purpose years > ago. > > What protocols make use of the registry? Sigh. The FTP SYST command, among other things. SYST is much less important now than it was a few decades ago when there was a lot more diversity of hardware architecture and operating systems, but there is what we would now describe as a normative reference from RFC 959 (STD 9) to this registry. The DNS HINFO record is also supposed to use them. While I haven't see a lot of uses of HINFO recently in the public DNS, we haven't deprecated the RR type either. I have generated an errata entry for RFC 959 noting that SYST should point to this registry rather than pointing more vaguely to "Assigned Numbers". I will leave similar comments on the definition of HINFO and possibly a modification to the new FTP Commands and Extensions registry (to note that this registry specifies the parameter space for SYST) to someone who has more energy and time for that kind of work. With a quarter-century's hindsight, it is clear that this registry, and the names in it, should have used structured names of some style such as OperatingSystem Delimiter Version Delimiter Subversion possibly with explicit registration for only the first element, but it is a little late now. Getting the list up to date and into shape would clearly require significant work, but I don't think we should discourage new registrations by anyone who thinks that particular entries are needed. > Absent a real usage, the registry should either be shutdown, > or just quietly left alone. I don't see how one can shut down a registry that is used normatively by two full standards (FTP and DNS) without first deprecating the FTP Command and the DNS RR that use it. Continuing the long-standing practice of neglect unless new entries are actually needed seems entirely reasonable and has the advantage of not requiring any action. In general, it is probably better to believe that registries should be updated when someone has a substantive need for new entries than to try to create some abstract requirement to add entries for their own sake. I am tempted to ask why we are even wasting time discussing this registry, but I won't. john From mnot@mnot.net Wed Jan 27 20:27:27 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A77D3A697D for ; Wed, 27 Jan 2010 20:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.604 X-Spam-Level: X-Spam-Status: No, score=-3.604 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JFylkBgfNUk for ; Wed, 27 Jan 2010 20:27:26 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 677D13A693C for ; Wed, 27 Jan 2010 20:27:26 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.167.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E594422E1F1; Wed, 27 Jan 2010 23:27:35 -0500 (EST) Subject: Re: Extension Relation Type Comparison - LC Comment on draft-nottingham-http-plink-header-07 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343788056821@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 28 Jan 2010 15:27:32 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E72343788056821@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1077) Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 04:27:27 -0000 On 26/01/2010, at 4:03 AM, Eran Hammer-Lahav wrote: > The current text about comparing extension relation types is unclear: >=20 > When extension relation types are compared, they MUST be compared as > URIs in a case-insensitive fashion, character-by-character. Because > of this, all-lowercase URIs SHOULD be used for extension relations. >=20 > What does it mean "compared as URIs"? >=20 > It is clear that these two URIs would be deemed equivalent: >=20 > http://example.com/rel/type > HTTP://example.COM/rel/TYPE >=20 > But are they also equivalent to: >=20 > http://example.com:80/rel/type None of those are equivalent; it specifies case-insensitive, = character-by-character. "As URIs" alludes to the fact that an extension = type might be serialised in a non-URI form; e.g., as a CURIE, if that's = your cup of tea.=20 I'll try to clarify this in the next draft. Cheers, -- Mark Nottingham http://www.mnot.net/ From eran@hueniverse.com Wed Jan 27 20:49:57 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632063A6997 for ; Wed, 27 Jan 2010 20:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9VGj71QtUqU for ; Wed, 27 Jan 2010 20:49:56 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 7B0083A6993 for ; Wed, 27 Jan 2010 20:49:56 -0800 (PST) Received: (qmail 7912 invoked from network); 28 Jan 2010 04:50:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Jan 2010 04:50:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 27 Jan 2010 21:50:11 -0700 From: Eran Hammer-Lahav To: Mark Nottingham Date: Wed, 27 Jan 2010 21:50:03 -0700 Subject: RE: Extension Relation Type Comparison - LC Comment on draft-nottingham-http-plink-header-07 Thread-Topic: Extension Relation Type Comparison - LC Comment on draft-nottingham-http-plink-header-07 Thread-Index: Acqf0jyxJbDcyPA8S62lFogINNexxQAAvDQA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437899D22CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343788056821@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 04:49:57 -0000 > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Wednesday, January 27, 2010 8:28 PM > To: Eran Hammer-Lahav > Cc: apps-discuss@ietf.org > Subject: Re: Extension Relation Type Comparison - LC Comment on draft- > nottingham-http-plink-header-07 >=20 >=20 > On 26/01/2010, at 4:03 AM, Eran Hammer-Lahav wrote: >=20 > > The current text about comparing extension relation types is unclear: > > > > When extension relation types are compared, they MUST be compared as > > URIs in a case-insensitive fashion, character-by-character. Because > > of this, all-lowercase URIs SHOULD be used for extension relations. > > > > What does it mean "compared as URIs"? > > > > It is clear that these two URIs would be deemed equivalent: > > > > http://example.com/rel/type > > HTTP://example.COM/rel/TYPE > > > > But are they also equivalent to: > > > > http://example.com:80/rel/type >=20 > None of those are equivalent; it specifies case-insensitive, character-by= - > character. "As URIs" alludes to the fact that an extension type might be > serialised in a non-URI form; e.g., as a CURIE, if that's your cup of tea= . I have talked to a few folks about this and they all assumed 'as URI' means= that outside the lower-case exception, normal URI comparison rules apply. = I agree with your intention though that these should be compared as case-in= sensitive strings. EHL From adam@adambarth.com Tue Jan 26 12:42:31 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4150F3A69C5 for ; Tue, 26 Jan 2010 12:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.704 X-Spam-Level: X-Spam-Status: No, score=-3.704 tagged_above=-999 required=5 tests=[AWL=-4.182, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GV2A47ac80z for ; Tue, 26 Jan 2010 12:42:29 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id 8BDC03A6991 for ; Tue, 26 Jan 2010 12:42:29 -0800 (PST) Received: by pxi16 with SMTP id 16so3502289pxi.29 for ; Tue, 26 Jan 2010 12:42:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.5.26 with SMTP id 26mr5901496wfe.210.1264538558156; Tue, 26 Jan 2010 12:42:38 -0800 (PST) In-Reply-To: References: From: Adam Barth Date: Tue, 26 Jan 2010 20:42:18 +0000 Message-ID: <7789133a1001261242m3fd2eb72o9e7ffb12f522cf7f@mail.gmail.com> Subject: Re: comments on draft-abarth-mime-sniff-03 To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 28 Jan 2010 09:20:49 -0800 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 20:42:31 -0000 On Wed, Jan 20, 2010 at 10:41 PM, Larry Masinter wrote= : > All or nothing: > > =A0Whenever possible, user agents should avoid > =A0employing a content sniffing algorithm. > > The normative advice seems to apply to roles > other than "user agents"; whether or not > there is a user isn't really relevant. What other roles did you have in mind? I think the primary consumer of this specification with be web browsers, which commonly consider themselves to be user agents. > Secondly, it's not clear the scope of the > "should avoid" or whether this is really > intended to be normative. =A0I'll assume > that it is. I've made this clearer by using SHOULD in all caps. > =A0 However, if a user agent does employ a > =A0 content sniffing algorithm, the user agent > =A0 should use the algorithm in this document exactly > > The algorithm isn't exact (more below). I've removed the word exactly, > And think this is the wrong normative advice. > Implementations SHOULD NOT sniff labeled content, > and MUST NOT sniff any way beyond the ways > explicitly allowed here, and when they do sniff, > should opt into sniffing on a situation by situation, > type by type basis. I disagree. Life would be more predictable if there were fewer sniffing options, not more. The more predictable life is, the more secure it is. > The application of sniffing should be reserved > for situations where the implementor has sufficient > reason to believe that there is sufficient existing > deployed content that would not function as expected > if sniffing were not implemented, and these situations > should be encouraged to be as fine a granularity > as the implementor needs. I agree that sniffing should be reserved for those cases where the implementor believes it is necessary. However, once the implementor has decided its necessary, they should go "whole hog" and implement the algorithm defined in the spec. If everyone got to pick and choose what heuristics to use, then we'd be in much the same mess we're in now. > This normative advice should not require > updating as the deployed content evolves. I don't think it does. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > TERMINOLOGY "resource" I've removed this word from the draft. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > Malformed content-type information vs. missing content-type > > I think the cases where content-type information supplied is > malformed should be treated differently than the cases where > content-type information is missing. In particular, it > should be possible and allowed to raise an error > if content-type information is malformed, even when > sniffing is performed on well-formed, but incorrect, > content-type. That is, the "opt-in" behavior could allow > an implementation to sniff when no content-type, but > not sniff when there is a malformed content-type. This would make the algorithm less predictable. The goal is to make life more predictable. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Contextual application > > There are many different contexts of use of MIME labeled > material in the web, and the opt-in behavior for sniffing > should be allowed to be contextualized. For example, one > might opt in to sniffing for but opt out of > sniffing a script or rel link and opt in when doing a GET > on the main body of a web page. This would make the algorithm less predictable. The goal is to make life more predictable. Either you want to sniff or you don't. Cherry picking what to sniff leads to even more complexity. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > multiple content-type headers are malformed: > >> For HTTP resources, only the last Content-Type HTTP header, >> if any, contributes any type information > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > A message with more than one content-type header > should be treated as malformed. > > =A0 If the Content-Type HTTP header is present but > =A0 the value of the last such header cannot be > =A0 interpreted as described by the HTTP > =A0 specifications (e.g. because its value doesn't > =A0 contain a U+002F SOLIDUS ('/') character), then > =A0 the resource has no type information (even > =A0 if there are multiple Content-Type HTTP headers and > =A0 one of the other ones is syntactically correct). That's not the way sniffing algorithms work. We might wish they worked some other way, but that's life. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The "algorithm for extracting an encoding ...." I've removed this section. I suspect it should have remained in HTML5 instead of being moved into this document. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > file extensions: > > =A0Note: It is essential that file extensions > =A0are not used for determining the media type > =A0 for resources fetched over HTTP because > =A0file extensions can often by supplied by > =A0 malicious parties. > > =A0"Often" is dubious. How can file extensions be > supplied more often than =A0content-type headers? I've removed the word "often" in favor of "in some cases" which is factually indisputable. > What is the security threat? I've explained this in a previous reply. > =A0For resources fetched over most other protocols, e.g. > =A0FTP, there is no type information. > > "most other protocols" is imprecise. > Does this apply to imap? data:? There seems > to be some attempt to define this for RSS? I've replaced the word "most" with "some" which is factually indisputable. > Is it the protocol or the scheme that > determines the method, or both? That's a question for folks more pedantic than me. I have no idea, but I suspect it's the protocol. > I also don't think this matches implementations > for FTP, aren't file extension used frequently > to determine content-type? The FTP protocol does not transmit the type information to the user agent. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > Waiting (section 5) I've already replied to these comments. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Adding new types: > > " User agents may support additional types if desired, > =A0 by implicitly adding to the above table." > > This makes no sense and is a disaster for > interoperability. Sadly, it admits the reality of what will happen. For example, no one knows what will happen with audio and video content on the web now that HTML supports these media types natively. To pretend like we can control user agents here is fantasy. I've made the requirements here tighter. > The only reason why we have badly deployed content > is that user agents "sniffed" new types. If the > deployed infrastructure doesn't deploy new > kinds of sniffing, then people won't distribute > content. =A0This is a harmful escalating path and > encouraging implementations to add to the table > is disruptive and harmful. Don't do it. I've changed "if desired" to "if necessary". If user agents feel that sniffing video formats is necessary, it doesn't matter what we write in the spec. They'll still do it. Adam From mnot@mnot.net Thu Jan 28 20:23:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22D713A67EA for ; Thu, 28 Jan 2010 20:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xett-VMaMRf6 for ; Thu, 28 Jan 2010 20:23:27 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id F3F753A6781 for ; Thu, 28 Jan 2010 20:23:26 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.167.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2F2E222E1F1; Thu, 28 Jan 2010 23:23:39 -0500 (EST) Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B596450.7020001@gmx.de> Date: Fri, 29 Jan 2010 15:23:37 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> <4B596450.7020001@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 04:23:28 -0000 On 22/01/2010, at 7:39 PM, Julian Reschke wrote: > Mark Nottingham wrote: >> On 21/01/2010, at 11:53 PM, Julian Reschke wrote: >>> So it appears that this change does not "allow applications to = ignore", but "requires applications to specify how to process", so it's = an "opt in", not an "opt out". >> Yes, sorry; forgot to (re-)update the changelog on that one. >>> That being said: what is an "application" in this context? What = needs to be done to specify this? An example would be useful; for = instance, it would be interesting what = would need to say to specify the required processing of anchor. >> Yes, it would. "Application" is intentionally a bit fuzzy, because = while some link relations are defined by their application, others have = been purposefully separated; e.g., "alternate" is used for a variety of = purposes. >=20 > OK, what needs to be done to specify this? Probably just a sentence or two to tease this out at the top. I've been = trying to come up with prose for this for a while, but it's difficult to = do it without messing it up. Will try again. >=20 >>> In general I think that making this somehow optional will be an = interop disaster. Link header processing should be uniform and not = depend on some out-of-band information. >>>=20 >>> If the reason this was changed was because of missing support in = those UAs that currently handle the "Link" header: let's file bugs. >> It wasn't, and the link header parsing is the same; it's just the = interpretation that changes, depending on whether the application = expects the anchor parameter to be used. This was done because in many = (or even most) instances, it's very surprising to have a link from A to = B to be able to assert things about C, and have their semantics = automatically applied.=20 >=20 > Both *parsing* and *processing* should be uniform. >=20 > I'm ok with allowing recipients to *reject* (*) link headers that = include the anchor parameter. On the other hand *ignoring* it needs to = be a bug. >=20 > Best regards, Julian >=20 > (*) treat it as invalid If that's the case, you're saying that whether the anchor is allowed is = really a property of the relation type, not the application, aren't you?=20= -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Thu Jan 28 20:25:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA933A67EA for ; Thu, 28 Jan 2010 20:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.727 X-Spam-Level: X-Spam-Status: No, score=-3.727 tagged_above=-999 required=5 tests=[AWL=-1.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtN96wKQP5cY for ; Thu, 28 Jan 2010 20:25:19 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 3F1E23A6781 for ; Thu, 28 Jan 2010 20:25:19 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.167.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A435922E258; Thu, 28 Jan 2010 23:25:37 -0500 (EST) Subject: Re: New Version Notification - draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <62C36D7B-2385-47AB-8A92-DEA15A81B99E@mac.com> Date: Fri, 29 Jan 2010 15:25:34 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <08D686C3-17DD-4179-93A3-710728DA991B@mnot.net> References: <20100119053002.5CD613A683B@core3.amsl.com> <0460AF05-93FE-41D1-8E7D-D2FE6889C1F9@subbu.org> <62C36D7B-2385-47AB-8A92-DEA15A81B99E@mac.com> To: Jan Algermissen X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 04:25:20 -0000 No, the extension fields are in the registry itself; e.g., by adding a = "foo" field to it, you add a "foo" field to every registered link = relation type, in the registry (NOT on the wire).=20 On 23/01/2010, at 8:53 AM, Jan Algermissen wrote: >=20 > On Jan 22, 2010, at 7:19 PM, Subbu Allamaraju wrote: >=20 >> You mean "link-extension" params? >=20 > Hmm, no I am getting confused :-) >=20 > I;d say link-extension =3D=3D field. >=20 > Mark? >=20 > Jan >=20 >=20 >=20 >>=20 >> Subbu >>=20 >> On Jan 20, 2010, at 11:37 PM, Jan Algermissen wrote: >>=20 >>>=20 >>> On Jan 20, 2010, at 10:38 PM, Subbu Allamaraju wrote: >>>=20 >>>> The usage of fields is not clear. Sec. 6.3 says that "entries in = the Link Relation Type Registry can be extended with = application-specific data". But the BNF in Sec. 5 does not specify = fields. Could you clarify the intent of fields? >>>=20 >>> I understand fields to be meant as link relation specific = parameters. >>>=20 >>> Jan >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Subbu >>>>=20 >>>> On Jan 18, 2010, at 9:31 PM, Mark Nottingham wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>>> From: Internet-Draft@ietf.org >>>>>> Date: 19 January 2010 4:30:02 PM AEDT >>>>>> To: mnot@pobox.com, = draft-nottingham-http-link-header@tools.ietf.org,lisa.dusseault@gmail.com >>>>>> Subject: New Version Notification - = draft-nottingham-http-link-header-07.txt >>>>>>=20 >>>>>> New version (-07) has been submitted for = draft-nottingham-http-link-header-07.txt. >>>>>> = http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-07.t= xt >>>>>> Sub state has been changed to AD Follow up from New Id Needed >>>>>>=20 >>>>>> Diff from previous version: >>>>>> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-link-header-07 >>>>>>=20 >>>>>> IETF Secretariat. >>>>>=20 >>>>>=20 >>>>> -- >>>>> Mark Nottingham http://www.mnot.net/ >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>> ----------------------------------- >>> Jan Algermissen, Consultant >>>=20 >>> Mail: algermissen@acm.org >>> Blog: http://www.nordsc.com/blog/ >>> Work: http://www.nordsc.com/ >>> ----------------------------------- >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 > ----------------------------------- > Jan Algermissen, Consultant >=20 > Mail: algermissen@acm.org > Blog: http://www.nordsc.com/blog/ > Work: http://www.nordsc.com/ > ----------------------------------- >=20 >=20 >=20 -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Thu Jan 28 20:30:37 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1533A687E for ; Thu, 28 Jan 2010 20:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[AWL=-1.303, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOMpDJq4TX9x for ; Thu, 28 Jan 2010 20:30:35 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id A76123A6821 for ; Thu, 28 Jan 2010 20:30:35 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.167.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0A9FC22E1EB; Thu, 28 Jan 2010 23:30:53 -0500 (EST) Subject: Re: exposing sensitive information in URIs - LC comments on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B586349.5050405@gmx.de> Date: Fri, 29 Jan 2010 15:30:51 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B586349.5050405@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 04:30:37 -0000 I sincerely don't believe that adding any such text to the Link draft = (or the URI specification, which is where this really belongs) will make = the world any more secure of a place.=20 However, I'll be happy to have that discussion with Eric *if* he brings = it up. Cheers, On 22/01/2010, at 1:23 AM, Julian Reschke wrote: > Hi, >=20 > finally a security related comment. >=20 > During IETF LC for draft-brown-versioning-link-relations we got a = comment from Eric Rescorla: >=20 > "In general this mechanism seems sound but I'm not sure that the = security considerations are entirely adequate. This mechanism lets you = learn information about other versions of a resource even if you = potentially don't have permission to view them directly. Consider a = limiting case where each version of the resource had a name that = contained the change set for that resource. E.g., >=20 > http://example.com/versions/filename/_@line_50_+_FOO;@line_60_+_BAR/; >=20 > In this case, seeing other parts of the version tree leaks information = about those versions. I don't think that this is a problem for the = draft, but it might be useful to mention that this feature has = implications for name construction." >=20 > I assume this is a concern that applies to the Link header in general. >=20 > Best regards, Julian >=20 >=20 -- Mark Nottingham http://www.mnot.net/ From subbu@subbu.org Thu Jan 28 22:22:56 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 888413A690A for ; Thu, 28 Jan 2010 22:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSBkTOjTLNMF for ; Thu, 28 Jan 2010 22:22:55 -0800 (PST) Received: from mail-gx0-f227.google.com (mail-gx0-f227.google.com [209.85.217.227]) by core3.amsl.com (Postfix) with ESMTP id 260813A6853 for ; Thu, 28 Jan 2010 22:22:55 -0800 (PST) Received: by gxk27 with SMTP id 27so1557886gxk.7 for ; Thu, 28 Jan 2010 22:23:12 -0800 (PST) Received: by 10.100.23.10 with SMTP id 10mr420854anw.61.1264746191725; Thu, 28 Jan 2010 22:23:11 -0800 (PST) Received: from ?192.168.0.196? (socks3.corp.yahoo.com [216.145.54.15]) by mx.google.com with ESMTPS id 22sm616190yxe.3.2010.01.28.22.23.09 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Jan 2010 22:23:10 -0800 (PST) Subject: Re: New Version Notification - draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Subbu Allamaraju In-Reply-To: <08D686C3-17DD-4179-93A3-710728DA991B@mnot.net> Date: Thu, 28 Jan 2010 22:23:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100119053002.5CD613A683B@core3.amsl.com> <0460AF05-93FE-41D1-8E7D-D2FE6889C1F9@subbu.org> <62C36D7B-2385-47AB-8A92-DEA15A81B99E@mac.com> <08D686C3-17DD-4179-93A3-710728DA991B@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 06:22:56 -0000 Could you elaborate on the purpose of such fields when they have no = bearing on rels on the wire? The last para of 4.1 does include an = example, but it seems vague. It also seems that any information that can = be expressed via fields can equally be described in prose as part of the = description. Subbu On Jan 28, 2010, at 8:25 PM, Mark Nottingham wrote: > No, the extension fields are in the registry itself; e.g., by adding a = "foo" field to it, you add a "foo" field to every registered link = relation type, in the registry (NOT on the wire).=20 >=20 >=20 > On 23/01/2010, at 8:53 AM, Jan Algermissen wrote: >=20 >>=20 >> On Jan 22, 2010, at 7:19 PM, Subbu Allamaraju wrote: >>=20 >>> You mean "link-extension" params? >>=20 >> Hmm, no I am getting confused :-) >>=20 >> I;d say link-extension =3D=3D field. >>=20 >> Mark? >>=20 >> Jan >>=20 >>=20 >>=20 >>>=20 >>> Subbu >>>=20 >>> On Jan 20, 2010, at 11:37 PM, Jan Algermissen wrote: >>>=20 >>>>=20 >>>> On Jan 20, 2010, at 10:38 PM, Subbu Allamaraju wrote: >>>>=20 >>>>> The usage of fields is not clear. Sec. 6.3 says that "entries in = the Link Relation Type Registry can be extended with = application-specific data". But the BNF in Sec. 5 does not specify = fields. Could you clarify the intent of fields? >>>>=20 >>>> I understand fields to be meant as link relation specific = parameters. >>>>=20 >>>> Jan >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Subbu >>>>>=20 >>>>> On Jan 18, 2010, at 9:31 PM, Mark Nottingham wrote: >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>>> From: Internet-Draft@ietf.org >>>>>>> Date: 19 January 2010 4:30:02 PM AEDT >>>>>>> To: mnot@pobox.com, = draft-nottingham-http-link-header@tools.ietf.org,lisa.dusseault@gmail.com >>>>>>> Subject: New Version Notification - = draft-nottingham-http-link-header-07.txt >>>>>>>=20 >>>>>>> New version (-07) has been submitted for = draft-nottingham-http-link-header-07.txt. >>>>>>> = http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-07.t= xt >>>>>>> Sub state has been changed to AD Follow up from New Id Needed >>>>>>>=20 >>>>>>> Diff from previous version: >>>>>>> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-link-header-07 >>>>>>>=20 >>>>>>> IETF Secretariat. >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Mark Nottingham http://www.mnot.net/ >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> ----------------------------------- >>>> Jan Algermissen, Consultant >>>>=20 >>>> Mail: algermissen@acm.org >>>> Blog: http://www.nordsc.com/blog/ >>>> Work: http://www.nordsc.com/ >>>> ----------------------------------- >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >> ----------------------------------- >> Jan Algermissen, Consultant >>=20 >> Mail: algermissen@acm.org >> Blog: http://www.nordsc.com/blog/ >> Work: http://www.nordsc.com/ >> ----------------------------------- >>=20 >>=20 >>=20 >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 From julian.reschke@gmx.de Fri Jan 29 04:45:31 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D511F3A6A6F for ; Fri, 29 Jan 2010 04:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.832 X-Spam-Level: X-Spam-Status: No, score=-4.832 tagged_above=-999 required=5 tests=[AWL=-2.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sycTs5XVUc7X for ; Fri, 29 Jan 2010 04:45:30 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 678443A6A51 for ; Fri, 29 Jan 2010 04:45:30 -0800 (PST) Received: (qmail invoked by alias); 29 Jan 2010 12:45:50 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp063) with SMTP; 29 Jan 2010 13:45:50 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19peAVo9cBpQO3DgvjNuLkya2Yv3YpEKDWkdFSGmB 1bS+tuq0ULOLIV Message-ID: <4B62D875.102@gmx.de> Date: Fri, 29 Jan 2010 13:45:41 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Mark Nottingham Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> <4B596450.7020001@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65000000000000002 Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 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 Jan 2010 12:45:31 -0000 Mark Nottingham wrote: > ... > If that's the case, you're saying that whether the anchor is allowed is really a property of the relation type, not the application, aren't you? > ... First of all, I'd prefer to distinguish between (A) "must be processed" and (B) "may be processed, otherwise link must be rejected altogether". I see two purposes for the anchor parameter: 1) Making a statement about a subset of the context resource, by specifying a fragment identifier 2) Making a statement about a different resource than the context resource, such as 2a) because the context is anonymous (such as the response body for a 204, see ), or 2b) because a reverse link is exposed (anchor as workaround for missing rev parameter) I'm still not sure why we would ever make special cases here, except for the known bugs in current implementations of the Link header where anchor is ignored (so mainly Mozilla/Opera for stylesheet links). Optimally, we just work with the vendors to get the bugs fixed. If that's not possible, allowing an opt-out per relation type might work, as long as behavior (B) would still be allowed. Is there any relation != "stylesheet" for which this would be relevant? Best regards, Julian