From seb@serialseb.com  Thu Jan  7 06:40:49 2010
Return-Path: <seb@serialseb.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7E73A6853 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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: <BLU102-DS695C704E48B280FF87F3CB5710@phx.gbl>
From: "Sebastien Lambla" <seb@serialseb.com>
To: <apps-discuss@ietf.org>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-GB link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>All,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>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.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>So there&#8217;s a clash between 2047 and 2388, =
which should
probably be addressed. In the mean-time, I&#8217;d like to know if =
anyone has
been known to use 2047 for parameters?<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I&#8217;ve quickly tested browser implementations, =
and they
simply pass back the UTF-8 code points I&#8217;ve provided in the =
markup, which
I find very surprising. How do people deal with such code-points in the
headers?<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thanks,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Sebastien Lambla <o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0288_01CA8FA7.64685530--

From A.Hoenes@TR-Sys.de  Mon Jan 11 07:09:16 2010
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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=?= <ah@TR-Sys.de>
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: <D0C0A51B-5A8A-414E-9E56-033EFA8ED71C@nokia.com> 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 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 HÎnes.

-- 

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


From lars.eggert@nokia.com  Wed Jan 13 00:39:45 2010
Return-Path: <lars.eggert@nokia.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 <lars.eggert@nokia.com>
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?= <ah@tr-sys.de>, Joe Touch <touch@isi.edu>
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" <port-srv-reg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "tsvwg@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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 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: <touch@ISI.EDU>
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 <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Lars Eggert <lars.eggert@nokia.com>
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?= <ah@tr-sys.de>, "port-srv-reg@ietf.org" <port-srv-reg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "tsvwg@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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 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: <A.Hoenes@TR-Sys.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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=?= <ah@TR-Sys.de>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 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 HÎnes.

-- 

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


From touch@ISI.EDU  Wed Jan 13 19:31:59 2010
Return-Path: <touch@ISI.EDU>
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 <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= <ah@TR-Sys.de>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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: <ogud@ogud.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 <lars.eggert@nokia.com>
From: Olafur Gudmundsson <ogud@ogud.com>
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" <port-srv-reg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "tsvwg@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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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: <wleggette@cleversafe.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661F73A69FE for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <wleggette@cleversafe.com>);  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 <wleggette@cleversafe.com>
To: "apps-discuss@ietf.org" <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: <C774FD6C.23CD8%wleggette@cleversafe.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: <wleggette@cleversafe.com>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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: <alexey.melnikov@isode.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8C9A3A6A08 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <S0-jSwBYj6x8@rufus.isode.com>; 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 <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Wesley Leggette <wleggette@cleversafe.com>
Subject: Re: Application protocol for distributed storage
References: <C774FD6C.23CD8%wleggette@cleversafe.com>
In-Reply-To: <C774FD6C.23CD8%wleggette@cleversafe.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Song Haibin <melodysong@huawei.com>, "'Woundy, Richard'" <Richard_Woundy@cable.comcast.com>, "apps-discuss@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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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, <http://www.ietf.org/IESGmems.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address


From wleggette@cleversafe.com  Thu Jan 14 20:03:35 2010
Return-Path: <wleggette@cleversafe.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22AC73A6839 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <wleggette@cleversafe.com>);  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 <wleggette@cleversafe.com>
To: Song Haibin <melodysong@huawei.com>, Alexey Melnikov <alexey.melnikov@isode.com>
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: <C77544FA.23CE2%wleggette@cleversafe.com>
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: <wleggette@cleversafe.com>
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" <Richard_Woundy@cable.comcast.com>, IETF Apps Discuss <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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" <melodysong@huawei.com> 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, <http://www.ietf.org/IESGmems.html>
>> Internet Messaging Team Lead, <http://www.isode.com>
>> JID: same as my email address
>>=20
>>=20
>=20
>=20


From magnus.westerlund@ericsson.com  Fri Jan 15 02:01:39 2010
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 <magnus.westerlund@ericsson.com>
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 <ogud@ogud.com>
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" <apps-discuss@ietf.org>, "port-srv-reg@ietf.org" <port-srv-reg@ietf.org>, "tsvwg@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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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
Färögatan 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: <aaron@serendipity.cx>
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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <apps-discuss@ietf.org>; Fri, 15 Jan 2010 05:59:45 -0800 (PST)
Received: by pwi20 with SMTP id 20so298178pwi.29 for <apps-discuss@ietf.org>; 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: <C774FD6C.23CD8%wleggette@cleversafe.com>
References: <C774FD6C.23CD8%wleggette@cleversafe.com>
From: Aaron Stone <aaron@serendipity.cx>
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 <wleggette@cleversafe.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2010 13:55:10 -0000

On Thu, Jan 14, 2010 at 2:57 PM, Wesley Leggette
<wleggette@cleversafe.com> 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: <ogud@ogud.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 <magnus.westerlund@ericsson.com>, Olafur Gudmundsson <ogud@ogud.com>
From: Olafur Gudmundsson <ogud@ogud.com>
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" <apps-discuss@ietf.org>, "port-srv-reg@ietf.org" <port-srv-reg@ietf.org>, "tsvwg@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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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: <michelle.cotton@icann.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 <michelle.cotton@icann.org>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, "tsvwg@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: <C775D4C1.1F7D2%michelle.cotton@icann.org>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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

<HTML>
<HEAD>
<TITLE>New version of document for review</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>Attn: TSVWG Working Group, DNSOPS Working Group and APPS AREA Working=
 Group<BR>
<BR>
There is a new version of the </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"=
Courier, Courier New"><SPAN STYLE=3D'font-size:10pt'>Internet Assigned Numb=
ers Authority (IANA) Procedures for the Management<BR>
of the Transport Protocol Port Number and Service Name Registry document:<B=
R>
</SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPA=
N STYLE=3D'font-size:11pt'><BR>
draft-ietf-tsvwg-iana-ports-04.txt <BR>
<BR>
Please review and send comments. &nbsp;Your feedback is much appreciated.<B=
R>
<BR>
Thank you,<BR>
<BR>
Michelle Cotton<BR>
(on behalf of the ports teams)<BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>


--_000_C775D4C11F7D2michellecottonicannorg_--

From melodysong@huawei.com  Thu Jan 14 19:42:21 2010
Return-Path: <melodysong@huawei.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6763A6A1B for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <melodysong@huawei.com>
Subject: RE: Application protocol for distributed storage
In-reply-to: <4B4FA328.3030205@isode.com>
To: 'Alexey Melnikov' <alexey.melnikov@isode.com>, 'Wesley Leggette' <wleggette@cleversafe.com>
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'" <Richard_Woundy@cable.comcast.com>, 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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, <http://www.ietf.org/IESGmems.html>
> Internet Messaging Team Lead, <http://www.isode.com>
> JID: same as my email address
> 
> 



From A.Hoenes@TR-Sys.de  Fri Jan 15 10:41:04 2010
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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=?= <ah@TR-Sys.de>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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 <postel@isi.edu>
#
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 <mrose@dbc.mtview.ca.us>
#
pop3s           995/tcp    pop3 protocol over TLS/SSL (was spop3)
pop3s           995/udp    pop3 protocol over TLS/SSL (was spop3)
#                          Gordon Mangione <gordm@microsoft.com>
#
imap            143/tcp    Internet Message Access Protocol
imap            143/udp    Internet Message Access Protocol
#                          Mark Crispin <MRC@CAC.Washington.EDU>
#
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:  [... <<as above>> ...]

----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 HÎnes.

-- 

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


From richard_woundy@cable.comcast.com  Fri Jan 15 14:20:19 2010
Return-Path: <richard_woundy@cable.comcast.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34413A68FA for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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: <C77544FA.23CE2%wleggette@cleversafe.com>
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> <C77544FA.23CE2%wleggette@cleversafe.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "Wesley Leggette" <wleggette@cleversafe.com>, "Song Haibin" <melodysong@huawei.com>, "Alexey Melnikov" <alexey.melnikov@isode.com>
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" <Richard_Woundy@cable.comcast.com>, IETF Apps Discuss <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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: <http://www.cleversafe.org/dispersed-storage/idas>. 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 <http://www.cleversafe.com/vision/object-storage>: "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
<http://www.cleversafe.com/vision/Dispersed_Data_Archiving_Top-10-Featur
es>: "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.
<http://www.google.com/patents?q=3Dcleversafe>?

-- 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" <melodysong@huawei.com> 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, <http://www.ietf.org/IESGmems.html>
>> Internet Messaging Team Lead, <http://www.isode.com>
>> JID: same as my email address
>>=20
>>=20
>=20
>=20


From wleggette@cleversafe.com  Fri Jan 15 15:30:00 2010
Return-Path: <wleggette@cleversafe.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EC413A6959 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <wleggette@cleversafe.com>);  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 <wleggette@cleversafe.com>);  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 <wleggette@cleversafe.com>
To: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>, Song Haibin <melodysong@huawei.com>, Alexey Melnikov <alexey.melnikov@isode.com>
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: <C776564E.23E43%wleggette@cleversafe.com>
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: <wleggette@cleversafe.com>
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 <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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.
> <http://www.google.com/patents?q=3Dcleversafe>?

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: <Nicolas.Williams@sun.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567B93A6844 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <apps-discuss@ietf.org>; 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 <apps-discuss@ietf.org>; 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 <Nicolas.Williams@sun.com>
To: Aaron Stone <aaron@serendipity.cx>
Subject: Re: Application protocol for distributed storage
Message-ID: <20100115234422.GM1061@Sun.COM>
References: <C774FD6C.23CD8%wleggette@cleversafe.com> <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" <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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: <john-ietf@jck.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B886B3A6908 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <john-ietf@jck.com>
To: Wesley Leggette <wleggette@cleversafe.com>
Subject: Re: Application protocol for distributed storage
Message-ID: <4C1F08AD46704B49C435ED75@PST.JCK.COM>
In-Reply-To: <C776564E.23E43%wleggette@cleversafe.com>
References: <C776564E.23E43%wleggette@cleversafe.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: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>, IETF Apps Discuss <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Jan 2010 14:31:31 -0000

--On Friday, January 15, 2010 17:28 -0600 Wesley Leggette
<wleggette@cleversafe.com> 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.
>> <http://www.google.com/patents?q=cleversafe>?
> 
> 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: <eburger@standardstrack.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5093A67FB for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <eburger@standardstrack.com>) id 1NWYTS-0004hI-QW; Sun, 17 Jan 2010 08:59:39 -0800
Message-Id: <BD19558A-B5D3-4631-8DBD-C6ACD78A70CB@standardstrack.com>
From: Eric Burger <eburger@standardstrack.com>
To: Wesley Leggette <wleggette@cleversafe.com>
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: <C776564E.23E43%wleggette@cleversafe.com> <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 <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Jan 2010 16:59:46 -0000

To jck's point, see, e.g., <https://datatracker.ietf.org/ipr/580/>.   
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
> <wleggette@cleversafe.com> 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.
>>> <http://www.google.com/patents?q=cleversafe>?
>>
>> 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: <magnus.westerlund@ericsson.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 <magnus.westerlund@ericsson.com>
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==?= <ah@TR-Sys.de>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 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: <mnot@mnot.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69733A6A48 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <mnot@mnot.net>
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> <CF881CDD-4148-4A6E-9B95-90EC96E56E8E@mnot.net> <90C41DD21FB7C64BB94121FBBC2E72343787E67BFA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav <eran@hueniverse.com>
X-Mailer: Apple Mail (2.1077)
Cc: Apps Discuss <discuss@apps.ietf.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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: <mnot@mnot.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055B03A692D for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <mnot@mnot.net>
Date: Tue, 19 Jan 2010 16:31:22 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net>
References: <20100119053002.5CD613A683B@core3.amsl.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
X-Mailer: Apple Mail (2.1077)
Cc: Apps Discuss <discuss@apps.ietf.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4EA93A68D9 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <julian.reschke@gmx.de>
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 <apps-discuss@ietf.org>,  HTTP Working Group <ietf-http-wg@w3.org>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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 
<http://tools.ietf.org/rfcdiff?url2=draft-reschke-rfc2231-in-http-08.txt>.

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: <cfinss@dial.pipex.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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" <cfinss@dial.pipex.com>
To: "Michelle Cotton" <michelle.cotton@icann.org>, <apps-discuss@ietf.org>, <tsvwg@ietf.org>
References: <C775D4C1.1F7D2%michelle.cotton@icann.org>
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" <cfinss@dial.pipex.com>
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 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" <michelle.cotton@icann.org>
To: <apps-discuss@ietf.org>; <dnsop@ietf.org>; <tsvwg@ietf.org>
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: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CEF63A6984 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <julian.reschke@gmx.de>
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 <discuss@apps.ietf.org>
Subject: Re: Fwd: New Version Notification -	draft-nottingham-http-link-header-07.txt
References: <20100119053002.5CD613A683B@core3.amsl.com> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net>
In-Reply-To: <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net>
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" <public-html@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 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 
<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-E>:

    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: <masinter@adobe.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A758828C0D8 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <masinter@adobe.com>
To: Adam Barth <w3c@adambarth.com>, Ian Hickson <ian@hixie.ch>
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: <C68CB012D9182D408CED7B884F441D4D5FDE79@nambxv01a.corp.adobe.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "apps-discuss@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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 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 <img src=3D...> 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: <algermissen1971@mac.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D723A67C1 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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: <EA551C32-6AC0-4AE1-AB22-0BA8876022C9@mac.com>
From: Jan Algermissen <algermissen1971@mac.com>
To: Subbu Allamaraju <subbu@subbu.org>
In-reply-to: <A70E9FE8-512E-42A1-8523-042368DABBBC@subbu.org>
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> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <A70E9FE8-512E-42A1-8523-042368DABBBC@subbu.org>
X-Mailer: Apple Mail (2.936)
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4013D3A6822 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <julian.reschke@gmx.de>
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 <discuss@apps.ietf.org>,  HTTP Working Group <ietf-http-wg@w3.org>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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 '
>    <draft-nottingham-http-link-header-07.txt> 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: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062873A6A5D for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <julian.reschke@gmx.de>
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 <discuss@apps.ietf.org>,  HTTP Working Group <ietf-http-wg@w3.org>
Subject: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt
References: <20100119053002.5CD613A683B@core3.amsl.com>	<E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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 
(<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-E>) 
say:

    o  Allowed applications to ignore links with anchor parameters if
       they're concerned.

The actual text changed from 
(<http://tools.ietf.org/html/draft-nottingham-http-link-header-06#section-5>)

    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 
(<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5.2>)

    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 
<http://tools.ietf.org/html/draft-brown-versioning-link-relations-06#appendix-A.1> 
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: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC113A6829 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <julian.reschke@gmx.de>
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 <discuss@apps.ietf.org>,  HTTP Working Group <ietf-http-wg@w3.org>
Subject: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt
References: <20100119053002.5CD613A683B@core3.amsl.com>	<E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2010 13:32:07 -0000

Hi,

<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-E> 
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 
<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5> 
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, 
<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5.3> 
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 
(<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-B>):

    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 
(<http://tools.ietf.org/html/rfc1866#section-5.7.3>):

     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 
<http://www.w3.org/TR/html4/struct/links.html#rev-link>:

    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:       <LINK href="docB" rel="foo">

    Has exactly the same meaning as:

    Document B:       <LINK href="docA" rev="foo">

    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: <B>; rev=foo

should be equivalent to

   Link: <A>; rel=foo; anchor=<B>

right?

Best regards, Julian



From julian.reschke@gmx.de  Thu Jan 21 05:48:01 2010
Return-Path: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6EFE3A67AD for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <julian.reschke@gmx.de>
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 <discuss@apps.ietf.org>,  HTTP Working Group <ietf-http-wg@w3.org>
Subject: parameter quoting - LC comment on draft-nottingham-http-link-header-07.txt
References: <20100119053002.5CD613A683B@core3.amsl.com>	<E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2010 13:48:01 -0000

Hi,

a few comments regarding quoting of link parameters:

<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5> 
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






From julian.reschke@gmx.de  Thu Jan 21 06:05:07 2010
Return-Path: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76A3E28C162 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <julian.reschke@gmx.de>
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 <discuss@apps.ietf.org>,  HTTP Working Group <ietf-http-wg@w3.org>
Subject: editorial LC comments on draft-nottingham-http-link-header-07.txt
References: <20100119053002.5CD613A683B@core3.amsl.com>	<E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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,
               <http://www.w3.org/TR/2009/CR-css3-mediaqueries-20090915>.

    [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,
               <http://www.w3.org/TR/1999/REC-html401-19991224>.

    [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,
               <http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014>.

    [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,
               <http://www.w3.org/TR/2008/REC-xhtml-basic-20080729>.

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,
               <http://www.w3.org/TR/2009/
               CR-css3-mediaqueries-20090915/>.

    [W3C.REC-html401-19991224]
               Jacobs, I., Raggett, D., and A. Hors, "HTML 4.01
               Specification", W3C Recommendation REC-html401-19991224,
               December 1999,
               <http://www.w3.org/TR/1999/REC-html401-19991224/>.

    [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,
               <http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/>.

    [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,
               <http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/>.

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: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E074E3A680D for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <julian.reschke@gmx.de>
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 <discuss@apps.ietf.org>,  HTTP Working Group <ietf-http-wg@w3.org>
Subject: exposing sensitive information in URIs - LC comments on draft-nottingham-http-link-header-07.txt
References: <20100119053002.5CD613A683B@core3.amsl.com>	<E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B4FC3A697E for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <julian.reschke@gmx.de>
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>	 <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <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 <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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: <asplake@googlemail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC363A69BD for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; Tue, 19 Jan 2010 13:06:12 -0800 (PST)
Received: by pwj2 with SMTP id 2so2641505pwj.34 for <discuss@apps.ietf.org>; 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: <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net>
References: <20100119053002.5CD613A683B@core3.amsl.com> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net>
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 <asplake@freenetname.co.uk>
To: Mark Nottingham <mnot@mnot.net>
Content-Type: multipart/alternative; boundary=000e0cd0eba27e9dbc047d8ad67f
X-Mailman-Approved-At: Thu, 21 Jan 2010 08:13:56 -0800
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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 <mnot@mnot.net>

>
>
> 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

<br>Thanks, and nice timing - I&#39;ve just ported my link header rubygem t=
o Python - see <a href=3D"http://pypi.python.org/pypi/LinkHeader/0.1">http:=
//pypi.python.org/pypi/LinkHeader/0.1</a> or <a href=3D"http://bitbucket.or=
g/asplake/link_header/">http://bitbucket.org/asplake/link_header/</a>.<br>
<br>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.<br>
<br>Caveat: I&#39;ve made no serious attempt (in either language) to parse =
title* attributes (&quot;title*&quot; &quot;=3D&quot; 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.<br>
<br>Regards,<br clear=3D"all">Mike<br><a href=3D"mailto:mjb@asplake.co.uk">=
mjb@asplake.co.uk</a><br><a href=3D"http://positiveincline.com">http://posi=
tiveincline.com</a><br><a href=3D"http://twitter.com/asplake">http://twitte=
r.com/asplake</a><br>

<br><br><div class=3D"gmail_quote">2010/1/19 Mark Nottingham <span dir=3D"l=
tr">&lt;<a href=3D"mailto:mnot@mnot.net">mnot@mnot.net</a>&gt;</span><br><b=
lockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 20=
4, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Begin forwarded message:<br>
<br>
&gt; From: <a href=3D"mailto:Internet-Draft@ietf.org">Internet-Draft@ietf.o=
rg</a><br>
&gt; Date: 19 January 2010 4:30:02 PM AEDT<br>
&gt; To: <a href=3D"mailto:mnot@pobox.com">mnot@pobox.com</a>, <a href=3D"m=
ailto:draft-nottingham-http-link-header@tools.ietf.org">draft-nottingham-ht=
tp-link-header@tools.ietf.org</a>,<a href=3D"mailto:lisa.dusseault@gmail.co=
m">lisa.dusseault@gmail.com</a><br>

&gt; Subject: New Version Notification - draft-nottingham-http-link-header-=
07.txt<br>
&gt;<br>
&gt; New version (-07) has been submitted for draft-nottingham-http-link-he=
ader-07.txt.<br>
&gt; <a href=3D"http://www.ietf.org/internet-drafts/draft-nottingham-http-l=
ink-header-07.txt" target=3D"_blank">http://www.ietf.org/internet-drafts/dr=
aft-nottingham-http-link-header-07.txt</a><br>
&gt; Sub state has been changed to AD Follow up from New Id Needed<br>
&gt;<br>
&gt; Diff from previous version:<br>
&gt; <a href=3D"http://tools.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-=
link-header-07" target=3D"_blank">http://tools.ietf.org/rfcdiff?url2=3Ddraf=
t-nottingham-http-link-header-07</a><br>
&gt;<br>
&gt; IETF Secretariat.<br>
<font color=3D"#888888"><br>
<br>
--<br>
Mark Nottingham =A0 =A0 <a href=3D"http://www.mnot.net/" target=3D"_blank">=
http://www.mnot.net/</a><br>
<br>
<br>
<br>
</font></blockquote></div><br>

--000e0cd0eba27e9dbc047d8ad67f--

From subbu@subbu.org  Wed Jan 20 13:39:01 2010
Return-Path: <subbu@subbu.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA8028C105 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; Wed, 20 Jan 2010 13:38:59 -0800 (PST)
Received: by bwz4 with SMTP id 4so6113990bwz.2 for <discuss@apps.ietf.org>; 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 <subbu@subbu.org>
In-Reply-To: <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net>
Date: Wed, 20 Jan 2010 13:38:47 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <A70E9FE8-512E-42A1-8523-042368DABBBC@subbu.org>
References: <20100119053002.5CD613A683B@core3.amsl.com> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.1077)
X-Mailman-Approved-At: Thu, 21 Jan 2010 08:13:59 -0800
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 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: <adam@adambarth.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D104B3A6992 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; Wed, 20 Jan 2010 15:15:03 -0800 (PST)
Received: by pxi16 with SMTP id 16so4083820pxi.29 for <apps-discuss@ietf.org>; 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: <C68CB012D9182D408CED7B884F441D4D5FDE79@nambxv01a.corp.adobe.com>
References: <C68CB012D9182D408CED7B884F441D4D5FDE79@nambxv01a.corp.adobe.com>
From: Adam Barth <ietf@adambarth.com>
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 <masinter@adobe.com>
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 <ian@hixie.ch>, "apps-discuss@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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 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 <masinter@adobe.com> 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
<http://en.wikipedia.org/wiki/Comet_(programming)>.  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: <david@dbooth.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABAFF3A6859 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <david@dbooth.org>
To: apps-discuss <apps-discuss@ietf.org>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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: <asplake@googlemail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250AF3A68F4 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; Thu, 21 Jan 2010 07:01:33 -0800 (PST)
Received: by pzk33 with SMTP id 33so36961pzk.2 for <discuss@apps.ietf.org>; 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> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <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 <asplake@freenetname.co.uk>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: multipart/alternative; boundary=000e0cd106121cfc6d047dadfa63
X-Mailman-Approved-At: Thu, 21 Jan 2010 08:13:58 -0800
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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 <julian.reschke@gmx.de>

> Hi,
>
> a few comments regarding quoting of link parameters:
>
> <http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5>
> 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),<br clear=3D"all"><br><blockquote style=3D"border-left:=
 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex=
;" class=3D"gmail_quote">
Which made have a closer look at existing parameters (sorry for not bringin=
g this up earlier):<br><br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | ( &quot;type&quot; &quot;=3D&quo=
t; type-name &quot;/&quot; subtype-name )<br><br>
I believe this *definitively* needs quoting, as &quot;/&quot; is a separato=
r character in HTTP and thus can not appear in a token.<br></blockquote>


<br>But is &#39;type-name &quot;/&quot; subtype-name&#39; a token?=A0 I did=
n&#39;t interpret as such - in fact I assumed (perhaps erroneously) that it=
 was in fact two tokens separated by &quot;/&quot;.<br><br>Regards,<br>Mike=
<br>
<br><br><div class=3D"gmail_quote">2010/1/21 Julian Reschke <span dir=3D"lt=
r">&lt;<a href=3D"mailto:julian.reschke@gmx.de">julian.reschke@gmx.de</a>&g=
t;</span><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px so=
lid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
a few comments regarding quoting of link parameters:<br>
<br>
&lt;<a href=3D"http://tools.ietf.org/html/draft-nottingham-http-link-header=
-07#section-5" target=3D"_blank">http://tools.ietf.org/html/draft-nottingha=
m-http-link-header-07#section-5</a>&gt; defines the new parameters:<br>
<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | ( &quot;hreflang&quot; &quot;=3D=
&quot; Language-Tag )<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | ( &quot;media&quot; &quot;=3D&qu=
ot; ( MediaDesc | &lt;&quot;&gt; MediaDesc &lt;&quot;&gt; ) )<br>
<br>
&quot;hreflang&quot; and &quot;media&quot;, so quoting is allowed for media=
, but it&#39;s not for hreflang. I think it&#39;s correct that valid langua=
ge tags never require quoting, but I&#39;m not sure that disallowing quotin=
g is the right thing to do here.<br>

<br>
Which made have a closer look at existing parameters (sorry for not bringin=
g this up earlier):<br>
<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | ( &quot;type&quot; &quot;=3D&quo=
t; type-name &quot;/&quot; subtype-name )<br>
<br>
I believe this *definitively* needs quoting, as &quot;/&quot; is a separato=
r character in HTTP and thus can not appear in a token.<br>
<br>
Also, as this spec uses the RFC 2616 ABNF, we probably need to duplicate th=
e statement from &lt;<a href=3D"http://greenbytes.de/tech/webdav/rfc2616.ht=
ml#rfc.section.3.7" target=3D"_blank">http://greenbytes.de/tech/webdav/rfc2=
616.html#rfc.section.3.7</a>&gt;:<br>

<br>
&quot;...Linear white space (LWS) MUST NOT be used between the type and sub=
type, ...&quot;<br>
<br>
Best regards, Julian<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div><br>

--000e0cd106121cfc6d047dadfa63--

From ogud@ogud.com  Thu Jan 21 08:25:10 2010
Return-Path: <ogud@ogud.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 <magnus.westerlund@ericsson.com>, Alfred  =?iso-8859-1?Q?=EF=BF=BD?= <ah@TR-Sys.de>
From: Olafur Gudmundsson <ogud@ogud.com>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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: <touch@ISI.EDU>
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 <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "tom.petch" <cfinss@dial.pipex.com>
Subject: Re: [tsvwg] New version of document for review
References: <C775D4C1.1F7D2%michelle.cotton@icann.org> <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 <michelle.cotton@icann.org>, 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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: <mnot@mnot.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B0D3A6AEC for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <mnot@mnot.net>
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>	<E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1077)
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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 =
<http://tools.ietf.org/html/draft-brown-versioning-link-relations-06#appen=
dix-A.1> 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: <mnot@mnot.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6DD3A67F6 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <mnot@mnot.net>
In-Reply-To: <4B586DF0.9010201@gmx.de>
Date: Fri, 22 Jan 2010 11:53:37 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A190150C-D5AC-467B-A665-64B9859E256F@mnot.net>
References: <20100119053002.5CD613A683B@core3.amsl.com>	 <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <4B56E27D.800@gmx.de>	 <4B585B06.1040704@gmx.de> <7a2269961001210701t15ea51cdmf48cc696282c44b6@mail.gmail.com> <4B586DF0.9010201@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1077)
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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: <mnot@mnot.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E800228C116 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <mnot@mnot.net>
In-Reply-To: <4B58574B.4050204@gmx.de>
Date: Fri, 22 Jan 2010 12:02:42 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE77FC83-4137-421B-9511-02B13642AE1A@mnot.net>
References: <20100119053002.5CD613A683B@core3.amsl.com>	<E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <4B56E27D.800@gmx.de> <4B58574B.4050204@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1077)
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2010 01:02:53 -0000

On 22/01/2010, at 12:31 AM, Julian Reschke wrote:
>=20
> So the grammar in =
<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5=
> 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, =
<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5=
.3> 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 =
(<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix=
-B>):
>=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: <mnot@mnot.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64DE128C122 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <mnot@mnot.net>
In-Reply-To: <4B585EFF.2080104@gmx.de>
Date: Fri, 22 Jan 2010 12:05:17 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1FD0B26-CCC1-4F7B-B701-8568F44BEC86@mnot.net>
References: <20100119053002.5CD613A683B@core3.amsl.com>	<E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <4B56E27D.800@gmx.de> <4B585EFF.2080104@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1077)
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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: <mnot@mnot.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8A93A680B for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <mnot@mnot.net>
In-Reply-To: <7a2269961001191306i9bf78c1oe55f574166874944@mail.gmail.com>
Date: Fri, 22 Jan 2010 14:46:23 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5991ED4-6105-48EB-99F8-64EA9D36162E@mnot.net>
References: <20100119053002.5CD613A683B@core3.amsl.com> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <7a2269961001191306i9bf78c1oe55f574166874944@mail.gmail.com>
To: mjb@asplake.co.uk
X-Mailer: Apple Mail (2.1077)
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2010 03:46:45 -0000

Thanks, Mike; looks interesting.=20

I have a less functional implementation at =
<http://gist.github.com/210535>; 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 <mnot@mnot.net>
>=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: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957793A68BD for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <julian.reschke@gmx.de>
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 <mnot@mnot.net>
Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt
References: <20100119053002.5CD613A683B@core3.amsl.com>	<E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <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 <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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 <http://tools.ietf.org/html/draft-brown-versioning-link-relations-06#appendix-A.1> 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: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F823A68AA for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <julian.reschke@gmx.de>
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 <mnot@mnot.net>
Subject: Re: parameter quoting - LC comment on draft-nottingham-http-link-header-07.txt
References: <20100119053002.5CD613A683B@core3.amsl.com>	 <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <4B56E27D.800@gmx.de>	 <4B585B06.1040704@gmx.de> <7a2269961001210701t15ea51cdmf48cc696282c44b6@mail.gmail.com> <4B586DF0.9010201@gmx.de> <A190150C-D5AC-467B-A665-64B9859E256F@mnot.net>
In-Reply-To: <A190150C-D5AC-467B-A665-64B9859E256F@mnot.net>
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 <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC753A68F5 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <julian.reschke@gmx.de>
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 <mnot@mnot.net>
Subject: Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt
References: <20100119053002.5CD613A683B@core3.amsl.com>	<E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <4B56E27D.800@gmx.de> <4B58574B.4050204@gmx.de> <FE77FC83-4137-421B-9511-02B13642AE1A@mnot.net>
In-Reply-To: <FE77FC83-4137-421B-9511-02B13642AE1A@mnot.net>
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 <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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 (<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-B>):
>>
>>   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.

(<http://tools.ietf.org/html/rfc1866#section-5.7.3>)

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: <subbu@subbu.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3A728C127 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; Fri, 22 Jan 2010 10:19:45 -0800 (PST)
Received: by fg-out-1718.google.com with SMTP id e21so30076fga.16 for <discuss@apps.ietf.org>; 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 <subbu@subbu.org>
In-Reply-To: <EA551C32-6AC0-4AE1-AB22-0BA8876022C9@mac.com>
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> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <A70E9FE8-512E-42A1-8523-042368DABBBC@subbu.org> <EA551C32-6AC0-4AE1-AB22-0BA8876022C9@mac.com>
To: Jan Algermissen <algermissen1971@mac.com>, Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.1077)
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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: <algermissen1971@mac.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F213A6774 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <algermissen1971@mac.com>
To: Subbu Allamaraju <subbu@subbu.org>
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> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <A70E9FE8-512E-42A1-8523-042368DABBBC@subbu.org> <EA551C32-6AC0-4AE1-AB22-0BA8876022C9@mac.com> <0460AF05-93FE-41D1-8E7D-D2FE6889C1F9@subbu.org>
X-Mailer: Apple Mail (2.936)
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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: <masinter@adobe.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2633A68F8 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <masinter@adobe.com>
To: Adam Barth <ietf@adambarth.com>
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: <C68CB012D9182D408CED7B884F441D4D5FE353@nambxv01a.corp.adobe.com>
References: <C68CB012D9182D408CED7B884F441D4D5FDE79@nambxv01a.corp.adobe.com> <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 <ian@hixie.ch>, "apps-discuss@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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 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
> <http://en.wikipedia.org/wiki/Comet_(programming)>.  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: <adam@adambarth.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524733A6782 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; Fri, 22 Jan 2010 19:26:13 -0800 (PST)
Received: by pzk4 with SMTP id 4so1457891pzk.32 for <apps-discuss@ietf.org>; 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: <C68CB012D9182D408CED7B884F441D4D5FE353@nambxv01a.corp.adobe.com>
References: <C68CB012D9182D408CED7B884F441D4D5FDE79@nambxv01a.corp.adobe.com>  <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.com>  <C68CB012D9182D408CED7B884F441D4D5FE353@nambxv01a.corp.adobe.com>
From: Adam Barth <ietf@adambarth.com>
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 <masinter@adobe.com>
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" <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 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 <masinter@adobe.com> 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
>> <http://en.wikipedia.org/wiki/Comet_(programming)>. =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: <ian@hixie.ch>
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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <ian@hixie.ch>
To: Larry Masinter <masinter@adobe.com>
Subject: RE: comments on draft-abarth-mime-sniff-03
In-Reply-To: <C68CB012D9182D408CED7B884F441D4D5FE353@nambxv01a.corp.adobe.com>
Message-ID: <Pine.LNX.4.64.1001230630450.19587@ps20323.dreamhostps.com>
References: <C68CB012D9182D408CED7B884F441D4D5FDE79@nambxv01a.corp.adobe.com> <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.com> <C68CB012D9182D408CED7B884F441D4D5FE353@nambxv01a.corp.adobe.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" <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 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: <ian@hixie.ch>
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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <ian@hixie.ch>
To: Adam Barth <ietf@adambarth.com>
Subject: Re: comments on draft-abarth-mime-sniff-03
In-Reply-To: <7789133a1001221925sf1f55b8k31953828848f2787@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1001230632200.19587@ps20323.dreamhostps.com>
References: <C68CB012D9182D408CED7B884F441D4D5FDE79@nambxv01a.corp.adobe.com> <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.com>  <C68CB012D9182D408CED7B884F441D4D5FE353@nambxv01a.corp.adobe.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" <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 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: <anthonybryan@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B4B3A6958 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; Sun, 24 Jan 2010 12:39:42 -0800 (PST)
Received: by iwn8 with SMTP id 8so2299590iwn.23 for <apps-discuss@ietf.org>; 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: <bb9e09ee1001241239r75f755canaed5121f7745886d@mail.gmail.com>
Subject: Updating IANA "Operating System Names" registry
From: Anthony Bryan <anthonybryan@gmail.com>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 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: <phoffman@imc.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3C53A6993 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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: <p062408afc78279849a87@[10.20.30.158]>
In-Reply-To: <bb9e09ee1001241239r75f755canaed5121f7745886d@mail.gmail.com>
References: <bb9e09ee1001241239r75f755canaed5121f7745886d@mail.gmail.com>
Date: Sun, 24 Jan 2010 14:29:08 -0800
To: Anthony Bryan <anthonybryan@gmail.com>, apps-discuss@ietf.org
From: Paul Hoffman <phoffman@imc.org>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 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: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8703A69DB for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <julian.reschke@gmx.de>
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 <ietf@adambarth.com>
Subject: Re: comments on draft-abarth-mime-sniff-03
References: <C68CB012D9182D408CED7B884F441D4D5FDE79@nambxv01a.corp.adobe.com> <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.com> <C68CB012D9182D408CED7B884F441D4D5FE353@nambxv01a.corp.adobe.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" <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 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: <eran@hueniverse.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B753A6928 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <eran@hueniverse.com>
To: "apps-discuss@ietf.org" <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 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: <narten@us.ibm.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4113A6882 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <apps-discuss@ietf.org>; 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 <apps-discuss@ietf.org>; 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 <apps-discuss@ietf.org>; 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 <anthonybryan@gmail.com>
Subject: Re: Updating IANA "Operating System Names" registry
In-reply-to: <bb9e09ee1001241239r75f755canaed5121f7745886d@mail.gmail.com>
References: <bb9e09ee1001241239r75f755canaed5121f7745886d@mail.gmail.com>
Comments: In-reply-to Anthony Bryan <anthonybryan@gmail.com> message dated "Sun, 24 Jan 2010 15:39:42 -0500."
Date: Tue, 26 Jan 2010 13:15:49 -0500
From: Thomas Narten <narten@us.ibm.com>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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: <stpeter@stpeter.im>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0183A685F for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <apps-discuss@ietf.org>; 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 <stpeter@stpeter.im>
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: <bb9e09ee1001241239r75f755canaed5121f7745886d@mail.gmail.com> <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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: <adam@adambarth.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F357D28C0F4 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; Tue, 26 Jan 2010 12:45:25 -0800 (PST)
Received: by pwi20 with SMTP id 20so3512423pwi.29 for <apps-discuss@ietf.org>; 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: <C68CB012D9182D408CED7B884F441D4D5FDE79@nambxv01a.corp.adobe.com>  <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.com>  <C68CB012D9182D408CED7B884F441D4D5FE353@nambxv01a.corp.adobe.com>  <7789133a1001221925sf1f55b8k31953828848f2787@mail.gmail.com>  <4B5D99BB.4050607@gmx.de>
From: Adam Barth <ietf@adambarth.com>
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 <julian.reschke@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2010 20:45:26 -0000

On Mon, Jan 25, 2010 at 1:16 PM, Julian Reschke <julian.reschke@gmx.de> 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: <adam@adambarth.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66FAA28C0F2 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; Tue, 26 Jan 2010 12:47:03 -0800 (PST)
Received: by pwi20 with SMTP id 20so3513523pwi.29 for <apps-discuss@ietf.org>; 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: <C68CB012D9182D408CED7B884F441D4D5FDE79@nambxv01a.corp.adobe.com>  <7789133a1001201514l47b43b8bw958e42794707dbc9@mail.gmail.com>  <C68CB012D9182D408CED7B884F441D4D5FE353@nambxv01a.corp.adobe.com>  <7789133a1001221925sf1f55b8k31953828848f2787@mail.gmail.com>
From: Adam Barth <ietf@adambarth.com>
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 <masinter@adobe.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2010 20:47:04 -0000

On Sat, Jan 23, 2010 at 3:25 AM, Adam Barth <ietf@adambarth.com> wrote:
> On Fri, Jan 22, 2010 at 5:34 PM, Larry Masinter <masinter@adobe.com> 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: <adam@adambarth.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564CD3A699F for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; Tue, 26 Jan 2010 12:51:17 -0800 (PST)
Received: by pwi20 with SMTP id 20so3516508pwi.29 for <apps-discuss@ietf.org>; 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 <ietf@adambarth.com>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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: <john-ietf@jck.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87813A691F for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <john-ietf@jck.com>
To: Thomas Narten <narten@us.ibm.com>, Anthony Bryan <anthonybryan@gmail.com>
Subject: Re: Updating IANA "Operating System Names" registry
Message-ID: <67600F318C5C1A2DCFD4C503@PST.JCK.COM>
In-Reply-To: <201001261815.o0QIFnC8007603@cichlid.raleigh.ibm.com>
References: <bb9e09ee1001241239r75f755canaed5121f7745886d@mail.gmail.com> <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jan 2010 09:07:15 -0000

--On Tuesday, January 26, 2010 13:15 -0500 Thomas Narten
<narten@us.ibm.com> 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: <mnot@mnot.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A77D3A697D for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <mnot@mnot.net>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343788056821@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Thu, 28 Jan 2010 15:27:32 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <ABA7C88D-17AC-46DB-BC71-3B7C9F829285@mnot.net>
References: <90C41DD21FB7C64BB94121FBBC2E72343788056821@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav <eran@hueniverse.com>
X-Mailer: Apple Mail (2.1077)
Cc: "apps-discuss@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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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: <eran@hueniverse.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632063A6997 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; 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 <eran@hueniverse.com>
To: Mark Nottingham <mnot@mnot.net>
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> <ABA7C88D-17AC-46DB-BC71-3B7C9F829285@mnot.net>
In-Reply-To: <ABA7C88D-17AC-46DB-BC71-3B7C9F829285@mnot.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
Cc: "apps-discuss@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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 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: <adam@adambarth.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4150F3A69C5 for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <apps-discuss@ietf.org>; Tue, 26 Jan 2010 12:42:29 -0800 (PST)
Received: by pxi16 with SMTP id 16so3502289pxi.29 for <apps-discuss@ietf.org>; 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: <C68CB012D9182D408CED7B884F441D4D5FDE79@nambxv01a.corp.adobe.com>
References: <C68CB012D9182D408CED7B884F441D4D5FDE79@nambxv01a.corp.adobe.com>
From: Adam Barth <w3c@adambarth.com>
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 <masinter@adobe.com>
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" <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2010 20:42:31 -0000

On Wed, Jan 20, 2010 at 10:41 PM, Larry Masinter <masinter@adobe.com> 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 <img src=3D...> 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: <mnot@mnot.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22D713A67EA for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <mnot@mnot.net>
In-Reply-To: <4B596450.7020001@gmx.de>
Date: Fri, 29 Jan 2010 15:23:37 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F1BF65AA-AE8F-435D-9097-AD629488E134@mnot.net>
References: <20100119053002.5CD613A683B@core3.amsl.com>	<E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> <4B596450.7020001@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1077)
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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 =
<http://tools.ietf.org/html/draft-brown-versioning-link-relations-06#appen=
dix-A.1> 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: <mnot@mnot.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA933A67EA for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <mnot@mnot.net>
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> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <A70E9FE8-512E-42A1-8523-042368DABBBC@subbu.org> <EA551C32-6AC0-4AE1-AB22-0BA8876022C9@mac.com> <0460AF05-93FE-41D1-8E7D-D2FE6889C1F9@subbu.org> <62C36D7B-2385-47AB-8A92-DEA15A81B99E@mac.com>
To: Jan Algermissen <algermissen1971@mac.com>
X-Mailer: Apple Mail (2.1077)
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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: <mnot@mnot.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1533A687E for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <mnot@mnot.net>
In-Reply-To: <4B586349.5050405@gmx.de>
Date: Fri, 29 Jan 2010 15:30:51 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <AD5F57CA-C457-46A5-8098-019FB9B09FCB@mnot.net>
References: <20100119053002.5CD613A683B@core3.amsl.com>	<E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <4B56E27D.800@gmx.de> <4B586349.5050405@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1077)
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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: <subbu@subbu.org>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 888413A690A for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; Thu, 28 Jan 2010 22:22:55 -0800 (PST)
Received: by gxk27 with SMTP id 27so1557886gxk.7 for <discuss@apps.ietf.org>; 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 <subbu@subbu.org>
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: <AAB9FDF5-08CC-4BE3-BC5D-CB00B146F65D@subbu.org>
References: <20100119053002.5CD613A683B@core3.amsl.com> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <A70E9FE8-512E-42A1-8523-042368DABBBC@subbu.org> <EA551C32-6AC0-4AE1-AB22-0BA8876022C9@mac.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 <mnot@mnot.net>
X-Mailer: Apple Mail (2.1077)
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D511F3A6A6F for <apps-discuss@core3.amsl.com>; 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 <apps-discuss@core3.amsl.com>; 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 <discuss@apps.ietf.org>; 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 <julian.reschke@gmx.de>
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 <mnot@mnot.net>
Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt
References: <20100119053002.5CD613A683B@core3.amsl.com>	<E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> <4B596450.7020001@gmx.de> <F1BF65AA-AE8F-435D-9097-AD629488E134@mnot.net>
In-Reply-To: <F1BF65AA-AE8F-435D-9097-AD629488E134@mnot.net>
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 <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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 
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-07.html#rfc.section.A.1>), 
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