From msk@cloudmark.com Sun Jan 2 23:22:32 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AA7E28C0FD for ; Sun, 2 Jan 2011 23:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.607 X-Spam-Level: X-Spam-Status: No, score=-103.607 tagged_above=-999 required=5 tests=[AWL=-1.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 gUayJQtJe1iI for ; Sun, 2 Jan 2011 23:22:21 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 327A328C0FA for ; Sun, 2 Jan 2011 23:22:21 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 2 Jan 2011 23:24:28 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Sun, 2 Jan 2011 23:24:27 -0800 Thread-Topic: apps-review team review for draft-ietf-eai-rfc5335bis-07 Thread-Index: AcurF0DTVgxpJJBeRKWAgDSK1T3MMg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F1341E73C8AEXCHC2corpclo_" MIME-Version: 1.0 Cc: John C Klensin , "Shawn.Steele@microsoft.com" , "abelyang@twnic.net.tw" Subject: [apps-discuss] apps-review team review for draft-ietf-eai-rfc5335bis-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 07:22:32 -0000 --_000_F5833273385BB34F99288B3648C4F06F1341E73C8AEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With apologies for the delayed submission of this due to the holidays... I have been selected as the Applications Area Review Team reviewer for this= draft (for background on apps-review, please see http://www.apps.ietf.org/= content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-ietf-eai-rfc5335bis-07 Title: Internationalized Email Headers Reviewer: Murray S, Kucherawy Review Date: 2010-12-23 IETF Last Call Date: unknown IESG Telechat Date: unknown Summary: This draft is not ready for publication as a Proposed Standard and= should be revised before publication. Major issues: Sections 1.2 and 4.2 of this specification "removes the blanket ban on appl= ying a content-transfer-encoding to all subtypes of message/ and instead...= " This is in reference to RFC2045 Section 6.4. I re-read RFC2045 Section = 6.4 and I don't have the same interpretation. It says: "In particular, it is EXPRESSLY FORBIDDEN to use any encodings other than "7bit", "8bit", or "binary" with any composite media type, i.e. one that recursively includes other Content-Type fields. Currently the only composite media types are "multipart" and "message". All encodings that are desired for bodies of type multipart or message must be done at the innermost level, by encoding the actual body that needs to be encoded." It seems to me that there is not an outright ban, but a restriction on whic= h particular encodings can be used. It also seems to me that "8bit" and "b= inary" encodings are sufficiently unrestrictive that they could contain any= conceivable encoding, including UTF-8, especially "binary". Thus, a binar= y-encoded message/global MIME object is legal and doesn't require any alter= ation to RFC2045, and therefore I don't understand the need for this sectio= n of this draft. Section 5.2.4 of RFC2046 specifies that future "message" subtypes are expec= ted to be "7bit" only, and anything else should register some other top-lev= el media type. Why was that not followed here? Having exchanged email now with one of the WG chairs, I realize there may b= e more background or operational experience with EAI than I have that expla= ins the above concerns. However, future readers of this specification will= likely also lack that context. Therefore, I recommend that either Section= 1.2 of this draft be extended with such discussion and background, or an a= ppendix be included to contain such. The last paragraph of Section 4.2 doe= s do a little of this, but I'm at a loss to see the point being made here. = Perhaps an example would help. If one of the other documents EAI is advan= cing contains such material, please add a reference to it here. The Security Considerations section should discuss the problem of having UT= F-8 aware transport (i.e. MTAs) coupled with UTF-8 unaware user agents (e.g= . readers) as well as filters and the like. The author talks about needing= bigger buffers, but I think that's far less interesting than the possible = semantic implications. I consider this a major issue, and so I would expec= t this discussion to be non-trivial in size, and include some admonishment = about not upgrading a delivery MTA to support UTF-8 message headers until t= he entire infrastructure it serves has already been verified to handle it. = This might be discussed in one of the other EAI documents already; if it i= s, this one should contain a reference to that. On a related note, Security Considerations should also talk about abuse mec= hanisms. If, for example, there are lots of ways of using UTF-8 to represe= nt something equivalent or similar to a particular displayed character or g= roup of characters (all the variants of "e" in French, using accents, for e= xample), then filtering systems can be bypassed by using one of the variant= s to avoid detection while still reaching the end user with largely the sam= e original effect. This too might be discussed elsewhere in general, in wh= ich case a reference to that discussion can be left here. Minor issues: Section 2 explains that some people want to be able to use non-ASCII charac= ters as part of header fields, though it also points out that RFC2047 alrea= dy presents a mechanism to do so in a 7-bit-clean manner. Section 4.3 then= lays out the ABNF required to update RFC5322 such that just about any fiel= d can contain UTF-8 data. Since this is a pretty big deal, it would be hel= pful to have some data about why the RFC2047 encoding mechanism that has be= en in widespread use since 1996 is not sufficient or appropriate, other tha= n what's presented here which basically states that people don't want to us= e that encoding scheme for some reason, perhaps personal preference. Section 4.6, which contains the registration for "message/global", says "(N= ote that a system compliant with MIME that doesn't recognize message/global= SHOULD treat it as "application/octet-stream" as described in Section 5.2.= 4 of [RFC2046].)" As another reviewer points out, and I concur, it's dange= rous to copy normative language from one document to another, rather than s= imply referencing it, as it encourages divergent requirements. Another ins= tance of this appears in Section 5. Nits: In the Abstract and in Section 1.1, the phrase "specifies a variant of Inte= rnet mail" seems to portray a much wider scope than what's being presented.= Suggest "specifies a modified version of the Internet message format". Section 3: "A plain ASCII string is full compatible..." I believe the auth= ors wanted "fully" here. Section 4: The title "Changes on..." should be "Changes to..." Section 4.1: The final paragraph is a little too conversational in its use = of language, such as starting a sentence with "Actually, ..." and another w= ith "And ..." This is inconsistent with the rest of the document and shoul= d be avoided. Section 4.2 and 4.4: The titles "Changes on..." should be "Changes to..." Section 4.5: "It described in" should be "It is described in" Section 4.6: "or within a non-SMTP environment which supports these message= s." Change "which" to "that". Section 4.6: The Security Considerations of "See Section 5" should also say= "of [this document]" or such. Section 4.6: "Email clients which forward messages..." and "This is a struc= tured media type which embeds..." Change "which" to "that" in both cases. Section 5: "...characters MUST be no more 998 octets, excluding..." Change = "no more 998" to "no more than 998". --_000_F5833273385BB34F99288B3648C4F06F1341E73C8AEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

With apologies for the delayed submission of this d= ue to the holidays…

 

I have been selected as the Applications Area Revie= w Team reviewer for this draft (for background on apps-review, please see htt= p://www.apps.ietf.org/content/applications-area-review-team).

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

 

Document: draft-ietf-eai-rfc5335bis-07

Title: Internationalized Email Headers  &= nbsp;

Reviewer: Murray S, Kucherawy

Review Date: 2010-12-23

IETF Last Call Date: unknown

IESG Telechat Date: unknown

Summary: This draft is not ready for publication as= a Proposed Standard and should be revised before publication.

 

Major issues:

Sections 1.2 and 4.2 of this specification “r= emoves the blanket ban on applying a content-transfer-encoding to all subtypes of message/ and instead…”  This is in reference to RFC2045 Section 6.4.  I re-read RFC2045 Section 6.4 and I don’t have the same interpretation.  It says:

 

   =
220;In particular, it is EXPRESSLY FORBIDDEN to use any


=
  
encodings other than "7bit", "8bit", or "binary&qu=
ot;
with any composite



=
  
media type, i.e. one that recursively includes other Content-Type



=
  
fields.  Currently the only composite media types are
"multipart" and



=
  
"message".  All encodings that are desired for bodies of typ=
e



=
  
multipart or message must be done at the innermost level, by encoding<=
/o:p>



=
  
the actual body that needs to be encoded.”



=
 



=
It seems
to me that there is not an outright ban, but a restriction on which particu=
lar encodings
can be used.  It also seems to me that “8bit” and “b=
inary”
encodings are sufficiently unrestrictive that they could contain any
conceivable encoding, including UTF-8, especially “binary”.&nbs=
p;
Thus, a binary-encoded message/global MIME object is legal and doesn’=
t
require any alteration to RFC2045, and therefore I don’t understand t=
he
need for this section of this draft.



=
 



=
Section
5.2.4 of RFC2046 specifies that future “message” subtypes are
expected to be “7bit” only, and anything else should register s=
ome
other top-level media type.  Why was that not followed here?



=
 



=
Having
exchanged email now with one of the WG chairs, I realize there may be more
background or operational experience with EAI than I have that explains the
above concerns.  However, future readers of this specification will li=
kely
also lack that context.  Therefore, I recommend that either Section 1.=
2 of
this draft be extended with such discussion and background, or an appendix =
be
included to contain such.  The last paragraph of Section 4.2 does do a
little of this, but I’m at a loss to see the point being made here.&n=
bsp;
Perhaps an example would help.  If one of the other documents EAI is
advancing contains such material, please add a reference to it here.



 



The Security Considerations section should discuss =
the
problem of having UTF-8 aware transport (i.e. MTAs) coupled with UTF-8 unaw=
are
user agents (e.g. readers) as well as filters and the like.  The autho=
r
talks about needing bigger buffers, but I think that's far less interesting
than the possible semantic implications.  I consider this a major issu=
e,
and so I would expect this discussion to be non-trivial in size, and includ=
e
some admonishment about not upgrading a delivery MTA to support UTF-8 messa=
ge
headers until the entire infrastructure it serves has already been verified=
 to
handle it.  This might be discussed in one of the other EAI documents
already; if it is, this one should contain a reference to that.<=
/p>


 



On a related note, Security Considerations should a=
lso
talk about abuse mechanisms.  If, for example, there are lots of ways =
of using
UTF-8 to represent something equivalent or similar to a particular displaye=
d character
or group of characters (all the variants of “e” in French, usin=
g
accents, for example), then filtering systems can be bypassed by using one =
of the
variants to avoid detection while still reaching the end user with largely =
the
same original effect.  This too might be discussed elsewhere in genera=
l, in
which case a reference to that discussion can be left here.





Minor issues:



 



Section 2 explains that some people want to be able=
 to
use non-ASCII characters as part of header fields, though it also points ou=
t
that RFC2047 already presents a mechanism to do so in a 7-bit-clean manner.=
 
Section 4.3 then lays out the ABNF required to update RFC5322 such that jus=
t
about any field can contain UTF-8 data.  Since this is a pretty big de=
al,
it would be helpful to have some data about why the RFC2047 encoding mechan=
ism
that has been in widespread use since 1996 is not sufficient or appropriate=
,
other than what’s presented here which basically states that people d=
on’t
want to use that encoding scheme for some reason, perhaps personal preferen=
ce.







Section 4.6, which contains the registration for &#=
8220;message/global”,
says “(Note that a system compliant with MIME that doesn't recognize
message/global SHOULD treat it as "application/octet-stream" as
described in Section 5.2.4 of [RFC2046].)”  As another reviewer
points out, and I concur, it’s dangerous to copy normative language f=
rom
one document to another, rather than simply referencing it, as it encourage=
s
divergent requirements.  Another instance of this appears in Section 5=
.



 



Nits:



 



In the Abstract and in Section 1.1, the phrase R=
20;specifies
a variant of Internet mail” seems to portray a much wider scope than =
what’s
being presented.  Suggest “specifies a modified version of the
Internet message format”.



 



Section 3: “A plain ASCII string is full comp=
atible…” 
I believe the authors wanted “fully” here.



 



Section 4: The title “Changes on…”=
;
should be “Changes to…”



 



Section 4.1: The final paragraph is a little too co=
nversational
in its use of language, such as starting a sentence with “Actually, &=
#8230;”
and another with “And …”  This is inconsistent with =
the
rest of the document and should be avoided.





Section 4.2 and 4.4: The titles “Changes on…” should be &=
#8220;Changes
to…”



 



Section 4.5: “It described in” should b=
e “It
is described in”



 



Section 4.6: “or within a non-SMTP environmen=
t
which supports these messages.”  Change “which” to &=
#8220;that”.



 



Section 4.6: The Security Considerations of “=
See
Section 5” should also say “of [this document]” or such.<=
o:p>



 



Section 4.6: “Email clients which forward mes=
sages…”
and “This is a structured media type which embeds…” =
 Change
“which” to “that” in both cases.



 



Section 5: “…characters MUST be no more=
 998
octets, excluding…” Change “no more 998” to “=
no
more than 998”.



 
--_000_F5833273385BB34F99288B3648C4F06F1341E73C8AEXCHC2corpclo_-- From stpeter@stpeter.im Mon Jan 3 15:07:23 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F08593A6C3D for ; Mon, 3 Jan 2011 15:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 qEqls5J+szsT for ; Mon, 3 Jan 2011 15:07:22 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0CDB93A6C3C for ; Mon, 3 Jan 2011 15:07:22 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BB8174009B; Mon, 3 Jan 2011 16:23:40 -0700 (MST) Message-ID: <4D225726.4080005@stpeter.im> Date: Mon, 03 Jan 2011 16:09:26 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian E Carpenter References: <4CF9B9EC.20409@gmail.com> In-Reply-To: <4CF9B9EC.20409@gmail.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010202020109070003040909" Cc: Discuss Apps Subject: Re: [apps-discuss] [Fwd: Gen-ART LC review of draft-loreto-http-bidirectional-05.txt] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 23:07:23 -0000 This is a cryptographically signed message in MIME format. --------------ms010202020109070003040909 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To close the loop on-list, the authors have added the following paragraph to the introduction: The authors acknowledge that both the "HTTP long polling" and "HTTP streaming" mechanisms stretch the original semantic of HTTP and that the HTTP protocol was not designed for bidirectional communication. This document neither encourages nor discourages the use of these mechanisms, and takes no position on whether they provide appropriate solutions to the problem of providing bidirectional communication between clients and servers. Instead, this document merely identifies technical issues with these mechanisms and suggests best practices for their deployment. That's not quite what we have in version -06, but we'll submit -07 soon if Brian doesn't object to that text. Peter On 12/3/10 8:47 PM, Brian E Carpenter wrote: > I thought I should forward my Gen-ART review here, since it > contains an opinion statement. See attachment. >=20 > Brian >=20 > -------- Original Message -------- > Subject: Gen-ART LC review of draft-loreto-http-bidirectional-05.txt > Date: Sat, 04 Dec 2010 16:44:06 +1300 > From: Brian E Carpenter > Organization: University of Auckland > To: draft-loreto-http-bidirectional.all@tools.ietf.org, General Area R= eview Team >=20 >=20 --------------ms010202020109070003040909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEw MzIzMDkyNlowIwYJKoZIhvcNAQkEMRYEFNdtvDrkCjUCfF4Jeb3TL7TcFVlgMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCCIxJbELItCJBiO7gtdSgOm/uuXgnV8o70tsW+5ue9sO56bNktpUlN4rRi PK0fZktskg0QyYY+Sqad6qBqe9qPTGTo0+IpFP4Dg49lorEIWyQ3jJsKa/y9i3R3igF46rZT teESCUfnVjDMF09SaCDC8ziYMh9Gh3XfhKPBBeL59Z9amIIROwNCZHj1IhBPfTnkod62Qbmq xJUOXK49icVzwvA4K0sBznhJZ/kzPXAdNnKjYLINn/Fe3pBRLPCDAS4v1HLfaSN68FXd49u8 VFXcmzqhcku/Az8WO9g8tPwb5IlM+NEAfbFs5xKYAdr2TkToyuMZgiz1WkbT+rHAVFMaAAAA AAAA --------------ms010202020109070003040909-- From brian.e.carpenter@gmail.com Mon Jan 3 19:29:09 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28C993A69B4 for ; Mon, 3 Jan 2011 19:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.426 X-Spam-Level: X-Spam-Status: No, score=-103.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 k8-LJD4w4cHW for ; Mon, 3 Jan 2011 19:29:07 -0800 (PST) Received: from mail-qy0-f170.google.com (mail-qy0-f170.google.com [209.85.216.170]) by core3.amsl.com (Postfix) with ESMTP id 92B073A69B3 for ; Mon, 3 Jan 2011 19:29:07 -0800 (PST) Received: by qyk10 with SMTP id 10so15050115qyk.1 for ; Mon, 03 Jan 2011 19:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=V6sch7AK6an5ooCdeFiRKzWoh4fq/teVzM7SS392OvQ=; b=WuZcFRENGyk05Qv3x9uSr77+a7/OEvgxQwML6N6hQ4x2+blqOGn3LaGpnf8Ay+IaKx iyYgwU+TX77qIL/cDBjsG18eWpHgf5hIynyC01CfLQdFtVzBJHyTcI8QL8PLQzl17YBT F+Asdbf/JQNanzJqsONOq9AXsIvOjizCW9lTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=BYbLOGXF0QOHQO/CKtqv5PFhvjGNaQ8x6mJNd4cV6lppZxJH7vEA/ypyXmUMuXVVsc BAsRT/42h5eOOvK5cALdF1TYOJGGN2Tcfh6a41Tz0eiNbCj0ezn7/VbdSkNtEhl0727z VroZZshH9JvWN3fj14MqgAtcqhR3MZckMwPqE= Received: by 10.229.225.17 with SMTP id iq17mr6416080qcb.288.1294111874445; Mon, 03 Jan 2011 19:31:14 -0800 (PST) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id l12sm12490094qcu.31.2011.01.03.19.31.11 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 19:31:13 -0800 (PST) Message-ID: <4D22947B.3000506@gmail.com> Date: Tue, 04 Jan 2011 16:31:07 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Peter Saint-Andre References: <4CF9B9EC.20409@gmail.com> <4D225726.4080005@stpeter.im> In-Reply-To: <4D225726.4080005@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Discuss Apps Subject: Re: [apps-discuss] [Fwd: Gen-ART LC review of draft-loreto-http-bidirectional-05.txt] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 03:29:09 -0000 It's OK for me, but at this point it's really the IESG's opinion that matters. Thanks Brian Carpenter On 2011-01-04 12:09, Peter Saint-Andre wrote: > To close the loop on-list, the authors have added the following > paragraph to the introduction: > > The authors acknowledge that both the "HTTP long polling" and "HTTP > streaming" mechanisms stretch the original semantic of HTTP and that > the HTTP protocol was not designed for bidirectional communication. > This document neither encourages nor discourages the use of these > mechanisms, and takes no position on whether they provide appropriate > solutions to the problem of providing bidirectional communication > between clients and servers. Instead, this document merely > identifies technical issues with these mechanisms and suggests best > practices for their deployment. > > That's not quite what we have in version -06, but we'll submit -07 soon > if Brian doesn't object to that text. > > Peter > > On 12/3/10 8:47 PM, Brian E Carpenter wrote: >> I thought I should forward my Gen-ART review here, since it >> contains an opinion statement. See attachment. >> >> Brian >> >> -------- Original Message -------- >> Subject: Gen-ART LC review of draft-loreto-http-bidirectional-05.txt >> Date: Sat, 04 Dec 2010 16:44:06 +1300 >> From: Brian E Carpenter >> Organization: University of Auckland >> To: draft-loreto-http-bidirectional.all@tools.ietf.org, General Area Review Team >> >> > From benl@google.com Thu Jan 6 07:29:49 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787FA3A6C33 for ; Thu, 6 Jan 2011 07:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.855 X-Spam-Level: X-Spam-Status: No, score=-103.855 tagged_above=-999 required=5 tests=[AWL=-1.879, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 EIyOTHfIzS39 for ; Thu, 6 Jan 2011 07:29:48 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id E30B53A6D14 for ; Thu, 6 Jan 2011 07:29:47 -0800 (PST) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p06FVrqC008803 for ; Thu, 6 Jan 2011 07:31:53 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294327914; bh=UP69RRHWGGYUU/4X7jvHl3J8mX4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=u8nc7/xQZ+AARX/yPFSLYnoxdm3MNriL6XXSM3oYTi9uTzHemKJl8EeU6i0qQkJCF DTLfKTFQS5p8DHzPhqxoA== Received: from qyj19 (qyj19.prod.google.com [10.241.83.83]) by hpaq6.eem.corp.google.com with ESMTP id p06FVmHf020772 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 6 Jan 2011 07:31:52 -0800 Received: by qyj19 with SMTP id 19so17694829qyj.12 for ; Thu, 06 Jan 2011 07:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4HF7vbiBG5YS3CoUX9wu70DOSHl4iLZrUnsX4DNBd8w=; b=BWKqmSdEvTDeyQ2eqttv3+gBNEmZ8ZTujH6HL3DADxzsmbBUAlcazFi9amXmpe/stX C8Xwy0FBWlv0jfqgUknQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hH30kqLSSKa1ZEPU9Hu/va/17y7O5RquFN4F2cWEnZwLtv6zPxOQENUmecs1T29R8b EpxWBDsyopxO1loOVpOQ== MIME-Version: 1.0 Received: by 10.229.215.135 with SMTP id he7mr2980674qcb.104.1294327911945; Thu, 06 Jan 2011 07:31:51 -0800 (PST) Received: by 10.220.88.137 with HTTP; Thu, 6 Jan 2011 07:31:51 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Thu, 6 Jan 2011 15:31:51 +0000 Message-ID: From: Ben Laurie To: Robert Sayre Content-Type: multipart/alternative; boundary=00163630f5376a161c04992f33be X-System-Of-Record: true X-Mailman-Approved-At: Thu, 06 Jan 2011 08:34:53 -0800 Cc: "apps-discuss@ietf.org" , "Roy T. Fielding" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 15:29:49 -0000 --00163630f5376a161c04992f33be Content-Type: text/plain; charset=ISO-8859-1 On 6 January 2011 01:28, Robert Sayre wrote: > > Peter Saint-Andre wrote: > > 2. In 2007, Robert Sayre put together a few slides on the topic: > > http://people.mozilla.com/~sayrer/2007/auth.html > > These are back on the Web, in case anyone missed them (probably not). > > On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding > wrote: > > > > Define them all and let's have a bake-off. It has been 16 years since > > HTTP auth was taken out of our hands so that the security experts could > > define something perfect. Zero progress so far. > > I think the IETF might do better to focus on a smaller problem, at > first. People often use self-signed certificates with HTTP/TLS, even > though the first thing their websites ask the user to do is type a > username and password into a form. There are some well-understood ways > to make this process more secure. Why hasn't the IETF fixed this > problem? If this smaller problem has no ready solution, then the > larger issue of authentication on the entire Web seems like a tough > nut to crack. > Two comments (one really being a response to Roy): 1. The IETF has fixed the problem, but no-one is using the fix - perhaps because it is not clear that it is the fix. I speak of RFC 4279, TLS pre-shared keys. These could be derived from a hash of the password and the site name, for example, and thus provide secure mutual authentication despite password reuse. 2. I have often heard (though I am not aware of hard evidence for this, nevertheless I find it plausible) that one reason no-one has bothered to improve HTTP auth is because no-one would use it since site owners want to control the user experience around signin. It seems to me, therefore, that HTTP is the wrong layer to fix the problem at - it needs to be pushed down into HTML or Javascript so that the page can control the look, while appropriate HTML elements or JS code can deal with the secure exchange of data. Of course, this still leaves the issue of trusted path: although we can provide elements which are safe to use, even when being phished, how does the user know those elements are actually being used, rather than simulated so as to get hold of the underlying password? The answer to this problem is hard, since it brings us back to taking the UI out of the sites hands. > It could be that the reasons for this lack of progress are > nontechnical. Just throwing that out there. > If you think UI is nontechnical, then I agree. Cheers, Ben. --00163630f5376a161c04992f33be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 6 January 2011 01:28, Robert Sayre <sayrer@gmail.com> wrote:
> Peter Saint-Andre <stpeter@stpeter.im> wrote:
> 2. In 2007, Robert Sayre put together a few slides on the topic:
> http://people.mozilla.com/~sayrer/2007/auth.html

These are back on the Web, in case anyone missed them (probably not).=

On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>
> Define them all and let's have a bake-off. =A0It has been 16 years= since
> HTTP auth was taken out of our hands so that the security experts coul= d
> define something perfect. =A0Zero progress so far.

I think the IETF might do better to focus on a smaller problem, at
first. People often use self-signed certificates with HTTP/TLS, even
though the first thing their websites ask the user to do is type a
username and password into a form. There are some well-understood ways
to make this process more secure. Why hasn't the IETF fixed this
problem? If this smaller problem has no ready solution, then the
larger issue of authentication on the entire Web seems like a tough
nut to crack.

Two comments (one really = being a response to Roy):

1. The IETF has fixed th= e problem, but no-one is using the fix - perhaps because it is not clear th= at it is the fix. I speak of RFC 4279, TLS pre-shared keys. These could be = derived from a hash of the password and the site name, for example, and thu= s provide secure mutual authentication despite password reuse.

2. I have often heard (though I am not aware of hard ev= idence for this, nevertheless I find it plausible) that one reason no-one h= as bothered to improve HTTP auth is because no-one would use it since site = owners want to control the user experience around signin. It seems to me, t= herefore, that HTTP is the wrong layer to fix the problem at - it needs to = be pushed down into HTML or Javascript so that the page can control the loo= k, while appropriate HTML elements or JS code can deal with the secure exch= ange of data.

Of course, this still leaves the issue of trusted path:= although we can provide elements which are safe to use, even when being ph= ished, how does the user know those elements are actually being used, rathe= r than simulated so as to get hold of the underlying password?

The answer to this problem is hard, since it brings us = back to taking the UI out of the sites hands.

=A0<= /div>
It could be that the reasons for this lack of progress are
nontechnical. Just throwing that out there.

=
If you think UI is nontechnical, then I agree.

Cheers,

Ben.

--00163630f5376a161c04992f33be-- From brian@estacado.net Thu Jan 6 08:33:10 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252E43A6C4F for ; Thu, 6 Jan 2011 08:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_25=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 lrDKpUmpmvdn for ; Thu, 6 Jan 2011 08:33:09 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id C61A73A6C2F for ; Thu, 6 Jan 2011 08:33:08 -0800 (PST) Received: from [192.168.1.105] (cpe-76-182-241-151.tx.res.rr.com [76.182.241.151]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id p06GZ8pP016423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jan 2011 10:35:13 -0600 (CST) (envelope-from brian@estacado.net) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Hibbard In-Reply-To: <00650698-AADF-4BF1-A036-2B95AEFE6069@Isode.com> Date: Thu, 6 Jan 2011 10:35:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4BF3DB9C-02D5-4778-9D30-694F8DB74A8D@estacado.net> References: <00650698-AADF-4BF1-A036-2B95AEFE6069@Isode.com> To: Kurt Zeilenga X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 06 Jan 2011 08:35:23 -0800 Cc: Alexey Melnikov , apps-discuss@ietf.org, draft-ietf-sipcore-sec-flows@tools.ietf.org Subject: Re: [apps-discuss] Apps-team review: draft-ietf-sipcore-sec-flows X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:33:10 -0000 Hello Kurt, Thank you for your input. The inconsistencies in presentation of DN = that you're talking about are the actual results of the dumps of the = OpenSSL "x509" certificate tool. The use of the tool in this context is = only to examine the content of the certificates for learning and testing = purposes, and in the draft, to show what designers and testers would = see in their environments. It is only because those are the actual = results from the tool most likely to be used by readers of this = document, that we are partial to leaving the dumps as they are. =20 With that said, if you remain convinced that consistency of = presentation is the more important factor here, I will go and make = changes to the x509 dumps. Regards, Brian On Dec 15, 2010, at 9:21 AM, Kurt Zeilenga wrote: > I have been selected as the Applications Area Review Team reviewer for = this draft (for background on apps-review, please = seehttp://www.apps.ietf.org/content/applications-area-review-team). >=20 > Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. >=20 > Document: draft-ietf-sipcore-sec-flows (rev-07 reviewed) > Title: Example call flows using Session Initiation Protocol (SIP) = security mechanisms > Reviewer: Kurt Zeilenga > Review Date: 12/15/2010 > IETF Last Call Date: [include if known] > IESG Telechat Date: 2011-01-20 > Summary: This draft is basically ready for publication as an = Informational RFC but has a few issues that should be fixed before = publication. > Major Issues: None. > Minor Issues:=20 >=20 > I see some inconsistencies in how Distinguished Names (DNs) are = presented in the RFC. >=20 > For instance (from 2.1): > Issuer: C=3DUS, ST=3DCalifornia, L=3DSan Jose, O=3Dsipit, > OU=3DSipit Test Certificate Authority >=20 > vs. (also from 2.1) > DirName:/C=3DUS/ST=3DCalifornia/L=3DSan Jose/O=3Dsipit/ > OU=3DSipit Test Certificate Authority >=20 > The former kind of looks like the LDAP DN format but, if that's what = was intended, the RDNs appear in the incorrect order. Note that in the = LDAP DN format, the most specific element appears first (the reverse of = how they appear in the BER/DER encoding of a DN). Also, there should be = no spaces after the RDN separators (the commas). >=20 > The latter appears to be DCE format. >=20 > I would think it appropriate to use a single format for all DNs and, = if one chooses to use the LDAP DN format, that values ought to be = constructed per RFC 4514. I note that Appendix A of RFC 4514 discusses = presentation issues of Distinguished Names. >=20 > Nits: The usual (many acronyms are not spelled out on first use, etc.) From dwm@xpasc.com Thu Jan 6 08:01:50 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72A63A6EFF; Thu, 6 Jan 2011 08:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 n202LIwHccwW; Thu, 6 Jan 2011 08:01:49 -0800 (PST) Received: from mail.xpasc.com (mail.xpasc.com [68.164.244.189]) by core3.amsl.com (Postfix) with ESMTP id 640053A6E48; Thu, 6 Jan 2011 08:01:49 -0800 (PST) Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id CDB7510058A; Thu, 6 Jan 2011 08:03:55 -0800 (PST) X-Propel-Return-Path: Received: from mail.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 3.1.2.exported $Rev: 9262 $) id iz6Urb16g3T0; Thu, 06 Jan 2011 08:03:55 -0800 Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 97631100585; Thu, 6 Jan 2011 08:03:55 -0800 (PST) Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id p06G3shY018211; Thu, 6 Jan 2011 08:03:54 -0800 Date: Thu, 6 Jan 2011 08:03:54 -0800 (PST) From: David Morris In-Reply-To: Message-ID: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Propel-ID: iz6Urb16g3T0 X-Mailman-Approved-At: Thu, 06 Jan 2011 08:36:14 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:01:51 -0000 On Thu, 6 Jan 2011, Ben Laurie wrote: > The answer to this problem is hard, since it brings us back to taking the UI > out of the sites hands. Which is only helpful if you can somehow gaurantee that the user agent software hasn't been compromised. Not something I'd bet on... From sayrer@gmail.com Wed Jan 5 17:26:08 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5A13A6E4C; Wed, 5 Jan 2011 17:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_57=0.6, 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 kfd7k09rhiTF; Wed, 5 Jan 2011 17:26:07 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 1C1AE3A6DD2; Wed, 5 Jan 2011 17:26:03 -0800 (PST) Received: by gxk28 with SMTP id 28so7425497gxk.31 for ; Wed, 05 Jan 2011 17:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SmSGVsL3s1/e2mEs3LupI5w3onGShvZ4UtUrWrsZAvc=; b=oqDjO5l9OasDvMqhtSRG5lBW5ly/sZVMnAjtawLZzAl/3BcHvbwgxm2A7LZBaVcfMN a9KveWQYf85Hokfz/WOSIeHFo5vugc3VUbSZ4nX7FUN/VFYr034yQl2lg0qKaJj1Dl2p 0X6JN5ZqZ8eGZJ643GK1sl/rs515U1g7olm48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MrgU77VixIxQZ2qTzxT40ypYmHsE2NSX6bk0ijTIlvi7TaDvo2k6K4qaw7P0+/hZSX clJhXNhTjD8ISKOAGHVBWw9YYGd3FJ6Qdm2ZMA4Z4qpL51b+FZmDyeKAjVv6EA5Y0kvH Vt1pSfmVsKKdhYbvPCUzUw5ewnPuywqbjy6UQ= MIME-Version: 1.0 Received: by 10.90.4.7 with SMTP id 7mr1387636agd.100.1294277289574; Wed, 05 Jan 2011 17:28:09 -0800 (PST) Received: by 10.90.133.12 with HTTP; Wed, 5 Jan 2011 17:28:08 -0800 (PST) In-Reply-To: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Wed, 5 Jan 2011 20:28:08 -0500 Message-ID: From: Robert Sayre To: "Roy T. Fielding" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 06 Jan 2011 08:36:24 -0800 Cc: "apps-discuss@ietf.org" , Yoav Nir , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 01:26:08 -0000 > Peter Saint-Andre wrote: > 2. In 2007, Robert Sayre put together a few slides on the topic: > http://people.mozilla.com/~sayrer/2007/auth.html These are back on the Web, in case anyone missed them (probably not). On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding wrote: > > Define them all and let's have a bake-off. =A0It has been 16 years since > HTTP auth was taken out of our hands so that the security experts could > define something perfect. =A0Zero progress so far. Hard to disagree with this assessment. It's pretty easy to define something better than the current HTTP authentication mechanisms, but pretty hard to design something more popular than forms+cookies. I've looked at this problem a little bit, and I gather the strictly technical security properties we're looking for are pretty well understood. Deployment and presentation control are the tough parts. Presentation control is actually a security trade-off--to get the control web designers want, you have to present graphics before the server has been authenticated. Also, I suspect it will be difficult to deploy a new HTTP mechanism that can withstand replay and DoS attacks, unless proxy conformance gets a lot better. So, I think those advocating TLS-only solutions might turn out to win the day, but not because the security properties on offer are particularly compelling. I think the IETF might do better to focus on a smaller problem, at first. People often use self-signed certificates with HTTP/TLS, even though the first thing their websites ask the user to do is type a username and password into a form. There are some well-understood ways to make this process more secure. Why hasn't the IETF fixed this problem? If this smaller problem has no ready solution, then the larger issue of authentication on the entire Web seems like a tough nut to crack. It could be that the reasons for this lack of progress are nontechnical. Just throwing that out there. --=20 Robert Sayre "I would have written a shorter letter, but I did not have the time." From tim-projects@sentinelchicken.org Thu Jan 6 08:31:15 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A934B3A6E25 for ; Thu, 6 Jan 2011 08:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, 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 DBcOmS3R6LzY for ; Thu, 6 Jan 2011 08:31:15 -0800 (PST) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by core3.amsl.com (Postfix) with ESMTP id 52DA73A6C4F for ; Thu, 6 Jan 2011 08:31:15 -0800 (PST) Received: (qmail 3319 invoked from network); 6 Jan 2011 16:28:47 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 6 Jan 2011 16:28:47 -0000 Received: (qmail 23661 invoked from network); 6 Jan 2011 16:29:18 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 6 Jan 2011 16:29:18 -0000 Received: (nullmailer pid 15198 invoked by uid 1000); Thu, 06 Jan 2011 16:25:59 -0000 Date: Thu, 6 Jan 2011 08:25:59 -0800 From: Tim To: Ben Laurie Message-ID: <20110106162559.GQ6792@sentinelchicken.org> References: <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Thu, 06 Jan 2011 08:36:36 -0800 Cc: "apps-discuss@ietf.org" , "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:31:15 -0000 > 1. The IETF has fixed the problem, but no-one is using the fix - perhaps > because it is not clear that it is the fix. I speak of RFC 4279, TLS > pre-shared keys. These could be derived from a hash of the password and the > site name, for example, and thus provide secure mutual authentication > despite password reuse. > > 2. I have often heard (though I am not aware of hard evidence for this, > nevertheless I find it plausible) that one reason no-one has bothered to > improve HTTP auth is because no-one would use it since site owners want to > control the user experience around signin. It seems to me, therefore, that > HTTP is the wrong layer to fix the problem at - it needs to be pushed down > into HTML or Javascript so that the page can control the look, while > appropriate HTML elements or JS code can deal with the secure exchange of > data. Yes, the user experience piece is definitely the biggest adoption problem for HTTP auth, IMO. However, I disagree that HTTP is the wrong layer. It has already been shown (by myself and others) that using HTTP authentication and controlling the user experience can largely be achieved already. A few tweaks to browser 401 response behavior (which doesn't require standards changes) and the ability for servers to force a log out are all that's left to provide to make this reliable. As for RFC 4279, I'm not really familiar with it, but I imagine the mechansims which allow for user experience customization right now with HTTP auth could easily be extended to any TLS authentication mechansim. The only requirement there would be to add some simple language allowing for this behavior in [1]. That is, allow XMLHttpRequest objects to hand the credentials they already accept off to the TLS layer, either for RFC 4279 or for SRP/TLS. > Of course, this still leaves the issue of trusted path: although we can > provide elements which are safe to use, even when being phished, how does > the user know those elements are actually being used, rather than simulated > so as to get hold of the underlying password? > > The answer to this problem is hard, since it brings us back to taking the UI > out of the sites hands. Yes, so what I've outlined above and elsewhere is a relatively simple transition path to allow adoption of better authentication standards with customizable user interfaces. But those are problematic by design. However, I'd assert that moving web applications off of cookies to some lower-layer mechanism is going to be a required first step in order to provide authentication prompts that are part of the browser, for those who need that security. tim 1. http://www.w3.org/TR/XMLHttpRequest/ From stpeter@stpeter.im Thu Jan 6 10:39:51 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C823A6F49 for ; Thu, 6 Jan 2011 10:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 V8jwJ58vetKh for ; Thu, 6 Jan 2011 10:39:50 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5C0A03A6F4D for ; Thu, 6 Jan 2011 10:39:50 -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 63EB2400EE for ; Thu, 6 Jan 2011 11:56:24 -0700 (MST) Message-ID: <4D260CE1.9030809@stpeter.im> Date: Thu, 06 Jan 2011 11:41:37 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090401070205010403060802" Subject: [apps-discuss] Fwd: time to act on IETF-80 BOFs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:39:51 -0000 This is a cryptographically signed message in MIME format. --------------ms090401070205010403060802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI. -------- Original Message -------- Subject: time to act on IETF-80 BOFs Date: Wed, 05 Jan 2011 22:29:34 +0100 From: Jari Arkko To: IETF Discussion , Working Group Chairs Just as a reminder, if any of you are thinking of proposing new IETF work: the deadline for BOF proposals for the next meeting is January 31st. But if you have something in mind, please talk to your ADs as soon as possible. More information at http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 Jari --------------ms090401070205010403060802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEw NjE4NDEzN1owIwYJKoZIhvcNAQkEMRYEFFnFF+3v893QMGSaax4fjpUb+WWGMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQB7Hm2xHOAwpJkv0lMXLVtyxUqKxlg7AlUKeQTZsp48CljbgxtFXX8PpADk I1VIyFTMjuH3EHqdirChVUo8QPawIKRGCeKnocWyMdVOiqWG169kHv+4weIC96n1iHmuTJgR O9xqqIzfcz2cEB+qyKlu8qTKb5wr4MdQZc3zozQK4k6zSdtuPzbDREWo5PGhbemAayzsrk8+ dciewtaKRcUGOBnosAlfdC1dnvWwZu2H75MpzpWZE6zANJ7seuNqecZyOWBaamNtHby4yQXj KP9Pn47T+uapEuHjuhnETCk/xcYZ573I1sW2MBAifMBeUHoGnTmYK1AnnV5k16Aoq7c4AAAA AAAA --------------ms090401070205010403060802-- From Kurt.Zeilenga@isode.com Thu Jan 6 14:41:40 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA413A6F67; Thu, 6 Jan 2011 14:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 jhEGIoTQcU23; Thu, 6 Jan 2011 14:41:39 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2ECE13A6D23; Thu, 6 Jan 2011 14:41:39 -0800 (PST) Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 6 Jan 2011 22:43:44 +0000 From: Kurt Zeilenga In-Reply-To: Date: Thu, 6 Jan 2011 14:43:41 -0800 Message-Id: References: To: Ted Hardie X-Mailer: Apple Mail (2.1082) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss , iesg@ietf.org Subject: Re: [apps-discuss] Apps Review Team review of draft-zeilenga-ldap-dontusecopy-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 22:41:40 -0000 On Oct 14, 2010, at 10:06 AM, Ted Hardie wrote: > I have been selected as the Applications Area Review Team reviewer for > this draft > (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). >=20 > Please resolve these comments along with any other Last Call comments > you may receive. > Please wait for direction from your document shepherd or AD before > posting a new version of the draft. >=20 > Document: draft-zeilenga-ldap-dontusecopy-08 > Title: The LDAP Don't Use Copy Control > Reviewer: Ted Hardie > Review Date: October 14, 2010 >=20 > Summary: This document is basically ready for publication on the > standards track, with one > clarification needed and some editorial issues. >=20 > Major Issues: >=20 > In section 3, the document currently says: >=20 > If original (master) information for the target or base object of = the > operation is not available (either locally or through chaining), the > server MUST either return a referral directing the client to a server > believed to be better able to service the request or return an > appropriate result code (e.g., unwillingToPerform). >=20 > The LDAP referral syntax permits the use of URIs other than LDAP, > provided they are believed capable of performing the operations > (see RFC 2251 section 4.1.11). But it is not clear > how a referral using a different URI scheme would handle > a request for authoritative data only. I believe the author should > consider whether restricting referrals to LDAP URIs > would be useful in this case or whether real-world deployments > make non-LDAP URIs sufficiently rare to make this superfluous. > Text describing the case would be useful for either approach. I was trying to avoid discussing chasing of referrals (even with only = LDAP URIs are used) as chasing of referrals is otherwise fraught with = problems. I will add text which says: 1) if the client chooses to chase an LDAP URL, it ought to use this = control in the request it send to the referred to server. 2) use of non-LDAP URIs is left to future documents. 3) in absence of assurance that only authoritative information is used, = the client ought to assume non-authorative information will be used. >=20 > Since the control is based on an X.511/DAP control, it is possible > to get this same functionality there, but the IANA does not appear to = list > any URI scheme for this, making its use in a referral also apparently > unlikely. DAP relies heavily on chaining not referrals. LDAP is increasingly slowly shifting to chaining instead of referrals. = (Given that LDAP doesn't have a chain operation, what LDAP servers do = today might better be called proxying as there is no distinction in the = proxied request of what infomration was provided by the originating = client and what was provided by the proxying server). >=20 > Minor Issues: None seen. >=20 > Nits: The background section has a number of cases where multiple > parenthetical expressions are used. Some re-writing to remove them > may increase the readability. For example: >=20 > If the server has access to > the original (master) information (directly or through chaining), it > performs the operation against the original (master) information and > return compareTrue or compareFalse (or an error). >=20 >=20 > If the server has access to the original (master) information > directly or through chaining, > it performs the operation against the original (master) information = and > returns compareTrue, compareFalse, or an error. >=20 > These can be resolved in cooperation with the RFC Editor's application > of the style guide. From evnikita2@gmail.com Thu Jan 6 22:23:09 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC44B3A67A5 for ; Thu, 6 Jan 2011 22:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.16 X-Spam-Level: X-Spam-Status: No, score=-3.16 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 lPVFbsAMTQRb for ; Thu, 6 Jan 2011 22:23:06 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 9EECD3A67B1 for ; Thu, 6 Jan 2011 22:23:03 -0800 (PST) Received: by bwz12 with SMTP id 12so16957524bwz.31 for ; Thu, 06 Jan 2011 22:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:to:subject:content-type; bh=zalD1+kBFp07e71peBiALp7ZIWevrxdtRAGV5NSD2e8=; b=RAlng9Wi8ipr6fri7kDcJilBSGCHwhHMySBZOPou4r3r2CYmIes6FqKMqajGoD7wC+ 2YYK687OMYnKn5Lpu9X9FYCOjnWHi1sbudXkR3sF9a3wB+HF5gCwV26aePvCXCMiUxwG d0hw6UpAcWXvZKsuImEAA28ibi7POFjx1/voQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type; b=c2C+myN2Lomx5WCaV2c4OKKLAr5NarnoCCNBGzpzcxvluv/E+C9G8JjI+efnN0AKh8 BgYQWoqQdpMzhk1KanXAFzcbT+oFIlEKIgLpGCbSaicKfcbYAu15IQVWCcjqqhWWShRN 2S9DsmH3BdkhDD+0cGJxbeOGLGrJJYjFsqQYg= Received: by 10.204.59.140 with SMTP id l12mr183506bkh.2.1294381509866; Thu, 06 Jan 2011 22:25:09 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id f20sm11439404bkf.4.2011.01.06.22.25.08 (version=SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 22:25:09 -0800 (PST) Message-ID: <4D26B1D6.9070906@gmail.com> Date: Fri, 07 Jan 2011 08:25:26 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Content-Type: multipart/alternative; boundary="------------020201010502020007030801" Subject: [apps-discuss] The 'afs' URI scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: URI , "apps-discuss@ietf.org" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 06:23:09 -0000 This is a multi-part message in MIME format. --------------020201010502020007030801 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello all, There has been a discussion on moving the 'afs' URI scheme on URI@w3.org mailing list. I am writing to request the wider discussion of the issue. So what do you think about this? Please copy the answers to URI@w3.org ML if possible. Mykyta Yevstifeyev --------------020201010502020007030801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello all,

There has been a discussion on moving the 'afs' URI scheme on URI@w3.org mailing list. I am writing to request the wider discussion of the issue. So what do you think about this?

Please copy the answers to URI@w3.org ML if possible.

Mykyta Yevstifeyev

 --------------020201010502020007030801-- From benl@google.com Thu Jan 6 10:14:13 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C6193A6CD8 for ; Thu, 6 Jan 2011 10:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.369 X-Spam-Level: X-Spam-Status: No, score=-103.369 tagged_above=-999 required=5 tests=[AWL=-1.392, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 yWjxIQPQWtlh for ; Thu, 6 Jan 2011 10:14:12 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 1B8DC3A6CED for ; Thu, 6 Jan 2011 10:14:11 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p06IGH0Q010677 for ; Thu, 6 Jan 2011 10:16:18 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294337778; bh=tOrSd+BaLDGYpH9HsyVCcafu+oA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=nhcwIisUO7oAkg66A8rDBAHv5zLtVTeKxgwhQrGOkd1tM+8dUs0mMmYzkOc12BMsQ vRwjIWFLBdC/r+miufS3g== Received: from qyk10 (qyk10.prod.google.com [10.241.83.138]) by wpaz24.hot.corp.google.com with ESMTP id p06IAUWp010579 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 6 Jan 2011 10:16:16 -0800 Received: by qyk10 with SMTP id 10so17933959qyk.1 for ; Thu, 06 Jan 2011 10:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ztYKyBRdnEWKJBsTrbql2FglzmqVhvAw6IaIUfdkB7w=; b=BxXEavN29UHyrsu3lhFh4wtPxqyyfTe7rbvsAK9O9yU8bnoEzoceDOSlCK6QPcd3dG ll62XjLsoR18WS0HmO5Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FCRb0q97ppk3nPf0vWscaA0RV1zaAaw54FU7Dt4Ih57ZFclnJC0C5VptKxZu+gFzH7 b9AIO/Z0ax7qhwFKRnlQ== MIME-Version: 1.0 Received: by 10.229.215.135 with SMTP id he7mr3108759qcb.104.1294337776341; Thu, 06 Jan 2011 10:16:16 -0800 (PST) Received: by 10.220.88.137 with HTTP; Thu, 6 Jan 2011 10:16:15 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Thu, 6 Jan 2011 18:16:15 +0000 Message-ID: From: Ben Laurie To: David Morris Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Mailman-Approved-At: Fri, 07 Jan 2011 11:38:45 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:14:13 -0000 On 6 January 2011 16:03, David Morris wrote: > > > On Thu, 6 Jan 2011, Ben Laurie wrote: > >> The answer to this problem is hard, since it brings us back to taking the UI >> out of the sites hands. > > Which is only helpful if you can somehow gaurantee that the user agent > software hasn't been compromised. Not something I'd bet on... That's rather overstating it. It's perfectly helpful when the UA software hasn't been compromised, which is a non-zero fraction of the time. When the UA s/w has been compromised I'm quite happy to fail to fix the problem: the right answer to that is to improve the robustness of the UA. From marsh@extendedsubset.com Thu Jan 6 11:49:53 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C8F3A6F34; Thu, 6 Jan 2011 11:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 5IsN4qZgy7XQ; Thu, 6 Jan 2011 11:49:50 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 601543A6D06; Thu, 6 Jan 2011 11:49:50 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PavsL-0007lR-0x; Thu, 06 Jan 2011 19:51:57 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7DDDC603D; Thu, 6 Jan 2011 19:51:54 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19YqhOZiaovwLDZ2QqifW+U3NXa/nAN2Ec= Message-ID: <4D261D59.9010405@extendedsubset.com> Date: Thu, 06 Jan 2011 13:51:53 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: der Mouse References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> <4D0E8148.7060607@extendedsubset.com> <201101061835.NAA23900@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201101061835.NAA23900@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 07 Jan 2011 11:38:54 -0800 Cc: apps-discuss@ietf.org, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, saag@ietf.org, ietf-http-wg@w3.org Subject: Re: [apps-discuss] [websec] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 19:49:54 -0000 On 01/06/2011 12:35 PM, der Mouse wrote: >> Look back far enough and you'll find all kinds of "electronic mail" >> services implementing the full range of peer and end user >> authentication, and sender-pays models. There was no spam on those >> systems, or at least not enough that anyone felt like they needed a >> word for it. > > There was basically no spam on open-Internet SMTP mail either, at the > time. Certainly "no spam" by today's standards. > >> Guess why we use the one we use today. > > At the time, the services you deride weren't providing a significant > value-add. I wasn't so much deriding them but saying there were points all over the trade-off curve and the market voted with its feet. Unambiguously. Of course, the marketing creeps followed. > Today? They would be. Perhaps not enough to make up for their costs; > probably not, in fact, or there'd be businesses arising in that space. There are plenty. It's a commoditized low-margin business these days. But the network infrastructure costs are not nearly the biggest cost once you factor in things like end-user support. E.g. http://www.google.com/search?q=hosted+vpn It occurred to me last night that one might recreate the good old days of the Internet with a VPN which allowed access to the good old folks who were on it back then. Sounds a little crass and elitist now that I propose it out loud. But imagine a global authenticated VPN where the only reason you could be banned is for spamming? Or one where you had to be at a university CS department? Or a whole set of overlapping criteria and you could choose what the membership criteria for your own view of the network? Your own personal Virtual Public Internet. > As a side note, it's interesting to see how well the early Internet > designers built; their systems are routinely being stressed several > orders of magnitude beyond what they were designed for, and are holding > up remarkably well. It is amazing, isn't it? > The postal system did collapse when it started > suffering from spam; that's why the paper chain mail is actually > illegal in many jurisdictions - it took down the postal system, once > upon a time. Nice. > The telphone system would collapse if phone spam > outnumbered real calls by 10, 25, 100 to 1. (Actually, in a sense they > already do. I have a fax line set up, and get dozens of fax spams for > every real fax. I've had to start adapting and applying my email spam > fighting techniques there....) We get so many unsolicited calls from telemarketers and robot dialers at home we don't answer the phone unless we recognize the caller ID. Sometimes family calling from roaming cell phones show up as 'unidentified caller' and we mistakenly don't answer. How much more broken can it be? - Marsh From mouse@Sparkle.Rodents-Montreal.ORG Thu Jan 6 10:39:24 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CD5F3A6F43; Thu, 6 Jan 2011 10:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.792 X-Spam-Level: X-Spam-Status: No, score=-8.792 tagged_above=-999 required=5 tests=[AWL=1.196, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 PImVhi95MZYY; Thu, 6 Jan 2011 10:39:23 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id CF3113A6F3A; Thu, 6 Jan 2011 10:39:22 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA23900; Thu, 6 Jan 2011 13:35:40 -0500 (EST) Date: Thu, 6 Jan 2011 13:35:40 -0500 (EST) From: der Mouse Message-Id: <201101061835.NAA23900@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 6 Jan 2011 13:19:53 -0500 (EST) To: apps-discuss@ietf.org, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, saag@ietf.org, ietf-http-wg@w3.org In-Reply-To: <4D0E8148.7060607@extendedsubset.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> <4D0E8148.7060607@extendedsubset.com> X-Mailman-Approved-At: Fri, 07 Jan 2011 11:40:25 -0800 Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:39:24 -0000 > Look back far enough and you'll find all kinds of "electronic mail" > services implementing the full range of peer and end user > authentication, and sender-pays models. There was no spam on those > systems, or at least not enough that anyone felt like they needed a > word for it. There was basically no spam on open-Internet SMTP mail either, at the time. Certainly "no spam" by today's standards. > Guess why we use the one we use today. At the time, the services you deride weren't providing a significant value-add. Today? They would be. Perhaps not enough to make up for their costs; probably not, in fact, or there'd be businesses arising in that space. As a side note, it's interesting to see how well the early Internet designers built; their systems are routinely being stressed several orders of magnitude beyond what they were designed for, and are holding up remarkably well. The postal system did collapse when it started suffering from spam; that's why the paper chain mail is actually illegal in many jurisdictions - it took down the postal system, once upon a time. The telphone system would collapse if phone spam outnumbered real calls by 10, 25, 100 to 1. (Actually, in a sense they already do. I have a fax line set up, and get dozens of fax spams for every real fax. I've had to start adapting and applying my email spam fighting techniques there....) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From sm@elandsys.com Sat Jan 8 03:19:53 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0ED53A69D2 for ; Sat, 8 Jan 2011 03:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 I4nXqM6DwO38 for ; Sat, 8 Jan 2011 03:19:51 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 0F8543A69C5 for ; Sat, 8 Jan 2011 03:19:51 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.234.35]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p08BLl9v032510 for ; Sat, 8 Jan 2011 03:21:55 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1294485718; bh=4DAffp14Rexb1z7g3cLrP/aHDYQ=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type; b=SIDjFjbRporusmtp4cyYMD18B5M5xcT3d+/lDGBxp+rW4tlxML82ibV7OvC/xH4t7 0qQtbAyxLhXS0JrUKSuNRauEYhPpVsBedGS3K5jhefeYEQWjg9GmPNL2ccTmvGBRZV P4JfKl/3tjHUbpv2u5+j3P3GJ3Gb0Xg4XXJgI/RI= Message-Id: <6.2.5.6.2.20110108015412.0daa6140@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 08 Jan 2011 02:45:34 -0800 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Apps Area Review Team Report for December 2010 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 11:19:53 -0000 Hello, The Applications Area Review Team provides semi-formal reviews of Internet-Drafts as a way to improve the quality of IETF specifications. The members of the team are selected from the IETF community, especially from among active participants and recognized experts in the Applications Area. The following reviews have been performed in December 2010: Reviewer I-D Vijay K. Gurbani draft-ietf-geopriv-rfc3825bis-14 Joseph Yee draft-cheshire-dnsext-dns-sd-07 Lisa Dusseault draft-ietf-httpstate-cookie-19 Enrico Marocco draft-ietf-sipcore-reinvite-07 Eliot Lear draft-ietf-eai-rfc5337bis-01 Kurt Zeilenga draft-ietf-sipcore-sec-flows-07 Ted Hardie draft-ietf-eai-rfc5337bis-01 Tim Bray draft-merrick-jms-uri-10 Barry Leiba draft-cdmi-mediatypes-04 Claudio Allocchio draft-ietf-eai-rfc5336bis-07 Dave Crocker draft-ietf-eai-rfc5336bis-07 Aaron Stone draft-ietf-ipfix-mediators-framework-09 Murray S. Kucherawy draft-ietf-eai-rfc5335bis-07 Pending review: draft-ietf-avt-rtp-svc assigned to Glenn Parsons draft-salowey-secsh-uri assigned to Joe Hildebrand draft-ietf-eai-rfc5335bis assigned to Dave Cridland The Apps Area Review Team received a request from an author for a review last month. The author was advised to solicit comments from the appropriate IETF mailing list first and to allow sufficient time for feedback before requesting an Apps Area Team review. The Apps Area Review Team currently comprises 31 members, including the four members currently on leave. The team performed 35 reviews in 2010. The top three reviewers for the last year are: Reviews Ted Hardie 4 Claudio Allocchio 3 Eliot Lear 3 Regards, S. Moonesamy On behalf of the Apps Review Team http://www.apps.ietf.org/content/applications-area-review-team From hallam@gmail.com Sat Jan 8 08:05:35 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED07028C116; Sat, 8 Jan 2011 08:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.394 X-Spam-Level: X-Spam-Status: No, score=-3.394 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6gCSwpkqFCfA; Sat, 8 Jan 2011 08:05:34 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 980FE28C115; Sat, 8 Jan 2011 08:05:30 -0800 (PST) Received: by yie19 with SMTP id 19so5709246yie.31 for ; Sat, 08 Jan 2011 08:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=EZat7nI2OqohWyhSuZ4/WUlxZZdT1hBAk9ZOiTKdMs8=; b=IsStjSvSUvS0dPFDf1N3Ml3awrq6X6rj5PoZzGDm8t25H5pVn6+V+O8BlPF4zYXGiw 15TFFqfUG6WgkHRo9pfnC6zEIrglsN88NS7dz4gkaK9K3deHlpnk8vEW0vNrYsxJ4yyZ hWZlZEK/FamRcOPXqikvjrHHlsdrGvTmrl/lo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WSyrgGBaHg3J5BznJYd6ZsF1Ar8HJ3QQhdyo4tPV51GGUNa4oJNsQCdx/zvFY8FyWK C5j2k8JRj00t4G/7PZ1MX0RU3qlQtl2dosSeNZKMm9U++nWz2mXgPU/iACBsZyYyhIrg IKFedcrAXxE3YeAiKRUmipB+NPHJj2bdEiEzY= MIME-Version: 1.0 Received: by 10.100.173.13 with SMTP id v13mr2476968ane.171.1294502858509; Sat, 08 Jan 2011 08:07:38 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 08:07:38 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Sat, 8 Jan 2011 11:07:38 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=0016e644dbc60acc57049957ef07 Cc: "apps-discuss@ietf.org" , "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:05:36 -0000 --0016e644dbc60acc57049957ef07 Content-Type: text/plain; charset=ISO-8859-1 I think that Ben is right that we are solving the wrong problem. The problem is that users are asked to maintain accounts at literally HUNDREDS of accounts. And some cretins, some utter morons, some bog-brained berks think it is reasonable to tell the user to have a different password for every one! I can't remember the account names, the password is easy as I only had one (for non financial) - until those cretins at Gawker screwed up. Now I have to reset my password at all those places. We have to solve the federated auth problem and it is really, really easy: Account Name is the RFC 821/822 email address. This is what the Web has started to adopt of its own accord as a user account identifier. It is the only one that people can remember reliably. Authentication service is resolved via DNS service lookup i.e. SRV or similar. I can show people how to fix up the issues to do with use of non-canonical names. Client authenticates to authentication service using any protocol they both support. This is quite simple to implement, just stick a list of supported auth services in the DNS. We can re-use all those existing auth protocols that work (SAML would be a good choice but we don't need to be overly restrictive here.) HTTP carries a standardized, non-linkable auth token I have some ideas on how we could modify DIGEST to do this. DIGEST would not be problematic if the password had 128 bits of ergodicity and we upgraded the digest function. The reason for re-using DIGEST here would be to avoid patent encumbrances. I considered the issue of linkability at great length when writing the original DIGEST design. At the moment I am focused on getting the foundation laid. But I will try to come up with a full proposal before Prague. I know that you can achieve some of the desired authentication properties with public keys at the client. The problem is that our current use of computers has gone way beyond the one-machine-per-person paradigm On a recent trip to Europe with the family I counted that we had 10 computers with us capable of supporting IP (3 laptops, 3 iPhones, 2 Nintendos, 1 iPad and a kindle). Cardspace has some really, really great properties but they are totally lost when you try to make the service accessible from multiple machines by putting it 'in the cloud'. In fact, other than a manager, I have never found anyone who reven thinks they know what they mean by 'in the cloud' for CardSpace. I certainly have never seen an explanation I can understand. Devices get lost. Devices get stolen. We don't want to encourage that so there needs to be something more than just a certificate based client auth scheme. I think we need some form of centralized (for given account) account management in the mix so that the user can authorize/deauthorize devices for use (c.f. Amazon's Kindle account management) So there are basically two architectural options for using public key. One is to use it strictly between the client and the auth service and use a token like approach as discussed above. Another is for the auth service to issue an assertion of the form 'you can tell its fred by this public key (amongst others)'. SAML already has support for both approaches BTW. On Thu, Jan 6, 2011 at 10:31 AM, Ben Laurie wrote: > > > On 6 January 2011 01:28, Robert Sayre wrote: >> >> > Peter Saint-Andre wrote: >> > 2. In 2007, Robert Sayre put together a few slides on the topic: >> > http://people.mozilla.com/~sayrer/2007/auth.html >> >> These are back on the Web, in case anyone missed them (probably not). >> >> On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding >> wrote: >> > >> > Define them all and let's have a bake-off. It has been 16 years since >> > HTTP auth was taken out of our hands so that the security experts could >> > define something perfect. Zero progress so far. >> >> I think the IETF might do better to focus on a smaller problem, at >> first. People often use self-signed certificates with HTTP/TLS, even >> though the first thing their websites ask the user to do is type a >> username and password into a form. There are some well-understood ways >> to make this process more secure. Why hasn't the IETF fixed this >> problem? If this smaller problem has no ready solution, then the >> larger issue of authentication on the entire Web seems like a tough >> nut to crack. > > Two comments (one really being a response to Roy): > 1. The IETF has fixed the problem, but no-one is using the fix - perhaps > because it is not clear that it is the fix. I speak of RFC 4279, TLS > pre-shared keys. These could be derived from a hash of the password and the > site name, for example, and thus provide secure mutual authentication > despite password reuse. > 2. I have often heard (though I am not aware of hard evidence for this, > nevertheless I find it plausible) that one reason no-one has bothered to > improve HTTP auth is because no-one would use it since site owners want to > control the user experience around signin. It seems to me, therefore, that > HTTP is the wrong layer to fix the problem at - it needs to be pushed down > into HTML or Javascript so that the page can control the look, while > appropriate HTML elements or JS code can deal with the secure exchange of > data. > Of course, this still leaves the issue of trusted path: although we can > provide elements which are safe to use, even when being phished, how does > the user know those elements are actually being used, rather than simulated > so as to get hold of the underlying password? > The answer to this problem is hard, since it brings us back to taking the UI > out of the sites hands. > >> >> It could be that the reasons for this lack of progress are >> nontechnical. Just throwing that out there. > > If you think UI is nontechnical, then I agree. > Cheers, > Ben. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > -- Website: http://hallambaker.com/ --0016e644dbc60acc57049957ef07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that Ben is right that we are solving the wrong problem.

The= problem is that users are asked to maintain accounts at literally HUNDREDS= of accounts.

And some cretins, some utter morons, some bog-brained= berks think it is reasonable to tell the user to have a different password= for every one!


I can't remember the account names, the password is easy as I o= nly had one (for non financial) - until those cretins at Gawker screwed up.= Now I have to reset my password at all those places.


We have to= solve the federated auth problem and it is really, really easy:

Account Name is the RFC 821/822 email address.

This is what the Web has started to adopt of its own accord as= a user account identifier. It is the only one that people can remember rel= iably.

Authentication service is resolved via DNS service lookup

i.e. SRV or similar. I can show people = how to fix up the issues to do with use of non-canonical names.

Client authenticates to authentication ser= vice using any protocol they both support.

This is quite simple to implement, just stick a list of supported auth= services in the DNS.

We can re-use all those exis= ting auth protocols that work (SAML would be a good choice but we don't= need to be overly restrictive here.)

HTTP carries a standardized, non-linkable = auth token

I have so= me ideas on how we could modify DIGEST to do this. DIGEST would not be prob= lematic if the password had 128 bits of ergodicity and we upgraded the dige= st function.

The reason for re-using DIGEST here would be to avoid p= atent encumbrances. I considered the issue of linkability at great length w= hen writing the original DIGEST design.


At the moment I am focused on getting the foundation laid. B= ut I will try to come up with a full proposal before Prague.


I know that you can achieve some of the desired aut= hentication properties with public keys at the client. The problem is that = our current use of computers has gone way beyond the one-machine-per-person= paradigm

On a recent trip to Europe with the family I counted th= at we had 10 computers with us capable of supporting IP (3 laptops, 3 iPhon= es, 2 Nintendos, 1 iPad and a kindle).

Cardspace h= as some really, really great properties but they are totally lost when you = try to make the service accessible from multiple machines by putting it = 9;in the cloud'. In fact, other than a manager, I have never found anyo= ne who reven thinks they know what they mean by 'in the cloud' for = CardSpace. I certainly have never seen an explanation I can understand.=A0<= /div>

Devices get lost. Devices get stolen. We don't want= to encourage that so there needs to be something more than just a certific= ate based client auth scheme.


I thi= nk we need some form of centralized (for given account) account management = in the mix so that the user can authorize/deauthorize devices for use (c.f.= Amazon's Kindle account management)

So there are basically two architectural options for us= ing public key. One is to use it strictly between the client and the auth s= ervice and use a token like approach as discussed above. Another is for the= auth service to issue an assertion of the form 'you can tell its fred = by this public key (amongst others)'.

SAML already has support for both approaches BTW.=A0


On Thu, Jan 6, 2011 at 10:31 AM, Ben Laurie <= benl@google.com> wrote:
> >
> On 6 January 2011 01:28, Robert Sayre <sayrer@gmail.com> wrote:
>>
>> >= ; Peter Saint-Andre <stpeter@stpet= er.im> wrote:
>> > 2. In 2007, Robert Sayre put together a few slides on the top= ic:
>> > http://people.mozilla.com/~sayrer/2007/auth.html
>>
>> These are back on the Web, in case anyone missed them (probably no= t).
>>
>> On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fieldin= g <fielding@gbiv.com>
>= ;> wrote:
>> >
>> > Define them all and let's have a bake-of= f. =A0It has been 16 years since
>> > HTTP auth was taken out o= f our hands so that the security experts could
>> > define some= thing perfect. =A0Zero progress so far.
>>
>> I think the IETF might do better to focus on a smaller= problem, at
>> first. People often use self-signed certificates w= ith HTTP/TLS, even
>> though the first thing their websites ask th= e user to do is type a
>> username and password into a form. There are some well-understood = ways
>> to make this process more secure. Why hasn't the IETF = fixed this
>> problem? If this smaller problem has no ready soluti= on, then the
>> larger issue of authentication on the entire Web seems like a toug= h
>> nut to crack.
>
> Two comments (one really being = a response to Roy):
> 1. The IETF has fixed the problem, but no-one i= s using the fix - perhaps
> because it is not clear that it is the fix. I speak of RFC 4279, TLS> pre-shared keys. These could be derived from a hash of the password = and the
> site name, for example, and thus provide secure mutual auth= entication
> despite password reuse.
> 2. I have often heard (though I am not= aware of hard evidence for this,
> nevertheless I find it plausible)= that one reason no-one has bothered to
> improve HTTP auth is becaus= e no-one would use it since site owners want to
> control the user experience around signin. It seems to me, therefore, = that
> HTTP is the wrong layer to fix the problem at - it needs to be= pushed down
> into HTML or Javascript so that the page can control t= he look, while
> appropriate HTML elements or JS code can deal with the secure exchange= of
> data.
> Of course, this still leaves the issue of trusted= path: although we can
> provide elements which are safe to use, even= when being phished, how does
> the user know those elements are actually being used, rather than simu= lated
> so as to get hold of the underlying password?
> The ans= wer to this problem is hard, since it brings us back to taking the UI
> out of the sites hands.
> =A0
>>
>> It could b= e that the reasons for this lack of progress are
>> nontechnical. = Just throwing that out there.
>
> If you think UI is nontechnic= al, then I agree.
> Cheers,
> Ben.
>
> _________________________________= ______________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
>



--
Website: http://hallambaker.com/


--0016e644dbc60acc57049957ef07-- From hallam@gmail.com Sat Jan 8 08:19:38 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B3AE28C13A; Sat, 8 Jan 2011 08:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rv2k8-0ECqSB; Sat, 8 Jan 2011 08:19:36 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id DD14728C116; Sat, 8 Jan 2011 08:19:34 -0800 (PST) Received: by yxt33 with SMTP id 33so7991387yxt.31 for ; Sat, 08 Jan 2011 08:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=P/kVq8JqTkbriAI2YHZ98j+IH6nPYaKiXLgMS1MrhJg=; b=gj3y71kH8mkwf9cxcnOrEcJQbI+UOFHppgDDPLZGHIdfFFp2xvOoVOpWrXtvD+yUkA +LKTe3Xre6ZFVGT3kLsOPfjpJ4+FCR/k4ryZHG6UBxHuR3hliF/G0Ra32UC7Ftq25kiT CSSObZqQKWywj3P9ZvOUXBi4SBO5ct7i6a2U8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=akVsGITiA3khO4gDCJU1IG1XlVTf0CvbBpjMaP9HTk7XT1qtjcDuiz08xafz+rqNOS +wqrQGZtiyzvfSjsGG6J0XLtD94i1iVJMpQmw12JwA00AmVcNDKtrDrIp3Wm4HuFW/B6 MyZXCnpieOCjP1JWjS/yGhBmH0vu4YVZLrxzI= MIME-Version: 1.0 Received: by 10.101.67.16 with SMTP id u16mr15882518ank.1.1294503702896; Sat, 08 Jan 2011 08:21:42 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 08:21:42 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Sat, 8 Jan 2011 11:21:42 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=00163662e65b5f211d049958212f Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:19:38 -0000 --00163662e65b5f211d049958212f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie wrote: > On 6 January 2011 16:03, David Morris wrote: > > > > > > On Thu, 6 Jan 2011, Ben Laurie wrote: > > > >> The answer to this problem is hard, since it brings us back to taking > the UI > >> out of the sites hands. > > > > Which is only helpful if you can somehow gaurantee that the user agent > > software hasn't been compromised. Not something I'd bet on... > > That's rather overstating it. It's perfectly helpful when the UA > software hasn't been compromised, which is a non-zero fraction of the > time. > > When the UA s/w has been compromised I'm quite happy to fail to fix > the problem: the right answer to that is to improve the robustness of > the UA. +1 If the UA is stuffed then the user is totally and utterly stuffed anyway. In particular if the UA is stuffed then a forms based experience is just as stuffed. If we are going to hypothecate attack models people have to be willing to apply them to their preferred solution too. The sensible approach is to work out how to stop the user from being stuffed e.g. * Comodo's free Anti-Virus with Default Deny Protection (TM) * Use code signing + trustworthy computing * Use a restricted browser Now I have a lot of ideas on how we can tackle these, but they are not relevant to this debate. I do however have a different take on the UI issue. HTML forms did have an advantage over the pathetic UI that browsers provided for BASIC and DIGEST (most don't even tell the user which is in use). But a federated auth scheme supported at the HTTP level could be simpler still. Instead of the user having to register for each site, they register once. Instead of the user having to log in to each site they log in once per session. Instead of the site having to manage lost passwords and forgotten accounts because the user has hundreds, this problem does not exist. It is a user interface crisis that is driving this need in my view. -- Website: http://hallambaker.com/ --00163662e65b5f211d049958212f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie <benl@google.com> wrote:
On 6 January 2011 16:03, David Morris <dwm@xpasc.com> wrote:
>
>
> On Thu, 6 Jan 2011, Ben Laurie wrote:
>
>> The answer to this problem is hard, since it brings us back to tak= ing the UI
>> out of the sites hands.
>
> Which is only helpful if you can somehow gaurantee that the user agent=
> software hasn't been compromised. Not something I'd bet on...<= br>
That's rather overstating it. It's perfectly helpful when the= UA
software hasn't been compromised, which is a non-zero fraction of the time.

When the UA s/w has been compromised I'm quite happy to fail to fix
the problem: the right answer to that is to improve the robustness of
the UA.

+1

If the = UA is stuffed then the user is totally and utterly stuffed anyway.=A0
=

In particular if the UA is stuffed then a forms based e= xperience is just as stuffed. If we are going to hypothecate attack models = people have to be willing to apply them to their preferred solution too.


The sensible approach is to work out how= to stop the user from being stuffed e.g.=A0

=A0* = Comodo's free Anti-Virus with Default Deny Protection (TM)
= =A0* Use code signing + trustworthy computing
=A0* Use a restricted browser=A0

Now I have a= lot of ideas on how we can tackle these, but they are not relevant to this= debate.


I do however have a differ= ent take on the UI issue.=A0

HTML forms did have an advantage over the pathetic UI t= hat browsers provided for BASIC and DIGEST (most don't even tell the us= er which is in use).

But a federated auth scheme s= upported at the HTTP level could be simpler still. Instead of the user havi= ng to register for each site, they register once. Instead of the user havin= g to log in to each site they log in once per session. Instead of the site = having to manage lost passwords and forgotten accounts because the user has= hundreds, this problem does not exist.


It is a user interface crisis that is dr= iving this need in my view.


-- Website: http://hallambaker.com/
--00163662e65b5f211d049958212f-- From romeda@gmail.com Sat Jan 8 09:35:35 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B324D3A67B5; Sat, 8 Jan 2011 09:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 K1de9OjHbzeT; Sat, 8 Jan 2011 09:35:34 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id E3BA93A67AD; Sat, 8 Jan 2011 09:35:17 -0800 (PST) Received: by wyf23 with SMTP id 23so19276867wyf.31 for ; Sat, 08 Jan 2011 09:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=K/xHYytBU+XmnS87+Mqw5HmwQyDfHfNbg8QAUiR6Wps=; b=FU7xxzQDcdWQZzLfDdqfAvH5LhwNpJwDoV5kMBUDLVRqgOtgxKKTgb6scom9ELoz5U TTUnuSDNxTuODZ0ZYkw4PPEB1/Ot7pTnPBnHfVpfQRaOQEPNhr+aVxRElpsF7dqxUPEL 2bsgcy/+LYq9A9JDJzhkxvmFOqzeQlzPCk0Z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=gNBj6PYnDHrSnvc/htfrh9KcFkHuYGy9L16H7r83JLBiGwvaWyy+HhTTfx+0WR5UXs HnoZAXB8V/u5aA50esEsA1o+wr6xcDrbrPLaZ3BQq8t8JI83jyVDCHhRiAP+n7TcVTDM j0SN1HZkPd+tBnieT7PjD7bisA2tRMECNkIJk= Received: by 10.216.59.143 with SMTP id s15mr410638wec.49.1294508241087; Sat, 08 Jan 2011 09:37:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.240.197 with HTTP; Sat, 8 Jan 2011 09:37:00 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> From: Blaine Cook Date: Sat, 8 Jan 2011 09:37:00 -0800 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Ben Laurie , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 17:35:35 -0000 Two points: 1. In this entire thread, no-one has mentioned OAuth. Maybe y'all don't like it, but it's used to authenticate more HTTP requests by volume and users than everything-except-cookies combined. You may want to consider the design of OAuth when proceeding with these discussions, rather than the laundry list of [completely] failed protocols. 2. With respect to federated auth, especially using email address-like identifiers, there has been a bevy of (deployed) work in this regard. The effort is called webfinger, and is worth a look. Instead of DNS, we use host-meta based HTTP lookups to dereference the identifiers. Many diaspora and status.net installs are using it today, and there are several proposals towards building a security & privacy infrastructure on top of webfinger (webid is one such proposal whose incorporation of client-side TLS certificates in a browser context makes me very weary of its potential for success). b. On 8 January 2011 08:21, Phillip Hallam-Baker wrote: > On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie wrote: >> >> On 6 January 2011 16:03, David Morris wrote: >> > >> > >> > On Thu, 6 Jan 2011, Ben Laurie wrote: >> > >> >> The answer to this problem is hard, since it brings us back to taking >> >> the UI >> >> out of the sites hands. >> > >> > Which is only helpful if you can somehow gaurantee that the user agent >> > software hasn't been compromised. Not something I'd bet on... >> >> That's rather overstating it. It's perfectly helpful when the UA >> software hasn't been compromised, which is a non-zero fraction of the >> time. >> >> When the UA s/w has been compromised I'm quite happy to fail to fix >> the problem: the right answer to that is to improve the robustness of >> the UA. > > +1 > If the UA is stuffed then the user is totally and utterly stuffed anyway. > In particular if the UA is stuffed then a forms based experience is just = as > stuffed. If we are going to hypothecate attack models people have to be > willing to apply them to their preferred solution too. > > The sensible approach is to work out how to stop the user from being stuf= fed > e.g. > =C2=A0* Comodo's free Anti-Virus with Default Deny Protection (TM) > =C2=A0* Use code signing + trustworthy computing > =C2=A0* Use a restricted browser > Now I have a lot of ideas on how we can tackle these, but they are not > relevant to this debate. > > I do however have a different take on the UI issue. > HTML forms did have an advantage over the pathetic UI that browsers provi= ded > for BASIC and DIGEST (most don't even tell the user which is in use). > But a federated auth scheme supported at the HTTP level could be simpler > still. Instead of the user having to register for each site, they registe= r > once. Instead of the user having to log in to each site they log in once = per > session. Instead of the site having to manage lost passwords and forgotte= n > accounts because the user has hundreds, this problem does not exist. > > It is a user interface crisis that is driving this need in my view. > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From hallam@gmail.com Sat Jan 8 09:50:39 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2C23A67FB; Sat, 8 Jan 2011 09:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 20paQQnmkSN0; Sat, 8 Jan 2011 09:50:37 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 4885D3A67E3; Sat, 8 Jan 2011 09:50:37 -0800 (PST) Received: by gxk28 with SMTP id 28so8482976gxk.31 for ; Sat, 08 Jan 2011 09:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=6bo8ZioF39rKL6lWvOQo5g2WqHHhQncsxAnkblyge2E=; b=jWIHeGDUOh6avcUiKYI7wTYJwXy3jV8Acwp85reJHuvwsDKt8TaSgr8SGj5bn7Q7bv jG2GSHJKVTAA9sgZKU7NZ4wuZ42O+jZbnhxcQUq74l1TCZaXmMIaC0yNxPR6LkqMfWnL tuiYH6ugrFSmbfe0lfKwHBKdlGFwnHo2lWpJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g3FpArmvl34jXqveOoAO3WWa9XUrTArhTTE14LqMm9R3QH4k7wPphX8fK/KgZnsYnM jBigHkW3i9jMtNPJtsOOxoaJFUSZhDnDiNwBUhJwN42VR72PMU6XBpttZm04NoXcFF3p +mWIZVwfHvsxDrYrql6OzS8B9K/d4dEIHJ0SA= MIME-Version: 1.0 Received: by 10.100.173.13 with SMTP id v13mr2521122ane.171.1294509165388; Sat, 08 Jan 2011 09:52:45 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 09:52:45 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Sat, 8 Jan 2011 12:52:45 -0500 Message-ID: From: Phillip Hallam-Baker To: Blaine Cook Content-Type: multipart/alternative; boundary=0016e644dbc6f623100499596635 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Ben Laurie , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 17:50:39 -0000 --0016e644dbc6f623100499596635 Content-Type: text/plain; charset=ISO-8859-1 OAUTH and Webfinger are both pretty much as good as you can expect to achieve if you decide at the start that you are not going to modify the infrastructure. But that decision limits what you can expect to achieve. A particular problem with OAuth is that you can only use the identity providers that are supported by the particular site. So I had to use my Twitter account to play spymaster. And when Twitter got shirty and started blocking other players accounts they lost their game account and their twitter account at the same time. There are people who think I should get a facebook account just so that I can use their application. Not happening. As for WebFinger, it works, but not nearly as well as a clean DNS scheme. DNS is designed to address this problem, HTTP is not. And solving the problem with HTTP requires us to have a scheme that involves DNS + HTTP + SSL + PKIX which is rather a lot of moving parts and to make matters work some those parts are not just moving, they are changing. I think it is a very good idea to look at WebFinger and OAuth and see how to realize these approaches direct in the infrastructure. But they should be seen as starting points, not ends. On Sat, Jan 8, 2011 at 12:37 PM, Blaine Cook wrote: > Two points: > > 1. In this entire thread, no-one has mentioned OAuth. Maybe y'all > don't like it, but it's used to authenticate more HTTP requests by > volume and users than everything-except-cookies combined. You may want > to consider the design of OAuth when proceeding with these > discussions, rather than the laundry list of [completely] failed > protocols. > > 2. With respect to federated auth, especially using email address-like > identifiers, there has been a bevy of (deployed) work in this regard. > The effort is called webfinger, and is worth a look. Instead of DNS, > we use host-meta based HTTP lookups to dereference the identifiers. > Many diaspora and status.net installs are using it today, and there > are several proposals towards building a security & privacy > infrastructure on top of webfinger (webid is one such proposal whose > incorporation of client-side TLS certificates in a browser context > makes me very weary of its potential for success). > > b. > > On 8 January 2011 08:21, Phillip Hallam-Baker wrote: > > On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie wrote: > >> > >> On 6 January 2011 16:03, David Morris wrote: > >> > > >> > > >> > On Thu, 6 Jan 2011, Ben Laurie wrote: > >> > > >> >> The answer to this problem is hard, since it brings us back to taking > >> >> the UI > >> >> out of the sites hands. > >> > > >> > Which is only helpful if you can somehow gaurantee that the user agent > >> > software hasn't been compromised. Not something I'd bet on... > >> > >> That's rather overstating it. It's perfectly helpful when the UA > >> software hasn't been compromised, which is a non-zero fraction of the > >> time. > >> > >> When the UA s/w has been compromised I'm quite happy to fail to fix > >> the problem: the right answer to that is to improve the robustness of > >> the UA. > > > > +1 > > If the UA is stuffed then the user is totally and utterly stuffed anyway. > > In particular if the UA is stuffed then a forms based experience is just > as > > stuffed. If we are going to hypothecate attack models people have to be > > willing to apply them to their preferred solution too. > > > > The sensible approach is to work out how to stop the user from being > stuffed > > e.g. > > * Comodo's free Anti-Virus with Default Deny Protection (TM) > > * Use code signing + trustworthy computing > > * Use a restricted browser > > Now I have a lot of ideas on how we can tackle these, but they are not > > relevant to this debate. > > > > I do however have a different take on the UI issue. > > HTML forms did have an advantage over the pathetic UI that browsers > provided > > for BASIC and DIGEST (most don't even tell the user which is in use). > > But a federated auth scheme supported at the HTTP level could be simpler > > still. Instead of the user having to register for each site, they > register > > once. Instead of the user having to log in to each site they log in once > per > > session. Instead of the site having to manage lost passwords and > forgotten > > accounts because the user has hundreds, this problem does not exist. > > > > It is a user interface crisis that is driving this need in my view. > > > > -- > > Website: http://hallambaker.com/ > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > -- Website: http://hallambaker.com/ --0016e644dbc6f623100499596635 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OAUTH and Webfinger are both pretty much as good as you can expect to achie= ve if you decide at the start that you are not going to modify the infrastr= ucture.

But that decision limits what you can expect to = achieve.


A particular problem with OAuth is that = you can only use the identity providers that are supported by the particula= r site. So I had to use my Twitter account to play spymaster. And when Twit= ter got shirty and started blocking other players accounts they lost their = game account and their twitter account at the same time.

There are people who think I should get a facebook acco= unt just so that I can use their application. Not happening.

=

As for WebFinger, it works, but not nearly as wel= l as a clean DNS scheme. DNS is designed to address this problem, HTTP is n= ot. And solving the problem with HTTP requires us to have a scheme that inv= olves DNS + HTTP + SSL + PKIX which is rather a lot of moving parts and to = make matters work some those parts are not just moving, they are changing.<= /div>


I think it is a very good idea to look a= t WebFinger and OAuth and see how to realize these approaches direct in the= infrastructure. But they should be seen as starting points, not ends.


On Sat, Jan 8, 2011 at 12:37 PM, Bl= aine Cook <romeda@= gmail.com> wrote:
Two points:

1. In this entire thread, no-one has mentioned OAuth. Maybe y'all
don't like it, but it's used to authenticate more HTTP requests by<= br> volume and users than everything-except-cookies combined. You may want
to consider the design of OAuth when proceeding with these
discussions, rather than the laundry list of [completely] failed
protocols.

2. With respect to federated auth, especially using email address-like
identifiers, there has been a bevy of (deployed) work in this regard.
The effort is called webfinger, and is worth a look. Instead of DNS,
we use host-meta based HTTP lookups to dereference the identifiers.
Many diaspora and status.ne= t installs are using it today, and there
are several proposals towards building a security & privacy
infrastructure on top of webfinger (webid is one such proposal whose
incorporation of client-side TLS certificates in a browser context
makes me very weary of its potential for success).

b.

On 8 January 2011 08:21, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie <benl@google.com> wrote:
>>
>> On 6 January 2011 16:03, David Morris <dwm@xpasc.com> wrote:
>> >
>> >
>> > On Thu, 6 Jan 2011, Ben Laurie wrote:
>> >
>> >> The answer to this problem is hard, since it brings us ba= ck to taking
>> >> the UI
>> >> out of the sites hands.
>> >
>> > Which is only helpful if you can somehow gaurantee that the u= ser agent
>> > software hasn't been compromised. Not something I'd b= et on...
>>
>> That's rather overstating it. It's perfectly helpful when = the UA
>> software hasn't been compromised, which is a non-zero fraction= of the
>> time.
>>
>> When the UA s/w has been compromised I'm quite happy to fail t= o fix
>> the problem: the right answer to that is to improve the robustness= of
>> the UA.
>
> +1
> If the UA is stuffed then the user is totally and utterly stuffed anyw= ay.
> In particular if the UA is stuffed then a forms based experience is ju= st as
> stuffed. If we are going to hypothecate attack models people have to b= e
> willing to apply them to their preferred solution too.
>
> The sensible approach is to work out how to stop the user from being s= tuffed
> e.g.
> =A0* Comodo's free Anti-Virus with Default Deny Protection (TM) > =A0* Use code signing + trustworthy computing
> =A0* Use a restricted browser
> Now I have a lot of ideas on how we can tackle these, but they are not=
> relevant to this debate.
>
> I do however have a different take on the UI issue.
> HTML forms did have an advantage over the pathetic UI that browsers pr= ovided
> for BASIC and DIGEST (most don't even tell the user which is in us= e).
> But a federated auth scheme supported at the HTTP level could be simpl= er
> still. Instead of the user having to register for each site, they regi= ster
> once. Instead of the user having to log in to each site they log in on= ce per
> session. Instead of the site having to manage lost passwords and forgo= tten
> accounts because the user has hundreds, this problem does not exist. >
> It is a user interface crisis that is driving this need in my view. >
> --
> Website: http://= hallambaker.com/
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>



--
Website: http://hallambaker.com/

--0016e644dbc6f623100499596635-- From benl@google.com Sun Jan 9 05:42:05 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 142683A69B1 for ; Sun, 9 Jan 2011 05:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.406 X-Spam-Level: X-Spam-Status: No, score=-104.406 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 xOv0mL9Z7Gn9 for ; Sun, 9 Jan 2011 05:42:04 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1505D3A69A6 for ; Sun, 9 Jan 2011 05:42:03 -0800 (PST) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p09DiE4N019411 for ; Sun, 9 Jan 2011 05:44:14 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294580654; bh=/mk8a9m6BHBI1j9A8YYpAAJT3g0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=rBd7e5LDKWOIj5qUWv3wG0oA2pnQGelokPC4sYnssr7Zzj8vz/Z6UYrf25BqbH1/I wOBB+UrZDr/XjglaTzg2Q== Received: from vws5 (vws5.prod.google.com [10.241.21.133]) by kpbe18.cbf.corp.google.com with ESMTP id p09DiCso015979 for ; Sun, 9 Jan 2011 05:44:12 -0800 Received: by vws5 with SMTP id 5so7521623vws.22 for ; Sun, 09 Jan 2011 05:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZRWqqE2GC4FvKBmajUqrY7ravsT74mc/cg/K4kzh7cM=; b=GcGbegD1O4aILaEJyw/n4kMpuLQjeb5LMacygSf0Zp49ph4nEnffspaTdOBCTWDX8Y A1EW0TKeMxpuyF7lmcZg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WX+kK4B4G3HeErl5S2/G/I1bA3Ykj3FXsZiU9f1dd+V96cJhNoRJYYontlCDmNFKW/ qNFiploG2G8enySMzZHg== MIME-Version: 1.0 Received: by 10.220.202.131 with SMTP id fe3mr8379018vcb.183.1294580652479; Sun, 09 Jan 2011 05:44:12 -0800 (PST) Received: by 10.220.88.137 with HTTP; Sun, 9 Jan 2011 05:44:12 -0800 (PST) In-Reply-To: References: <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <20110108194952.GS12542@zedshaw> Date: Sun, 9 Jan 2011 13:44:12 +0000 Message-ID: From: Ben Laurie To: Blaine Cook Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Sun, 09 Jan 2011 09:40:07 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "Zed A. Shaw" , "http-auth@ietf.org" , "saag@ietf.org" , Phillip Hallam-Baker , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 13:42:05 -0000 On 9 January 2011 01:29, Blaine Cook wrote: > On 8 January 2011 11:49, Zed A. Shaw wrote: >> On Sat, Jan 08, 2011 at 09:37:00AM -0800, Blaine Cook wrote: >> I don't normally respond, just being a lurker, but this statement is >> competely wrong Blaine. =A0OAuth may be used for more requests, but not >> more sites. =A0It's used on a tiny number of sites, with OpenID being us= ed >> on way many more, and even then, not nowhere near the number of websites >> that form based authentication and browser authentication methods. >> >> Don't equate twitter having a ton of traffic to OAuth being some kind of >> raving success, and sure as hell don't evaluate the technical merits of >> something by its popularity. > > Agreed - though, facebook is also using oauth-based (not 1.0, but > essentially the same approach) logins, and there are a number of other > sites that do provide oauth-based login infrastructure. > > Moreover, the nudge towards oauth is intended with the movement > towards a new auth infrastructure in mind. We'd need some kind of > discovery / negotiation mechanism on top to make it not the > one-or-two-companies-own-the-web play that login-over-oauth is now. > (c.f. OpenID Connect). > > b. > >> While I agree that TLS client side isn't going to work, none of the >> proposed authentication methods will work without a change to browsers >> to support a way for two websites to establish a session in the browser. >> If that feature existed you would cut down on a lot of the complexity of >> things like OpenID and OAuth. > > Again, agreed. ;-) > > for the record, I don't think that OAuth itself is a suitable > replacement for HTTP authorisation, but wanted to stir the pot, > especially away from overwrought technical solutions that don't > actually solve anyone's needs. Towards ones that are ripe for phishing and have no privacy protections? I don't believe that's a good direction. From marsh@extendedsubset.com Sat Jan 8 13:31:00 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D5A3A683E; Sat, 8 Jan 2011 13:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 X4bPP+UTK2H0; Sat, 8 Jan 2011 13:30:58 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 493D93A683C; Sat, 8 Jan 2011 13:30:58 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PbgPH-000IjG-DU; Sat, 08 Jan 2011 21:33:03 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id BB8EB603D; Sat, 8 Jan 2011 21:33:00 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/yNdr6BhRuIy23ofn2b5a1o+UJfu2Keao= Message-ID: <4D28D80B.2020006@extendedsubset.com> Date: Sat, 08 Jan 2011 15:32:59 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 09 Jan 2011 09:40:17 -0800 Cc: "apps-discuss@ietf.org" , "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Ben Laurie , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [http-auth] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 21:31:00 -0000 On 01/08/2011 10:07 AM, Phillip Hallam-Baker wrote: > I think that Ben is right that we are solving the wrong problem. I think Ben is nearly always right. :-) But let me toss out a different perspective. I'll try carefully and hope that this doesn't come across as trolling, but it is a bit contrarian (hopefully in a good way). > The problem is that users are asked to maintain accounts at literally > HUNDREDS of accounts. > > And some cretins, some utter morons, some bog-brained berks think it is > reasonable to tell the user to have a different password for every one! Such users have asked to do business with hundreds of entities, so at least something is working right. The user is free to use the same password everywhere (more convenient), or use a different password at every site (more secure). Many users like to set up "domains of password re-use" among several like-sites. The user is free to decide the point on the trade-off that works for them. I use a different password for everything. I write them down on blank business cards and keep them physically secure. I have taught some small children to use this scheme and they have no trouble with it. Most web browsers and sites remember the passwords anyway so the paper is really just backup. > I can't remember the account names, the password is easy as I only had > one (for non financial) - until those cretins at Gawker screwed up. Now > I have to reset my password at all those places. So you had decided on a coarse-grained scheme: financial and non-financial. Seems reasonable on the surface. Say you have a dozen sites across which you share a password. These sites are really secure - let's estimate the probability that each one will be breached or compromised or you will accidentally login unencrypted from a public internet location is only 1 in 10 per year. Hey a 90% success rate isn't bad, right? But the probability that they will all succeed is 0.9^12 = 28% over a year. Expect to be changing that password every few months. In the case of "HUNDREDS of accounts", 0.9^200 = 0.000000001. Well, those of the sort of odds you're supposed to serve the attacker, not yourself. > We have to solve the federated auth problem and it is really, really easy: No, it borders on the impossible. > Account Name is the RFC 821/822 email address. > > This is what the Web has started to adopt of its own accord as a > user account identifier. It is the only one that people can remember > reliably. Which is why everyone just has one email address? Come on, most people have several. And often they do so for a reason, it's not just that people get new ISPs or switch for new features all the time. I train my kids to lie about their names and ages when they do stuff online. They don't have emails. You don't have a personal email and a work email at least? > Authentication service is resolved via DNS service lookup > i.e. SRV or similar. I can show people how to fix up the issues to > do with use of non-canonical names. [skipping a bunch of technical stuff] > I know that you can achieve some of the desired authentication > properties with public keys at the client. The problem is that our > current use of computers has gone way beyond the one-machine-per-person > paradigm > On a recent trip to Europe with the family I counted that we had 10 > computers with us capable of supporting IP (3 laptops, 3 iPhones, 2 > Nintendos, 1 iPad and a kindle). It was only a brief period in the history of computing that might have ever been true anyway. Before networks "user identity" hardly mattered. Immediately after networks, we got heterogeneous networks. As soon as heterogeneous networks arrived, we got single sign-on. I think the deeper problem today is that most people looking at the issue are coming from the service provider side. Their job is made greatly simpler if they can assume 1 user = 1 person = 1 email etc. So they make this assumption as much as they can get away with it. But the reality is that people don't work that way. Historically, people have had multiple identities and they presented themselves differently to different parties. This is intentional and it's not duplicitous, its part of normal social interaction. When you discuss business matters at work you give out a business card with a business phone number and address on it. When you meet people at church or school, you give people your home phone. Your home phone and address were the ones printed in the directory. So the fact that "a person" has more than one "device" is not the big problem (that's actually sometimes a desperate solution from the perspective of the user). The problem for the service provider is that they don't want to give up the simplifying assumption (and the behavioral tracking it enables) that a real person represents an atomic unit of identity. Aside from the brittleness of their security, this is one reason why centralized identity, top-down federated authentication and single-sign-on schemes are not a good plan for the web. They don't accurately model the problem domain. These schemes originated for use in corporate and university settings which, at the end of the day, have all of the protected resources owned by a single party. The universal ritual for everyone's first day at a new job is the granting of a new username, password, and email identity for use in that specific context. So single sign-on was designed so that one person could be granted access to, say, the file server, email, printer, and maybe the phone system, all within the restricted context of their "employee-ness" at one specific company. Even though multiple systems are involved, it's still fundamentally a one-to-one relationship between two identities, the person-as-employee and the company-as-employer. This doesn't map to the web with multiple persons each needing to control the mapping of their own multiple identities to multiple corporations. I don't want to pull out my US State Department-issued passport in order to leave a comment on some random blog or log into an online game. I don't want to use any of my gmail addresses for that either. Bad things happen when you force-fit the wrong model on to the design. Security and privacy are always the first to go. (Somewhere I saw the other day somebody seriously proposing using Facebook as a centralized identity authority.) More subtly, people find the system harder to use, and overall they just don't like it or trust it as much. People won't use it, or they'll use it and not like it, or they won't use it as much, or they'll figure out a way to defeat it. > Cardspace has some really, really great properties but they are totally > lost when you try to make the service accessible from multiple machines > by putting it 'in the cloud'. In fact, other than a manager, I have > never found anyone who reven thinks they know what they mean by 'in the > cloud' for CardSpace. I certainly have never seen an explanation I can > understand. Cloud is largely an experiment in making unwarranted assumptions about identity in the other direction: between the corporation and their devices. > Devices get lost. Devices get stolen. My impression is that lost and stolen devices are significant, but they're by far not the biggest security issue on the web. > We don't want to encourage that so > there needs to be something more than just a certificate based client > auth scheme. > > I think we need some form of centralized (for given account) account > management in the mix so that the user can authorize/deauthorize devices > for use (c.f. Amazon's Kindle account management) You're not going to create everybody's favorite web authentication infrastructure if it has the goal of controlling people use of their own devices. > So there are basically two architectural options for using public key. > One is to use it strictly between the client and the auth service and > use a token like approach as discussed above. Another is for the auth > service to issue an assertion of the form 'you can tell its fred by this > public key (amongst others)'. > SAML already has support for both approaches BTW. Forget the wants of corporations and websites, they exist only because of their customers and users who outnumber them a millionfold. Forget mechanisms for now, those are simple engineering once the problem is stated correctly. What do people want to do? What would they want to do if they knew to ask for it? How can we help them do it in the most secure way possible? How can we give people the tools to manage their own identities and make their own security-convenience trade-offs in the most informed way? Regards, - Marsh From romeda@gmail.com Sat Jan 8 17:27:45 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878EC28C157; Sat, 8 Jan 2011 17:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.349 X-Spam-Level: X-Spam-Status: No, score=-104.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 1CHuczRPWZBj; Sat, 8 Jan 2011 17:27:43 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 716E728C0D8; Sat, 8 Jan 2011 17:27:42 -0800 (PST) Received: by wwa36 with SMTP id 36so18596520wwa.13 for ; Sat, 08 Jan 2011 17:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=afxLGSrBPz4bvHwp6VG7sozjob/7t1YO0xeVPH7/4wU=; b=LAQdyT9SddL8nJPhVQM29j6ZoZWBU/E9RdL3dcQirexwAxBPozXDZ7R8vOxplF5rDX pFjcIvOVsoXraVaAoigoriOzby1Vb5bpOibBUZFxefgem0XrfG3Rn9ZgZZb3HPJCgqNi R8mjqJHHWIO0driOK5UwZbhB8m9IcGUiv4KRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=W00D/vRaeMJ9JFN6mWMx9sDgFjHR+OAwMhDTnEtxnjcdIaIr5rkVlZ7DByNvMeDYzG 5/zSOQnpfLw3pRace51aLC/URn3bISpnzt4Im8calKLP9JFUc4/cInuXHJkc/AsqHLnA Cp3q0SjBiSJ/ix2U6AtTOIZ27Ltj1Pjqyu1Q0= Received: by 10.216.142.101 with SMTP id h79mr26233429wej.49.1294536590896; Sat, 08 Jan 2011 17:29:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.240.197 with HTTP; Sat, 8 Jan 2011 17:29:29 -0800 (PST) In-Reply-To: <20110108194952.GS12542@zedshaw> References: <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <20110108194952.GS12542@zedshaw> From: Blaine Cook Date: Sat, 8 Jan 2011 17:29:29 -0800 Message-ID: To: "Zed A. Shaw" , Blaine Cook , Phillip Hallam-Baker , Ben Laurie , "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 09 Jan 2011 09:40:29 -0800 Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 01:27:45 -0000 On 8 January 2011 11:49, Zed A. Shaw wrote: > On Sat, Jan 08, 2011 at 09:37:00AM -0800, Blaine Cook wrote: > I don't normally respond, just being a lurker, but this statement is > competely wrong Blaine. =C2=A0OAuth may be used for more requests, but no= t > more sites. =C2=A0It's used on a tiny number of sites, with OpenID being = used > on way many more, and even then, not nowhere near the number of websites > that form based authentication and browser authentication methods. > > Don't equate twitter having a ton of traffic to OAuth being some kind of > raving success, and sure as hell don't evaluate the technical merits of > something by its popularity. Agreed - though, facebook is also using oauth-based (not 1.0, but essentially the same approach) logins, and there are a number of other sites that do provide oauth-based login infrastructure. Moreover, the nudge towards oauth is intended with the movement towards a new auth infrastructure in mind. We'd need some kind of discovery / negotiation mechanism on top to make it not the one-or-two-companies-own-the-web play that login-over-oauth is now. (c.f. OpenID Connect). b. > While I agree that TLS client side isn't going to work, none of the > proposed authentication methods will work without a change to browsers > to support a way for two websites to establish a session in the browser. > If that feature existed you would cut down on a lot of the complexity of > things like OpenID and OAuth. Again, agreed. ;-) for the record, I don't think that OAuth itself is a suitable replacement for HTTP authorisation, but wanted to stir the pot, especially away from overwrought technical solutions that don't actually solve anyone's needs. b. From romeda@gmail.com Sun Jan 9 08:49:58 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D3E3A677E; Sun, 9 Jan 2011 08:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.682 X-Spam-Level: X-Spam-Status: No, score=-104.682 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 E-915Pk+xrKV; Sun, 9 Jan 2011 08:49:57 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 806623A6816; Sun, 9 Jan 2011 08:49:56 -0800 (PST) Received: by wyf23 with SMTP id 23so19771279wyf.31 for ; Sun, 09 Jan 2011 08:52:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=WIm+nFsAde/ye4Tom3yY4aVsYWqIxOmEG0wpwlytdzI=; b=Clwy4B80sy6LoL3fprCaKqTJWjn5jUnpqvWX13saEtPhxSf5b7x8DxNHBQSjcDcjCd lfcG5pVl93HS5iW0GIedlgBOnavigJXk4i2/IydnDkOElogTRR0AhkBJJLExNslRhjcb 3VhXaddZVP6P01QaxCJX/3QLZLRMHhtPUbNbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=SCyIoxVnZRbGdpwm6boOG67l5B48h3JNw3U4Qv7Uwv2Fgk2Zdex0rweQm3owUIDeF7 p6Z+OnAy9Cb1o11hDx+iBjjsxaDOGtwHOfDokx3hRjYxfdoNN0LQ+E37lyu16j3Dhpyk refSLACQIk5R32y/JZB1jn0f41uSaOrFKq+z4= Received: by 10.216.177.9 with SMTP id c9mr26823431wem.34.1294591283468; Sun, 09 Jan 2011 08:41:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.240.197 with HTTP; Sun, 9 Jan 2011 08:40:54 -0800 (PST) In-Reply-To: References: <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <20110108194952.GS12542@zedshaw> From: Blaine Cook Date: Sun, 9 Jan 2011 08:40:54 -0800 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sun, 09 Jan 2011 09:40:38 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "Zed A. Shaw" , "http-auth@ietf.org" , "saag@ietf.org" , Phillip Hallam-Baker , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 16:49:58 -0000 > Towards ones that are ripe for phishing and have no privacy > protections? I don't believe that's a good direction. *shrug* If the alternative is Facebook handling everyone's logins, it can't get much worse, can it? b. From stpeter@stpeter.im Sun Jan 9 12:03:57 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05AA3A682F for ; Sun, 9 Jan 2011 12:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 OgnPhyBQCrrL for ; Sun, 9 Jan 2011 12:03:56 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AC73C3A6811 for ; Sun, 9 Jan 2011 12:03:56 -0800 (PST) Received: from squire.local (dsl-251-175.dynamic-dsl.frii.net [216.17.251.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BBF10400EE for ; Sun, 9 Jan 2011 13:20:51 -0700 (MST) Message-ID: <4D2A152C.8010305@stpeter.im> Date: Sun, 09 Jan 2011 13:06:04 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000009020204080702030709" Subject: [apps-discuss] http authentication thread X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:03:57 -0000 This is a cryptographically signed message in MIME format. --------------ms000009020204080702030709 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, please reply to the http authentication thread only on the http-auth@ietf.org list. As one of the admins for the apps-discuss list, I have started to discard messages that cc this list (e.g., if there are too many recipients or a non-subscriber posts to this list). Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000009020204080702030709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEw OTIwMDYwNFowIwYJKoZIhvcNAQkEMRYEFNryh9TBy4Ee3++MntgfvkgPAEJnMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCER3mJLxYWbPWqb1cyN7NwydUW9DiBRgaHY8DtBnFAJbv7xoSOI3a6TpW/ 6xin32x1SWrk30caFPVCiIsm2S9U5Lxu4GEEztwypsy/PxeRFmdGmXXFvB+qgRTOLFv+szlr 7ES1P7njElGPt6ZEgH7JfHAwHE7ZBIeu0aedROtoa2AjleaAdupxj9rMnpQ8+wP3mSAJOvpi tXaLz+LyHT5iNxfKURJfqVlZAFFFLUxMhqJyKyhSku6qKnVC67/MKi0/IO2yNmASfaxrwsov 8eAvhlu6UjD33pw1clAs+Ln2sseu62023MMjOFCrLU2Uia+ZNu28yFd4qr7tcuEi64uvAAAA AAAA --------------ms000009020204080702030709-- From john-ietf@jck.com Sun Jan 9 12:46:44 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45F628C0CE for ; Sun, 9 Jan 2011 12:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.242 X-Spam-Level: X-Spam-Status: No, score=-103.242 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ec169boLHe3K for ; Sun, 9 Jan 2011 12:46:43 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id E38413A6845 for ; Sun, 9 Jan 2011 12:46:37 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pc2Bb-000AZr-7X; Sun, 09 Jan 2011 15:48:26 -0500 Date: Sun, 09 Jan 2011 15:47:58 -0500 From: John C Klensin To: Peter Saint-Andre , Alexey Melnikov Message-ID: <29C75A778465CFAE8FF258FF@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========8B582E745D82C14AEE2F==========" Cc: apps-discuss@ietf.org Subject: [apps-discuss] Which thread would you like this discussion on (was: http authentication thread) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:46:45 -0000 --==========8B582E745D82C14AEE2F========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Area Directors, Someone brought this to the Apps-Discuss list. I can only assure you that it wasn't me. If you want discussions on http-auth, websec, kitten --or any of a variety of other lists to which I (and I suspect many others who want to follow apps-discuss) have no time to subscribe-- then please ask people to take/keep the discussion off of apps-discuss so that those of us who are trying only to take a broad applications view can claim ignorance (and, if appropriate, WGs with an excessively narrow focus) when a specific proposal comes up on IETF Last Call. Otherwise, if the topic is going to be cross-posted and cross-discussed on multiple lists, those who are moderating those lists should be prepared to accept traffic that arose as a consequence of posting to the others. One or the other. thanks, john ---------- Forwarded Message ---------- Date: Sunday, January 09, 2011 13:06 -0700 From: Peter Saint-Andre To: apps-discuss@ietf.org Subject: [apps-discuss] http authentication thread Folks, please reply to the http authentication thread only on the http-auth@ietf.org list. As one of the admins for the apps-discuss list, I have started to discard messages that cc this list (e.g., if there are too many recipients or a non-subscriber posts to this list). ---------- End Forwarded Message ---------- ---------- Forwarded Message ---------- Date: Sunday, January 09, 2011 20:02 +0000 From: Tobias Gondrom To: john-ietf@jck.com Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation I notice that you posted replies on this subject to the websec mailing-list. As all IETF WG mailing-lists this is a members-only list. I will approve your post this time. If you in the future wish to send emails again to this list, please subscribe/join: https://www.ietf.org/mailman/listinfo/websec Otherwise, I will assume you cc'ed websec in error and discard your emails in the future (as long as you are not a member). Thanks and kind regards, Tobias (chair of websec) ---------- End Forwarded Message ---------- --==========8B582E745D82C14AEE2F========== Content-Type: message/rfc822; name="[apps-discuss] http authentication thread" Return-path: Envelope-to: john-ietf@jck.com Delivery-date: Sun, 09 Jan 2011 15:06:23 -0500 Received: from [64.170.98.32] (helo=mail.ietf.org) by bs.jck.com with esmtp (Exim 4.34) id 1Pc1Wr-000AJe-Tc for john-ietf@jck.com; Sun, 09 Jan 2011 15:06:23 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5898C3A6844; Sun, 9 Jan 2011 12:03:58 -0800 (PST) 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 A05AA3A682F for ; Sun, 9 Jan 2011 12:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 OgnPhyBQCrrL for ; Sun, 9 Jan 2011 12:03:56 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AC73C3A6811 for ; Sun, 9 Jan 2011 12:03:56 -0800 (PST) Received: from squire.local (dsl-251-175.dynamic-dsl.frii.net [216.17.251.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BBF10400EE for ; Sun, 9 Jan 2011 13:20:51 -0700 (MST) Message-ID: <4D2A152C.8010305@stpeter.im> Date: Sun, 09 Jan 2011 13:06:04 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Subject: [apps-discuss] http authentication thread X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0009829623==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0009829623== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000009020204080702030709" This is a cryptographically signed message in MIME format. --------------ms000009020204080702030709 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, please reply to the http authentication thread only on the http-auth@ietf.org list. As one of the admins for the apps-discuss list, I have started to discard messages that cc this list (e.g., if there are too many recipients or a non-subscriber posts to this list). Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000009020204080702030709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEw OTIwMDYwNFowIwYJKoZIhvcNAQkEMRYEFNryh9TBy4Ee3++MntgfvkgPAEJnMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCER3mJLxYWbPWqb1cyN7NwydUW9DiBRgaHY8DtBnFAJbv7xoSOI3a6TpW/ 6xin32x1SWrk30caFPVCiIsm2S9U5Lxu4GEEztwypsy/PxeRFmdGmXXFvB+qgRTOLFv+szlr 7ES1P7njElGPt6ZEgH7JfHAwHE7ZBIeu0aedROtoa2AjleaAdupxj9rMnpQ8+wP3mSAJOvpi tXaLz+LyHT5iNxfKURJfqVlZAFFFLUxMhqJyKyhSku6qKnVC67/MKi0/IO2yNmASfaxrwsov 8eAvhlu6UjD33pw1clAs+Ln2sseu62023MMjOFCrLU2Uia+ZNu28yFd4qr7tcuEi64uvAAAA AAAA --------------ms000009020204080702030709-- --===============0009829623== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============0009829623==-- --==========8B582E745D82C14AEE2F==========-- From msk@cloudmark.com Mon Jan 10 11:55:32 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 659F628C115 for ; Mon, 10 Jan 2011 11:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.43 X-Spam-Level: X-Spam-Status: No, score=-103.43 tagged_above=-999 required=5 tests=[AWL=-0.832, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 e7DeUOHnQFCh for ; Mon, 10 Jan 2011 11:55:29 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 217BE3A6946 for ; Mon, 10 Jan 2011 11:55:29 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 10 Jan 2011 11:57:43 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Mon, 10 Jan 2011 11:57:42 -0800 Thread-Topic: An XML RFC primer? Thread-Index: AcuxAKQkAEttCaEBTeGMHJ6biz6+Mw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F1341E73D79EXCHC2corpclo_" MIME-Version: 1.0 Subject: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:55:32 -0000 --_000_F5833273385BB34F99288B3648C4F06F1341E73D79EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I've got a project on the go that will result in a few different I-Ds for c= onsideration, one of which contains a specification for a new XML-based rep= orting format. Can someone suggest some RFCs that have done a good job of = the same sort of thing in the past that I could use as a template for such = work, or a BCP or similar? Thanks, -MSK --_000_F5833273385BB34F99288B3648C4F06F1341E73D79EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I’ve got a project on the go that will result in= a few different I-Ds for consideration, one of which contains a specification for= a new XML-based reporting format.  Can someone suggest some RFCs that have d= one a good job of the same sort of thing in the past that I could use as a templa= te for such work, or a BCP or similar?

 

Thanks,

-MSK

--_000_F5833273385BB34F99288B3648C4F06F1341E73D79EXCHC2corpclo_-- From tbray@textuality.com Mon Jan 10 12:21:28 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3BEB28C0F9 for ; Mon, 10 Jan 2011 12:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 9g0kdlW5jGx3 for ; Mon, 10 Jan 2011 12:21:28 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id ADD1628C105 for ; Mon, 10 Jan 2011 12:21:27 -0800 (PST) Received: by bwz12 with SMTP id 12so19440939bwz.31 for ; Mon, 10 Jan 2011 12:23:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.74.143 with SMTP id u15mr2854092faj.27.1294691021497; Mon, 10 Jan 2011 12:23:41 -0800 (PST) Received: by 10.223.126.212 with HTTP; Mon, 10 Jan 2011 12:23:41 -0800 (PST) X-Originating-IP: [216.239.45.130] In-Reply-To: References: Date: Mon, 10 Jan 2011 12:23:41 -0800 Message-ID: From: Tim Bray To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:21:28 -0000 RFC4287 (Atom) specifies a small XML language and has been quite well-received. Also see RFC3479 AKA BCP 70. -Tim On Mon, Jan 10, 2011 at 11:57 AM, Murray S. Kucherawy w= rote: > Hi all, > > > > I=92ve got a project on the go that will result in a few different I-Ds f= or > consideration, one of which contains a specification for a new XML-based > reporting format.=A0 Can someone suggest some RFCs that have done a good = job > of the same sort of thing in the past that I could use as a template for > such work, or a BCP or similar? > > > > Thanks, > > -MSK > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From anthonybryan@gmail.com Mon Jan 10 15:41:17 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A8A23A67D1 for ; Mon, 10 Jan 2011 15:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[AWL=0.329, 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 4K+q7jJ-MwaU for ; Mon, 10 Jan 2011 15:41:16 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 081043A67B2 for ; Mon, 10 Jan 2011 15:41:15 -0800 (PST) Received: by ewy8 with SMTP id 8so9247206ewy.31 for ; Mon, 10 Jan 2011 15:43:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=57M0z/b8l06EB0phGhrHHkZfnrqgX1+PCMxVL4YcLhI=; b=Ln5eBd7Asms2DEt5jQsYpxHWvd/2JyOUWBs2wjDg9MsVe/2+IpFiQGjAUgHWE/JNZS 1UPufmY8SatBHvDsALgn/v63eDEbPD3aIypHJCfI96p4DNvlGUhgmEychhgh4WYwzQy5 wuhE9jQIPUtsaiqLa2rAcVwRa7ZFUxzBaciW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=N5pOjA3G5jCz5XqTYQ+Qe44XB2GJm+OigTGruerPbSlPQ+CRs3/HarREXxvVZrMDT8 rEBHm4ZNFHmA9S4sCcbqQuCqZfV9pg0wcyQ/81uz8S2bDn8Rj2wmqsJ/bT/AvXYT6sYn QZjiIybyvANKZ49U5eqHNSjnymJXefj6xh7AU= MIME-Version: 1.0 Received: by 10.213.9.131 with SMTP id l3mr5302271ebl.37.1294703010393; Mon, 10 Jan 2011 15:43:30 -0800 (PST) Received: by 10.213.9.208 with HTTP; Mon, 10 Jan 2011 15:43:30 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Jan 2011 18:43:30 -0500 Message-ID: From: Anthony Bryan To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:41:17 -0000 On Mon, Jan 10, 2011 at 2:57 PM, Murray S. Kucherawy wr= ote: > Hi all, > > > > I=92ve got a project on the go that will result in a few different I-Ds f= or > consideration, one of which contains a specification for a new XML-based > reporting format.=A0 Can someone suggest some RFCs that have done a good = job > of the same sort of thing in the past that I could use as a template for > such work, or a BCP or similar? there's also the slightly newer Metalink, RFC 5854, based heavily off of At= om. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From duerst@it.aoyama.ac.jp Mon Jan 10 16:31:40 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC083A67B1 for ; Mon, 10 Jan 2011 16:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.37 X-Spam-Level: X-Spam-Status: No, score=-100.37 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UP0+aaLJaJNT for ; Mon, 10 Jan 2011 16:31:40 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id C1AF73A67E9 for ; Mon, 10 Jan 2011 16:31:39 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p0B0XnIx001403 for ; Tue, 11 Jan 2011 09:33:49 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 740f_4802_752c0e96_1d1a_11e0_8d8b_001d096c5782; Tue, 11 Jan 2011 09:33:49 +0900 Received: from [IPv6:::1] ([133.2.210.1]:41169) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 11 Jan 2011 09:33:49 +0900 Message-ID: <4D2BA56C.2030102@it.aoyama.ac.jp> Date: Tue, 11 Jan 2011 09:33:48 +0900 From: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:31:41 -0000 On 2011/01/11 5:23, Tim Bray wrote: > RFC4287 (Atom) specifies a small XML language and has been quite > well-received. Yes. But please note that some special requirements on namespace declarations are highly non-standard and not recemmended for imitation. > Also see RFC3479 AKA BCP 70. -Tim That one is indeed very well worth reading. Regards, Martin. > On Mon, Jan 10, 2011 at 11:57 AM, Murray S. Kucherawy wrote: >> Hi all, >> >> >> >> I’ve got a project on the go that will result in a few different I-Ds for >> consideration, one of which contains a specification for a new XML-based >> reporting format. Can someone suggest some RFCs that have done a good job >> of the same sort of thing in the past that I could use as a template for >> such work, or a BCP or similar? >> >> >> >> Thanks, >> >> -MSK >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From tbray@textuality.com Mon Jan 10 16:36:24 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883993A6812 for ; Mon, 10 Jan 2011 16:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 K+LKcrQVI9p6 for ; Mon, 10 Jan 2011 16:36:22 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id CB09B3A67B1 for ; Mon, 10 Jan 2011 16:36:21 -0800 (PST) Received: by fxm9 with SMTP id 9so19757520fxm.31 for ; Mon, 10 Jan 2011 16:38:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.79.6 with SMTP id n6mr395794fak.122.1294706316319; Mon, 10 Jan 2011 16:38:36 -0800 (PST) Received: by 10.223.126.212 with HTTP; Mon, 10 Jan 2011 16:38:36 -0800 (PST) X-Originating-IP: [216.239.45.130] In-Reply-To: <4D2BA56C.2030102@it.aoyama.ac.jp> References: <4D2BA56C.2030102@it.aoyama.ac.jp> Date: Mon, 10 Jan 2011 16:38:36 -0800 Message-ID: From: Tim Bray To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:36:24 -0000 What are the non-standard namespace practices in 4287? -Tim On Mon, Jan 10, 2011 at 4:33 PM, "Martin J. D=FCrst" wrote: > On 2011/01/11 5:23, Tim Bray wrote: >> >> RFC4287 (Atom) specifies a small XML language and has been quite >> well-received. > > Yes. But please note that some special requirements on namespace > declarations are highly non-standard and not recemmended for imitation. > >> Also see RFC3479 AKA BCP 70. =A0-Tim > > That one is indeed very well worth reading. > > Regards, =A0 =A0Martin. > >> On Mon, Jan 10, 2011 at 11:57 AM, Murray S. Kucherawy >> =A0wrote: >>> >>> Hi all, >>> >>> >>> >>> I=92ve got a project on the go that will result in a few different I-Ds= for >>> consideration, one of which contains a specification for a new XML-base= d >>> reporting format. =A0Can someone suggest some RFCs that have done a goo= d >>> job >>> of the same sort of thing in the past that I could use as a template fo= r >>> such work, or a BCP or similar? >>> >>> >>> >>> Thanks, >>> >>> -MSK >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> > > -- > #-# Martin J. D=FCrst, Professor, Aoyama Gakuin University > #-# http://www.sw.it.aoyama.ac.jp =A0 mailto:duerst@it.aoyama.ac.jp > From duerst@it.aoyama.ac.jp Mon Jan 10 17:17:21 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC9CE3A6888 for ; Mon, 10 Jan 2011 17:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.344 X-Spam-Level: X-Spam-Status: No, score=-100.344 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxS86AclW3Dz for ; Mon, 10 Jan 2011 17:17:20 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by core3.amsl.com (Postfix) with ESMTP id 95C713A6886 for ; Mon, 10 Jan 2011 17:17:19 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p0B1JTLK026384 for ; Tue, 11 Jan 2011 10:19:30 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 740f_5fbc_d65272f4_1d20_11e0_8d8b_001d096c5782; Tue, 11 Jan 2011 10:19:29 +0900 Received: from [IPv6:::1] ([133.2.210.1]:46163) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 11 Jan 2011 10:19:29 +0900 Message-ID: <4D2BB020.6050802@it.aoyama.ac.jp> Date: Tue, 11 Jan 2011 10:19:28 +0900 From: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: <4D2BA56C.2030102@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 01:17:21 -0000 For a very long time during the discussions in the Atom WG, there was a requirement to put the namespace declaration for the HTML namespace on the div element that encloses XHTML content. Going back now to the spec, I see that that requirement/wart is gone (see http://tools.ietf.org/html/rfc4287#section-3.1.1.3). Congratulations to whomever got the WG to get away from this (was that you?). I herewith gladly retract my concern re. Atom. It's good to learn that things are better than one has thought, even if it takes a long time. Regards, Martin. On 2011/01/11 9:38, Tim Bray wrote: > What are the non-standard namespace practices in 4287? -Tim > > On Mon, Jan 10, 2011 at 4:33 PM, "Martin J. Dürst" > wrote: >> On 2011/01/11 5:23, Tim Bray wrote: >>> >>> RFC4287 (Atom) specifies a small XML language and has been quite >>> well-received. >> >> Yes. But please note that some special requirements on namespace >> declarations are highly non-standard and not recemmended for imitation. >> >>> Also see RFC3479 AKA BCP 70. -Tim >> >> That one is indeed very well worth reading. >> >> Regards, Martin. >> >>> On Mon, Jan 10, 2011 at 11:57 AM, Murray S. Kucherawy >>> wrote: >>>> >>>> Hi all, >>>> >>>> >>>> >>>> I’ve got a project on the go that will result in a few different I-Ds for >>>> consideration, one of which contains a specification for a new XML-based >>>> reporting format. Can someone suggest some RFCs that have done a good >>>> job >>>> of the same sort of thing in the past that I could use as a template for >>>> such work, or a BCP or similar? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> -MSK >>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>> >>>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> >> >> -- >> #-# Martin J. Dürst, Professor, Aoyama Gakuin University >> #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp >> > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From fanf2@hermes.cam.ac.uk Tue Jan 11 03:25:36 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6B2D28C100 for ; Tue, 11 Jan 2011 03:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, UPPERCASE_50_75=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 Y+WVUhv-hNdl for ; Tue, 11 Jan 2011 03:25:35 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id 8E4583A6967 for ; Tue, 11 Jan 2011 03:25:35 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:38790) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1PccOE-0001Ic-XF (Exim 4.72) (return-path ); Tue, 11 Jan 2011 11:27:50 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1PccOE-0003Zc-9W (Exim 4.67) (return-path ); Tue, 11 Jan 2011 11:27:50 +0000 Date: Tue, 11 Jan 2011 11:27:50 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Tim Bray In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 11:25:36 -0000 On Mon, 10 Jan 2011, Tim Bray wrote: > Also see RFC3479 AKA BCP 70. I think you mean RFC 3470. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From tbray@textuality.com Tue Jan 11 07:26:41 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D0F3A6833 for ; Tue, 11 Jan 2011 07:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UPPERCASE_50_75=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 PhIfwwFznVLq for ; Tue, 11 Jan 2011 07:26:40 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id EB47F3A67A8 for ; Tue, 11 Jan 2011 07:26:39 -0800 (PST) Received: by ewy8 with SMTP id 8so9525588ewy.31 for ; Tue, 11 Jan 2011 07:28:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.72.197 with SMTP id n5mr5310082faj.8.1294759733835; Tue, 11 Jan 2011 07:28:53 -0800 (PST) Received: by 10.223.126.212 with HTTP; Tue, 11 Jan 2011 07:28:53 -0800 (PST) X-Originating-IP: [216.113.201.123] Received: by 10.223.126.212 with HTTP; Tue, 11 Jan 2011 07:28:53 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Jan 2011 07:28:53 -0800 Message-ID: From: Tim Bray To: Tony Finch Content-Type: multipart/alternative; boundary=20cf3054a4f90137d1049993be43 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 15:26:41 -0000 --20cf3054a4f90137d1049993be43 Content-Type: text/plain; charset=ISO-8859-1 Oops yep good catch. -Tim On Jan 11, 2011 3:27 AM, "Tony Finch" wrote: On Mon, 10 Jan 2011, Tim Bray wrote: > Also see RFC3479 AKA BCP 70. I think you mean RFC 3470. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. --20cf3054a4f90137d1049993be43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Oops yep good catch.
-Tim

On Jan 11, 2011 3:27 AM, "Tony Finch"= ; <dot@dotat.at> wrote:

On Mon, 10 Jan 2011, Tim Bray w= rote:

> Also see RFC3479 AKA BCP 70.

I think you mean RFC 34= 70.

Tony.
--
f.anthony.n.finch =A0<dot@dotat.at&g= t; =A0http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7= ,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.

--20cf3054a4f90137d1049993be43-- From adam@nostrum.com Mon Jan 10 16:43:46 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552003A67ED; Mon, 10 Jan 2011 16:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 rxHCiWBqyk8K; Mon, 10 Jan 2011 16:43:45 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 084B63A6825; Mon, 10 Jan 2011 16:43:44 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0B0jvW9019554 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 10 Jan 2011 18:45:57 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D2BA844.1070801@nostrum.com> Date: Mon, 10 Jan 2011 18:45:56 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 11 Jan 2011 08:09:42 -0800 Cc: Bernard Aboba , Spencer Dawkins , Apps Discuss , IESG Subject: Re: [apps-discuss] Apps Area Review team review: draft-ietf-martini-gin-10.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:43:46 -0000 Ted: Thank you for your detailed review. I have applied your comments to version -11 of the document (now available in the repository), except as noted below. On 11/30/10 4:11 PM, Ted Hardie wrote: > Section 7.4 contains two elements which it may be appropriate to consider > for inclusion in the Security Considerations. The first of these is that > proxies will not be able to apply policy decisions on as granular a basis as > before: > > Proxies will be unable to make policy decisions on a > contact-by-contact basis regarding whether to include themselves in > the path. Second, and similarly, all AORs on the SIP-PBX that are > registered with a common REGISTER request will be forced to share a > common Service-Route. I tried to reiterate this issue in the security section with the following paragraph: As noted in Section 7.4, intermediaries need to take care if they use a policy token in the Path and Service-Route mechanisms, as doing so will cause them to apply the same policy to all users serviced by the same SIP-PBX. This may frequently be the correct behavior, but circumstances can arise in which differentiation of user policy is required. This text was in the version you reviewed. Do you think it needs to be amended in some way to capture the issue you highlight above, or does this text address your concern? > Would this extend to proxies including themselves for the purposes of > CALEA? If so, this might be a privacy issue. Proxies can't use Path to insert themselves for LI purposes, as doing so would be inherently visible to user agents (which could potentially alert users to the condition). In my experience, LI in SIP is performed via mechanisms that are unrelated to any of the mechanisms described in this document. /a From gonzalo.camarillo@ericsson.com Mon Jan 10 23:48:14 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00383A69ED for ; Mon, 10 Jan 2011 23:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.12 X-Spam-Level: X-Spam-Status: No, score=-105.12 tagged_above=-999 required=5 tests=[AWL=-1.521, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 iMLjprr4BJ0C for ; Mon, 10 Jan 2011 23:48:14 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id BD8A23A69E8 for ; Mon, 10 Jan 2011 23:48:13 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-cd-4d2c0bc4e433 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E4.9D.23694.4CB0C2D4; Tue, 11 Jan 2011 08:50:28 +0100 (CET) Received: from [131.160.126.193] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Tue, 11 Jan 2011 08:50:28 +0100 Message-ID: <4D2C0BC2.7050002@ericsson.com> Date: Tue, 11 Jan 2011 09:50:26 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Kurt.Zeilenga@Isode.com References: <4BF3DB9C-02D5-4778-9D30-694F8DB74A8D@estacado.net> <1B9BC3F1-3FA4-4FAF-BD32-2FE8417840FD@estacado.net> In-Reply-To: <1B9BC3F1-3FA4-4FAF-BD32-2FE8417840FD@estacado.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Tue, 11 Jan 2011 08:09:49 -0800 Cc: Adam Roach , apps-discuss@ietf.org, draft-ietf-sipcore-sec-flows@tools.ietf.org, Brian Hibbard Subject: Re: [apps-discuss] Apps-team review: draft-ietf-sipcore-sec-flows X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 07:48:15 -0000 Hi Kurt, could you please have a look at Brian's explanation below and let us know whether or not you are happy with it? Thanks, Gonzalo >> *From: *Brian Hibbard > >> *Date: *January 6, 2011 10:35:07 AM CST >> *To: *Kurt Zeilenga > > >> *Cc: *Alexey Melnikov > >, >> draft-ietf-sipcore-sec-flows@tools.ietf.org >> , >> apps-discuss@ietf.org >> *Subject: **Re: Apps-team review: draft-ietf-sipcore-sec-flows * >> >> Hello Kurt, >> >> Thank you for your input. The inconsistencies in presentation of DN >> that you're talking about are the actual results of the dumps of the >> OpenSSL "x509" certificate tool. The use of the tool in this context >> is only to examine the content of the certificates for learning and >> testing purposes, and in the draft, to show what designers and >> testers would see in their environments. It is only because those >> are the actual results from the tool most likely to be used by readers >> of this document, that we are partial to leaving the dumps as they are. >> >> With that said, if you remain convinced that consistency of >> presentation is the more important factor here, I will go and make >> changes to the x509 dumps. >> >> Regards, >> Brian >> >> On Dec 15, 2010, at 9:21 AM, Kurt Zeilenga wrote: >> >>> I have been selected as the Applications Area Review Team reviewer >>> for this draft (for background on apps-review, please >>> seehttp://www.apps.ietf.org/content/applications-area-review-team). >>> >>> Please resolve these comments along with any other Last Call comments >>> you may receive. Please wait for direction from your document >>> shepherd or AD before posting a new version of the draft. >>> >>> Document: draft-ietf-sipcore-sec-flows (rev-07 reviewed) >>> Title: Example call flows using Session Initiation Protocol (SIP) >>> security mechanisms >>> Reviewer: Kurt Zeilenga >>> Review Date: 12/15/2010 >>> IETF Last Call Date: [include if known] >>> IESG Telechat Date: 2011-01-20 >>> Summary: This draft is basically ready for publication as an >>> Informational RFC but has a few issues that should be fixed before >>> publication. >>> Major Issues: None. >>> Minor Issues: >>> >>> I see some inconsistencies in how Distinguished Names (DNs) are >>> presented in the RFC. >>> >>> For instance (from 2.1): >>> Issuer: C=US, ST=California, L=San Jose, O=sipit, >>> OU=Sipit Test Certificate Authority >>> >>> vs. (also from 2.1) >>> DirName:/C=US/ST=California/L=San Jose/O=sipit/ >>> OU=Sipit Test Certificate Authority >>> >>> The former kind of looks like the LDAP DN format but, if that's what >>> was intended, the RDNs appear in the incorrect order. Note that in >>> the LDAP DN format, the most specific element appears first (the >>> reverse of how they appear in the BER/DER encoding of a DN). Also, >>> there should be no spaces after the RDN separators (the commas). >>> >>> The latter appears to be DCE format. >>> >>> I would think it appropriate to use a single format for all DNs and, >>> if one chooses to use the LDAP DN format, that values ought to be >>> constructed per RFC 4514. I note that Appendix A of RFC 4514 >>> discusses presentation issues of Distinguished Names. >>> >>> Nits: The usual (many acronyms are not spelled out on first use, etc.) >> > From ted.ietf@gmail.com Tue Jan 11 09:52:40 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E99B3A6A75; Tue, 11 Jan 2011 09:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.193 X-Spam-Level: X-Spam-Status: No, score=-3.193 tagged_above=-999 required=5 tests=[AWL=0.406, 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 TyLuffr9oiOz; Tue, 11 Jan 2011 09:52:39 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 74CE828C2C3; Tue, 11 Jan 2011 09:52:39 -0800 (PST) Received: by qyk34 with SMTP id 34so2961959qyk.10 for ; Tue, 11 Jan 2011 09:54:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kpeASiYId5ByZX1vx64VkXB+jbDVhaUmHjLJYX6EkWM=; b=phYbpm2M+auVbj3Gu0Zv//eFncayOi/g2ipfMhph0B66YntwaFX9/gt3nTLoVnoYlk x1dF6ICO415rK4TZPUE5T1I396o5SeXYk2cIzpyBF4CuSGSdtFuWAwz1o6rD74PJy3zb Yi+LSId+aDw0naUiTppu0J/H8FFNCKeTqBk8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=O58+z1Zok17I0Y+KW9MFHZSlwsR4w3v4Ou48HYI3xgFmTb6PCZypkc4Ok2qJWsxkzJ R5oBO88w0iEkOJZCO3WCMxhjAh99Uu/B+s92xIS+9TznPbfP5OEjKnBeZGq7o1GQdair IOWyNyCsFcgsf0WXM1xl+oXs49yapuFYL1IKI= MIME-Version: 1.0 Received: by 10.229.96.132 with SMTP id h4mr26697609qcn.41.1294768496366; Tue, 11 Jan 2011 09:54:56 -0800 (PST) Received: by 10.229.230.138 with HTTP; Tue, 11 Jan 2011 09:54:56 -0800 (PST) In-Reply-To: <4D2BA844.1070801@nostrum.com> References: <4D2BA844.1070801@nostrum.com> Date: Tue, 11 Jan 2011 09:54:56 -0800 Message-ID: From: Ted Hardie To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bernard Aboba , Spencer Dawkins , Apps Discuss , IESG Subject: Re: [apps-discuss] Apps Area Review team review: draft-ietf-martini-gin-10.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 17:52:40 -0000 Hi Adam, Thanks for the response; some discussion in-line. On Mon, Jan 10, 2011 at 4:45 PM, Adam Roach wrote: > Ted: > > Thank you for your detailed review. I have applied your comments to versi= on > -11 of the document (now available in the repository), except as noted > below. > > On 11/30/10 4:11 PM, Ted Hardie wrote: >> >> Section 7.4 contains two elements which it may be appropriate to conside= r >> for inclusion in the Security Considerations. =A0The first of these is t= hat >> proxies will not be able to apply policy decisions on as granular a basi= s >> as >> before: >> >> =A0 =A0Proxies will be unable to make policy decisions on a >> =A0 =A0contact-by-contact basis regarding whether to include themselves = in >> =A0 =A0the path. =A0Second, and similarly, all AORs on the SIP-PBX that = are >> =A0 =A0registered with a common REGISTER request will be forced to share= a >> =A0 =A0common Service-Route. > > I tried to reiterate this issue in the security section with the followin= g > paragraph: > > =A0 As noted in Section 7.4, intermediaries need to take care if they use > =A0 a policy token in the Path and Service-Route mechanisms, as doing so > =A0 will cause them to apply the same policy to all users serviced by the > =A0 same SIP-PBX. =A0This may frequently be the correct behavior, but > =A0 circumstances can arise in which differentiation of user policy is > =A0 required. > The only difference I see is that the first calls out the Service-Route as common separately from the application of policy, where the second treats t= he application of a particular Service-Route as the application of a particular policy. You might choose to call it out separately again, but if you have considere= d it and feel the text is fine as it stands, I'm happy with that result. > This text was in the version you reviewed. Do you think it needs to be > amended in some way to capture the issue you highlight above, or does thi= s > text address your concern? > >> Would this extend to proxies including themselves for the purposes of >> CALEA? =A0If so, this might be a privacy issue. > > Proxies can't use Path to insert themselves for LI purposes, as doing so > would be inherently visible to user agents (which could potentially alert > users to the condition). In my experience, LI in SIP is performed via > mechanisms that are unrelated to any of the mechanisms described in this > document. > Thanks for clarifying that this method would not be used for that purpose; that resolves my concern here. regards, Ted > /a > From ietfc@btconnect.com Tue Jan 11 10:09:52 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE4F3A6A64 for ; Tue, 11 Jan 2011 10:09:52 -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 xwWfZ6KMNLIm for ; Tue, 11 Jan 2011 10:09:51 -0800 (PST) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by core3.amsl.com (Postfix) with ESMTP id 6BB1D3A6A62 for ; Tue, 11 Jan 2011 10:09:50 -0800 (PST) Received: from host217-44-202-158.range217-44.btcentralplus.com (HELO pc6) ([217.44.202.158]) by c2bthomr14.btconnect.com with SMTP id BHB83208; Tue, 11 Jan 2011 18:12:05 +0000 (GMT) Message-ID: <01dd01cbb1b2$35775860$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Murray S. Kucherawy" , References: Date: Tue, 11 Jan 2011 18:08:37 +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-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D2C9D70.0181, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4D2C9D75.0223,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 18:09:52 -0000 ----- Original Message ----- From: "Murray S. Kucherawy" To: Sent: Monday, January 10, 2011 8:57 PM I've got a project on the go that will result in a few different I-Ds for consideration, one of which contains a specification for a new XML-based reporting format. Can someone suggest some RFCs that have done a good job of the same sort of thing in the past that I could use as a template for such work, or a BCP or similar? Netconf chose XML and XSD, and probably wishes it hadn't. I had a quick scan of archives and cannot find any decent summary of just why it doesn't work; Randy Presuhn is always the most articulate as to just why XML gets it wrong, its lack of coherent intellectual underpinnings. OK, Netconf has a more challenging objective, of replacing aspects of SMI and SNMP but even so, some at least of the problems are generic, such as - lack of proper typing - naming and namespaces (eg the no namespace, null namespace, ...) - impossibility of validating documents with XSD (possible with DSDL). I did a survey of many (most?) IETF XML RFC/I-D before we started, and saw a lot of options with no guidance as to which way to go. (I found some documents that were plain wrong). I raised this lack of guidance on the IETF list but got no traction. Netconf did take advice from the XML Directorate, and they were plain wrong, in one key regard, which has turned out to be an issue that has taken years so far, and as yet is unresolved (the question they failed to answer correctly was what is and is not valid XML? the consequence is an inability to parse XML documents transported by Netconf as currently specified). So, if there anything better, with tools available, I would recommend it Tom Petch Thanks, -MSK From tbray@textuality.com Tue Jan 11 11:44:15 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960433A6A90 for ; Tue, 11 Jan 2011 11:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, 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 pOqJmC-UEAmP for ; Tue, 11 Jan 2011 11:44:14 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 935D33A69C5 for ; Tue, 11 Jan 2011 11:44:14 -0800 (PST) Received: by fxm9 with SMTP id 9so20698766fxm.31 for ; Tue, 11 Jan 2011 11:46:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.74.143 with SMTP id u15mr45959faj.27.1294775191378; Tue, 11 Jan 2011 11:46:31 -0800 (PST) Received: by 10.223.126.212 with HTTP; Tue, 11 Jan 2011 11:46:31 -0800 (PST) X-Originating-IP: [216.239.45.130] In-Reply-To: <01dd01cbb1b2$35775860$4001a8c0@gateway.2wire.net> References: <01dd01cbb1b2$35775860$4001a8c0@gateway.2wire.net> Date: Tue, 11 Jan 2011 11:46:31 -0800 Message-ID: From: Tim Bray To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 19:44:15 -0000 On Tue, Jan 11, 2011 at 9:08 AM, t.petch wrote: > =A0- impossibility of validating documents with XSD (possible with DSDL). The general lousiness of XSD is now well-known. Atom was very happy with RNG, but ymmv. > Netconf did take advice from the XML Directorate, and they were plain wro= ng, in > one key regard, which has turned out to be an issue that has taken years = so far, > and as yet is unresolved (the question they failed to answer correctly wa= s what > is and is not valid XML? the consequence is an inability to parse XML doc= uments > transported by Netconf as currently specified). Huh? Formally, "valid" means "has a DTD and conforms to it" but almost nobody uses DTDs any more. Whether something is or is not XML is not in any doubt either de jure or de facto, we have good interoperability among parsers these days. If Netconf XML can't be parsed, the specification must have some awful problems. I've certainly seen some lousy XML-based protocols here and there, but this the first instance of "inability to parse" I've run across. -Tim From tbray@textuality.com Tue Jan 11 11:45:12 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46DF93A6A95 for ; Tue, 11 Jan 2011 11:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 qDN+SHHfYdSg for ; Tue, 11 Jan 2011 11:45:11 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 37C823A6A94 for ; Tue, 11 Jan 2011 11:45:11 -0800 (PST) Received: by fxm9 with SMTP id 9so20699699fxm.31 for ; Tue, 11 Jan 2011 11:47:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.72.6 with SMTP id k6mr39280faj.46.1294775247952; Tue, 11 Jan 2011 11:47:27 -0800 (PST) Received: by 10.223.126.212 with HTTP; Tue, 11 Jan 2011 11:47:27 -0800 (PST) X-Originating-IP: [216.239.45.130] In-Reply-To: References: Date: Tue, 11 Jan 2011 11:47:27 -0800 Message-ID: From: Tim Bray To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 19:45:12 -0000 Oh, and others have also found this slide-set, from a talk I gave at the Vancouver IETF, useful: http://www.ietf.org/proceedings/70/slides/xmltut-0.pdf -Tim On Mon, Jan 10, 2011 at 11:57 AM, Murray S. Kucherawy w= rote: > Hi all, > > > > I=92ve got a project on the go that will result in a few different I-Ds f= or > consideration, one of which contains a specification for a new XML-based > reporting format.=A0 Can someone suggest some RFCs that have done a good = job > of the same sort of thing in the past that I could use as a template for > such work, or a BCP or similar? > > > > Thanks, > > -MSK > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From lhotka@cesnet.cz Tue Jan 11 13:15:13 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF823A659A for ; Tue, 11 Jan 2011 13:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, NO_RELAYS=-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 cWtQayKFCwzt for ; Tue, 11 Jan 2011 13:15:12 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id DFB203A6AB2 for ; Tue, 11 Jan 2011 13:15:11 -0800 (PST) Received: from stardust-w.lhotkovi.cz (unknown [IPv6:2001:718:1a02:7:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id 560FE2CDE05B; Tue, 11 Jan 2011 22:17:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <01dd01cbb1b2$35775860$4001a8c0@gateway.2wire.net> Date: Tue, 11 Jan 2011 22:17:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8161A2F7-1941-492E-839C-651265F54D63@cesnet.cz> References: <01dd01cbb1b2$35775860$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1082) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 21:15:13 -0000 Hi Tom, On Jan 11, 2011, at 6:08 PM, t.petch wrote: > ----- Original Message ----- > From: "Murray S. Kucherawy" > To: > Sent: Monday, January 10, 2011 8:57 PM >=20 > I've got a project on the go that will result in a few different I-Ds = for > consideration, one of which contains a specification for a new = XML-based > reporting format. Can someone suggest some RFCs that have done a good = job of > the same sort of thing in the past that I could use as a template for = such work, > or a BCP or similar? >=20 > >=20 > Netconf chose XML and XSD, and probably wishes it hadn't. I had a = quick scan of > archives and cannot find any decent summary of just why it doesn't = work; Randy > Presuhn is always the most articulate as to just why XML gets it = wrong, its lack > of coherent intellectual underpinnings. OK, Netconf has a more = challenging > objective, of replacing aspects of SMI and SNMP but even so, some at = least of > the problems are generic, such as > - lack of proper typing In fact YANG helps a lot, but yes, types like IP addresses are still not = built in. > - naming and namespaces (eg the no namespace, null namespace, ...) Well, in hindsight, XML namespaces perhaps could have been done in a = better way - James Clark has an interesting account on it in his blog - = but namespaces as such are indispensible for NETCONF data modeling. For = example, JSON has no namespaces. > - impossibility of validating documents with XSD (possible with DSDL). I am not a fan of XSD (as you know) but this statement may be too = strong. In the particular case of RFC 4741, the problem is more in the = design of the XSD schema than in XSD as such. >=20 > I did a survey of many (most?) IETF XML RFC/I-D before we started, and = saw a lot > of options with no guidance as to which way to go. (I found some = documents that > were plain wrong). I raised this lack of guidance on the IETF list = but got no > traction. >=20 > Netconf did take advice from the XML Directorate, and they were plain = wrong, in It seems it was sufficient to carefully read the XML spec. =20 > one key regard, which has turned out to be an issue that has taken = years so far, > and as yet is unresolved (the question they failed to answer correctly = was what > is and is not valid XML? the consequence is an inability to parse XML = documents > transported by Netconf as currently specified). This has been recently resolved in draft-ietf-netconf-rfc4742bis-05. =20 >=20 > So, if there anything better, with tools available, I would recommend = it My observation is that quite often problems have been caused by how = people (mis)use XML rather than by XML itself. Lada >=20 > Tom Petch > >=20 >=20 > Thanks, > -MSK >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietfc@btconnect.com Wed Jan 12 02:16:53 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359733A6975 for ; Wed, 12 Jan 2011 02:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 vQKHyx03MJDn for ; Wed, 12 Jan 2011 02:16:52 -0800 (PST) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by core3.amsl.com (Postfix) with ESMTP id 0B7E63A69F8 for ; Wed, 12 Jan 2011 02:16:51 -0800 (PST) Received: from host217-44-202-158.range217-44.btcentralplus.com (HELO pc6) ([217.44.202.158]) by c2bthomr13.btconnect.com with SMTP id BHG63290; Wed, 12 Jan 2011 10:19:03 +0000 (GMT) Message-ID: <013a01cbb239$4a47f1a0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Tim Bray" , "Murray S. Kucherawy" References: Date: Wed, 12 Jan 2011 10:15:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit 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-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D2D8006.00DF, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4D2D8018.013F,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 10:16:53 -0000 ----- Original Message ----- From: "Tim Bray" To: "Murray S. Kucherawy" Cc: Sent: Tuesday, January 11, 2011 8:47 PM Subject: Re: [apps-discuss] An XML RFC primer? Oh, and others have also found this slide-set, from a talk I gave at the Vancouver IETF, useful: http://www.ietf.org/proceedings/70/slides/xmltut-0.pdf -Tim Yes, I endorse that. (especially where it says 'Use Plain Text If: ... you possibly can') I also found a series of 11 .pdf about XML Best Practices most helpful in identifying the choices a user of XML has to make, and some of the consequences. It is these choices I would have liked the IETF to be more pro-active about, back in 2006, but, as I said, there was no support for that. Tom Petch On Mon, Jan 10, 2011 at 11:57 AM, Murray S. Kucherawy wrote: > Hi all, > > > > I’ve got a project on the go that will result in a few different I-Ds for > consideration, one of which contains a specification for a new XML-based > reporting format. Can someone suggest some RFCs that have done a good job > of the same sort of thing in the past that I could use as a template for > such work, or a BCP or similar? > > > > Thanks, > > -MSK > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From ietfc@btconnect.com Wed Jan 12 02:20:58 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DAF03A6A0B for ; Wed, 12 Jan 2011 02:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, J_CHICKENPOX_15=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 fXL1gQPy9+bi for ; Wed, 12 Jan 2011 02:20:57 -0800 (PST) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by core3.amsl.com (Postfix) with ESMTP id EEAF03A6A1E for ; Wed, 12 Jan 2011 02:20:56 -0800 (PST) Received: from host217-44-202-158.range217-44.btcentralplus.com (HELO pc6) ([217.44.202.158]) by c2bthomr07.btconnect.com with SMTP id BNU09741; Wed, 12 Jan 2011 10:23:12 +0000 (GMT) Message-ID: <014201cbb239$ded879c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Tim Bray" References: <01dd01cbb1b2$35775860$4001a8c0@gateway.2wire.net> Date: Wed, 12 Jan 2011 10:19:49 +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-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0302.4D2D810F.023B, actions=TAG X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4D2D8111.00E7,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 10:20:58 -0000 ----- Original Message ----- From: "Tim Bray" To: "t.petch" Cc: "Murray S. Kucherawy" ; Sent: Tuesday, January 11, 2011 8:46 PM On Tue, Jan 11, 2011 at 9:08 AM, t.petch wrote: > Netconf did take advice from the XML Directorate, and they were plain wrong, in > one key regard, which has turned out to be an issue that has taken years so far, > and as yet is unresolved (the question they failed to answer correctly was what > is and is not valid XML? the consequence is an inability to parse XML documents > transported by Netconf as currently specified). Huh? Formally, "valid" means "has a DTD and conforms to it" but almost nobody uses DTDs any more. Whether something is or is not XML is not in any doubt either de jure or de facto, we have good interoperability among parsers these days. If Netconf XML can't be parsed, the specification must have some awful problems. I've certainly seen some lousy XML-based protocols here and there, but this the first instance of "inability to parse" I've run across. I was not clear enough. It is the ability to parse the Netconf datastream into XML documents that is the problem with Netconf as currently specified, and which has caused much grief for several years. As Lada has said, there is an I-D which is likely to fix this (but whose progress is tortuous). Tom Petch -Tim From lhotka@cesnet.cz Wed Jan 12 04:05:51 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923FE28C139 for ; Wed, 12 Jan 2011 04:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, NO_RELAYS=-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 34MwVTOAgKLs for ; Wed, 12 Jan 2011 04:05:50 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id B969F28C11F for ; Wed, 12 Jan 2011 04:05:49 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e] (unknown [IPv6:2001:718:1a02:7:201:80ff:fe65:dd1e]) by office2.cesnet.cz (Postfix) with ESMTPSA id F20212CDE057 for ; Wed, 12 Jan 2011 13:08:03 +0100 (CET) From: Ladislav Lhotka To: apps-discuss@ietf.org In-Reply-To: <014201cbb239$ded879c0$4001a8c0@gateway.2wire.net> References: <01dd01cbb1b2$35775860$4001a8c0@gateway.2wire.net> <014201cbb239$ded879c0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Wed, 12 Jan 2011 13:08:03 +0100 Message-ID: <1294834083.12118.93.camel@behold> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] An XML RFC primer? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 12:05:51 -0000 On St, 2011-01-12 at 10:19 +0100, t.petch wrote: > ----- Original Message ----- > From: "Tim Bray" > To: "t.petch" > Cc: "Murray S. Kucherawy" ; > Sent: Tuesday, January 11, 2011 8:46 PM > On Tue, Jan 11, 2011 at 9:08 AM, t.petch wrote: > > > Netconf did take advice from the XML Directorate, and they were plain wrong, > in > > one key regard, which has turned out to be an issue that has taken years so > far, > > and as yet is unresolved (the question they failed to answer correctly was > what > > is and is not valid XML? the consequence is an inability to parse XML > documents > > transported by Netconf as currently specified). > > Huh? Formally, "valid" means "has a DTD and conforms to it" but > almost nobody uses DTDs any more. Whether something is or is not XML > is not in any doubt either de jure or de facto, we have good > interoperability among parsers these days. If Netconf XML can't be > parsed, the specification must have some awful problems. > > I've certainly seen some lousy XML-based protocols here and there, but > this the first instance of "inability to parse" I've run across. > > > I was not clear enough. It is the ability to parse the Netconf > datastream into XML documents that is the problem with > Netconf as currently specified, and which has caused much > grief for several years. As Lada has said, there is an I-D > which is likely to fix this (but whose progress is tortuous). Simply put, somebody was able to convince the WG that the string "]]>]]>" cannot appear ANYWHERE in a valid XML document, so this string was used as the end-of-message marker. It was not technically difficult to fix this blunder, the biggest problem was backward compatibility with devices that already use the broken framing. Lada > > Tom Petch > > > > -Tim > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From Kurt.Zeilenga@Isode.com Thu Jan 13 06:53:59 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80953A6B9D for ; Thu, 13 Jan 2011 06:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.934 X-Spam-Level: X-Spam-Status: No, score=-100.934 tagged_above=-999 required=5 tests=[AWL=-1.335, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_25=0.6, USER_IN_WHITELIST=-100] 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 3tCecf9EG0g1 for ; Thu, 13 Jan 2011 06:53:58 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 7162A3A6B9A for ; Thu, 13 Jan 2011 06:53:58 -0800 (PST) Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 13 Jan 2011 14:56:19 +0000 From: Kurt Zeilenga In-Reply-To: <4D2C0BC2.7050002@ericsson.com> Date: Thu, 13 Jan 2011 06:56:16 -0800 Message-Id: <627F499B-09E6-4896-A45F-6E29C1C611BC@Isode.com> References: <4BF3DB9C-02D5-4778-9D30-694F8DB74A8D@estacado.net> <1B9BC3F1-3FA4-4FAF-BD32-2FE8417840FD@estacado.net> <4D2C0BC2.7050002@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1082) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , draft-ietf-sipcore-sec-flows@tools.ietf.org, apps-discuss@ietf.org, Brian Hibbard Subject: Re: [apps-discuss] Apps-team review: draft-ietf-sipcore-sec-flows X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 14:53:59 -0000 On Jan 10, 2011, at 11:50 PM, Gonzalo Camarillo wrote: > Hi Kurt, >=20 > could you please have a look at Brian's explanation below and let us > know whether or not you are happy with it? My general view is that our examples and discussions should well use = established syntaxes. Inconsistent use of syntaxes not only reduces = readability of individual documents containing such inconsistencies, but = tends to cause confusion in the whole series of documents. With DNs, = we see significant confusion over whether the RDNs are to be written = least-to-most specific or most-to-least specific. This document adds = to that confusion. As far as the desire to use actual output of a tool a developer might = use, I note that I would hope that bugs in such tools, such as those in = its use of formal syntaxes, would be corrected over time. So, I would suggestion that, either one don't use the exact output of = the tools and noting this in the I-D OR using the exact output in the = tools and noting both that flaws in that output and the fact that = different versions of these tools might produce different output. -- Kurt >=20 > Thanks, >=20 > Gonzalo >=20 >>> *From: *Brian Hibbard > >>> *Date: *January 6, 2011 10:35:07 AM CST >>> *To: *Kurt Zeilenga >> > >>> *Cc: *Alexey Melnikov >> >, >>> draft-ietf-sipcore-sec-flows@tools.ietf.org >>> , >>> apps-discuss@ietf.org >>> *Subject: **Re: Apps-team review: draft-ietf-sipcore-sec-flows * >>>=20 >>> Hello Kurt, >>>=20 >>> Thank you for your input. The inconsistencies in presentation of = DN >>> that you're talking about are the actual results of the dumps of the >>> OpenSSL "x509" certificate tool. The use of the tool in this = context >>> is only to examine the content of the certificates for learning and >>> testing purposes, and in the draft, to show what designers and >>> testers would see in their environments. It is only because those >>> are the actual results from the tool most likely to be used by = readers >>> of this document, that we are partial to leaving the dumps as they = are. =20 >>>=20 >>> With that said, if you remain convinced that consistency of >>> presentation is the more important factor here, I will go and make >>> changes to the x509 dumps. >>>=20 >>> Regards, >>> Brian >>>=20 >>> On Dec 15, 2010, at 9:21 AM, Kurt Zeilenga wrote: >>>=20 >>>> I have been selected as the Applications Area Review Team reviewer >>>> for this draft (for background on apps-review, please >>>> seehttp://www.apps.ietf.org/content/applications-area-review-team). >>>>=20 >>>> Please resolve these comments along with any other Last Call = comments >>>> you may receive. Please wait for direction from your document >>>> shepherd or AD before posting a new version of the draft. >>>>=20 >>>> Document: draft-ietf-sipcore-sec-flows (rev-07 reviewed) >>>> Title: Example call flows using Session Initiation Protocol (SIP) >>>> security mechanisms >>>> Reviewer: Kurt Zeilenga >>>> Review Date: 12/15/2010 >>>> IETF Last Call Date: [include if known] >>>> IESG Telechat Date: 2011-01-20 >>>> Summary: This draft is basically ready for publication as an >>>> Informational RFC but has a few issues that should be fixed before >>>> publication. >>>> Major Issues: None. >>>> Minor Issues: >>>>=20 >>>> I see some inconsistencies in how Distinguished Names (DNs) are >>>> presented in the RFC. >>>>=20 >>>> For instance (from 2.1): >>>> Issuer: C=3DUS, ST=3DCalifornia, L=3DSan Jose, O=3Dsipit, >>>> OU=3DSipit Test Certificate Authority >>>>=20 >>>> vs. (also from 2.1) >>>> DirName:/C=3DUS/ST=3DCalifornia/L=3DSan Jose/O=3Dsipit/ >>>> OU=3DSipit Test Certificate Authority >>>>=20 >>>> The former kind of looks like the LDAP DN format but, if that's = what >>>> was intended, the RDNs appear in the incorrect order. Note that in >>>> the LDAP DN format, the most specific element appears first (the >>>> reverse of how they appear in the BER/DER encoding of a DN). Also, >>>> there should be no spaces after the RDN separators (the commas). >>>>=20 >>>> The latter appears to be DCE format. >>>>=20 >>>> I would think it appropriate to use a single format for all DNs = and, >>>> if one chooses to use the LDAP DN format, that values ought to be >>>> constructed per RFC 4514. I note that Appendix A of RFC 4514 >>>> discusses presentation issues of Distinguished Names. >>>>=20 >>>> Nits: The usual (many acronyms are not spelled out on first use, = etc.) >>>=20 >>=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From benl@google.com Fri Jan 14 01:57:59 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B973A6AC9 for ; Fri, 14 Jan 2011 01:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.736 X-Spam-Level: X-Spam-Status: No, score=-103.736 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 NGfUYNioMABE for ; Fri, 14 Jan 2011 01:57:59 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id E2B873A6A0D for ; Fri, 14 Jan 2011 01:57:56 -0800 (PST) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p0EA0KUE024965 for ; Fri, 14 Jan 2011 02:00:20 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294999221; bh=4HjEKMmA6PPVeYrCzXGB9XJoaJc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ku1dye3cK8J2LuGDWh2s2F5CiKiqDwelNTN3jW0GmSOUBEBd0QpGqNkcbReNbv7ek 3vrYo093/UqwUfoB+dwDw== Received: from qwa26 (qwa26.prod.google.com [10.241.193.26]) by kpbe11.cbf.corp.google.com with ESMTP id p0EA0IwC027482 for ; Fri, 14 Jan 2011 02:00:19 -0800 Received: by qwa26 with SMTP id 26so2542252qwa.19 for ; Fri, 14 Jan 2011 02:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pOv0POGRSp4j8mzD5VRvAxYScXGJeD+JAQmTzfFsha8=; b=QlnWNTYdpnVqArTKVax8JGp+chiH908UHFXhpfKJHxQ9pdwSR1UnDQoKzHvmANLchD riQVXwbbQy5wyTvopi9Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Q42xBptqqqWzKPqxAdm9MCgsaqciCJPxGka8QYv4t96iB5eQwqPkGq1k2ZkcK6qwBU uC7s/RdAorxzTno2ce0Q== MIME-Version: 1.0 Received: by 10.229.95.11 with SMTP id b11mr537655qcn.28.1294999218581; Fri, 14 Jan 2011 02:00:18 -0800 (PST) Received: by 10.220.88.137 with HTTP; Fri, 14 Jan 2011 02:00:18 -0800 (PST) In-Reply-To: References: <4D2A239C.6040801@extendedsubset.com> Date: Fri, 14 Jan 2011 10:00:18 +0000 Message-ID: From: Ben Laurie To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Fri, 14 Jan 2011 10:22:37 -0800 Cc: apps-discuss@ietf.org, dwm@xpasc.com, websec@ietf.org, marsh@extendedsubset.com, kitten@ietf.org, zedshaw@zedshaw.com, http-auth@ietf.org, ietf-http-wg@w3.org, hallam@gmail.com, saag@ietf.org Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 09:57:59 -0000 On 14 January 2011 02:24, Peter Gutmann wrote: > Marsh Ray writes: > >>Phishing can be said to have been prevented only when the user can be rel= ied >>upon to refuse to enter his password into an insecure box. > > I think you need to phrase that more generally, "when the user can be rel= ied > upon to not authenticate to the wrong site", because there's more ways of > authenticating around than just typing a string into a web form. =A0For e= xample > some password managers do site-specifc passwords, so even if you go to th= e > wrong site you can't accidentally provide your credentials for the correc= t > site. That phrasing is only correct if the authentication method leaks the passwo= rd... > >>For example, my bank asks for my username and then shows me a familiar >>picture (e.g., a rocking horse) that is supposed to prevent phishing. Thi= s >>stops phishing only in the sense that it requires the attacker to use a C= GI >>proxy app rather than simple static phishing site. > > ... or display a broken-image GIF, or a message that the award-winning > security whatsit is being upgraded and will be back soon, or ... > > (this is from a real-world evaluation of the (in-)effectiveness of site > images, I can dig up the ref if required). =A0Site images rate more as a > security gimmick than any real security measure. Exactly. From brian@estacado.net Thu Jan 13 13:27:52 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52B0D3A6BE1 for ; Thu, 13 Jan 2011 13:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_25=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 8PM+7UwsK0QM for ; Thu, 13 Jan 2011 13:27:51 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 6DF523A6BDA for ; Thu, 13 Jan 2011 13:27:50 -0800 (PST) Received: from dn3-77.estacado.net (dn3-77.estacado.net [172.16.3.77]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id p0DLU6Sf054760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Jan 2011 15:30:07 -0600 (CST) (envelope-from brian@estacado.net) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Hibbard In-Reply-To: <627F499B-09E6-4896-A45F-6E29C1C611BC@Isode.com> Date: Thu, 13 Jan 2011 15:30:01 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BF3DB9C-02D5-4778-9D30-694F8DB74A8D@estacado.net> <1B9BC3F1-3FA4-4FAF-BD32-2FE8417840FD@estacado.net> <4D2C0BC2.7050002@ericsson.com> <627F499B-09E6-4896-A45F-6E29C1C611BC@Isode.com> To: Kurt Zeilenga X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Fri, 14 Jan 2011 10:22:48 -0800 Cc: draft-ietf-sipcore-sec-flows@tools.ietf.org, Adam Roach , Gonzalo Camarillo , apps-discuss@ietf.org Subject: Re: [apps-discuss] Apps-team review: draft-ietf-sipcore-sec-flows X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 21:27:52 -0000 Hello All, Based on Kurt's feedback, if there are no objections, my plan is to move = forward with adding a statement to the document stating that the flaws = in DN presentation=20 * are directly from the OpenSSL * that there presented only as examples * they are subject to change (as is all the output from the tool) from = version to version * hopefully future versions of the tool will be both correct and = consistent according to RFC 4514 I'll put this disclaimer where output is first presented, and will craft = the words a little more nicely.=20 I'll include RFC 4514 as an informative Reference. If anyone has any objections or clarifications, please speak up soon. =20= Thank you, -b On Jan 13, 2011, at 8:56 AM, Kurt Zeilenga wrote: >=20 > On Jan 10, 2011, at 11:50 PM, Gonzalo Camarillo wrote: >=20 >> Hi Kurt, >>=20 >> could you please have a look at Brian's explanation below and let us >> know whether or not you are happy with it? >=20 > My general view is that our examples and discussions should well use = established syntaxes. Inconsistent use of syntaxes not only reduces = readability of individual documents containing such inconsistencies, but = tends to cause confusion in the whole series of documents. With DNs, = we see significant confusion over whether the RDNs are to be written = least-to-most specific or most-to-least specific. This document adds = to that confusion. >=20 > As far as the desire to use actual output of a tool a developer might = use, I note that I would hope that bugs in such tools, such as those in = its use of formal syntaxes, would be corrected over time. >=20 > So, I would suggestion that, either one don't use the exact output of = the tools and noting this in the I-D OR using the exact output in the = tools and noting both that flaws in that output and the fact that = different versions of these tools might produce different output. >=20 > -- Kurt >=20 >>=20 >> Thanks, >>=20 >> Gonzalo >>=20 >>>> *From: *Brian Hibbard > >>>> *Date: *January 6, 2011 10:35:07 AM CST >>>> *To: *Kurt Zeilenga >>> > >>>> *Cc: *Alexey Melnikov >>> >, >>>> draft-ietf-sipcore-sec-flows@tools.ietf.org >>>> , >>>> apps-discuss@ietf.org >>>> *Subject: **Re: Apps-team review: draft-ietf-sipcore-sec-flows * >>>>=20 >>>> Hello Kurt, >>>>=20 >>>> Thank you for your input. The inconsistencies in presentation of = DN >>>> that you're talking about are the actual results of the dumps of = the >>>> OpenSSL "x509" certificate tool. The use of the tool in this = context >>>> is only to examine the content of the certificates for learning and >>>> testing purposes, and in the draft, to show what designers and >>>> testers would see in their environments. It is only because those >>>> are the actual results from the tool most likely to be used by = readers >>>> of this document, that we are partial to leaving the dumps as they = are. =20 >>>>=20 >>>> With that said, if you remain convinced that consistency of >>>> presentation is the more important factor here, I will go and make >>>> changes to the x509 dumps. >>>>=20 >>>> Regards, >>>> Brian >>>>=20 >>>> On Dec 15, 2010, at 9:21 AM, Kurt Zeilenga wrote: >>>>=20 >>>>> I have been selected as the Applications Area Review Team reviewer >>>>> for this draft (for background on apps-review, please >>>>> = seehttp://www.apps.ietf.org/content/applications-area-review-team). >>>>>=20 >>>>> Please resolve these comments along with any other Last Call = comments >>>>> you may receive. Please wait for direction from your document >>>>> shepherd or AD before posting a new version of the draft. >>>>>=20 >>>>> Document: draft-ietf-sipcore-sec-flows (rev-07 reviewed) >>>>> Title: Example call flows using Session Initiation Protocol (SIP) >>>>> security mechanisms >>>>> Reviewer: Kurt Zeilenga >>>>> Review Date: 12/15/2010 >>>>> IETF Last Call Date: [include if known] >>>>> IESG Telechat Date: 2011-01-20 >>>>> Summary: This draft is basically ready for publication as an >>>>> Informational RFC but has a few issues that should be fixed before >>>>> publication. >>>>> Major Issues: None. >>>>> Minor Issues: >>>>>=20 >>>>> I see some inconsistencies in how Distinguished Names (DNs) are >>>>> presented in the RFC. >>>>>=20 >>>>> For instance (from 2.1): >>>>> Issuer: C=3DUS, ST=3DCalifornia, L=3DSan Jose, O=3Dsipit, >>>>> OU=3DSipit Test Certificate Authority >>>>>=20 >>>>> vs. (also from 2.1) >>>>> DirName:/C=3DUS/ST=3DCalifornia/L=3DSan Jose/O=3Dsipit/ >>>>> OU=3DSipit Test Certificate Authority >>>>>=20 >>>>> The former kind of looks like the LDAP DN format but, if that's = what >>>>> was intended, the RDNs appear in the incorrect order. Note that = in >>>>> the LDAP DN format, the most specific element appears first (the >>>>> reverse of how they appear in the BER/DER encoding of a DN). = Also, >>>>> there should be no spaces after the RDN separators (the commas). >>>>>=20 >>>>> The latter appears to be DCE format. >>>>>=20 >>>>> I would think it appropriate to use a single format for all DNs = and, >>>>> if one chooses to use the LDAP DN format, that values ought to be >>>>> constructed per RFC 4514. I note that Appendix A of RFC 4514 >>>>> discusses presentation issues of Distinguished Names. >>>>>=20 >>>>> Nits: The usual (many acronyms are not spelled out on first use, = etc.) >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From marsh@extendedsubset.com Fri Jan 14 09:05:16 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06A53A6BA3; Fri, 14 Jan 2011 09:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 yVAyY+betpQV; Fri, 14 Jan 2011 09:05:15 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 74AE43A6B9A; Fri, 14 Jan 2011 09:05:15 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Pdn7h-0004Py-OE; Fri, 14 Jan 2011 17:07:37 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 4809C603E; Fri, 14 Jan 2011 17:07:33 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18lbvaEQEauG/YHYvKNkaHDVNFTUVsfTMQ= Message-ID: <4D3082D5.6070801@extendedsubset.com> Date: Fri, 14 Jan 2011 11:07:33 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 14 Jan 2011 10:23:01 -0800 Cc: apps-discuss@ietf.org, benl@google.com, dwm@xpasc.com, websec@ietf.org, kitten@ietf.org, zedshaw@zedshaw.com, http-auth@ietf.org, ietf-http-wg@w3.org, hallam@gmail.com, saag@ietf.org Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 17:05:16 -0000 On 01/13/2011 08:24 PM, Peter Gutmann wrote: > Marsh Ray writes: > >> Phishing can be said to have been prevented only when the user can >> be relied upon to refuse to enter his password into an insecure >> box. > > I think you need to phrase that more generally, "when the user can be > relied upon to not authenticate to the wrong site", because there's > more ways of authenticating around than just typing a string into a > web form. I was trying to be as general as possible but still thinking in terms of phising for passwords. (This conversation has bounced around a bit between "better HTTP password authentication don't you dare mention client certificates" and "open-minded discussion of login authentication methods". I'm happy to contribute to whatever, but we risk miscommunication-mistaken-for-disagreement unless we settle on the scope first.) The term "authenticate to the wrong site" has completely different meaning depending on whether or not we're talking about capture-and-reuse credentials like passwords or whether or not we're assuming encryption which authenticates the server to the user (https). So I was thinking of "password into insecure box" as being more general. Maybe the attack somehow doesn't even involve the "wrong site", maybe bad guy injects something into the right site instead? > For example some password managers do site-specifc > passwords, so even if you go to the wrong site you can't accidentally > provide your credentials for the correct site. OMG, I can't stand it when I type the right password (for something else) into the wrong box. I admit that I have not always immediately changed that password when I've done it into a computer I also sort-of trusted (but in a different scope). > Site images rate > more as a security gimmick than any real security measure. It'd be interesting to know if banks get an actual reduction in the rate of phishing from that. On 01/13/2011 08:33 PM, Peter Gutmann wrote: > Phillip Hallam-Baker writes: > >> Such users have asked to do business with hundreds of entities, so >> at least something is working right. > > Actually they haven't asked to to business with most of them, but > are required to have an account for > user-tracking/spam-defeating/who-knows-what purposes. Yep. I guess I was counting things like Slashdot and Twitter as "doing business", even though it wasn't a monetary transaction. There is some value stored in those credentials, or at least pain-in-the butt potential costs to me if they were compromised for some reason. > If browsers > provided a basic "generate a random password just for this site" > feature, as many password managers have been doing for years and > years, then we could focus on the tiny fraction of sites where > authentication really matters. That would be convenient, but how many people back up the password manager in their browser? I don't, I prefer to write them down. I use multiple computers and multiple browsers. No browser has every password. Encouraging them to be centralized in the browser seems less than ideal, since it's the browser that gets pwned more than anything else. > Two major problems that we initially > need to overcome are: > > 1. Browsers (I'm using this as a generic for "client-side software") > treat all passwords as being equal, from your high-value banking > one to your throwaway knitting-patterns-blog one. Yes, I agree that's a big problem. I don't think we should think of them as being fully-ordered on a dimension of 'value' however. For example, let's say I have: A. Password for current employer's single-sign-on Kerberos/Active Directory infrastructure. B. Password I use at job-hunting website C. Password I use for my pseudonym where I flame newbies and post obscene patterns on the knitting patterns blog. My work desktop computer will most likely be backdoored by my employer. They may not care about C, but I care greatly that they do not find B. I log in to the employer from a home PC or smartphone from a VPN A. I may have a sense of responsibility about protecting A, but apparently I'm looking for a new job anyway. I'm more interested that prospective employers don't find out about C. From a public internet terminal I may not care at all about accessing C because it doesn't seem plausible that it would associate back with my professional identity. > 2. Browsers (ditto) have close to zero support for even the most > basic password management that any number of plugins and add-ons have > had for years (the Firefox 3.6 password manager is, AFAICT, unchanged > since the Netscape 2.0 one from fifteen years ago). It works sort of OK for me. But I'm only happy with it because I wouldn't trust it with all of my passwords regardless of how . > If we could start to address this, and at least begin to bound the > problem, we've made a start. Theorising about blue-sky solutions > isn't useful when we haven't even defined the real problem we're > trying to solve. Yes, let's resist the attraction of actual solutions until we have defined the problem to death. The possible solutions and their pros and cons of will usually be obvious by that point. - Marsh From marsh@extendedsubset.com Fri Jan 14 09:24:36 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C0C3A6BA3; Fri, 14 Jan 2011 09:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 zqPHCjGSpFEG; Fri, 14 Jan 2011 09:24:35 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id A0FAF3A6BB4; Fri, 14 Jan 2011 09:24:31 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PdnQM-000EKn-PO; Fri, 14 Jan 2011 17:26:54 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 0015C603E; Fri, 14 Jan 2011 17:26:50 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19CXS3o05S/+ZXWLvW9ImCQ+6e1DVdiVUQ= Message-ID: <4D30875B.5050109@extendedsubset.com> Date: Fri, 14 Jan 2011 11:26:51 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 14 Jan 2011 10:23:12 -0800 Cc: apps-discuss@ietf.org, benl@google.com, dwm@xpasc.com, websec@ietf.org, kitten@ietf.org, zedshaw@zedshaw.com, http-auth@ietf.org, ietf-http-wg@w3.org, hallam@gmail.com, saag@ietf.org Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 17:24:36 -0000 On 01/14/2011 04:12 AM, Peter Gutmann wrote: > > Who says there's a password involved? It's equally appropriate for public- > key/certificate-based auth, "sign this challenge" for example. I think "when > the user can be relied upon to not authenticate to the wrong site" covers most > of the bases and is technology- and mechanism-neutral. What is being authenticated? How much of the surrounding context is being assumed or implied, and how much is actually being authenticated? Who is doing the authentication? What capabilities will the result be used to authorize? These are real questions that go to the heart of the problem. I don't believe that they have been reconsidered in the context of today's computing environment. Give a description of the semantics of the "sign this challenge" act, without presupposing agreement on definitions we take for granted like "authentication", "login", "session", etc. I suspect the result would sound absurd enough that we would want to throw out the whole thing and start over. I suspect we avoid this exercise because we realize this subconsciously, or at least avoid saying it out loud. I suspect that this is a big part of why we find the problem intractable. - Marsh From tytso@mit.edu Thu Jan 13 10:25:19 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AC3B3A6BC5; Thu, 13 Jan 2011 10:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juOwH3Aiz1Kx; Thu, 13 Jan 2011 10:25:18 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id C5E403A6A5E; Thu, 13 Jan 2011 10:25:17 -0800 (PST) X-AuditID: 12074423-b7bd0ae000000a00-16-4d2f441cdfc6 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id E4.10.02560.C144F2D4; Thu, 13 Jan 2011 13:27:40 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p0DIRd4p016603; Thu, 13 Jan 2011 13:27:40 -0500 Received: from [192.168.1.196] (c-71-194-208-146.hsd1.il.comcast.net [71.194.208.146]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p0DIRAXG003778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Jan 2011 13:27:36 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Theodore Tso In-Reply-To: Date: Thu, 13 Jan 2011 13:27:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <45F97DFD-3AAB-44DE-8DC9-3694608EB740@mit.edu> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAARcg5EE= X-Mailman-Approved-At: Fri, 14 Jan 2011 10:23:21 -0800 Cc: "apps-discuss@ietf.org" , "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Ben Laurie , "ietf-http-wg@w3.org Group" Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 18:25:19 -0000 On Jan 8, 2011, at 11:07 AM, Phillip Hallam-Baker wrote: > I think that Ben is right that we are solving the wrong problem. >=20 > The problem is that users are asked to maintain accounts at literally = HUNDREDS of accounts.=20 >=20 > And some cretins, some utter morons, some bog-brained berks think it = is reasonable to tell the user to have a different password for every = one! >=20 > I can't remember the account names, the password is easy as I only had = one (for non financial) - until those cretins at Gawker screwed up. Now = I have to reset my password at all those places. The fact that web sites, like Gawker, will screw up, is why you need to = maintain different passwords at every single one. And at least Gawker = admitted that they screwed up, and told everyone to change their = passwords once this came out. Many large corporations would have tried = to stonewall and claim their security is perfect or at least not = publicize the security breach to their users. Personally, I think the horse left the barn a long, long time ago, and = this is not a problem we can fix today. What I use for my non-financial = accounts is the LastPass plugin, which scans HTML form pages looking for = username/password form fields, and if it finds them, looks up the = username/password in a database which is stored in the cloud in an = encrypted fashion, and populates them into HTML form. It also will = automatically generate nice, long, random passwords for every site when = you change your password, and allows you easily use long, = hard-to-memorize (and thus secure) passwords that are different for = every single web site. The only reason why I don't use it for my financial web sites is because = it's a closed source browser plugin, so I can't audit it to make sure = it's not stashing away passwords and publishing them to the manufacturer = via some covert channel. But if they want to steal my Financial Times = and Economists logins, hey, they can be my guest. It may be ugly that we're dealing with this at the HTML/presentation = battle, but any other solution will take years to roll out, and the = issues of trust and liability which to date have doomed any large-scale = PKI rollout are going to bite us here. And in a federated scheme, the = question of which federated entities a user should trust to potentially = give access to *all* of their web sites is still at best a research = problem. So at least for web security, maybe the best we can do is to = make things easier for the browser or browser plugins to manage = different accounts at hundreds of different web sites. This may = ultimately be an easier, and be a much more easily deployable, solution = than some kind of federated authentication proposal. -- Ted From paul.hoffman@vpnc.org Sun Jan 16 18:39:04 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781C228C0EF for ; Sun, 16 Jan 2011 18:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.709 X-Spam-Level: X-Spam-Status: No, score=-101.709 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] 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 eawT2RVgVoOE for ; Sun, 16 Jan 2011 18:39:03 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id AF78E28C0EC for ; Sun, 16 Jan 2011 18:39:03 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0H2fZV0085552 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 16 Jan 2011 19:41:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D33AC5F.3010609@vpnc.org> Date: Sun, 16 Jan 2011 18:41:35 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 02:39:04 -0000 Greetings again. I would like this WG to consider adopting the following draft as a WG item. It is definitely apps-related, and there is no other appropriate WG in the Applications or Security areas for it. It has been discussed in the websec WG, but that WG is limited to HTTP only (and this document covers TLS for all application protocols). FWIW, some of the topics in this draft are quite open for active discussion. The discussion in websec brought up some interesting issues, but they got discussed in the HTTP context only, and this WG would be a better place to discuss them for all server protocols. --Paul Hoffman A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Specifying That a Server Supports TLS Author(s) : P. Hoffman Filename : draft-hoffman-server-has-tls-03.txt Pages : 8 Date : 2011-01-16 A server that hosts applications that can be run with or without TLS may want to communicate with clients whether the server is hosting an application only using TLS or also hosting the application without TLS. Many clients have a policy to try to set up a TLS session but fall back to insecure if the TLS session cannot be set up. If the server can securely communicate whether or not it can fall back to insecure tells such a client whether or not they should even try to set up an insecure session with the server. This document describes the use cases for this type of communication and a secure method for communicating that information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-server-has-tls-03.txt From yaojk@cnnic.cn Sun Jan 16 22:43:54 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B093A6D09 for ; Sun, 16 Jan 2011 22:43:54 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -99.377 X-Spam-Level: X-Spam-Status: No, score=-99.377 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] 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 wPZqgfN1HCoG for ; Sun, 16 Jan 2011 22:43:53 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id ED9133A6C69 for ; Sun, 16 Jan 2011 22:43:52 -0800 (PST) Received: (eyou send program); Mon, 17 Jan 2011 14:46:25 +0800 Message-ID: <495246785.22018@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 17 Jan 2011 14:46:25 +0800 Message-ID: From: "Jiankang YAO" To: "Paul Hoffman" , References: <495232101.07985@cnnic.cn> Date: Mon, 17 Jan 2011 14:46:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: Re: [apps-discuss] For consideration as an appsawg document:draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 06:43:54 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBhdWwgSG9mZm1hbiIgPHBh dWwuaG9mZm1hbkB2cG5jLm9yZz4NClRvOiA8YXBwcy1kaXNjdXNzQGlldGYub3JnPg0KU2VudDog TW9uZGF5LCBKYW51YXJ5IDE3LCAyMDExIDEwOjQxIEFNDQpTdWJqZWN0OiBbYXBwcy1kaXNjdXNz XSBGb3IgY29uc2lkZXJhdGlvbiBhcyBhbiBhcHBzYXdnIGRvY3VtZW50OmRyYWZ0LWhvZmZtYW4t c2VydmVyLWhhcy10bHMtMDMudHh0DQoNCg0KPiBHcmVldGluZ3MgYWdhaW4uIEkgd291bGQgbGlr ZSB0aGlzIFdHIHRvIGNvbnNpZGVyIGFkb3B0aW5nIHRoZSBmb2xsb3dpbmcgDQo+IGRyYWZ0IGFz IGEgV0cgaXRlbS4gSXQgaXMgZGVmaW5pdGVseSBhcHBzLXJlbGF0ZWQsIGFuZCB0aGVyZSBpcyBu byBvdGhlciANCj4gYXBwcm9wcmlhdGUgV0cgaW4gdGhlIEFwcGxpY2F0aW9ucyBvciBTZWN1cml0 eSBhcmVhcyBmb3IgaXQuIEl0IGhhcyBiZWVuIA0KPiBkaXNjdXNzZWQgaW4gdGhlIHdlYnNlYyBX RywgYnV0IHRoYXQgV0cgaXMgbGltaXRlZCB0byBIVFRQIG9ubHkgKGFuZCANCj4gdGhpcyBkb2N1 bWVudCBjb3ZlcnMgVExTIGZvciBhbGwgYXBwbGljYXRpb24gcHJvdG9jb2xzKS4NCj4gDQoNClRo aXMgZG9jdW1lbnQgYWxzbyBkaXNjdXNzZXMgVGhlIEhBU1RMUyBSZXNvdXJjZSBSZWNvcmQgYW5k DQpyZXF1ZXN0cyB0aGF0IElBTkEgYWxsb2NhdGUgYSBuZXcgRE5TIHJlc291cmNlIHJlY29yZA0K ICAgdHlwZSBjYWxsZWQgSEFTVExTIGZyb20gdGhlIGRhdGEgdHlwZXMgcmFuZ2UuDQoNCkkgdGhp bmsgdGhhdCBETlNFWFQgV0cncyBjb21tZW50cyBhcmUgYWxzbyBpbXBvcnRhbnQgdG8gdGhlIEFE cyBhbmQgV0cgdG8gY29uc2lkZXIgd2hldGhlciB0aGlzIGRvY3VtZW50IGhhcHBlbnMgdG8gYmUg ZmFsbCBpbiB0aGUgc2NvcGUgb2YgIEFQUFNBV0cuDQoNCkppYW5rYW5nIFlhbw0KDQoNCg0KPiBG V0lXLCBzb21lIG9mIHRoZSB0b3BpY3MgaW4gdGhpcyBkcmFmdCBhcmUgcXVpdGUgb3BlbiBmb3Ig YWN0aXZlIA0KPiBkaXNjdXNzaW9uLiBUaGUgZGlzY3Vzc2lvbiBpbiB3ZWJzZWMgYnJvdWdodCB1 cCBzb21lIGludGVyZXN0aW5nIGlzc3VlcywgDQo+IGJ1dCB0aGV5IGdvdCBkaXNjdXNzZWQgaW4g dGhlIEhUVFAgY29udGV4dCBvbmx5LCBhbmQgdGhpcyBXRyB3b3VsZCBiZSBhIA0KPiBiZXR0ZXIg cGxhY2UgdG8gZGlzY3VzcyB0aGVtIGZvciBhbGwgc2VydmVyIHByb3RvY29scy4NCj4gDQo+IC0t UGF1bCBIb2ZmbWFuDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgDQo+IGRpcmVjdG9yaWVzLg0KPiANCj4gVGl0 bGUgICAgICAgICAgIDogU3BlY2lmeWluZyBUaGF0IGEgU2VydmVyIFN1cHBvcnRzIFRMUw0KPiBB dXRob3IocykgICAgICAgOiBQLiBIb2ZmbWFuDQo+IEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWhv ZmZtYW4tc2VydmVyLWhhcy10bHMtMDMudHh0DQo+IFBhZ2VzICAgICAgICAgICA6IDgNCj4gRGF0 ZSAgICAgICAgICAgIDogMjAxMS0wMS0xNg0KPiANCj4gQSBzZXJ2ZXIgdGhhdCBob3N0cyBhcHBs aWNhdGlvbnMgdGhhdCBjYW4gYmUgcnVuIHdpdGggb3Igd2l0aG91dCBUTFMNCj4gbWF5IHdhbnQg dG8gY29tbXVuaWNhdGUgd2l0aCBjbGllbnRzIHdoZXRoZXIgdGhlIHNlcnZlciBpcyBob3N0aW5n IGFuDQo+IGFwcGxpY2F0aW9uIG9ubHkgdXNpbmcgVExTIG9yIGFsc28gaG9zdGluZyB0aGUgYXBw bGljYXRpb24gd2l0aG91dA0KPiBUTFMuICBNYW55IGNsaWVudHMgaGF2ZSBhIHBvbGljeSB0byB0 cnkgdG8gc2V0IHVwIGEgVExTIHNlc3Npb24gYnV0DQo+IGZhbGwgYmFjayB0byBpbnNlY3VyZSBp ZiB0aGUgVExTIHNlc3Npb24gY2Fubm90IGJlIHNldCB1cC4gIElmIHRoZQ0KPiBzZXJ2ZXIgY2Fu IHNlY3VyZWx5IGNvbW11bmljYXRlIHdoZXRoZXIgb3Igbm90IGl0IGNhbiBmYWxsIGJhY2sgdG8N Cj4gaW5zZWN1cmUgdGVsbHMgc3VjaCBhIGNsaWVudCB3aGV0aGVyIG9yIG5vdCB0aGV5IHNob3Vs ZCBldmVuIHRyeSB0bw0KPiBzZXQgdXAgYW4gaW5zZWN1cmUgc2Vzc2lvbiB3aXRoIHRoZSBzZXJ2 ZXIuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcw0KPiB0aGUgdXNlIGNhc2VzIGZvciB0aGlzIHR5 cGUgb2YgY29tbXVuaWNhdGlvbiBhbmQgYSBzZWN1cmUgbWV0aG9kIGZvcg0KPiBjb21tdW5pY2F0 aW5nIHRoYXQgaW5mb3JtYXRpb24uDQo+IA0KPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFm dCBpczoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaG9mZm1h bi1zZXJ2ZXItaGFzLXRscy0wMy50eHQNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdA0KPiBhcHBzLWRp c2N1c3NAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h cHBzLWRpc2N1c3M= From paul.hoffman@vpnc.org Mon Jan 17 07:19:35 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06CA3A6F40 for ; Mon, 17 Jan 2011 07:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.71 X-Spam-Level: X-Spam-Status: No, score=-101.71 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] 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 kGF5cgC4xDYt for ; Mon, 17 Jan 2011 07:19:35 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id DCD6A3A6F3E for ; Mon, 17 Jan 2011 07:19:34 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0HFM8QL082442 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 17 Jan 2011 08:22:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D345EA0.3000506@vpnc.org> Date: Mon, 17 Jan 2011 07:22:08 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <495232101.07985@cnnic.cn> <495246785.22018@cnnic.cn> In-Reply-To: <495246785.22018@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] For consideration as an appsawg document:draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:19:35 -0000 On 1/16/11 10:46 PM, Jiankang YAO wrote: > This document also discusses The HASTLS Resource Record and requests > that IANA allocate a new DNS resource record type called HASTLS from > the data types range. > > I think that DNSEXT WG's comments are also important to the ADs and > WG to consider whether this document happens to be fall in the scope > of APPSAWG. Of course, getting input from the wide community is important. Note that for Resource Records, however, the DNSEXT WG is not the decider: the expert reviewer for the registry is. This is why the APPSAWG is a more appropriate place to discuss the semantics and desirability of the protocol. (Also, given that I have not yet done a first attempt at a wire format for the new RRtype, it is certainly premature to even ask DNSEXT...) From ajs@shinkuro.com Mon Jan 17 07:22:49 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DCDF3A6F42 for ; Mon, 17 Jan 2011 07:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCWoTYDlH1Hm for ; Mon, 17 Jan 2011 07:22:48 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 938653A6F3E for ; Mon, 17 Jan 2011 07:22:48 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 908571ECB408 for ; Mon, 17 Jan 2011 15:25:22 +0000 (UTC) Date: Mon, 17 Jan 2011 10:25:20 -0500 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20110117152520.GN3923@shinkuro.com> References: <495232101.07985@cnnic.cn> <495246785.22018@cnnic.cn> <4D345EA0.3000506@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D345EA0.3000506@vpnc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [apps-discuss] For consideration as an appsawg document:draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:22:49 -0000 On Mon, Jan 17, 2011 at 07:22:08AM -0800, Paul Hoffman wrote: > Of course, getting input from the wide community is important. Note that > for Resource Records, however, the DNSEXT WG is not the decider: the > expert reviewer for the registry is. This is why the APPSAWG is a more > appropriate place to discuss the semantics and desirability of the > protocol. Speaking as one of the co-chairs of DNSEXT, but without having discussed this with my co-chair, I agree with Paul. The RRTYPE itself is way less interesting than the overall protocol. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From magnus.westerlund@ericsson.com Wed Jan 19 00:28:00 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11023A70DF; Wed, 19 Jan 2011 00:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 t5DB8hE8T3Nb; Wed, 19 Jan 2011 00:28:00 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5E4163A70D6; Wed, 19 Jan 2011 00:27:59 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-d3-4d36a12dd6a9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A2.7C.13987.D21A63D4; Wed, 19 Jan 2011 09:30:37 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Wed, 19 Jan 2011 09:30:37 +0100 Message-ID: <4D36A12C.9010301@ericsson.com> Date: Wed, 19 Jan 2011 09:30:36 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , Internet Area , rai-discuss@ietf.org, ops-area@ietf.org, SAAG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [apps-discuss] Fwd: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 08:28:01 -0000 Hi, I just want to make people aware of this IETF last call for an update of the IANA procedures for registration of Service Name and Transport protocol port numbers. Best Regards Magnus Westerlund -------- Ursprungligt meddelande -------- Ämne: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Datum: Tue, 18 Jan 2011 22:26:03 +0100 Frĺn: The IESG Till: IETF-Announce Kopia: tsvwg@ietf.org The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry' as a BCP 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 2011-02-01. 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://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From paul.hoffman@vpnc.org Wed Jan 19 07:41:08 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1EF63A6ED1 for ; Wed, 19 Jan 2011 07:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.725 X-Spam-Level: X-Spam-Status: No, score=-101.725 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] 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 GMQ9l1235WKi for ; Wed, 19 Jan 2011 07:41:08 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id F16A93A6E62 for ; Wed, 19 Jan 2011 07:41:07 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0JFhl2G002296 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 19 Jan 2011 08:43:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3706B3.1080408@vpnc.org> Date: Wed, 19 Jan 2011 07:43:47 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4D36A12C.9010301@ericsson.com> In-Reply-To: <4D36A12C.9010301@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] Fwd: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 15:41:08 -0000 There are a number of policy statements made in this document that affect application design. Apps people should definitely take a look and comment. (I did my commenting during WG LC...) --Paul Hoffman On 1/19/11 12:30 AM, Magnus Westerlund wrote: > Hi, > > I just want to make people aware of this IETF last call for an update of > the IANA procedures for registration of Service Name and Transport > protocol port numbers. > > Best Regards > > Magnus Westerlund > > -------- Ursprungligt meddelande -------- > Ämne: Last Call: (Internet > Assigned Numbers Authority (IANA) Procedures for the Management of the > Service Name and Transport Protocol Port Number Registry) to BCP > Datum: Tue, 18 Jan 2011 22:26:03 +0100 > Frĺn: The IESG > Till: IETF-Announce > Kopia: tsvwg@ietf.org > > > The IESG has received a request from the Transport Area Working Group WG > (tsvwg) to consider the following document: > - 'Internet Assigned Numbers Authority (IANA) Procedures for the > Management of the Service Name and Transport Protocol Port Number > Registry' > as a BCP > > 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 2011-02-01. 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://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ > > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > From stpeter@stpeter.im Wed Jan 19 10:40:37 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E778F3A7196 for ; Wed, 19 Jan 2011 10:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPIxlHFPUOJU for ; Wed, 19 Jan 2011 10:40:36 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C1CA43A719E for ; Wed, 19 Jan 2011 10:40:36 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7FA5F400EE for ; Wed, 19 Jan 2011 11:58:54 -0700 (MST) Message-ID: <4D3730C3.5050902@stpeter.im> Date: Wed, 19 Jan 2011 11:43:15 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010706070809060504020409" Subject: [apps-discuss] call for AppsArea presentations at IETF 80 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 18:40:38 -0000 This is a cryptographically signed message in MIME format. --------------ms010706070809060504020409 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, IETF 80 is fast approaching. As always, your area directors are seeking presentations for the AppsArea meeting. The purpose of this meeting is to discuss important issues, developments, and work within the applications area, along with outside work that has an impact on Internet applications. If you would like to make a presentation, please contact me and Alexey via mailto:app-ads@tools.ietf.org and provide a brief description of the proposed topic, including the amount of time you might need to present and field questions. Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010706070809060504020409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEx OTE4NDMxNVowIwYJKoZIhvcNAQkEMRYEFNdGsdKqd/xZK/IYHnGJnz2TIUWDMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAsqW4DQ6qTIs3/7tsVGioiml/j7R0X7qLe+aAOcTQ9LTA6jFSeut8vgf04 OR82Qz4gLq+TlCxylD8NXcFeGxOmhS6TmiI1SjECHQtYemt8RQs/a+KNb5d9dIf7do2Y8lcY cGQ6oigQ54m16cSzUtAN3Xa2EsMcQSUMt5Dc2jJDX+waIGUe7iImqiPy/WL9+TdIcnEPrz1K 042rXzm5y81jpeHJnTJrkRyJ/TzQjt1ZsMSP8r4NVO96BARETjEToemGKHXPAXY+BSOlIioX fU2QlK9Dx24FIGWMu8NuyFDFg8nC0a76LugIiXmriGiP9w+UwUgW3oXh2Ifn7LBqox3vAAAA AAAA --------------ms010706070809060504020409-- From Claudio.Allocchio@garr.it Thu Jan 20 09:02:12 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40B183A7037 for ; Thu, 20 Jan 2011 09:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 Q5smz7q9l7o5 for ; Thu, 20 Jan 2011 09:02:11 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 896063A6FDE for ; Thu, 20 Jan 2011 09:02:10 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p0KH4hRb010915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jan 2011 18:04:43 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p0KH4hRb010915 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=qSkhwHU1ypuHAcICZ6iwHmb797Z7YWKd0Sy1/f6NsG6cwqN47ycNwQDgR8qJxhunV URFU0PXV5yMqqvlKzIgFHQObPlgAGKM35yiXEg24Vu3mXPagPORWwiY0dBe2PHzxeN3 X2YOC0R/Pet22GX9ed3UoLyavfWJCsRc8RXxmlM= Date: Thu, 20 Jan 2011 18:04:42 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: "Murray S. Kucherawy" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Shawn.Steele@microsoft.com" , John C Klensin , "apps-discuss@ietf.org" , "abelyang@twnic.net.tw" Subject: Re: [apps-discuss] apps-review team review for draft-ietf-eai-rfc5335bis-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:02:12 -0000 > The Security Considerations section should discuss the problem of having > UTF-8 aware transport (i.e. MTAs) coupled with UTF-8 unaware user agents > (e.g. readers) as well as filters and the like. The author talks about > needing bigger buffers, but I think that's far less interesting than the > possible semantic implications. I consider this a major issue, and so I > would expect this discussion to be non-trivial in size, and include some > admonishment about not upgrading a delivery MTA to support UTF-8 message > headers until the entire infrastructure it serves has already been > verified to handle it. This might be discussed in one of the other EAI > documents already; if it is, this one should contain a reference to > that. a late (never too late!) +1 > > On a related note, Security Considerations should also talk about abuse > mechanisms. If, for example, there are lots of ways of using UTF-8 to > represent something equivalent or similar to a particular displayed > character or group of characters (all the variants of "e" in French, > using accents, for example), then filtering systems can be bypassed by > using one of the variants to avoid detection while still reaching the > end user with largely the same original effect. This too might be > discussed elsewhere in general, in which case a reference to that > discussion can be left here. and another +1 here! ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From evnikita2@gmail.com Mon Jan 24 01:16:46 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8143A6827 for ; Mon, 24 Jan 2011 01:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 Ut3tC8CbKYeO for ; Mon, 24 Jan 2011 01:16:45 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 61C183A63EB for ; Mon, 24 Jan 2011 01:16:45 -0800 (PST) Received: by yxt33 with SMTP id 33so1408825yxt.31 for ; Mon, 24 Jan 2011 01:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=vsY+WOo1Ztpf4cUe+RZVEs0PB8jQCBY45FBfi+VIv94=; b=QPTzG7CiUWssqbeQ1/nE7HIKSYVD7ZzhpG+b5xQQC9whiLcXX1wN+dxkTTWuhMvx8n zaj8aXqCnaGiTKmTlXhgTcJfXhH+wcKd1vym/BHSUL8RerblW7NNMaLWk+nJSByubR7c VHZoZWQGn5wbe8t6rzbBsvUkWfaYKEkZcRmgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=IbaQgSxuQhLmOmDI3B6rwp+S9+uVZn31XMwDAIVhbm9NpjLzVaxrFe+w1xZDEswozg yxKGimVPduawmnjxDqiELB/ybSLZdjaB7U2lCIKe7NSsi6fD2GyD+D0lbfFJsNwR8MoP eVkdWzFzjUd0tE1SLuxHTmWzGhCpqjGfu2sbQ= MIME-Version: 1.0 Received: by 10.151.42.18 with SMTP id u18mr223909ybj.269.1295860779193; Mon, 24 Jan 2011 01:19:39 -0800 (PST) Received: by 10.150.53.6 with HTTP; Mon, 24 Jan 2011 01:19:39 -0800 (PST) Date: Mon, 24 Jan 2011 11:19:39 +0200 Message-ID: From: Mykyta Yevstifeyev To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Revising Full Standards X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 09:16:46 -0000 Hello all, There are a number of Full Standards (STD20-26), that, IMO, need revsising. Firstly, all of these documents define the protocols only for TCP and UDP, and that might be useful to define them for such protocols, as DCCP or SCTP. Moreover, in spite of being the Full Standards, it does not meet the current practices and view of Internet Standards. So I'd like to ask whether making docs to obsolete these standards make any sense? Or it would be OK just to update the corresponding dosuments for DCCP and SCTP? All the best, Mykyta Yevstifeyev From barryleiba.mailing.lists@gmail.com Mon Jan 24 18:32:26 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A7F3A6B58 for ; Mon, 24 Jan 2011 18:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.811 X-Spam-Level: X-Spam-Status: No, score=-102.811 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 h35gGi+ShqBn for ; Mon, 24 Jan 2011 18:32:26 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E4F633A6B54 for ; Mon, 24 Jan 2011 18:32:25 -0800 (PST) Received: by iwn40 with SMTP id 40so5126992iwn.31 for ; Mon, 24 Jan 2011 18:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4kUKKHPO/j6VzYlwYWBXEzeGvQItqJnhruXa6nTNVFs=; b=lCItrWr6cfH/HxhFpgZmsf4pc9voSy2T/m2FEZ7zFvX80t8vrSXTskNXUw9/6W/CGv cV4gY7bR3MSoS/O6SDSYk0uWqM9GANA2TUytlxMMJZnuMALjoxj8qPo0n/4ITUrX3CXT l50uafqhZPnxPSX31YF7vKC3SERK60UMsCqHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=tQnt5eyJbYlKSSWdxEDAwQ1wvITRp8xApMBhyURpyVOdV7+dmI0Ajx1bUsEW1CgiEt qkHRW9CO61qF0T5/Tvu7neL1pZ8/ietIb6Pqw6jyYoiFlGA4wdJEure2iD35OoxyuTJ+ YyeVtWouxoKsztJ7367v5ePLuzVzHLoEiWpqE= MIME-Version: 1.0 Received: by 10.42.229.5 with SMTP id jg5mr5825523icb.353.1295922922098; Mon, 24 Jan 2011 18:35:22 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.227.193 with HTTP; Mon, 24 Jan 2011 18:35:22 -0800 (PST) In-Reply-To: <4D33AC5F.3010609@vpnc.org> References: <4D33AC5F.3010609@vpnc.org> Date: Mon, 24 Jan 2011 21:35:22 -0500 X-Google-Sender-Auth: E6ujY7Dig3VOP_d3-LpJIn6qPc4 Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 02:32:27 -0000 Jiankang, Alexey, and I have discussed this, and we think the document (see below) is appropriate for the appsawg to adopt, review, and discuss. I would like to hear, as soon as possible and in any case by 4 Feb, any objections to adoption of the document by appsawg. I am also asking participants here to please review the document and begin discussion on this mailing list. Barry, as appsawg chair On Sun, Jan 16, 2011 at 9:41 PM, Paul Hoffman wrote= : > Greetings again. I would like this WG to consider adopting the following > draft as a WG item. It is definitely apps-related, and there is no other > appropriate WG in the Applications or Security areas for it. It has been > discussed in the websec WG, but that WG is limited to HTTP only (and this > document covers TLS for all application protocols). > > FWIW, some of the topics in this draft are quite open for active discussi= on. > The discussion in websec brought up some interesting issues, but they got > discussed in the HTTP context only, and this WG would be a better place t= o > discuss them for all server protocols. > > --Paul Hoffman > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Specifying That a Server Suppo= rts TLS > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : P. Hoffman > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-hoffman-server-has-tls-03.= txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 8 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-01-16 > > A server that hosts applications that can be run with or without TLS > may want to communicate with clients whether the server is hosting an > application only using TLS or also hosting the application without > TLS. =A0Many clients have a policy to try to set up a TLS session but > fall back to insecure if the TLS session cannot be set up. =A0If the > server can securely communicate whether or not it can fall back to > insecure tells such a client whether or not they should even try to > set up an insecure session with the server. =A0This document describes > the use cases for this type of communication and a secure method for > communicating that information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hoffman-server-has-tls-03.txt > _______________________________________________ From simon@josefsson.org Tue Jan 25 01:40:10 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814483A6A85 for ; Tue, 25 Jan 2011 01:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.656 X-Spam-Level: X-Spam-Status: No, score=-102.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 cHnOvlLqYYb9 for ; Tue, 25 Jan 2011 01:40:09 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 43C9E3A6A81 for ; Tue, 25 Jan 2011 01:40:08 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0P9glEp029013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 25 Jan 2011 10:42:50 +0100 X-Hashcash: 1:22:110125:apps-discuss@ietf.org::kMXNLgGZQUYi4FWa:C1eI From: Simon Josefsson To: apps-discuss@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Tue, 25 Jan 2011 10:42:48 +0100 Message-ID: <87wrlt2uav.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Subject: [apps-discuss] draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 09:40:10 -0000 I believe the goal of this document is great and I would like to see it happen in one form or the other. Diving into some details... It says: Secure Only (SSO) -- The server responds using TLS on the TLS- specific port for the application. For example, a host for a web server only responds to HTTP requests on port 443. Alternately, if the application supports in-band security update (such as STARTTTLS for SMTP), the server responds on the normal port, tries to establish a TLS session, and does not proceed with the protocol if a TLS session cannot be established. The distinction between STARTTLS-capable protocols and non-STARTTLS-capable protocols is not as clear as you might think here. There is RFC 2817 for STARTTLS over HTTP, which is run over port 80. In general, I think the document is confusing "secure" form with non-STARTTLS TLS-wrapped form. For example: Given a particular client application configuration, there are three interesting types of clients: Insecure Only (CIO) -- The client is configured to only attempt communication for the application in its insecure form. For example, a POP client might be configured to only try insecure POP on port 110. Secure Only (CSO) -- The client is configured to only attempt communication for the application in its secure, TLS-wrapped form. For example, a POP client might be configured to only try secure POP on port 995. Allows Fallback From Secure to Insecure (CFB) -- The client is configured to attempt communication for the application in its secure, TLS-wrapped form, but if it fails to set up a TLS session, the client will attempt to attempt communication to the same server using the insecure form. This doesn't match existing clients since it doesn't acknowledge STARTTLS heuristics. A classification that better matches existing clients would be this one: Given a particular client application configuration, there are five interesting types of clients: Insecure only - the client doesn't use TLS at all. Insecure upgrade - the client connects without TLS and upgrades to TLS using a STARTTLS mechanism if it is available. If STARTTLS is not available, it proceeds insecurely. Fall-back - the client first attempts to connect on the TLS-wrapped port (non-STARTTLS) and on failures reverts back to the insecure port and becomes a Insecure only, Insecure upgrade or Secure Upgrade client. Secure Only - the client only connects to the TLS-wrapped port, and on failures gives up. Secure Upgrade - the client connects without TLS and upgrades to TLS using a STARTTLS mechanism. If STARTTLS is unavailable, connection fails. Thoughts? /Simon From lear@cisco.com Tue Jan 25 07:36:24 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776513A67EC for ; Tue, 25 Jan 2011 07:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.202 X-Spam-Level: X-Spam-Status: No, score=-110.202 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 jZjWmswd812h for ; Tue, 25 Jan 2011 07:36:23 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3A77A3A6801 for ; Tue, 25 Jan 2011 07:36:23 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIEANt9Pk2Q/khLgWdsb2JhbACEEqBcFQEBCwsiJKFDil+QY4Ejgzh0BIwo Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 25 Jan 2011 15:39:03 +0000 Received: from ams3-vpn-dhcp4915.cisco.com (ams3-vpn-dhcp4915.cisco.com [10.61.83.50]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p0PFd4JC016194; Tue, 25 Jan 2011 15:39:05 GMT Message-ID: <4D3EEE94.2090801@cisco.com> Date: Tue, 25 Jan 2011 16:39:00 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Barry Leiba References: <4D33AC5F.3010609@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 15:36:24 -0000 Barry, Paul, This is an important draft that has broad impact. In particular, this approach would trim the double IANA port assignment requests that do occur and that we would like to see not occur. I do have several substantial comments about the draft: 1. The draft states that DNSSEC MUST be used, and there is some logic to this. If you have an unprotected communication then it is possible for both an upgrade DOS attack and downgrade MITM attack. That having been said, let's at least note that this is a substantial gating function to implementation. 2. I don't understand unde what circumstances CFB would be used. The reason that such fallback mechanisms exist is because the client doesn't have knowledge of what server capabilities are. In this case, the server through DNS is expressing its capabilities to the client, so when is CSO applicable? 3. The presentation form of the new RR is not self-explanatory. Might I recommend something like (servicename-or-number/protocol TLS=port# plain=port#). 4. In the case of a hostname that offers many services and may be in some way virtualized, the client may have to sift through quite a number of 3-tuples to retrieve relevant information. Another approach would be to make use of a DKIM-like approach in the RR label, although one would have to take care that a label not contain all numbers (I seem to recall that's not allowed). 5. Perhaps most important, this service should be generalized in a different way. What is being proposed here is a host connection policy record. TLS is not the only issue. Another issue would be whether SCTP is in use for a given, for instance. I wonder if this draft should be recast in a more extensible approach, so that a host doesn't need to query for a bunch of records (TCP, DTLS, SCTP, etc.). 6. Along these lines we should view this as an evolution of SRV. Thanks, Eliot On 1/25/11 3:35 AM, Barry Leiba wrote: > Jiankang, Alexey, and I have discussed this, and we think the document > (see below) is appropriate for the appsawg to adopt, review, and > discuss. I would like to hear, as soon as possible and in any case by > 4 Feb, any objections to adoption of the document by appsawg. I am > also asking participants here to please review the document and begin > discussion on this mailing list. > > Barry, as appsawg chair > > On Sun, Jan 16, 2011 at 9:41 PM, Paul Hoffman wrote: >> Greetings again. I would like this WG to consider adopting the following >> draft as a WG item. It is definitely apps-related, and there is no other >> appropriate WG in the Applications or Security areas for it. It has been >> discussed in the websec WG, but that WG is limited to HTTP only (and this >> document covers TLS for all application protocols). >> >> FWIW, some of the topics in this draft are quite open for active discussion. >> The discussion in websec brought up some interesting issues, but they got >> discussed in the HTTP context only, and this WG would be a better place to >> discuss them for all server protocols. >> >> --Paul Hoffman >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Specifying That a Server Supports TLS >> Author(s) : P. Hoffman >> Filename : draft-hoffman-server-has-tls-03.txt >> Pages : 8 >> Date : 2011-01-16 >> >> A server that hosts applications that can be run with or without TLS >> may want to communicate with clients whether the server is hosting an >> application only using TLS or also hosting the application without >> TLS. Many clients have a policy to try to set up a TLS session but >> fall back to insecure if the TLS session cannot be set up. If the >> server can securely communicate whether or not it can fall back to >> insecure tells such a client whether or not they should even try to >> set up an insecure session with the server. This document describes >> the use cases for this type of communication and a secure method for >> communicating that information. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-hoffman-server-has-tls-03.txt >> _______________________________________________ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From barryleiba.mailing.lists@gmail.com Tue Jan 25 18:12:46 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E46A3A6902 for ; Tue, 25 Jan 2011 18:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.815 X-Spam-Level: X-Spam-Status: No, score=-102.815 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 buVneIn2krER for ; Tue, 25 Jan 2011 18:12:45 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4D2143A68D5 for ; Tue, 25 Jan 2011 18:12:45 -0800 (PST) Received: by iwn40 with SMTP id 40so470539iwn.31 for ; Tue, 25 Jan 2011 18:15:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=zdknrxhUXx8R/dpgU6Vn7n1AHlDVFMKGKviIuLiJH3I=; b=hyeflM83uKec8F+aiJPcOXt/j5yxpmgw7B3LkFMH5DYqWONjbEYOli/dNI9/46FH4v ywWTkXYOfwywvqs5/8B22Q3InmIX5PQ0g1edKnqOOAD/VLHrwPEM2yrYDQfPK8/TmLw9 ENXbN6KFRR/YbFsRuDpYRxlzyMP2z0BoS2Ig0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=Wi0M+Kjnfm/Q9k9H4VHHkPa0/KG33T44oR1A/pG2lk0CxbfCHpmpqtI0BZAsovOB5B tjP82LL6LmIBC8ZfMryQPiI9o54Xxg98Cp2EEWFYlDlA4684RgKm8atw9hbDiE6mMG8z mTTK9VQyPPDFBbJZNZMhLHk6iC9sLHvHbB0vw= MIME-Version: 1.0 Received: by 10.42.218.200 with SMTP id hr8mr7625467icb.219.1296008144205; Tue, 25 Jan 2011 18:15:44 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.227.193 with HTTP; Tue, 25 Jan 2011 18:15:44 -0800 (PST) Date: Tue, 25 Jan 2011 21:15:44 -0500 X-Google-Sender-Auth: QlDkG_bwiDIK7bClhoz5-_5fXQM Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] For consideration as an appsawg document: draft-faltstrom-5892bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 02:12:46 -0000 This document was one we discussed at IETF 79 in Beijing, and the chairs and ADs recommend that the appsawg working group adopt, review, and discuss it. The document deals with bringing IDNAbis (IDNA 2008) up to the Unicode 6.0 level. At issue are three particular code points that have been reclassified by Unicode 6.0. While we discussed the document in Beijing, it has changed since then, in that its recommendation is very different to the version that was posted at the time. This is the abstract from the -01 version, posted in December: This document specifies IETF consensus related to and changes made to Unicode when version 6.0 was released on Oct 11 2011. The consensus is that no update is needed to RFC 5892 based on the changes made in Unicode 6.0. The appsawg chairs will be looking for objections to accepting this as a working group document; please make such objections by 4 Feb. In any case, please review the document and comment on it. We'd like to see whether the applications area supports the consensus claim made in the abstract above, or does not... so please post comments either way. Barry, appsawg chair From barryleiba.mailing.lists@gmail.com Tue Jan 25 18:17:03 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C4E3A690E for ; Tue, 25 Jan 2011 18:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.816 X-Spam-Level: X-Spam-Status: No, score=-102.816 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 RGazePRJJFeI for ; Tue, 25 Jan 2011 18:17:02 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id D45593A68D5 for ; Tue, 25 Jan 2011 18:17:02 -0800 (PST) Received: by iyi42 with SMTP id 42so6362230iyi.31 for ; Tue, 25 Jan 2011 18:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=RouWsQkFXyt6YT5JIf5ZsGUe8DG7skxX42J6z4sZXjo=; b=MgMT3TDfkfGCws95KqZw9HOi73lfRlyX49Y/KAgwRq8M1f8MyGoDXDGhatKYLR969j RW+r31SIJyy4x42hdhiYC8/Q/THtnQp8RFNM+P19m6Pu332d6U/Sg5vFyxcajJwlBvJE mGT1qk0r5gs44UPtuocnVIgiHeWRBqQYNraYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=D/eyuvag92gr4vvyJCW+UAYBqn/QOS/y5bjWXN6IRf2OTue119nDPdDA+XshK6EMv8 uxkBHOrdaaqpYzAMNT3/6W3MZmumzfwYkFfLwwWWJpZjTAK6Y9vQzGr8guMLEhE94OBL ZjR+GbXLdRvXmHXtKUAiuuKNS1cHw28EyWeQg= MIME-Version: 1.0 Received: by 10.42.229.5 with SMTP id jg5mr7610248icb.353.1296008401960; Tue, 25 Jan 2011 18:20:01 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.227.193 with HTTP; Tue, 25 Jan 2011 18:20:01 -0800 (PST) In-Reply-To: References: Date: Tue, 25 Jan 2011 21:20:01 -0500 X-Google-Sender-Auth: 4L7F_b1Bz59wf0ilhQ22QVNWatE Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-faltstrom-5892bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 02:17:03 -0000 > This document was one we discussed at IETF 79 in Beijing, and the > chairs and ADs recommend that the appsawg working group adopt, review, > and discuss it. Sorry; I meant to include a link to the document: http://tools.ietf.org/html/draft-faltstrom-5892bis Barry From barryleiba.mailing.lists@gmail.com Tue Jan 25 18:29:21 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA6E3A6917 for ; Tue, 25 Jan 2011 18:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.818 X-Spam-Level: X-Spam-Status: No, score=-102.818 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 x9jq6nyc0F+p for ; Tue, 25 Jan 2011 18:29:20 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6BEB03A68D5 for ; Tue, 25 Jan 2011 18:29:20 -0800 (PST) Received: by iwn40 with SMTP id 40so481174iwn.31 for ; Tue, 25 Jan 2011 18:32:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=K4CcICk0rVsMGtoJAL7H5PaJEj/f1HPf6E+uOGeZgD8=; b=NxIhIzLISRBfmVXNuTZRsZ5wycE8mW63/t8joCXxmxDFxhKqz6tawxzQsz+TY54+Qb h53lktUOMGOYcN6UGknvXstgV2cG4dnMbtRYrpmEgxUVJ41WEd+Ks2yFU0i23x2UGzSP /vk5Hp3vLpcWNmLhvYVRnyGkYNduHijkexdmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=BjJSo1accHSjNXZiJgBoiBzCq6jiZlrc4VUyrwA9Ap8QM8X6tGhK955/u2Qf6rsyLC 5xTkJW7ZGLXFRPHjHvRUHZhLGyxT7P6U+YUcNeJx44GwE+XPl4En7jv+22yr5Tcu8VFp hm+dM+yr6GLpwcS23mviGBXPIr7OLYW64bqmU= MIME-Version: 1.0 Received: by 10.42.180.130 with SMTP id bu2mr7660025icb.18.1296009138332; Tue, 25 Jan 2011 18:32:18 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.227.193 with HTTP; Tue, 25 Jan 2011 18:32:18 -0800 (PST) Date: Tue, 25 Jan 2011 21:32:18 -0500 X-Google-Sender-Auth: R2ebYqA26PClxXjr3qOEEFe3kp4 Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] For consideration as an appsawg document: draft-nottingham-http-portal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 02:29:21 -0000 http://tools.ietf.org/html/draft-nottingham-http-portal This document has been discussed briefly on the httpbis mailing list, but it's not a product of that working group. The discussions were some time ago, and there wasn't a lot; see the following two threads: -00 version: http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0156.html http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0157.html http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0193.html http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0196.html -01 version: http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0197.html http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0004.html The document has sat with no discussion since then, and the appsawg chairs and ADs recommend that the working group adopt, review, and discuss it. Please copy discussion to both lists -- this one, and also the httpbis list, . The appsawg chairs will be looking for objections to accepting this as a working group document; please make such objections by 4 Feb. In any case, please review the document and comment on it. This document needs broad review and consensus across the applications area. Barry, appsawg chair From mnot@mnot.net Tue Jan 25 18:48:42 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81A323A68FD for ; Tue, 25 Jan 2011 18:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.582 X-Spam-Level: X-Spam-Status: No, score=-104.582 tagged_above=-999 required=5 tests=[AWL=-1.983, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 sxoqx-AKpf9V for ; Tue, 25 Jan 2011 18:48: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 1D4433A6840 for ; Tue, 25 Jan 2011 18:48:39 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.1.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AD88C509D9; Tue, 25 Jan 2011 21:51:32 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Wed, 26 Jan 2011 13:51:27 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <8F92F7CF-7482-4DEA-86F3-7D4965A616B8@mnot.net> References: To: Barry Leiba X-Mailer: Apple Mail (2.1082) Cc: HTTP Working Group , apps-discuss@ietf.org Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-nottingham-http-portal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 02:48:43 -0000 I wouldn't be averse to this.=20 However, some implementation experience is necessary. In particular, I'd = like to run an experiment where the status code is deployed on a captive = portal in a large network, to see if it affects current implementations. The IETF meeting network seems like an ideal place to do so, and I've = pinged ietf-management@ietf.org (last August) about doing so, but = haven't had any response. It also needs adoption by people who use captive portals. To that end, = I've had some positive interactions with the Wireless Broadband Alliance = about the draft, but that discussion tailed off = without any conclusive action. I've also had some (brief) discussions = with a few Squid developers (Squid is often used to interpose captive = portals), and there was interest in supporting the draft, but this also = needs following up. Cheers, On 26/01/2011, at 1:32 PM, Barry Leiba wrote: > http://tools.ietf.org/html/draft-nottingham-http-portal >=20 > This document has been discussed briefly on the httpbis mailing list, > but it's not a product of that working group. The discussions were > some time ago, and there wasn't a lot; see the following two threads: >=20 > -00 version: > http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0156.html > http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0157.html > http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0193.html > http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0196.html >=20 > -01 version: > http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0197.html > http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0004.html >=20 > The document has sat with no discussion since then, and the appsawg > chairs and ADs recommend that the working group adopt, review, and > discuss it. Please copy discussion to both lists -- this one, and > also the httpbis list, . >=20 > The appsawg chairs will be looking for objections to accepting this as > a working group document; please make such objections by 4 Feb. In > any case, please review the document and comment on it. This document > needs broad review and consensus across the applications area. >=20 > Barry, appsawg chair > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From barryleiba.mailing.lists@gmail.com Tue Jan 25 18:52:17 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5679A3A687E for ; Tue, 25 Jan 2011 18:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.82 X-Spam-Level: X-Spam-Status: No, score=-102.82 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 71GMbPgDDy3F for ; Tue, 25 Jan 2011 18:52:16 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 8B0183A6847 for ; Tue, 25 Jan 2011 18:52:16 -0800 (PST) Received: by iyi42 with SMTP id 42so6383623iyi.31 for ; Tue, 25 Jan 2011 18:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SKxNAii3klxYA/eOO8ramFNNEyrtqqQFY1o9U21FVos=; b=ggXral+I6gBofTUC9ETdIxX+eRZPjjFSklGyXWkX4BLFx3YOUY7I8e/n7I7p4y00lR R0Wn+TIlkLJLH4wWEE2DIeKDYZl3au6E3kPoK5sef/QnAvd288lFZrlwTbvXlPd1dFng fJK9/7JbYFrBNPjm/mQHggVuxnq10h0ZT/YgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=YANSTeeQTTL/LP/bqgdOrvOQndllhG/xamBsXbSvHPT24fNXF0+FochdD2FtVw8F74 oHrLKtWtYsKhIEy1ix1ZyD+WyP/ZqdnbLoFZ0gZ8kXArcv5ZcLGcOIkyYXn1Zp3u5d2a njheEbMSgZ1hcOyelyoq/3KMEKsq1iFEaOpIo= MIME-Version: 1.0 Received: by 10.42.220.4 with SMTP id hw4mr7631579icb.420.1296010515811; Tue, 25 Jan 2011 18:55:15 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.227.193 with HTTP; Tue, 25 Jan 2011 18:55:15 -0800 (PST) In-Reply-To: <8F92F7CF-7482-4DEA-86F3-7D4965A616B8@mnot.net> References: <8F92F7CF-7482-4DEA-86F3-7D4965A616B8@mnot.net> Date: Tue, 25 Jan 2011 21:55:15 -0500 X-Google-Sender-Auth: 7-RSGKGo9k_3zMkVz7SWUmI7Urg Message-ID: From: Barry Leiba To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Cc: HTTP Working Group , apps-discuss@ietf.org Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-nottingham-http-portal X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 02:52:17 -0000 > However, some implementation experience is necessary. In particular, I'd like to > run an experiment where the status code is deployed on a captive portal in a large > network, to see if it affects current implementations. That might mean that the target status of the document should, for now, be "experimental". The best way to get some experiments going, and to drive some experimental implementations, is to have an experimental spec. > The IETF meeting network seems like an ideal place to do so, and I've pinged > ietf-management@ietf.org (last August) about doing so, but haven't had any > response. Try sending Joel a note (he responded to your other query on the wgchairs list). Barry From mnot@mnot.net Tue Jan 25 19:01:03 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0963A68DB for ; Tue, 25 Jan 2011 19:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.566 X-Spam-Level: X-Spam-Status: No, score=-104.566 tagged_above=-999 required=5 tests=[AWL=-1.968, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 Lo2JXj3sA0az for ; Tue, 25 Jan 2011 19:01:02 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id C67783A687E for ; Tue, 25 Jan 2011 19:01:01 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.1.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F3AEC509D9 for ; Tue, 25 Jan 2011 22:03:58 -0500 (EST) From: Mark Nottingham Content-Type: multipart/alternative; boundary=Apple-Mail-4--123746281 Date: Wed, 26 Jan 2011 14:03:53 +1100 References: <89CE1E1F-7329-4CD0-BE88-64A7A49B7116@w3.org> To: apps-discuss@ietf.org Message-Id: <8C554E71-3863-40A2-9B43-8D78D4D51EDD@mnot.net> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [apps-discuss] Fwd: Web 2.0 Security and Privacy 2011 Workshop CFP X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 03:01:03 -0000 --Apple-Mail-4--123746281 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 FYI. (acting as liaison to the W3C) Begin forwarded message: > Resent-From: public-web-security@w3.org > From: Thomas Roessler > Date: 18 January 2011 5:48:47 AM AEDT > To: public-web-security@w3.org > Cc: Thomas Roessler > Subject: Web 2.0 Security and Privacy 2011 Workshop CFP > archived-at: = >=20 > The CFP is available online here: > http://www.w2spconf.com/2011/cfp.html >=20 >=20 >=20 >> =20 >> Web 2.0 Security and Privacy 2011 Workshop Call for Papers >> Important Dates >> Paper submission deadline: March 25, 2011 (11:59pm US-PST) >> Workshop acceptance notification date: April 22, 2011 >> Workshop date: Thursday, May 26, 2011 >> Workshop paper submission web site: http://submissions.w2spconf.com/ >> Previous W2SP Workshops: 2010, 2009, 2008, 2007 >> W2SP brings together researchers, practitioners, web programmers, = policy makers, and others interested in the latest understanding and = advances in the security and privacy of the web, browsers and their = eco-system. We have had four years of successful W2SP workshops. This = year, we will additionally invite selected papers to a special issue of = the journal. >> We are seeking both short position papers (2=964 pages) and longer = papers (a maximum of 10 pages). The scope of W2SP 2011 includes, but is = not limited to: >> Trustworthy cloud-based services >> Privacy and reputation in social networks >> Security and privacy as a service >> Usable security and privacy >> Security for the mobile web >> Identity management and psuedonymity >> Web services/feeds/mashups >> Provenance and governance >> Security and privacy policies for composible content >> Next-generation browser technology >> Secure extensions and plug-ins >> Advertisement and affiliate fraud >> Measurement study for understanding web security and privacy >> Workshop Co-Chairs >> Larry Koved (IBM Research) >> Dan S. Wallach (Rice University) >> Program Chair >> Helen J. Wang (Microsoft Research) >> Program Committee >> Dirk Balfanz (Google) >> Adam Barth (Google) >> Dan Boneh (Stanford) >> Suresh Chari (IBM Research) >> Hao Chen (UC Davis) >> Shuo Chen (MSR) >> Collin Jackson (CMU) >> Martin Johns (SAP Research) >> Larry Koved (IBM Research) >> Christopher Kruegel (UCSB) >> Ben Livshits (MSR) >> John C. Mitchell (Stanford University) >> Charlie Reis (Google) >> Thomas Roessler (W3C) >> V.N. Venkatakrishnan (UI Chicago) >> Dan S. Wallach (Rice University) >> Helen J. Wang (MSR) >> Mary Ellen Zurko (IBM Research) >> =20 >=20 -- Mark Nottingham http://www.mnot.net/ --Apple-Mail-4--123746281 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Resent-From: = public-web-security@w3.org<= br>
From: Thomas Roessler <tlr@w3.org>
Date: 18 January 2011 = 5:48:47 AM AEDT
Cc: Thomas Roessler <tlr@w3.org>
Subject: Web 2.0 Security = and Privacy 2011 Workshop CFP

The = CFP is available online here:
=  http://www.w2spconf.com/2011/cfp.html



 
Web = 2.0 Security and Privacy 2011 Workshop Call for Papers
Important Dates
Paper submission deadline: March 25, 2011 = (11:59pm US-PST)
Workshop acceptance notification = date: April 22, 2011
Workshop date: Thursday, May 26, = 2011
Workshop paper submission web site: http://submissions.w2spconf.com/
Previous W2SP Workshops: 2010, 2009, 2008, 2007
W2SP brings together researchers, = practitioners, web programmers, policy makers, and others interested in = the latest understanding and advances in the security and privacy of the = web, browsers and their eco-system. We have had four years of successful = W2SP workshops. This year, we will additionally invite selected papers = to a special issue of the journal.
We are seeking both short position papers (2=964 pages) and = longer papers (a maximum of 10 pages). The scope of W2SP 2011 includes, = but is not limited to:
  • Trustworthy cloud-based services
  • Privacy and reputation = in social networks
  • Security and privacy as a service
  • Usable security and = privacy
  • Security for the mobile web
  • Identity management and = psuedonymity
  • Web = services/feeds/mashups
  • Provenance and governance
  • Security and privacy = policies for composible content
  • Next-generation browser technology
  • Secure extensions and = plug-ins
  • Advertisement and affiliate fraud
  • Measurement study for = understanding web security and privacy
Workshop Co-Chairs
  • Larry Koved (IBM Research)
  • Dan S. Wallach (Rice = University)
Program Chair
  • Helen J. Wang (Microsoft = Research)
Program Committee
  • Dirk Balfanz (Google)
  • Adam Barth (Google)
  • Dan Boneh = (Stanford)
  • Suresh Chari (IBM Research)
  • Hao Chen (UC Davis)
  • Shuo Chen (MSR)
  • Collin Jackson = (CMU)
  • Martin Johns (SAP Research)
  • Larry Koved (IBM = Research)
  • Christopher Kruegel (UCSB)
    • Ben Livshits (MSR)
  • John C. Mitchell = (Stanford University)
  • Charlie Reis (Google)
  • Thomas Roessler = (W3C)
  • V.N.= Venkatakrishnan (UI Chicago)
  • Dan S. Wallach (Rice University)
  • Helen J. Wang (MSR)
  • Mary Ellen Zurko (IBM = Research)
 
=

http://www.mnot.net/



= --Apple-Mail-4--123746281-- From duerst@it.aoyama.ac.jp Tue Jan 25 23:09:05 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6BC3A6942 for ; Tue, 25 Jan 2011 23:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.234 X-Spam-Level: X-Spam-Status: No, score=-100.234 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPBCm6KAU8gu for ; Tue, 25 Jan 2011 23:08:34 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id 381873A684D for ; Tue, 25 Jan 2011 23:08:33 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p0Q7BQkd021539 for ; Wed, 26 Jan 2011 16:11:26 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6527_38ab_7d25ca80_291b_11e0_b6a8_001d096c5782; Wed, 26 Jan 2011 16:11:26 +0900 Received: from [IPv6:::1] ([133.2.210.1]:49720) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 26 Jan 2011 16:11:25 +0900 Message-ID: <4D3FC90B.3000205@it.aoyama.ac.jp> Date: Wed, 26 Jan 2011 16:11:07 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "idna-update@alvestrand.no" , apps-discuss@ietf.org Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-faltstrom-5892bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 07:09:06 -0000 Hello Barry, [cc (former) IDNA WG mailing list] The current -01 draft of this document was reviewed and discussed extensively on the (former) IDNA WG mailing list last December (see http://www.alvestrand.no/pipermail/idna-update/2010-December/thread.html). In my understanding, there was quite some agreement on what needed to be fixed, and these fixes were mostly editorial, although some of them on a very hight level. I have nothing against making that draft a working item of the Apps WG (hopefully being done with it very quickly, because it has already been discussed extensively on the IDNA list), but I'd prefer to do this in a way that avoids having to send in the same comments twice. My preference would be to have the authors integrate the comments from the IDNA list and then take the draft up here, because I think it will make it easier for reviewers here to review the draft. Regards, Martin. On 2011/01/26 11:15, Barry Leiba wrote: > This document was one we discussed at IETF 79 in Beijing, and the > chairs and ADs recommend that the appsawg working group adopt, review, > and discuss it. > > The document deals with bringing IDNAbis (IDNA 2008) up to the Unicode > 6.0 level. At issue are three particular code points that have been > reclassified by Unicode 6.0. > > While we discussed the document in Beijing, it has changed since then, > in that its recommendation is very different to the version that was > posted at the time. This is the abstract from the -01 version, posted > in December: > > This document specifies IETF consensus related to and changes made to > Unicode when version 6.0 was released on Oct 11 2011. The consensus > is that no update is needed to RFC 5892 based on the changes made in > Unicode 6.0. > > The appsawg chairs will be looking for objections to accepting this as > a working group document; please make such objections by 4 Feb. In > any case, please review the document and comment on it. We'd like to > see whether the applications area supports the consensus claim made in > the abstract above, or does not... so please post comments either way. [in a later mail] > Sorry; I meant to include a link to the document: > http://tools.ietf.org/html/draft-faltstrom-5892bis > Barry, appsawg chair > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From patrik@frobbit.se Tue Jan 25 23:09:11 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADFEC3A6948 for ; Tue, 25 Jan 2011 23:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.159 X-Spam-Level: X-Spam-Status: No, score=-102.159 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 6zIA1+hJc6pm for ; Tue, 25 Jan 2011 23:08:25 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id 1EB943A6837 for ; Tue, 25 Jan 2011 23:08:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id DF3A8F4D5372; Wed, 26 Jan 2011 08:11:23 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AV+bmASVeU4D; Wed, 26 Jan 2011 08:11:23 +0100 (CET) Received: from 95.209.37.214.bredband.tre.se (95.209.37.214.bredband.tre.se [95.209.37.214]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id C5284F4D52DB; Wed, 26 Jan 2011 08:11:22 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4D33AC5F.3010609@vpnc.org> Date: Wed, 26 Jan 2011 08:11:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D33AC5F.3010609@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 07:09:11 -0000 I have had a look at this, and have three questions: 1. Have I understood it correct if the client by using this RR can = refuse to fall back to insecure connection for "communication using = HTTP"? I.e. it seems the RR is specifying whether fallback is possible = to not only per port, which works when you have "STARTTLS" or similar, = but not when fallback is between ports? 2. If so, the "input" to the query should in that case be not only the = hostname, but the protocol and hostname, right? So one could use a = prefix-based mechanism like _http._tcp.example.com. IN HASTLS 0 443 0 3. I am always a bit nervous over RDATA that has variable length. Do you = have an implementation of this so that you have tried to ensure "it = works"? Otherwise, as someone said, overall negotiation I think is interesting. Patrik On 17 jan 2011, at 03.41, Paul Hoffman wrote: > Greetings again. I would like this WG to consider adopting the = following draft as a WG item. It is definitely apps-related, and there = is no other appropriate WG in the Applications or Security areas for it. = It has been discussed in the websec WG, but that WG is limited to HTTP = only (and this document covers TLS for all application protocols). >=20 > FWIW, some of the topics in this draft are quite open for active = discussion. The discussion in websec brought up some interesting issues, = but they got discussed in the HTTP context only, and this WG would be a = better place to discuss them for all server protocols. >=20 > --Paul Hoffman >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Specifying That a Server Supports TLS > Author(s) : P. Hoffman > Filename : draft-hoffman-server-has-tls-03.txt > Pages : 8 > Date : 2011-01-16 >=20 > A server that hosts applications that can be run with or without TLS > may want to communicate with clients whether the server is hosting an > application only using TLS or also hosting the application without > TLS. Many clients have a policy to try to set up a TLS session but > fall back to insecure if the TLS session cannot be set up. If the > server can securely communicate whether or not it can fall back to > insecure tells such a client whether or not they should even try to > set up an insecure session with the server. This document describes > the use cases for this type of communication and a secure method for > communicating that information. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-hoffman-server-has-tls-03.txt > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From evnikita2@gmail.com Wed Jan 26 02:18:58 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1BD3A697F; Wed, 26 Jan 2011 02:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 eDoevuOJaeHj; Wed, 26 Jan 2011 02:18:57 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 105003A6825; Wed, 26 Jan 2011 02:18:55 -0800 (PST) Received: by fxm9 with SMTP id 9so824840fxm.31 for ; Wed, 26 Jan 2011 02:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type; bh=zfUhmGCehru/y2x4Dc0y/iusKRYc8Lktub/cObhei3s=; b=CvN30GRK5TfOLGLLVfTaqvyXLioJXlvSfvlC51XrR0kQvHrV2CLABFpjmhAhyO9rDs OH6uNjORpJgE5iOg0xnMQXlRuY6L5+6eEQ/OfyDb0VWZRkWAa5xNdfp2ey8b0R3js0wy eu4fKbQWLFYKMcoJswyIIZ0oCDWqlO1NaIUh4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type; b=ok9NsSg+4jfbZsuR2tE0XMZuHnjEzMq43vC8uqsi7hstwpTJxAxafXW552FfP5riig llCHso9GEuV1g7RnKM4cdoSH+EylbmQ5cI/yrwnBedjyzXGhNzewDFZ0OpA+fY07vOlu bv4lOY9TDM53TQIC3VlJZdPrEZIAJQN2oe5BY= Received: by 10.223.86.196 with SMTP id t4mr1423300fal.34.1296037312662; Wed, 26 Jan 2011 02:21:52 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id e6sm5425067fav.8.2011.01.26.02.21.49 (version=SSLv3 cipher=RC4-MD5); Wed, 26 Jan 2011 02:21:51 -0800 (PST) Message-ID: <4D3FF5D4.2060900@gmail.com> Date: Wed, 26 Jan 2011 12:22:12 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF Discussion , iesg , "uri-review@ietf.org" Content-Type: multipart/alternative; boundary="------------020407090604000606070509" Cc: URI , "apps-discuss@ietf.org" Subject: [apps-discuss] Last Call summary on draft-yevstifeyev-tn3270-uri X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 10:18:59 -0000 This is a multi-part message in MIME format. --------------020407090604000606070509 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello all, This message summarizes the Last Call on draft-yevstifeyev-tn3270-uri (http://tools.ietf.org/id/draft-yevstifeyev-tn3270-uri-13.txt). Firstly, some statistical information. The Last Call was requested by Peter Saint-Andre on 4 January, 2011 and was announced on 4 January, 2011. The Last Call ends on 1 February, 2011. The LC announcement has been sent out to IETF Discussion, uri-review and URI@w3c.org mailing lists. A number of comments have been received during the Last Call. The most current version - 13 - I have just uploaded is believed to resolve them. Moreover, a number of improvements have been made to improve the document quality. Secondly, here is the exhaustive list of differences between the 12 version and 13 version. /Intended status/ - did not change: Informational; /Title/ - changed. Was *The 'tn3270' Uniform Resource Identifier Scheme* and now is *The 'tn3270' Uniform Resource Identifier (URI) Scheme*. I'm asking Peter to change the write0up in accordance to this. /Abstract/ - did not change; /Introduction/ - changed. Added the RFC 2119 boilerplate (now used throughout the document); added the reference to IANA registry; clarified the purpose of the document; some other minor changes. /Scheme definition/ - changed. Splitted the designated service into Telnet 3270 and Telnet 3270 Enchanted, added the reference to IBM Publication GA23-0059, related to 3270 data stream; added the reference to RFC 3049, related to TN3270E; clarified the URI syntax, as follows. Was: > The 'tn3270' URI takes the following form (given in ABNF, as > described inRFC 5234 [RFC5234 ]): > > tn3270uri = "tn3270:" "//" authority ["/"] > > The 'authority' rule is defined inRFC 3986 [RFC3986 ]. The final > character "/" can be omitted. > Now: > The 'tn3270' URI takes the following form (given in ABNF, as > described inRFC 5234 [RFC5234 ]): > > tn3270uri = "tn3270:" hier-part > hier-part = "//" authority ["/"] > ;the URI takes the form > ;tn3270://:@:/ > ;that is formally defined via the 'authority' > > The 'authority' rule is specified inRFC 3986 [RFC3986 ]. If 'port' > (in the 'authority' part) is omitted, it SHALL default to 21. The > final character "/" MAY be omitted. /Security Considerations/ - changed. Clarified why there are no other security considerations for 'tn3270' scheme other than the 'telnet' one has. /IANA Considerations/ - changed. added the reference to RFC 4395; changed the description of protocol, that uses the scheme in accordance with Section 2; changed the Contact and author to IESG and IETF, respectively. /References/ - RFC 4395 is now Informative; added the references to RFC 3049, IANA registry and IBM Publication GA23-0059. /Acknowledgments/ - corrected the typographical mistake in the last name of Alfred Hoenes. /Author's addresses/ - changed, clarified the address. Lastly, during the LC the document was reviewed by IANA, GenART and OPS-DIR Review Team. I'm citing their reviews. IANA: > IANA understands that, upon approval of this document, there is a single > Action that IANA needs to complete. > > In the URI schemes registry located at: > > http://www.iana.org/assignments/uri-schemes.html > > in the Provisional URI Schemes section, the follow registration will be > added: > > URI Scheme: tn3270 > Description: TN3270 Telnet Service > Reference: [RFC-to-be] > > IANA understands that this is the only action required upon approval of > this document. GenART: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-yevstifeyev-tn3270-uri-12 > Reviewer: Vijay K. Gurbani > Review Date: Jan-14-2011 > IETF LC End Date: Feb-02-2011 > IESG Telechat date: Unknown > > Summary: This draft is ready as an Informational RFC. > > Major issues: 0 > Minor issues: 0 > Nits/editorial comments: 0 > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ OPS-DIR: > -----Original Message----- > From:ops-dir-bounces@ietf.org [mailto:ops-dir-bounces@ietf.org] On > Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) > Sent: Wednesday, January 12, 2011 1:07 PM > To:ops-dir@ietf.org > Cc:draft-yevstifeyev-tn3270-uri-authors@tools.ietf.org > Subject: [OPS-DIR] OPS-DIR Review of draft-yevstifeyev-tn3270-uri-12 > > I reviewed draft-yevstifeyev-tn3270-uri-12 for its operational impacts.. > > Summary: > The document gives a specification of syntax, semantics and use of > 'tn3270' URI scheme. > > Obviously this is an individual submission without any document write-up > and supporting AD. > I would like to read a document write-up with the regular template even > if it is written by the author. > > The main purpose of the document, namely to update the IANA registration > of tn3270 URI scheme using the given registration template, should be > added to the Introduction section. In general I would suggest to include > in the Introduction section the purpose of the action and more > importantly why existing IANA registrations are not sufficient and why > the publication of this RFC is needed. > > Obviously the GEN-Area reviewer (Tom Petch) has an opposite opinion and > does not see this IANA registration in the interest of IETF (see > https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55119&tid=129 > 4831574). The reviewer furthermore states, following the rules in > RFC4395 the document should provide concrete contact information for the > editor instead of an anonymous email address only. > > I don't see any additional operation impact other than above. > > Other issues: > > - The used language needs some polishing. > > - Following are draft nits suggesting correction: > > == The copyright year in the IETF Trust and authors Copyright Line does > not > match the current year > > -> Use new template or: s/2010/2011/ > > -- Obsolete informational reference (is this intentional?): RFC 1738 > (Obsoleted by RFC 4248, RFC 4266) > > -> Use correct reference or clarify. > > > Mehmet > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir > The most current version is believed to resolve all the comments received. No changes are intended to be made up to the end of the LC. This message is to allow the IESG to preliminarily review the doc. Looking forward for the decision of IESG, Mykyta Yevstifeyev --------------020407090604000606070509 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello all,

This message summarizes the Last Call on draft-yevstifeyev-tn3270-uri (http://tools.ietf.org/id/draft-yevstifeyev-tn3270-uri-13.txt). 

Firstly, some statistical information.  The Last Call was requested by Peter Saint-Andre on 4 January, 2011 and was announced on 4 January, 2011.  The Last Call ends on 1 February, 2011.  The LC announcement has been sent out to IETF Discussion, uri-review and URI@w3c.org mailing lists.  A number of comments have been received during the Last Call.  The most current version - 13 - I have just uploaded is believed to resolve them.  Moreover, a number of improvements have been made to improve the document quality.

Secondly, here is the exhaustive list of differences between the 12 version and 13 version.

Intended status - did not change: Informational;

Title - changed.  Was The 'tn3270' Uniform Resource Identifier Scheme and now is The 'tn3270' Uniform Resource Identifier (URI) Scheme.  I'm asking Peter to change the write0up in accordance to this.

Abstract - did not change;

Introduction - changed.  Added the RFC 2119 boilerplate (now used throughout the document); added the reference to IANA registry; clarified the purpose of the document; some other minor changes.

Scheme definition - changed.  Splitted the designated service into Telnet 3270 and Telnet 3270 Enchanted, added the reference to IBM Publication GA23-0059, related to 3270 data stream; added the reference to RFC 3049, related to TN3270E; clarified the URI syntax, as follows.  Was:
The 'tn3270' URI takes the following form (given in ABNF, as
   described in RFC 5234 [RFC5234]):

   tn3270uri = "tn3270:" "//" authority ["/"]

   The 'authority' rule is defined in RFC 3986 [RFC3986]. The final
   character "/" can be omitted.

Now:

  The 'tn3270' URI takes the following form (given in ABNF, as
   described in RFC 5234 [RFC5234]):

   tn3270uri = "tn3270:" hier-part
   hier-part = "//" authority ["/"]
               ;the URI takes the form
               ;tn3270://<user>:<password>@<host>:<port>/
               ;that is formally defined via the 'authority'

   The 'authority' rule is specified in RFC 3986 [RFC3986].  If 'port'
   (in the 'authority' part) is omitted, it SHALL default to 21.  The
   final character "/" MAY be omitted.

Security Considerations - changed.  Clarified why there are no other security considerations for 'tn3270' scheme other than the 'telnet' one has.

IANA Considerations - changed.  added the reference to RFC 4395; changed the description of protocol, that uses the scheme in accordance with Section 2; changed the Contact and author to IESG and IETF, respectively.

References - RFC 4395 is now Informative; added the references to RFC 3049, IANA registry and IBM Publication GA23-0059.

Acknowledgments - corrected the typographical mistake in the last name of Alfred Hoenes.

Author's addresses - changed, clarified the address.

Lastly, during the LC the document was reviewed by IANA, GenART and OPS-DIR Review Team.  I'm citing their reviews.

IANA:
IANA understands that, upon approval of this document, there is a single
Action that IANA needs to complete.

In the URI schemes registry located at:

http://www.iana.org/assignments/uri-schemes.html

in the Provisional URI Schemes section, the follow registration will be
added:

URI Scheme: tn3270
Description: TN3270 Telnet Service
Reference: [RFC-to-be]

IANA understands that this is the only action required upon approval of
this document.

GenART:

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-yevstifeyev-tn3270-uri-12
Reviewer: Vijay K. Gurbani
Review Date: Jan-14-2011
IETF LC End Date: Feb-02-2011
IESG Telechat date: Unknown

Summary: This draft is ready as an Informational RFC.

Major issues: 0
Minor issues: 0
Nits/editorial comments: 0

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/

OPS-DIR:

-----Original Message-----
From: ops-dir-bounces@ietf.org [mailto:ops-dir-bounces@ietf.org] On
Behalf Of ext Ersue, Mehmet (NSN - DE/Munich)
Sent: Wednesday, January 12, 2011 1:07 PM
To: ops-dir@ietf.org
Cc: draft-yevstifeyev-tn3270-uri-authors@tools.ietf.org
Subject: [OPS-DIR] OPS-DIR Review of draft-yevstifeyev-tn3270-uri-12

I reviewed draft-yevstifeyev-tn3270-uri-12 for its operational impacts..

Summary:
The document gives a specification of syntax, semantics and use of
'tn3270' URI scheme.

Obviously this is an individual submission without any document write-up
and supporting AD.
I would like to read a document write-up with the regular template even
if it is written by the author.

The main purpose of the document, namely to update the IANA registration
of tn3270 URI scheme using the given registration template, should be
added to the Introduction section. In general I would suggest to include
in the Introduction section the purpose of the action and more
importantly why existing IANA registrations are not sufficient and why
the publication of this RFC is needed.

Obviously the GEN-Area reviewer (Tom Petch) has an opposite opinion and
does not see this IANA registration in the interest of IETF (see
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55119&tid=129
4831574). The reviewer furthermore states, following the rules in
RFC4395 the document should provide concrete contact information for the
editor instead of an anonymous email address only.

I don't see any additional operation impact other than above.

Other issues:

- The used language needs some polishing.

- Following are draft nits suggesting correction:

== The copyright year in the IETF Trust and authors Copyright Line does
not
   match the current year

-> Use new template or: s/2010/2011/

-- Obsolete informational reference (is this intentional?): RFC 1738
   (Obsoleted by RFC 4248, RFC 4266)

-> Use correct reference or clarify.


Mehmet

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
The most current version is believed to resolve all the comments received.

No changes are intended to be made up to the end of the LC.  This message is to allow the IESG to preliminarily review the doc.

Looking forward for the decision of IESG,
Mykyta Yevstifeyev
--------------020407090604000606070509-- From mnot@mnot.net Wed Jan 26 03:52:06 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291623A69AB for ; Wed, 26 Jan 2011 03:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.567 X-Spam-Level: X-Spam-Status: No, score=-104.567 tagged_above=-999 required=5 tests=[AWL=-1.968, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 m9UxHNbTcYw3 for ; Wed, 26 Jan 2011 03:52:05 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id E9BC03A6987 for ; Wed, 26 Jan 2011 03:52:04 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.1.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C1FF3509D9 for ; Wed, 26 Jan 2011 06:54:58 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2011 22:54:53 +1100 References: To: apps-discuss@ietf.org Message-Id: <1A875F6E-25AF-40A1-883D-6CDD622CE363@mnot.net> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [apps-discuss] Fwd: XML Prague 2011, 26-27 March 2011 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 11:52:06 -0000 Given that the plenary is immediately afterwards, this seems like an = excellent opportunity for XML folks to kill two birds with one stone, = and perhaps for IETF folks who use XML (or want to) to mingle with XML = experts. Cheers, Begin forwarded message: >> XML Prague 2011's theme is "Web and XML" and the organizers are now=20= >> welcoming submissions (before 5 January 2011) for presentations = related to: >>=20 >> * XML as a new lingua franca for the Web. Why did it never happen? >> * HTML5 and XHTML: breaking-up, coexistence or convergence? >> * JSON and XML love-in: how to enable Web Apps and Web Widgets? >> * XML Databases role in Web architecture. >> * XML and the emerging Semantic Web. >> * XML-based formats for electronic books. >>=20 >> Please find more details at: >> http://www.xmlprague.cz/2011/call-for-papers.html -- Mark Nottingham http://www.mnot.net/ From alexey.melnikov@isode.com Wed Jan 26 04:18:05 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A52703A69AB for ; Wed, 26 Jan 2011 04:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO2mKJDOE+pO for ; Wed, 26 Jan 2011 04:18:04 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9CF183A69B1 for ; Wed, 26 Jan 2011 04:18:04 -0800 (PST) Received: from [188.28.132.149] (188.28.132.149.threembb.co.uk [188.28.132.149]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 26 Jan 2011 12:21:03 +0000 Message-ID: <4D401196.8050903@isode.com> Date: Wed, 26 Jan 2011 12:20:38 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mykyta Yevstifeyev References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Revising Full Standards X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 12:18:05 -0000 Mykyta Yevstifeyev wrote: >Hello all, > Hi Mykyta, >There are a number of Full Standards (STD20-26), that, IMO, need >revsising. Firstly, all of these documents define the protocols only >for TCP and UDP, and that might be useful to define them for such >protocols, as DCCP or SCTP. Moreover, in spite of being the Full >Standards, it does not meet the current practices and view of Internet >Standards. > I haven't looked at specified Full Standards you mentioned above, so I am just commenting in general. >So I'd like to ask whether making docs to obsolete these standards >make any sense? Or it would be OK just to update the corresponding >dosuments for DCCP and SCTP? > > I think doing the latter is usually the preferred way. That wouldn't invalidate Full Standard status of documents for transport protocols they were originally specified for. > > From bensons@queuefull.net Wed Jan 26 00:09:15 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3727F3A6951 for ; Wed, 26 Jan 2011 00:09:15 -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 zClISQUZfvIB for ; Wed, 26 Jan 2011 00:09:06 -0800 (PST) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id B84833A6958 for ; Wed, 26 Jan 2011 00:09:06 -0800 (PST) Received: by pxi6 with SMTP id 6so31473pxi.31 for ; Wed, 26 Jan 2011 00:12:06 -0800 (PST) Received: by 10.142.43.1 with SMTP id q1mr35503wfq.344.1296029526073; Wed, 26 Jan 2011 00:12:06 -0800 (PST) Received: from [12.139.174.225] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id w22sm19922912wfd.7.2011.01.26.00.12.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 Jan 2011 00:12:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Benson Schliesser In-Reply-To: Date: Wed, 26 Jan 2011 00:12:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7A645677-DADD-41F8-BE10-6673C93DA4E4@queuefull.net> References: <4D33AC5F.3010609@vpnc.org> To: Barry Leiba X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Wed, 26 Jan 2011 08:17:30 -0800 Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 08:09:15 -0000 I support the general goal, and think this is a worthy WG item. However, similar to what other folks have said: I think using a single = HASTLS resource record per host to carry a variable number of = port/policy triples isn't the ideal approach. Rather, a single = port/policy triple should be associated with a protocol-specific record, = i.e. a record name based on SRV. If the SRV record format is leveraged, the HASTLS protocol needs to = define what service name gets used as a record name - the non-TLS = version (_http._tcp), TLS version (_https._tcp), both, neither (web), = etc. Further, the protocol needs to define how HASTLS records coexist with = SRV records. For instance, if there is a _http._tcp record and a = _https._tcp record, what does a given HASTLS record mean? Would a = triple "0 443 1" imply that _http._tcp SRV records shouldn't exist? And more fundamentally, is a HASTLS record any more useful than the = information gleaned by querying SRV records in the first place? Cheers, -Benson On Jan 24, 2011, at 6:35 PM, Barry Leiba wrote: > Jiankang, Alexey, and I have discussed this, and we think the document > (see below) is appropriate for the appsawg to adopt, review, and > discuss. I would like to hear, as soon as possible and in any case by > 4 Feb, any objections to adoption of the document by appsawg. I am > also asking participants here to please review the document and begin > discussion on this mailing list. >=20 > Barry, as appsawg chair >=20 > On Sun, Jan 16, 2011 at 9:41 PM, Paul Hoffman = wrote: >> Greetings again. I would like this WG to consider adopting the = following >> draft as a WG item. It is definitely apps-related, and there is no = other >> appropriate WG in the Applications or Security areas for it. It has = been >> discussed in the websec WG, but that WG is limited to HTTP only (and = this >> document covers TLS for all application protocols). >>=20 >> FWIW, some of the topics in this draft are quite open for active = discussion. >> The discussion in websec brought up some interesting issues, but they = got >> discussed in the HTTP context only, and this WG would be a better = place to >> discuss them for all server protocols. >>=20 >> --Paul Hoffman >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>=20 >> Title : Specifying That a Server Supports TLS >> Author(s) : P. Hoffman >> Filename : draft-hoffman-server-has-tls-03.txt >> Pages : 8 >> Date : 2011-01-16 >>=20 >> A server that hosts applications that can be run with or without TLS >> may want to communicate with clients whether the server is hosting an >> application only using TLS or also hosting the application without >> TLS. Many clients have a policy to try to set up a TLS session but >> fall back to insecure if the TLS session cannot be set up. If the >> server can securely communicate whether or not it can fall back to >> insecure tells such a client whether or not they should even try to >> set up an insecure session with the server. This document describes >> the use cases for this type of communication and a secure method for >> communicating that information. >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-hoffman-server-has-tls-03.txt >> _______________________________________________ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From jefsey@jefsey.com Wed Jan 26 08:54:22 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81E33A681F; Wed, 26 Jan 2011 08:54:22 -0800 (PST) X-Quarantine-ID: <82PeCo-qenLi> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char FC hex): To: "Martin J. D\374rst" ) id 1Pi8gD-0004Fy-AL; Wed, 26 Jan 2011 08:57:14 -0800 Message-Id: <7.0.1.0.2.20110126100411.05880f78@jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 26 Jan 2011 17:57:22 +0100 To: "Martin J. Dürst" , Barry Leiba From: JFC Morfin In-Reply-To: <4D3FC90B.3000205@it.aoyama.ac.jp> References: <4D3FC90B.3000205@it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1157263527==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Cc: info@incsa.org, "idna-update@alvestrand.no" , iucg@ietf.org, apps-discuss@ietf.org, iutf@iutf.org Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-faltstrom-5892bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 16:54:23 -0000 --=====================_1157263527==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Dear Barry, Thie http://tools.ietf.org/html/draft-faltstrom-5892bis draft proposes to reverse and publish an IETFconsensus in a one line sentence located in a security section. As you will understand it from the debate on the former WG/IDNABis mailing list, the agreement that Martin refers to was mostly found among the Unicode Members of this list, the proposed Draft restoring to a large extent the IETF dependence on Unicode that was severed by IDNA2008, as per its charter. The underlaying technical issue is not to be neglected, but Unicode is not the solution: even if it may simplify the engineering task, it has been denied by usage and this has resulted in IDNA2008. This question has led to the inclusion of the http://incsa.org (heavy but eventually necessary) project in the IUse community technical area. FYI, the IUse community is emerging from the introduction of the principle of subsidiarity in the Internet architecture by IDNA2008 (what the proposed I_D would repel) and is present within the IETF through a part of the Members of the iucg@ietf.org non-WG mailing list. Its IUTF (Intelligent Use Task Force) area was confirmed by the answers of the IESG and IAB to my appeals: IESG and IAB acknowledged the importance of this area (the IESG had partly qualified as research from my report and I_D, when approving IDNA2008) but did not agree and inform the IETF that it was something of specific importance within the IETF scope. Furthermore, in being people centered (cf. WSIS declarations), the IUTF area spans every technology, service, and use of the world digital ecosystem networks, and is not limited to the Internet. However, the IUse emerging community adheres to the Internet stratum architectural principles of permanent change as documented by RFC 1958, of simplicity as documented by RFC 3439, and subsidiarity as implied by RFC 5890 to 5895. These principles add to the IETF cardinal principles of Open process, Technical competence, Volunteer Core, Rough consensus and running code, and Protocol ownership as documented by RFC 3935. At this time, the IUse emerging community is discussing, for its own use, the cardinal principle of Multi-Consensus and living mode due to the topology of its IUI (Intelligent Use Interface) Internet encapsulating scope. We will also most probably add the principle of precaution of which the I_D was integrated in my IESG appeal. As the initial facilitator of the IUse community, my present health problems have created a delay for us in concerting our organization and relations with the IGF, @larges, Civil Society, consumers, and standardization bodies, which we hope to overcome before this summer. In addition, we have the exploration, development, and initial testing of the ML-DNS logic. I want to emphasize that the idea I initially explored with Lisa Dussault was to consider our concerns as matters belonging to the Application Area: the IUI concept, inherited from IDNA2008 and illustrated by RFC 5895, is only a milestone for me towards the Intersem stratum, the Semiotic Internet, and of the semantic facilitation services (Internet of thoughts). The borderline was difficult to determine. Initially, John Klensin provided a good definition: the separation between what belongs to scripts and what belongs to languages. However, this is inadequate because diversity is everywhere and not only in languages, and even in languages the separation is between orthotypography and meaning. In addition, a people centric approach, as is necessary in linguistic diversity (and as per the general international consensus), implies UIs with many technologies/services within many cultural/political contexts. The solution was, therefore, the IUI middle area being dedicated to the robust and stable Use of the Internet on the inner side, and to a modular Interfacing with the users' diversity on the outer side. This permits us to stay within what we call the "Internet PLUS" (plugged layers on the user side) content oriented domain, i.e. still outside of the semantic stratum. However, that fringe to fringe Internet Plus addition to the network hourglass, is where an Intelligent Internet experience (not network) can be provided (not imposed on) to users. To clarify this, we use my 25 year old terminology: ITU documents signal-based basic services, IETF documents passive content oriented value-added services, IUTF is to document active content extended services, and the step above will be semantic facilitation services. (N.B. active content is when the received content is designedly not equal to the sent content; facilitation's purpose is brain to brain intercomprehension). Fringe to fringe, active content extended services are obviously for interoperating with layer seven applications. The same, it will have to interoperate with the above layers on the user side. This points us towards a new principle that we need now to fully understand and document, which is uncoupling. This results from the fact that introducing the IUI does not call for a single bit level change in the Internet technology, nor a single coma in RFCs. It only results from a different reading of the RFCs: instead of reading them as documenting a single global decentralized or possibly decentralized system, we read them as documenting the _uncoupled_ parts of an intricate network. We use a proper (distributed relational spaces) and figuratively (virtual topology) image: "the networks of the network of networks". This is why the "IETF consensus is… that it is important IDNA standard is aligned with the Unicode Standard" is in definite, clear opposition with the above. Unicode covers the typographic area, the IETF the networking area, and IDNA2008 documents the way the networking area handles orthotypography. Unicode provides codes to ISO 10646 that multiple (including non-Internet) digital technologies - that are also used by Internet users - use to support the users' orthotypographies, while there is a major operating non-resolved issue, which is the impact of homography. This is why we need to protect the IDNA2008 consensus we found. This implies that your sentence would be appealed. We are at the beginning of a running code and a live testing effort based upon the IDNA2008 consensus. It probably represents a tremendous power growth capacity for the Internet (by what is called "multiplication by division"), and we cannot permit it to be confused, nor that people start building astray upon that confusion at this rather young stage. The BCP009 process must apply when documenting an "IETF consensus". This consensus must really be an IETF consensus, with an open debate, IAB guidance (IDNA specifics, and there are others on their agenda), Last Call, IESG decision, and Internet Users community support. This is not the case, at least yet. You realize that I would be the appellant: I am not sure that I can handle the workload, and I am not sure that the workload would really help the IETF because this is a point that was already addressed in a WG charter, correctly open in RFC 5892 and that should be consensually accepted by the regular IETF and IAB work on the matter, along with IUTF testing and Internet Community (users, manufacturers, operators, TLD managers) practical decisions within the coming two years. There is nothing to say more, except Patrick or someone else find sometimes that RFC 5892 turns incorrect or if someone explore, document and propose a compatible alternative to Unicode that would better fit the people's needs in a network environment which certainly differs from a typesetter workshop. Best, jfc At 08:11 26/01/2011, Martin J. Dürst wrote: >Hello Barry, > >[cc (former) IDNA WG mailing list] > >The current -01 draft of this document was reviewed and discussed >extensively on the (former) IDNA WG mailing list last December >(see >http://www.alvestrand.no/pipermail/idna-update/2010-December/thread.html). >In my understanding, there was quite some agreement on what needed >to be fixed, and these fixes were mostly editorial, although some of >them on a very hight level. > >I have nothing against making that draft a working item of the Apps >WG (hopefully being done with it very quickly, because it has >already been discussed extensively on the IDNA list), but I'd prefer >to do this in a way that avoids having to send in the same comments >twice. My preference would be to have the authors integrate the >comments from the IDNA list and then take the draft up here, because >I think it will make it easier for reviewers here to review the draft. > >Regards, Martin. --=====================_1157263527==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit
Dear Barry,

Thie http://tools.ietf.org/html/draft-faltstrom-5892bis draft proposes to reverse and publish an IETFconsensus in a one line sentence located in a security section. As you will understand it from the debate on the former WG/IDNABis mailing list, the agreement that Martin refers to was mostly found among the Unicode Members of this list, the proposed Draft restoring to a large extent the IETF dependence on Unicode that was severed by IDNA2008, as per its charter. The underlaying technical issue is not to be neglected, but Unicode is not the solution: even if it may simplify the engineering task, it has been denied by usage and this has resulted in IDNA2008. This question has led to the inclusion of the http://incsa.org (heavy but eventually necessary) project in the IUse community technical area.

FYI, the IUse community is emerging from the introduction of the principle of subsidiarity in the Internet architecture by IDNA2008 (what the proposed I_D would repel) and is present within the IETF through a part of the Members of the iucg@ietf.org non-WG mailing list. Its IUTF (Intelligent Use Task Force) area was confirmed by the answers of the IESG and IAB to my appeals: IESG and IAB acknowledged the importance of this area (the IESG had partly qualified as research from my report and I_D, when approving IDNA2008) but did not agree and inform the IETF that it was something of specific importance within the IETF scope. Furthermore, in being people centered (cf. WSIS declarations), the IUTF area spans every technology, service, and use of the world digital ecosystem networks, and is not limited to the Internet.

However, the IUse emerging community adheres to the Internet stratum architectural principles of permanent change as documented by RFC 1958, of simplicity as documented by RFC 3439, and subsidiarity as implied by RFC 5890 to 5895. These principles add to the IETF cardinal principles of Open process, Technical competence, Volunteer Core, Rough consensus and running code, and Protocol ownership as documented by RFC 3935. At this time, the IUse emerging community is discussing, for its own use, the cardinal principle of Multi-Consensus and living mode due to the topology of its IUI (Intelligent Use Interface) Internet encapsulating scope. We will also most probably add the principle of precaution of which the I_D was integrated in my IESG appeal.

As the initial facilitator of the IUse community, my present health problems have created a delay for us in concerting our organization and relations with the IGF, @larges, Civil Society, consumers, and standardization bodies, which we hope to overcome before this summer. In addition, we have the exploration, development, and initial testing of the ML-DNS logic.

I want to emphasize that the idea I initially explored with Lisa Dussault was to consider our concerns as matters belonging to the Application Area: the IUI concept, inherited from IDNA2008 and illustrated by RFC 5895, is only a milestone for me towards the Intersem stratum, the Semiotic Internet, and of the semantic facilitation services (Internet of thoughts). The borderline was difficult to determine.

Initially, John Klensin provided a good definition: the separation between what belongs to scripts and what belongs to languages. However, this is inadequate because diversity is everywhere and not only in languages, and even in languages the separation is between orthotypography and meaning.

 In addition, a people centric approach, as is necessary in linguistic diversity (and as per the general international consensus), implies UIs with many technologies/services within many cultural/political contexts.

The solution was, therefore, the IUI middle area being dedicated to the robust and stable Use of the Internet on the inner side, and to a modular Interfacing with the users' diversity on the outer side. This permits us to stay within what we call the "Internet PLUS" (plugged layers on the user side) content oriented domain, i.e. still outside of the semantic stratum. However, that fringe to fringe Internet Plus addition to the network hourglass, is where an Intelligent Internet experience (not network) can be provided (not imposed on) to users. To clarify this, we use my 25 year old terminology: ITU documents signal-based basic services, IETF documents passive content oriented value-added services, IUTF is to document active content extended services, and the step above will be semantic facilitation services. (N.B. active content is when the received content is designedly not equal to the sent content; facilitation's purpose is brain to brain intercomprehension).

Fringe to fringe, active content extended services are obviously for interoperating with layer seven applications. The same, it will have to interoperate with the above layers on the user side. This points us towards a new principle that we need now to fully understand and document, which is uncoupling. This results from the fact that introducing the IUI does not call for a single bit level change in the Internet technology, nor a single coma in RFCs. It only results from a different reading of the RFCs: instead of reading them as documenting a single global decentralized or possibly decentralized system, we read them as documenting the _uncoupled_ parts of an intricate network. We use a proper (distributed relational spaces) and figuratively (virtual topology) image: "the networks of the network of networks".

This is why the "IETF consensus is… that it is important IDNA standard is aligned with the Unicode Standard" is in definite, clear opposition with the above. Unicode covers the typographic area, the IETF the networking area, and IDNA2008 documents the way the networking area handles orthotypography. Unicode provides codes to ISO 10646 that multiple (including non-Internet) digital technologies - that are also used by Internet users - use to support the users' orthotypographies, while there is a major operating non-resolved issue, which is the impact of homography.

This is why we need to protect the IDNA2008 consensus we found. This implies  that your sentence would be appealed. We are at the beginning of a running code and a live testing effort based upon the IDNA2008 consensus. It probably represents a tremendous power growth capacity for the Internet (by what is called "multiplication by division"), and we cannot permit it to be confused, nor that people start building astray upon that confusion at this rather young stage. The BCP009 process must apply when documenting an "IETF consensus". This consensus must really be an IETF consensus, with an open debate, IAB guidance (IDNA specifics, and there are others on their agenda), Last Call, IESG decision, and Internet Users community support. This is not the case, at least yet.

You realize that I would be the appellant: I am not sure that I can handle the workload, and I am not sure that the workload would really help the IETF because this is a point that was already addressed in a WG charter, correctly open in RFC 5892 and that should be consensually accepted by the regular IETF and IAB work on the matter, along with IUTF testing and Internet Community (users, manufacturers, operators, TLD managers) practical decisions within the coming two years. There is nothing to say more, except Patrick or someone else find sometimes that RFC 5892 turns incorrect or if someone explore, document and propose a compatible alternative to Unicode that would better fit the people's needs in a network environment which certainly differs from a typesetter workshop.

Best,
jfc


At 08:11 26/01/2011, Martin J. Dürst wrote:
Hello Barry,

[cc (former) IDNA WG mailing list]

The current -01 draft of this document was reviewed and discussed extensively on the (former) IDNA WG mailing list last December
(see http://www.alvestrand.no/pipermail/idna-update/2010-December/thread.html). In my understanding, there was quite some agreement on what needed to be fixed, and these fixes were mostly editorial, although some of them on a very hight level.

I have nothing against making that draft a working item of the Apps WG (hopefully being done with it very quickly, because it has already been discussed extensively on the IDNA list), but I'd prefer to do this in a way that avoids having to send in the same comments twice. My preference would be to have the authors integrate the comments from the IDNA list and then take the draft up here, because I think it will make it easier for reviewers here to review the draft.

Regards,  Martin.

--=====================_1157263527==.ALT-- From tbray@textuality.com Wed Jan 26 16:58:47 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572AA28C0E3 for ; Wed, 26 Jan 2011 16:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 C60bYbFgvQaQ for ; Wed, 26 Jan 2011 16:58:46 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5451928C0E0 for ; Wed, 26 Jan 2011 16:58:46 -0800 (PST) Received: by fxm9 with SMTP id 9so1709655fxm.31 for ; Wed, 26 Jan 2011 17:01:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.79.6 with SMTP id n6mr182056fak.122.1296090107668; Wed, 26 Jan 2011 17:01:47 -0800 (PST) Received: by 10.223.126.212 with HTTP; Wed, 26 Jan 2011 17:01:47 -0800 (PST) X-Originating-IP: [216.239.45.130] Date: Wed, 26 Jan 2011 17:01:47 -0800 Message-ID: From: Tim Bray To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Feeling kind of confused about draft-merrick-jms-uri-12 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 00:58:47 -0000 I was asked to review it. My review was quite negative, challenging the notion that a URI was even appropriate for this space, and pointing out some fairly serious problems with the text. I'd have expected at least another draft. Today, the IESG announces that that draft, with one small change, is being published as an Informational RFC. So, what is the purpose of doing apps-area reviews, given that this one produced no observable effects? -Tim From mnot@mnot.net Wed Jan 26 17:12:48 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1063A68F8 for ; Wed, 26 Jan 2011 17:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.552 X-Spam-Level: X-Spam-Status: No, score=-104.552 tagged_above=-999 required=5 tests=[AWL=-1.953, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 q84I0mkr-yh4 for ; Wed, 26 Jan 2011 17:12:47 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 5A2D53A68F6 for ; Wed, 26 Jan 2011 17:12:47 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.1.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AAC01509D9; Wed, 26 Jan 2011 20:15:42 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Thu, 27 Jan 2011 12:15:34 +1100 Content-Transfer-Encoding: 7bit Message-Id: <4A236DC2-091E-4072-A74F-55744ED10494@mnot.net> References: To: Tim Bray X-Mailer: Apple Mail (2.1082) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Feeling kind of confused about draft-merrick-jms-uri-12 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 01:12:48 -0000 It's a provisional registration, and the bar for that is pretty low: http://tools.ietf.org/html/rfc4395#section-3 Cheers, On 27/01/2011, at 12:01 PM, Tim Bray wrote: > I was asked to review it. My review was quite negative, challenging > the notion that a URI was even appropriate for this space, and > pointing out some fairly serious problems with the text. I'd have > expected at least another draft. Today, the IESG announces that that > draft, with one small change, is being published as an Informational > RFC. > > So, what is the purpose of doing apps-area reviews, given that this > one produced no observable effects? > > -Tim > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From sm@elandsys.com Wed Jan 26 21:52:38 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862DC3A6921 for ; Wed, 26 Jan 2011 21:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Oq5y7+6YM3an for ; Wed, 26 Jan 2011 21:52:36 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id A7CCA3A6923 for ; Wed, 26 Jan 2011 21:52:36 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.233.69]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p0R5tVpW018989; Wed, 26 Jan 2011 21:55:36 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1296107738; bh=MRSa53yzL9jVfcGGr+YMo1uITJY=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=3M8NNWgv1IcsU2QxuztbS1W1m+zycJhDqrWjl2hyzTBmuXC6WqHlDQ7DOpHjvgAW9 G2qOqy6d0j79lVRax4MQC6QDAwj+yzlCyileVBZnqzKEDTwoTuKL/2ZbyHlDeklp40 7+PL4dX8Hh1vM0GsOJ3EipYDoMG2NNaps9eowiMQ= Message-Id: <6.2.5.6.2.20110126212046.0c26cae8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 26 Jan 2011 21:30:56 -0800 To: Tim Bray From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Feeling kind of confused about draft-merrick-jms-uri-12 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 05:52:38 -0000 Hi Tim, At 17:01 26-01-11, Tim Bray wrote: >I was asked to review it. My review was quite negative, challenging >the notion that a URI was even appropriate for this space, and >pointing out some fairly serious problems with the text. I'd have >expected at least another draft. Today, the IESG announces that that >draft, with one small change, is being published as an Informational >RFC. According to the document write-up: "The document had 2 reviews from the Apps Review team and most of the comments were addressed, although reviewers have disagreed with authors on some philosophical points. The document was also discussed on the uri-review@ietf.org mailing list." Which points in the review ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02090.html ) were considered as philosophical points? >So, what is the purpose of doing apps-area reviews, given that this >one produced no observable effects? I'll leave it to the Application Area Directors to address that question. Regards, S. Moonesamy From john@jck.com Wed Jan 26 23:17:34 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25ABD3A6955 for ; Wed, 26 Jan 2011 23:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 CVsTD9tpJiy2 for ; Wed, 26 Jan 2011 23:17:33 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 3052E3A6945 for ; Wed, 26 Jan 2011 23:17:33 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PiM9g-000DVF-MH; Thu, 27 Jan 2011 02:20:32 -0500 Date: Thu, 27 Jan 2011 02:20:32 -0500 From: John C Klensin To: S Moonesamy , Tim Bray Message-ID: <5869A181BE49612A2C0C7836@PST.JCK.COM> In-Reply-To: <6.2.5.6.2.20110126212046.0c26cae8@resistor.net> References: <6.2.5.6.2.20110126212046.0c26cae8@resistor.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Feeling kind of confused about draft-merrick-jms-uri-12 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 07:17:34 -0000 --On Wednesday, January 26, 2011 21:30 -0800 S Moonesamy wrote: >> draft, with one small change, is being published as an >> Informational RFC. > > According to the document write-up: > > "The document had 2 reviews from the Apps Review team > and most of the comments were addressed, although reviewers > have disagreed with authors on some philosophical points. > The document was also discussed on the uri-review@ietf.org > mailing list." > > Which points in the review ( > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg0 > 2090.html ) were considered as philosophical points? > >> So, what is the purpose of doing apps-area reviews, given >> that this one produced no observable effects? > > I'll leave it to the Application Area Directors to address > that question. Remember too that, as Mark has already pointed out in a different way, the main point of a provisional registration is to lower the odds that the same protocol identifier string will be used to designate two different protocols. I am not advising this in any way and I personally don't think it would be worth the effort, but, in the interest of procedural knowledge and consistency, RFC 2026 does give anyone who feels strongly about this decision the right to appeal it. john From yoshiro.yoneya@jprs.co.jp Thu Jan 27 00:45:21 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E3823A6B1D for ; Thu, 27 Jan 2011 00:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.858 X-Spam-Level: X-Spam-Status: No, score=-99.858 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100] 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 nj5Gman-okPk for ; Thu, 27 Jan 2011 00:45:20 -0800 (PST) Received: from send12.jprs.co.jp (send12.jprs.co.jp [IPv6:2001:df0:8:6::72]) by core3.amsl.com (Postfix) with ESMTP id 8907B3A6B0A for ; Thu, 27 Jan 2011 00:45:19 -0800 (PST) Received: from sendsms12.jprs.co.jp (sendsms12.jprs.co.jp [202.11.17.114]) by send12.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id p0R8mE2l016037; Thu, 27 Jan 2011 17:48:15 +0900 (JST) Received: from sendsms12.jprs.co.jp (unknown [127.0.0.1]) by sendsms12.jprs.co.jp (Symantec Mail Security) with ESMTP id C95583417; Thu, 27 Jan 2011 17:48:14 +0900 (JST) X-AuditID: ca0b1172-0000000b00000914-46-4d41314e60eb Received: from NOTE550 (off-cpu02.tyo.jprs.co.jp [172.18.4.70]) by sendsms12.jprs.co.jp (Symantec Mail Security) with SMTP id 640A23191; Thu, 27 Jan 2011 17:48:14 +0900 (JST) Date: Thu, 27 Jan 2011 17:48:11 +0900 From: Yoshiro YONEYA To: apps-discuss@ietf.org, idna-update@alvestrand.no Message-Id: <20110127174811.881f8a14.yoshiro.yoneya@jprs.co.jp> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [apps-discuss] idnkit-2.1 released X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 08:45:21 -0000 Dear all, I'm very pleased to announce that JPRS has released idnkit-2.1 which is an implementation of IDNA2008, and it provides features IDN encoding conversion tool and APIs for application software. The idnkit-2.1 and its additional packages are available from following URL: Major changes since idnkit-2.0 release are: - Bug fix + Quotation marks in configuration file was not processed properly + Logic of ACE prefix check was inappropriate - Correspond to RFC publication + IDNA Table version was updated according to RFC 5892 publication + "map" entry directive name of configuration file was changed according to RFC 5895 publication (resman-idna2008-mappings-01 -> rfc5895) - Addition of packages + Windows Package, Java API Package, Python API Package and Perl API Package were added I hope that the idnkit-2.1 is useful for IDN zone administrators, IDN site administrators, IDN-aware application developers, and IDNA2008 protocol designers. Please feel free to give your comments about the idnkit-2.1 to following e-mail address: Regards, -- Yoshiro YONEYA From paul.hoffman@vpnc.org Thu Jan 27 10:43:46 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD153A69C6 for ; Thu, 27 Jan 2011 10:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.743 X-Spam-Level: X-Spam-Status: No, score=-101.743 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] 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 tTTYU59kfbqC for ; Thu, 27 Jan 2011 10:43:45 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CB8323A6983 for ; Thu, 27 Jan 2011 10:43:45 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0RIkmRW069044 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 27 Jan 2011 11:46:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D41BD98.9030701@vpnc.org> Date: Thu, 27 Jan 2011 10:46:48 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4D33AC5F.3010609@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 18:43:46 -0000 On 1/25/11 11:11 PM, Patrik Fältström wrote: > I have had a look at this, and have three questions: > > 1. Have I understood it correct if the client by using this RR can > refuse to fall back to insecure connection for "communication using > HTTP"? I.e. it seems the RR is specifying whether fallback is > possible to not only per port, which works when you have "STARTTLS" > or similar, but not when fallback is between ports? The intention is to tell a client that could fall back, regardless of if it on the same port (STARTTLS) or between ports (443 to 80), that the server offers the non-secured option. I can try to make this clearer in a future draft. > 2. If so, the "input" to the query should in that case be not only > the hostname, but the protocol and hostname, right? So one could use > a prefix-based mechanism like _http._tcp.example.com. IN HASTLS 0 443 > 0 That might be good to do anyway. That is, having the query be in the same format as SRV queries, but with a HASTLS type, could give just the information wanted. The result could be an RRset with multiple HASTLS records. > 3. I am always a bit nervous over RDATA that has variable length. Do > you have an implementation of this so that you have tried to ensure > "it works"? No, and I think that the above proposal might allay your fears. > Otherwise, as someone said, overall negotiation I think is > interesting. Great! From stpeter@stpeter.im Thu Jan 27 10:51:56 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 085543A69DA for ; Thu, 27 Jan 2011 10:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 9VRd57Uh33t0 for ; Thu, 27 Jan 2011 10:51:55 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 025333A69D5 for ; Thu, 27 Jan 2011 10:51:55 -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 4B53A400F6; Thu, 27 Jan 2011 12:11:19 -0700 (MST) Message-ID: <4D41BF81.7030502@stpeter.im> Date: Thu, 27 Jan 2011 11:54:57 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Barry Leiba References: <4D33AC5F.3010609@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070207050806010504080703" Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 18:51:56 -0000 This is a cryptographically signed message in MIME format. --------------ms070207050806010504080703 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree that this document is appropriate for the appsawg. On 1/24/11 7:35 PM, Barry Leiba wrote: > Jiankang, Alexey, and I have discussed this, and we think the document > (see below) is appropriate for the appsawg to adopt, review, and > discuss. I would like to hear, as soon as possible and in any case by > 4 Feb, any objections to adoption of the document by appsawg. I am > also asking participants here to please review the document and begin > discussion on this mailing list. >=20 > Barry, as appsawg chair >=20 > On Sun, Jan 16, 2011 at 9:41 PM, Paul Hoffman w= rote: >> Greetings again. I would like this WG to consider adopting the followi= ng >> draft as a WG item. It is definitely apps-related, and there is no oth= er >> appropriate WG in the Applications or Security areas for it. It has be= en >> discussed in the websec WG, but that WG is limited to HTTP only (and t= his >> document covers TLS for all application protocols). >> >> FWIW, some of the topics in this draft are quite open for active discu= ssion. >> The discussion in websec brought up some interesting issues, but they = got >> discussed in the HTTP context only, and this WG would be a better plac= e to >> discuss them for all server protocols. >> >> --Paul Hoffman >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Specifying That a Server Supports TLS >> Author(s) : P. Hoffman >> Filename : draft-hoffman-server-has-tls-03.txt >> Pages : 8 >> Date : 2011-01-16 >> >> A server that hosts applications that can be run with or without TLS >> may want to communicate with clients whether the server is hosting an >> application only using TLS or also hosting the application without >> TLS. Many clients have a policy to try to set up a TLS session but >> fall back to insecure if the TLS session cannot be set up. If the >> server can securely communicate whether or not it can fall back to >> insecure tells such a client whether or not they should even try to >> set up an insecure session with the server. This document describes >> the use cases for this type of communication and a secure method for >> communicating that information. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-hoffman-server-has-tls-03.tx= t --------------ms070207050806010504080703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEy NzE4NTQ1N1owIwYJKoZIhvcNAQkEMRYEFFuzwWVJWlez5isgxVjYf6B8Gk9CMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCdqyHthj8XK0/BzgRGIArticwDBrhdfFtBL90UewIDhPRD3Ezo1tAjMThw 2n+ryD76bnNGP4VUMDe3eD3PEZXj9CfSG1gQ6WBdbuB4OkhAfKDB7acoE/spBadQc6W/fgEN LZWH5Bf21p6pR6fNhqZhCba16AZOMmmrXjUk8NyC14ABExC/wXKoc1O/GsYydyVwTT3PgdA7 QAFqq+VLrSdPAOjPCECFG3kaL/G1y5ZHo+iwlZHiOxQPORBTYdADprlZ4HfZLBuixpEwWNIe rtCjDYcEekRyLMJFVAhj+Qn7EXhMvhVrEQKGkZEfL69QffkY+Zd3ZdTl7hqS8bxi3iasAAAA AAAA --------------ms070207050806010504080703-- From paul.hoffman@vpnc.org Thu Jan 27 11:17:10 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F753A69F0 for ; Thu, 27 Jan 2011 11:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.744 X-Spam-Level: X-Spam-Status: No, score=-101.744 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] 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 6oG8AYz-ewWx for ; Thu, 27 Jan 2011 11:17:09 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D7DEC3A69ED for ; Thu, 27 Jan 2011 11:17:09 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0RJKDYH070520 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 27 Jan 2011 12:20:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D41C56C.8060900@vpnc.org> Date: Thu, 27 Jan 2011 11:20:12 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4D33AC5F.3010609@vpnc.org> <4D3EEE94.2090801@cisco.com> In-Reply-To: <4D3EEE94.2090801@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:17:10 -0000 On 1/25/11 7:39 AM, Eliot Lear wrote: > 1. The draft states that DNSSEC MUST be used, and there is some logic > to this. If you have an unprotected communication then it is possible > for both an upgrade DOS attack and downgrade MITM attack. That having > been said, let's at least note that this is a substantial gating > function to implementation. At the time I wrote this, I thought that there would be agreement in the DNSEXT WG to help make sure that DNSSEC was used end-to-end. It now seems there is no interest in pursuing that. So, I will downgrade this to a security consideration that says that relying on this security-related information, if gotten insecurely, gives an attacker a different way to perform a downgrade attack. > 2. I don't understand unde what circumstances CFB would be used. The > reason that such fallback mechanisms exist is because the client doesn't > have knowledge of what server capabilities are. In this case, the > server through DNS is expressing its capabilities to the client, so when > is CSO applicable? No client *needs* to use HASTLS: it is useful for making decisions when things go wrong. A HASTLS query might be made by a CSO client when they can't reach a site they thought had a TLS service (such as if they had been there before); a CFB client would want to do a HASTLS query before falling back to insecure; a CIO client might do a HASTLS query before trying to communicate at all. > 3. The presentation form of the new RR is not self-explanatory. Might > I recommend something like (servicename-or-number/protocol TLS=port# > plain=port#). See my earlier response to Patrik. > 4. In the case of a hostname that offers many services and may be in > some way virtualized, the client may have to sift through quite a number > of 3-tuples to retrieve relevant information. Another approach would be > to make use of a DKIM-like approach in the RR label, although one would > have to take care that a label not contain all numbers (I seem to recall > that's not allowed). I think that returning an RRset would solve both your concern and Patrik's concern about variable-length responses. 5. Perhaps most important, this service should be generalized in a > different way. What is being proposed here is a host connection policy > record. TLS is not the only issue. Another issue would be whether SCTP > is in use for a given, for instance. I wonder if this draft should be > recast in a more extensible approach, so that a host doesn't need to > query for a bunch of records (TCP, DTLS, SCTP, etc.). That is certainly an option. I tend to shy away from kitchen-sink approaches, but doing so means that there then needs to be many more RRtypes. This balance is based on preference, not protocol needs. The WG should certainly be the ones to say which style preference should be used in the protocol. > 6. Along these lines we should view this as an evolution of SRV. Errr, just to be clear: are you proposing that this be an update to RFC 2782? If so, please give a straw-man for how that would work. I don't see how SRV records are extensible. From lear@cisco.com Thu Jan 27 13:05:32 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E787E3A6A72 for ; Thu, 27 Jan 2011 13:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.212 X-Spam-Level: X-Spam-Status: No, score=-110.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 Ca01RWraMFhT for ; Thu, 27 Jan 2011 13:05:32 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 18BB63A69C3 for ; Thu, 27 Jan 2011 13:05:30 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAH9tQU2Q/khNgWdsb2JhbACEFKBpFQEBFiIkoGmKXpBjgSODOHQEjCc Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 27 Jan 2011 21:08:34 +0000 Received: from dhcp-10-55-95-186.cisco.com (dhcp-10-55-95-186.cisco.com [10.55.95.186]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0RL8YXE010219; Thu, 27 Jan 2011 21:08:34 GMT Message-ID: <4D41DECD.6090800@cisco.com> Date: Thu, 27 Jan 2011 22:08:29 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Hoffman References: <4D33AC5F.3010609@vpnc.org> <4D3EEE94.2090801@cisco.com> <4D41C56C.8060900@vpnc.org> In-Reply-To: <4D41C56C.8060900@vpnc.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 21:05:33 -0000 Paul, Just on this point: >> 6. Along these lines we should view this as an evolution of SRV. > > Errr, just to be clear: are you proposing that this be an update to > RFC 2782? If so, please give a straw-man for how that would work. I > don't see how SRV records are extensible. > Were there a way to capture SRV functionality while offering the HASTLS capability, then we could deprecate SRV. I would only recommend doing so, however, for a more generalized approach. I think you're really quite close to this already, especially given your answer to Patrik (which I liked). Eliot From bensons@queuefull.net Thu Jan 27 16:18:45 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A0503A6B0D for ; Thu, 27 Jan 2011 16:18:45 -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 8c16PtpPISBu for ; Thu, 27 Jan 2011 16:18:44 -0800 (PST) Received: from mail-gw0-f66.google.com (mail-gw0-f66.google.com [74.125.83.66]) by core3.amsl.com (Postfix) with ESMTP id 2F7423A6AFD for ; Thu, 27 Jan 2011 16:18:44 -0800 (PST) Received: by gwj18 with SMTP id 18so294412gwj.1 for ; Thu, 27 Jan 2011 16:21:48 -0800 (PST) Received: by 10.236.108.167 with SMTP id q27mr3512820yhg.36.1296174107017; Thu, 27 Jan 2011 16:21:47 -0800 (PST) Received: from dhcp-171-70-244-184.cisco.com (dhcp-171-70-244-184.cisco.com [171.70.244.184]) by mx.google.com with ESMTPS id 66sm700074yhl.46.2011.01.27.16.21.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 16:21:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Benson Schliesser Resent-Cc: apps-discuss@ietf.org Resent-From: Benson Schliesser In-Reply-To: Date: Wed, 26 Jan 2011 00:12:00 -0800 Content-Transfer-Encoding: quoted-printable Resent-Date: Thu, 27 Jan 2011 16:21:44 -0800 Resent-To: Barry Leiba , Paul Hoffman References: <4D33AC5F.3010609@vpnc.org> Message-Id: <7A645677-DADD-41F8-BE10-6673C93DA4E4@queuefull.net> To: Barry Leiba X-Mailer: Apple Mail (2.1082) Resent-Message-Id: <20110128001844.2F7423A6AFD@core3.amsl.com> Cc: "apps-discuss@ietf.org, Paul Hoffman" Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 00:18:45 -0000 I support the general goal, and think this is a worthy WG item. However, similar to what other folks have said: I think using a single = HASTLS resource record per host to carry a variable number of = port/policy triples isn't the ideal approach. Rather, a single = port/policy triple should be associated with a protocol-specific record, = i.e. a record name based on SRV. If the SRV record format is leveraged, the HASTLS protocol needs to = define what service name gets used as a record name - the non-TLS = version (_http._tcp), TLS version (_https._tcp), both, neither (web), = etc. Further, the protocol needs to define how HASTLS records coexist with = SRV records. For instance, if there is a _http._tcp record and a = _https._tcp record, what does a given HASTLS record mean? Would a = triple "0 443 1" imply that _http._tcp SRV records shouldn't exist? And more fundamentally, is a HASTLS record any more useful than the = information gleaned by querying SRV records in the first place? Cheers, -Benson On Jan 24, 2011, at 6:35 PM, Barry Leiba wrote: > Jiankang, Alexey, and I have discussed this, and we think the document > (see below) is appropriate for the appsawg to adopt, review, and > discuss. I would like to hear, as soon as possible and in any case by > 4 Feb, any objections to adoption of the document by appsawg. I am > also asking participants here to please review the document and begin > discussion on this mailing list. >=20 > Barry, as appsawg chair >=20 > On Sun, Jan 16, 2011 at 9:41 PM, Paul Hoffman = wrote: >> Greetings again. I would like this WG to consider adopting the = following >> draft as a WG item. It is definitely apps-related, and there is no = other >> appropriate WG in the Applications or Security areas for it. It has = been >> discussed in the websec WG, but that WG is limited to HTTP only (and = this >> document covers TLS for all application protocols). >>=20 >> FWIW, some of the topics in this draft are quite open for active = discussion. >> The discussion in websec brought up some interesting issues, but they = got >> discussed in the HTTP context only, and this WG would be a better = place to >> discuss them for all server protocols. >>=20 >> --Paul Hoffman >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>=20 >> Title : Specifying That a Server Supports TLS >> Author(s) : P. Hoffman >> Filename : draft-hoffman-server-has-tls-03.txt >> Pages : 8 >> Date : 2011-01-16 >>=20 >> A server that hosts applications that can be run with or without TLS >> may want to communicate with clients whether the server is hosting an >> application only using TLS or also hosting the application without >> TLS. Many clients have a policy to try to set up a TLS session but >> fall back to insecure if the TLS session cannot be set up. If the >> server can securely communicate whether or not it can fall back to >> insecure tells such a client whether or not they should even try to >> set up an insecure session with the server. This document describes >> the use cases for this type of communication and a secure method for >> communicating that information. >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-hoffman-server-has-tls-03.txt >> _______________________________________________ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From bensons@queuefull.net Thu Jan 27 16:36:03 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD513A6A0C for ; Thu, 27 Jan 2011 16:36: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 Anl628JwIRq1 for ; Thu, 27 Jan 2011 16:36:02 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id C13433A6A08 for ; Thu, 27 Jan 2011 16:36:02 -0800 (PST) Received: by yxt33 with SMTP id 33so966577yxt.31 for ; Thu, 27 Jan 2011 16:39:07 -0800 (PST) Received: by 10.101.168.12 with SMTP id v12mr1067298ano.111.1296175147330; Thu, 27 Jan 2011 16:39:07 -0800 (PST) Received: from dhcp-171-70-244-184.cisco.com (dhcp-171-70-244-184.cisco.com [171.70.244.184]) by mx.google.com with ESMTPS id e24sm21049366ana.22.2011.01.27.16.39.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 16:39:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Benson Schliesser In-Reply-To: <4D41DECD.6090800@cisco.com> Date: Thu, 27 Jan 2011 16:39:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <125235BD-7CCD-481A-9BFC-21BC0AEAA765@queuefull.net> References: <4D33AC5F.3010609@vpnc.org> <4D3EEE94.2090801@cisco.com> <4D41C56C.8060900@vpnc.org> <4D41DECD.6090800@cisco.com> To: Eliot Lear , Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] For consideration as an appsawg document: draft-hoffman-server-has-tls-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 00:36:03 -0000 (sorry for resending my previous note, by accident...) On Jan 27, 2011, at 1:08 PM, Eliot Lear wrote: >>> 6. Along these lines we should view this as an evolution of SRV. >>=20 >> Errr, just to be clear: are you proposing that this be an update to >> RFC 2782? If so, please give a straw-man for how that would work. I >> don't see how SRV records are extensible. >>=20 >=20 > Were there a way to capture SRV functionality while offering the = HASTLS > capability, then we could deprecate SRV. I would only recommend doing > so, however, for a more generalized approach. I think you're really > quite close to this already, especially given your answer to Patrik > (which I liked). Of course, SRV could be deprecated if its capability is performed by the = HASTLS mechanism. But "service discovery" is one thing, and "TLS = fallback indication" is another. In terms of a more generalized = approach, creating SRV++ would be a better way to think of the problem. Cheers, -Benson From mark@coactus.com Thu Jan 27 08:17:45 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9476A3A67D3 for ; Thu, 27 Jan 2011 08:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 YC7dA3nPolqC for ; Thu, 27 Jan 2011 08:17:44 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id B2B343A67ED for ; Thu, 27 Jan 2011 08:17:43 -0800 (PST) Received: by ewy8 with SMTP id 8so1046512ewy.31 for ; Thu, 27 Jan 2011 08:20:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.17.201 with SMTP id j51mr2063166wej.44.1296145245774; Thu, 27 Jan 2011 08:20:45 -0800 (PST) Sender: mark@coactus.com Received: by 10.216.48.7 with HTTP; Thu, 27 Jan 2011 08:20:45 -0800 (PST) In-Reply-To: <4A236DC2-091E-4072-A74F-55744ED10494@mnot.net> References: <4A236DC2-091E-4072-A74F-55744ED10494@mnot.net> Date: Thu, 27 Jan 2011 11:20:45 -0500 X-Google-Sender-Auth: z8XDizCP4iz-MHDfEwo31w5usJ4 Message-ID: From: Mark Baker To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 28 Jan 2011 08:08:37 -0800 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Feeling kind of confused about draft-merrick-jms-uri-12 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 16:17:45 -0000 On Wed, Jan 26, 2011 at 8:15 PM, Mark Nottingham wrote: > It's a provisional registration, and the bar for that is pretty low: > =A0http://tools.ietf.org/html/rfc4395#section-3 Agreed. The request was initially for permanent registration, but feedback here forced a change to provisional; http://tools.ietf.org/html/draft-merrick-jms-uri-07 Mark. From ylafon@w3.org Fri Jan 28 08:55:59 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8763A67D3; Fri, 28 Jan 2011 08:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.174 X-Spam-Level: X-Spam-Status: No, score=-9.174 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_HI=-8] 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 rk4xXlt0+nYM; Fri, 28 Jan 2011 08:55:57 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 0FB583A67AE; Fri, 28 Jan 2011 08:55:57 -0800 (PST) Received: from ylafon by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1Pirf5-00070j-Mv; Fri, 28 Jan 2011 11:59:03 -0500 Date: Fri, 28 Jan 2011 11:59:03 -0500 (EST) From: Yves Lafon To: apps-discuss@ietf.org, iesg@ietf.org Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: [apps-discuss] apps-team review of draft-bryan-metalinkhttp-19 (fwd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 16:55:59 -0000 (Forwarding to apps-discuss & IESG per request) --=20 Baroula que barouleras, au ti=E9u toujou t'entourneras. ~~Yves ---------- Forwarded message ---------- Date: Fri, 28 Jan 2011 10:39:59 -0500 (EST) From: Yves Lafon To: apps-review@ietf.org Cc: Alexey Melnikov , anthonybryan@gmail.com, neil@nabber.org, henrik@henriknordstrom.net, tatsuhiro.t@gmail.com, peter@poeml.de, alan.ford@roke.co.uk Subject: apps-team review of draft-bryan-metalinkhttp-19 Dear authors, I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Document: draft-bryan-metalinkhttp-19 Title: Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP Header Field= s Reviewer: Yves Lafon Review Date: 2011-01-28 IETF Last Call Date: 2011-02-18 Summary: This draft is almost ready for publication, but has a few small editorial fixes, and possibly needs some minor clarifications. Major Issues: None Minor Issues: In section 3, Remove [[Some organizations have many mirrors. Only send a few mirrors, or only use the Link header fields if Want-Digest is used?]] and add something along the lines of "As some organizations can have many= =20 mirrors, ..." in front of the next paragraph. Also "network proximity" might be a decision choice for the set of mirrors that might be returned. In section 3.2 Did you consider exposing the ASN of the mirror network prefix would be a g= ood=20 option on top of Geographical Location? It is not uncommon to have better= =20 bandwidth between two countries than between two ISPs in the same country. In section 6. << If Instance Digests are not provided by the Metalink servers, the Link head= er=20 fields MUST be ignored. >>=20 Clarification about what needs ot be ignored: "the Link header fields pertaining to this specification MUST be ignored" to avoid any zealous reading of the text. In section 7. It might be good that if any Ranged requests generated after the first requ= est=20 ends up with a complete response and not a partial one (as servers might no= t=20 support HTTP ranges) then all but the fastest connection must be closed. Th= e=20 other option would be to add a requirement in 2. that Metalink servers and= =20 mirrors MUST support HTTP Ranges (which would be a better way of solving th= e=20 issue). Also I noted a dependency on 'draft-ietf-ftpext2-hash' in the Normative=20 References section. Nits: In section 3. last paragraph and 7.1.1 6th paragraph, "fieldss" -> "fields" In section 6. "Cryptographic Hashes of Whole Files", "Files" might be replaced by "Documents" Thanks ! --=20 Baroula que barouleras, au ti=E9u toujou t'entourneras. ~~Yves From evnikita2@gmail.com Sun Jan 30 03:59:42 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C203A694A; Sun, 30 Jan 2011 03:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 TYWF3YHUHqjy; Sun, 30 Jan 2011 03:59:41 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id A1A0E3A696E; Sun, 30 Jan 2011 03:59:40 -0800 (PST) Received: by fxm9 with SMTP id 9so5189400fxm.31 for ; Sun, 30 Jan 2011 04:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=NacpH+YwbnJBRNmuuIwGM9X1+82Trn8R31DmApd9jP4=; b=ZabW+O68pbgHYx+zUu7LmgOImIsxL7N2Fr9A3UTTAlkDhrk7l4j6chsFNbRr2E1naQ c+6+8CC6QJ86tgtaxNZQvyocpLr6SfhoNxb6rtZGDS6kzZJyughdP4RPk73uPKVmejuK lnZMFB67q+L+qVTweP5nVV+McVyB6MLP3heoc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=knFbbDY2PXRnYySo2N0nwI1Ma8HMBTHJMG9fYyLH0Ef7HHRnVPoGkTyjnxoBnc60ei PdTW7PX37XqoHaulV+nqssPLgGPF7MW44sMb2LGBB9oy74tOPhgAG8eYS5XMDY37YAR1 ivuBqqM94mpc85u0YbB7W+TDuBdAEJI7BFtyE= Received: by 10.223.73.198 with SMTP id r6mr4692626faj.14.1296388971584; Sun, 30 Jan 2011 04:02:51 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id n3sm7002378fax.31.2011.01.30.04.02.49 (version=SSLv3 cipher=RC4-MD5); Sun, 30 Jan 2011 04:02:50 -0800 (PST) Message-ID: <4D455380.6040103@gmail.com> Date: Sun, 30 Jan 2011 14:03:12 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: URI , "uri-review@ietf.org" , "apps-discuss@ietf.org" References: %3C4D26B005.2060909@gmail.com%3E <4D2C7755.5080908@gmail.com> <81F42F63D5BB344ABF294F8E80990C7902782BBA@MTV-EXCHANGE.microfocus.com> In-Reply-To: <81F42F63D5BB344ABF294F8E80990C7902782BBA@MTV-EXCHANGE.microfocus.com> Content-Type: multipart/alternative; boundary="------------040403050504050705050707" Subject: Re: [apps-discuss] The state of 'afs' URi scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 11:59:42 -0000 This is a multi-part message in MIME format. --------------040403050504050705050707 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello all, I'd like to resume the discussion on 'afs' URI scheme by citing RFC 4395: > In some circumstances, it is appropriate to note a URI scheme that > was once in use or registered but for whatever reason is *no longer in > common use* or the use is not recommended. In this case, it is > possible for an individual to request that the URI scheme be > registered (newly, or as an update to an existing registration) as > 'historical'. Any scheme that is no longer in common use MAY be > designated as historical; the registration should contain some > indication to where the scheme was previously defined or documented. So there is a sense in moving this scheme to Historical category since it fully matches to these guidelines. Therefore I do not consider such action as inappropriate for the 'afs' URI scheme. Any other thoughts as for this? All the best, Mykyta Yevstifeyev --------------040403050504050705050707 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello all,

I'd like to resume the discussion on 'afs' URI scheme by citing RFC 4395:
 
In some circumstances, it is appropriate to note a URI scheme that
   was once in use or registered but for whatever reason is no longer in
   common use or the use is not recommended.  In this case, it is
   possible for an individual to request that the URI scheme be
   registered (newly, or as an update to an existing registration) as
   'historical'.  Any scheme that is no longer in common use MAY be
   designated as historical; the registration should contain some
   indication to where the scheme was previously defined or documented.

So there is a sense in moving this scheme to Historical category since it fully matches to these guidelines.  Therefore I do not consider such action as inappropriate for the 'afs' URI scheme.

Any other thoughts as for this?

All the best,
Mykyta Yevstifeyev



--------------040403050504050705050707-- From alexey.melnikov@isode.com Sun Jan 30 05:37:07 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7833A6800 for ; Sun, 30 Jan 2011 05:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.928 X-Spam-Level: X-Spam-Status: No, score=-101.928 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 TnPiTbN05HlI for ; Sun, 30 Jan 2011 05:37:05 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 1FF4C3A67B7 for ; Sun, 30 Jan 2011 05:37:05 -0800 (PST) Received: from [192.168.0.102] ((unknown) [109.73.6.25]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 30 Jan 2011 13:40:14 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D456A15.8080708@isode.com> Date: Sun, 30 Jan 2011 16:39:33 +0300 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Tim Bray References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable Cc: derek.rokicki@softwareag.com, discuss@apps.ietf.org, m8philli@uk.ibm.com, iesg@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-merrick-jms-uri-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 13:37:07 -0000 Hi Tim, I am sorry I haven't replied to your message earlier (and didn't make=20 sure that one of the editors do). Tim Bray wrote: >Dear IESG, sorry, got the wrong address for you first time around. >This also went to: SM , Apps Discuss >, m8philli@uk.ibm.com, peaston@progress.com, >derek.rokicki@softwareag.com, eric@tibco.com, Alexey Melnikov > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >I have been selected as the Applications Area Review Team reviewer for >this draft (for background on apps-review, please see >http://www.apps.ietf.org/content/applications-area-review-team). >Please resolve these comments along with any other Last Call comments >you may receive. Please wait for direction from your document shepherd >or AD before posting a new version of the draft. > >Document: draft-merrick-jms-uri-10 >Title: URI Scheme for Java(tm) Message Service 1.0 >Reviewer: Tim Bray >Review Date: Dec 16, 2010 >Summary: The draft has some mechanical issues which are not >show-stoppers. I have questions whether this ought to be an RFC since >there seems very modest expectation of interoperability between >implementations; why, then, an IETF RFC, which suggests that the >resulting URIs should be useful for identification of resources on an >internetworked scale. >Major Issues: > >1. the draft suggests that given a =93jms:=94 URI, there is little >expectation that, without checking on the value of the =93variant=94 and >for the presence of vendor-specific parameters, it can be used >interoperably in more than one implementation. In which case, I have >to wonder about the appropriateness of using a *Uniform* resource >identifier for whatever purposes are contemplated for these things; no >motivations or use-cases are provided. >The last paragraph of section 1 is troubling. For convenience, I quote: ><<<<< >As a consequence of building upon an API, rather than a protocol, the >utility of a "jms" URI depends on the context in which it is used. >That context includes agreement on the same JMS provider or underlying >protocol, agreement on how to look up endpoints (JNDI), and when using >serialized Java object messages, sufficiently similar Java Class >environments that serialized objects can be appropriately read and >written. Users of this scheme need to establish the necessary shared >context parts as just enumerated - a context which can span the globe, >or merely a small local network. With that shared context, this URI >scheme enables endpoint identification in a uniform way, and the means >to connect to those endpoints. > =20 > >Given this, what are the advantages of having a *Uniform* resource >identifier, if there is not much expectation of uniformity in >implementations? > =20 > I have to say that I was a bit concerned about this text as well, but I=20 liked editors honesty regarding the state of affairs. Considering that this URI scheme is already in use (and referenced by=20 other specs) and considering that it is a provisional registration, I=20 think it is Ok. Personally, I would much prefer to register a URI scheme=20 as provisional, then to reject the URI scheme registration and pretend=20 that it doesn't exist. As other people already pointed out it is=20 important to register URI schemes to at least avoid URI scheme name=20 conflicts. >2. Section 3.3 says =93 If users plan switching between JMS vendors, >they might also need to plan on regenerating resources that contain >URIs in this vendor specific form=94; this sharpens my concerns about >the lack of interoperability... > >I=92m getting the impression, reading this, that =93jms:jndi=94 is probably >quite interoperable, > I got the same impression. >but the variants are maybe a back-door for vendor abuse. > It is possible. But personally, I prefer to provide some extensible=20 framework to begin with than to let vendors extend URIs is completely=20 unpredictable ways. >Minor Issues: > >1. Section 1. Need references for terms like javax.jms.Destination for >people who aren=92t familiar with Java pathname voodoo. > >2. Section 4 para beginning =93Each variant can have query >parameters...=94 - did you consider separating the variant prefix from >the rest of the parameter name with =93.=94 or some other syntax marker? I >note that you use =93jndi-=94 for another class of parameter names below. > >3. Same paragraph. Should the variant be used as a prefix even if it=92s >a vendor-supplied one starting with =93vnd.=94? An example of this would >be nice. > I think these 3 issues were addressed. >4. 4.1.1 and so on, should the draft impose any constraints on the >syntax of these parameter values? Perhaps they are inherited from the >referenced sections in the JMS 1.1 spec? If so, please say so. Ah, I >see that 4.1.3 does specify some syntax, albeit loosely; there are a >lot of different syntaxes which may be used to specify =93 number >between 0 and 9, inclusive=94. Are you OK with 0x3 or, for timeToLive, >=931,500=94? > I think this was at least partially addressed. >5. 4.2.1 Perhaps a note prior to launching into all the parameters on >syntax constraints, with, I=92m assuming, normative references into the >JMS spec? > Addressed. >6. 4.2.2 includes great gobs of Java code illustrating how to use such >an endpoint. Does this not contradict with the assertion at the top of >section 4 which says =93 Operations available on JMS destinations are >fully and normatively defined by the JMS specification and as such, >are out of scope for this URI specification=94? > >In any case, 4.2.2 needs a bit of preparatory language explaining what >it is. Is it normative behavior for implementations? Is it there for >illustrative purposes? Is it required to use Java, or could I code >something equivalent in C# or Ruby? A few paragraphs in there=92s a >passing reference to =93the following (non-normative) code...=94 > >7. 4.3.1, see comments on 4.2.2 above. Is this description of >programming practice normative, illustrative, or what? > I think the updated text is clearer on these 2 issues. >8. Section 6, 3rd para: I haven=92t ever seen anything like the note >about what an OASIS TC might be doing in an RFC before, but possibly >I=92ve just missed the examples. > I think this point was addressed. >9. Section 7, last para: =93As described in Section 4, others can define >additional variants=94... there is no description in Section 4 of how to >define additional variants. > Right, I've missed that. >Also, while the language in the opening of >the draft suggests that the set of variants is open-ended, this is the >first explicit mention of this possibility that I encountered. Is >there a registry? > >Oh, there it is in section 9.2. OK, I think that the beginning of the >doc needs to say that the set of variants is open-ended and >vendor-extensible. It also smells like a big huge honking >interoperability hole. > I think it does now. >Nits: > >1. Section 4 para 3, superfluous comma after =93Both the variant=94. > >2. Section 4 para beginning =93Each variant can have query >parameters...=94 - did you consider separating the variant prefix from >the rest of the parameter name with =93.=94 or some other syntax marker? I >note that you use =93jndi-=94 for another class of parameter names below. > >3. Section 4.1 I assume =93shared=94 means =93available in all variants=94?= If >so, why not say so? > Fixed. >4. Section 4.1 first para, the word =93property=94 suddenly appears for >the first time. Is this a synonym of =93parameter=94? > >5. Section 4.1.1 Lots of references here need to be turned into RFC >style with square brackets > I think RFC Editor will take care of this. >5. Same section, missing full stop after =93following shared parameters=94. > >6. 4.1.1 Probably more idiomatic of normative text to say, instead of >=93This MUST be=94, =93The value of this parameter MUST be...=94 > >7. 4.1.1 Missing full-stop at end. > >8. 6, 2nd para: What=92s an =93SPI=94? > All of these were fixed as well. From alexey.melnikov@isode.com Sun Jan 30 06:12:01 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E613A67F9 for ; Sun, 30 Jan 2011 06:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 pNhVWVbROlZI for ; Sun, 30 Jan 2011 06:12:00 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C24393A67B7 for ; Sun, 30 Jan 2011 06:11:59 -0800 (PST) Received: from [192.168.0.102] ((unknown) [109.73.6.25]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 30 Jan 2011 14:15:10 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D457248.2080700@isode.com> Date: Sun, 30 Jan 2011 17:14:32 +0300 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Tim Bray References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Feeling kind of confused about draft-merrick-jms-uri-12 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 14:12:01 -0000 Tim Bray wrote: >I was asked to review it. My review was quite negative, challenging >the notion that a URI was even appropriate for this space, and >pointing out some fairly serious problems with the text. > Ok, I think there were some process failures on my side. I was keen to get this document finished before my AD term ends at the beginning of April, version -11 of the document was posted close to the IESG telechat date and I didn't follow up on your detailed comments. I did read your comments and from a quick look it seemed that most of your minor issues were addressed, while I didn't think your major issue were blocking publication. So my apologies for not communicating anything back to you. I have replied to your original review and I hope you find my answers satisfactory. Now, commenting on some specific issues: >I'd have expected at least another draft. > I believe -11 was posted to address some of your concerns. My reading of changes in draft-merrick-jms-uri-11.txt is that editors addressed pretty much all your minor issues and nits. I apologize again for not replying to your major issues and not insisting that editors do, but I hope my replies in additional message explain why I thought that these issues are not worth blocking the document for. Having said that, if you think some specific editorial changes can improve the document, I would be very interested to hear and apply them in AUTH48. If the changes are sufficiently major, I will ask IESG and the community to verify that they are acceptable. >Today, the IESG announces that that >draft, with one small change, is being published as an Informational >RFC. > >So, what is the purpose of doing apps-area reviews, given that this >one produced no observable effects? > There was lack of acknowledgment of your review from my side, but in general I don't think I agree with your statement. My understanding of how Apps Review Team should work is that it provides additional reviews and information to Applications AD (and the rest of IESG) about suitability of publications and quality of documents. This is similar to SecDir (Security Area reviews) and Gen-Art (General Area reviews). None of them are supposed to be treated more than general IETF LC comments, although in practice ADs of relevant areas are actually paying much more attention to them. So, your review was treated as one input regarding the document. This document was also reviewed by the Designated Expert for URI registrations (Graham Klyne) and Mark Nottingham (another Apps Review Team review). While they clearly indicated that the document is not ready for PS, I got impression that they thought that the publication as Informational with Provisional URI registration is quite acceptable. Best Regards, Alexey -- IETF Application Area Director, Internet Messaging Team Lead, JID: same as my email address From anthonybryan@gmail.com Sat Jan 29 15:43:39 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41FA3A68EA; Sat, 29 Jan 2011 15:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.335 X-Spam-Level: X-Spam-Status: No, score=-3.335 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, 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 1Jp3SOAlSZW8; Sat, 29 Jan 2011 15:43:38 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 3B2F03A68DC; Sat, 29 Jan 2011 15:43:36 -0800 (PST) Received: by ewy8 with SMTP id 8so2205109ewy.31 for ; Sat, 29 Jan 2011 15:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OfhZqqIL9KBM0Sv5CLQ7lGKwD58pdVaKaghVxgett6M=; b=aQBlGatGtfcX0lKYgyVJ4jHYutUBoptKEFH6oZcAHlmzIdNdusPKiL1YfCclcIh8Nm 9skZ9sK62/5GAN4ts+3MdCQU0HDHd05eZiBRARJrmknLijIdh7uFLvLGW8oZyxG+VvnF bl5plyJP1Eqx7AjkeSR09kK5wI/E2AMqYMqms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OlNzvWYos2+l0afg2RT3f2MQqSns5t03WCUwFGozwkrHC2ZvTg7EZP8T/qwx7oKwiR j1//PnVHlFl9bzTU+JIQ3TfSc5L8PHsQL+pHrGU1cbDuDKUTtki29QRuuoGk3YsxDJEU loWQWKR7l1qCW4gYdi3UytD2l7r9bgWjKReT4= MIME-Version: 1.0 Received: by 10.213.29.77 with SMTP id p13mr6769708ebc.2.1296344806412; Sat, 29 Jan 2011 15:46:46 -0800 (PST) Received: by 10.213.98.69 with HTTP; Sat, 29 Jan 2011 15:46:46 -0800 (PST) In-Reply-To: References: Date: Sat, 29 Jan 2011 18:46:46 -0500 Message-ID: From: Anthony Bryan To: Yves Lafon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 30 Jan 2011 08:12:03 -0800 Cc: apps-discuss@ietf.org, apps-review@ietf.org, neil@nabber.org, henrik@henriknordstrom.net, "Ford, Alan" , iesg@ietf.org Subject: Re: [apps-discuss] apps-team review of draft-bryan-metalinkhttp-19 (fwd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 23:43:39 -0000 thank you for the review. On Fri, Jan 28, 2011 at 11:59 AM, Yves Lafon wrote: > (Forwarding to apps-discuss & IESG per request) > > -- > Baroula que barouleras, au ti=E9u toujou t'entourneras. > > =A0 =A0 =A0 =A0~~Yves > > ---------- Forwarded message ---------- > Date: Fri, 28 Jan 2011 10:39:59 -0500 (EST) > From: Yves Lafon > To: apps-review@ietf.org > Cc: Alexey Melnikov , anthonybryan@gmail.com, > =A0 =A0neil@nabber.org, henrik@henriknordstrom.net, tatsuhiro.t@gmail.com= , > =A0 =A0peter@poeml.de, alan.ford@roke.co.uk > Subject: apps-team review of draft-bryan-metalinkhttp-19 > > Dear authors, > > I have been selected as the Applications Area Review Team reviewer for > this draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). > > Document: draft-bryan-metalinkhttp-19 > Title: Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP Header Fie= lds > Reviewer: Yves Lafon > Review Date: 2011-01-28 > IETF Last Call Date: 2011-02-18 > > Summary: This draft is almost ready for publication, but has a few small > editorial fixes, and possibly needs some minor clarifications. > > Major Issues: None > > Minor Issues: > > In section 3, > > Remove > [[Some organizations have many mirrors. =A0Only send a few mirrors, or > =A0only use the Link header fields if Want-Digest is used?]] > and add something along the lines of "As some organizations can have many > mirrors, ..." in front of the next paragraph. removed. > Also "network proximity" might be a decision choice for the set of mirror= s > that might be returned. added. > In section 3.2 > Did you consider exposing the ASN of the mirror network prefix would be a > good option on top of Geographical Location? It is not uncommon to have > better bandwidth between two countries than between two ISPs in the same > country. no, this can be done internally on the server side though for mirror priority (currently via MirrorBrain w/ mod_asn). Should we mention this in the Mirror Priority section and add a reference to RFC 1930? http://www.mirrorbrain.org/ http://www.mirrorbrain.org/mod_asn/ > In section 6. > << > If Instance Digests are not provided by the Metalink servers, the Link > header fields MUST be ignored. >>> > Clarification about what needs ot be ignored: > "the Link header fields pertaining to this specification MUST be ignored" > to avoid any zealous reading of the text. fixed. > In section 7. > It might be good that if any Ranged requests generated after the first > request ends up with a complete response and not a partial one (as server= s > might not support HTTP ranges) then all but the fastest connection must b= e > closed. The other option would be to add a requirement in 2. that Metalin= k > servers and mirrors MUST support HTTP Ranges (which would be a better way= of > solving the issue). I added "If any Ranged requests generated after the first request ends up with a complete response and not a partial one (as servers might not support HTTP ranges), then all but the fastest connection can be closed. " an earlier draft mentioned that mirrors MUST support HTTP Ranges, but feedback was that this might exclude mirrors. currently it says "Mirror servers SHOULD support serving partial content." we have walked a fine line with not requiring too much on a mirror network so it's less restrictive and more mirrors can join in the mirror pool versus having all the features we want. > Also I noted a dependency on 'draft-ietf-ftpext2-hash' in the Normative > References section. yes, we will remove this unless we want draft-ietf-ftpext2-hash to hold up this document. most likely we will remove it. > Nits: > > In section 3. last paragraph and 7.1.1 6th paragraph, "fieldss" -> "field= s" > In section 6. "Cryptographic Hashes of Whole Files", > =A0 =A0 =A0 =A0 =A0 =A0 =A0"Files" might be replaced by "Documents" changed to "Documents". or would "Resources" be better? thanks! --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From eric@tibco.com Sun Jan 30 08:36:45 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAB4C3A6807 for ; Sun, 30 Jan 2011 08:36:44 -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=[AWL=0.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 MpAhfB3s8ewb for ; Sun, 30 Jan 2011 08:36:42 -0800 (PST) Received: from mx2-app.tibco.com (mx2-app.tibco.com [63.100.100.143]) by core3.amsl.com (Postfix) with ESMTP id 626C03A6802 for ; Sun, 30 Jan 2011 08:36:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,401,1291622400"; d="scan'208";a="19145388" Received: from tibco-5.tibco.com (HELO na-pa-fe02.na.tibco.com) ([63.100.100.5]) by mx2-app.tibco.com with ESMTP; 30 Jan 2011 08:39:49 -0800 Received: from NA-PA-VBE03.na.tibco.com ([10.106.136.138]) by na-pa-fe02.na.tibco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Jan 2011 08:39:48 -0800 Received: from 10.106.136.112 ([10.106.136.112]) by NA-PA-VBE03.na.tibco.com ([10.106.136.139]) with Microsoft Exchange Server HTTP-DAV ; Sun, 30 Jan 2011 16:39:47 +0000 References: <4D456A15.8080708@isode.com> Content-Transfer-Encoding: base64 thread-topic: apps-team review of draft-merrick-jms-uri-10 thread-index: AcvAnE4weNro4YFDT4mIaKEgBQ1Vig== From: "Eric Johnson" Content-Type: text/plain; charset="utf-8" In-Reply-To: <4D456A15.8080708@isode.com> Message-ID: <5522228A-11AB-49E9-A9B0-08DB302F78A4@tibco.com> Date: Sun, 30 Jan 2011 08:39:44 -0800 To: "Alexey Melnikov" MIME-Version: 1.0 (iPhone Mail 8C148) X-OriginalArrivalTime: 30 Jan 2011 16:39:48.0304 (UTC) FILETIME=[4F004500:01CBC09C] X-TM-AS-Product-Ver: SMEX-10.0.0.1412-6.500.1024-17924.007 X-TM-AS-Result: No--48.611800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: discuss@apps.ietf.org, derek.rokicki@softwareag.com, iesg@ietf.org, m8philli@uk.ibm.com Subject: Re: [apps-discuss] apps-team review of draft-merrick-jms-uri-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 16:36:45 -0000 TXkgYXBvbG9naWVzIGFwcGFyZW50bHkgYXJlIGR1ZSBhcyB3ZWxsLiBJJ3ZlIGV4Y2hhbmdlZCBl bWFpbCB3aXRoIFRpbSBhbHJlYWR5LiBJIGNvbXBvc2VkIGEgdG9wIHRvIGJvdHRvbSByZXNwb25z ZSB0byBUaW0sIGFuZCBzb21laG93IEkgbWFuYWdlZCB0byBsb3NlIGl0LCBpbnN0ZWFkIG9mIHNl bmRpbmcgaXQuIFdvcnNlIHlldCwgSSBkaWRuJ3QgcmVhbGl6ZSB0aGF0IGhhZCBoYXBwZW5lZCB1 bnRpbCBJIGV4Y2hhbmdlZCBlbWFpbHMgd2l0aCBUaW0uDQoNClNwZWNpZmljYWxseSB3aXRoIHJl c3BlY3QgdG8gdGhlIHF1ZXN0aW9uIGFyb3VuZCB0aGUgdmFyaWFudHMsIGFuZCB0aGUgcG90ZW50 aWFsIGZvciB2ZW5kb3IgaW5jb21wYXRpYmlsaXR5LCB3ZSdyZSBzdHVjayBiZXR3ZWVuIHR3byBi YWQgY2hvaWNlcy4gU3VwcG9ydCB0aGUgZXh0ZW5zaWJpbGl0eSwgYW5kIHRoaXMgbmV3IGRlZmlu aXRpb24gd29ya3MgYXMgYSBzdWJzdGl0dXRlIGZvciBhbGwgZXhpc3RpbmcgdXNlcyB3aGlsZSBy aXNraW5nIGluY29tcGF0aWJsZSB2YXJpYW50cywgb3IgZG9uJ3QgZGVmaW5lIGhvdyB0byBleHRl bmQsIGFuZCBwZW9wbGUgZG9uJ3QgYWRvcHQgdGhlIHByb3Bvc2VkIGRlZmluaXRpb24sIGFuZCBy ZW1haW4gaW5jb21wYXRpYmxlLCBidXQgbm90IGltbWVkaWF0ZWx5IGFuZCByZWNvZ25pemFibHkg c28uDQoNCkVyaWMNCg0KT24gSmFuIDMwLCAyMDExLCBhdCA1OjQwIEFNLCAiQWxleGV5IE1lbG5p a292IiA8YWxleGV5Lm1lbG5pa292QGlzb2RlLmNvbT4gd3JvdGU6DQoNCj4gSGkgVGltLA0KPiBJ IGFtIHNvcnJ5IEkgaGF2ZW4ndCByZXBsaWVkIHRvIHlvdXIgbWVzc2FnZSBlYXJsaWVyIChhbmQg ZGlkbid0IG1ha2Ugc3VyZSB0aGF0IG9uZSBvZiB0aGUgZWRpdG9ycyBkbykuDQo+IA0KPiBUaW0g QnJheSB3cm90ZToNCj4gDQo+PiBEZWFyIElFU0csIHNvcnJ5LCBnb3QgdGhlIHdyb25nIGFkZHJl c3MgZm9yIHlvdSBmaXJzdCB0aW1lIGFyb3VuZC4NCj4+IFRoaXMgYWxzbyB3ZW50IHRvOiBTTSA8 c20raWV0ZkBlbGFuZHN5cy5jb20+LCBBcHBzIERpc2N1c3MNCj4+IDxkaXNjdXNzQGFwcHMuaWV0 Zi5vcmc+LCBtOHBoaWxsaUB1ay5pYm0uY29tLCBwZWFzdG9uQHByb2dyZXNzLmNvbSwNCj4+IGRl cmVrLnJva2lja2lAc29mdHdhcmVhZy5jb20sIGVyaWNAdGliY28uY29tLCBBbGV4ZXkgTWVsbmlr b3YNCj4+IDxhbGV4ZXkubWVsbmlrb3ZAaXNvZGUuY29tPg0KPj4gPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+PiBJIGhhdmUgYmVlbiBzZWxl Y3RlZCBhcyB0aGUgQXBwbGljYXRpb25zIEFyZWEgUmV2aWV3IFRlYW0gcmV2aWV3ZXIgZm9yDQo+ PiB0aGlzIGRyYWZ0IChmb3IgYmFja2dyb3VuZCBvbiBhcHBzLXJldmlldywgcGxlYXNlIHNlZQ0K Pj4gaHR0cDovL3d3dy5hcHBzLmlldGYub3JnL2NvbnRlbnQvYXBwbGljYXRpb25zLWFyZWEtcmV2 aWV3LXRlYW0pLg0KPj4gUGxlYXNlIHJlc29sdmUgdGhlc2UgY29tbWVudHMgYWxvbmcgd2l0aCBh bnkgb3RoZXIgTGFzdCBDYWxsIGNvbW1lbnRzDQo+PiB5b3UgbWF5IHJlY2VpdmUuIFBsZWFzZSB3 YWl0IGZvciBkaXJlY3Rpb24gZnJvbSB5b3VyIGRvY3VtZW50IHNoZXBoZXJkDQo+PiBvciBBRCBi ZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCj4+IA0KPj4gRG9jdW1l bnQ6IGRyYWZ0LW1lcnJpY2stam1zLXVyaS0xMA0KPj4gVGl0bGU6IFVSSSBTY2hlbWUgZm9yIEph dmEodG0pIE1lc3NhZ2UgU2VydmljZSAxLjANCj4+IFJldmlld2VyOiBUaW0gQnJheQ0KPj4gUmV2 aWV3IERhdGU6IERlYyAxNiwgMjAxMA0KPj4gU3VtbWFyeTogVGhlIGRyYWZ0IGhhcyBzb21lIG1l Y2hhbmljYWwgaXNzdWVzIHdoaWNoIGFyZSBub3QNCj4+IHNob3ctc3RvcHBlcnMuIEkgaGF2ZSBx dWVzdGlvbnMgd2hldGhlciB0aGlzIG91Z2h0IHRvIGJlIGFuIFJGQyBzaW5jZQ0KPj4gdGhlcmUg c2VlbXMgdmVyeSBtb2Rlc3QgZXhwZWN0YXRpb24gb2YgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVu DQo+PiBpbXBsZW1lbnRhdGlvbnM7IHdoeSwgdGhlbiwgYW4gSUVURiBSRkMsIHdoaWNoIHN1Z2dl c3RzIHRoYXQgdGhlDQo+PiByZXN1bHRpbmcgVVJJcyBzaG91bGQgYmUgdXNlZnVsIGZvciBpZGVu dGlmaWNhdGlvbiBvZiByZXNvdXJjZXMgb24gYW4NCj4+IGludGVybmV0d29ya2VkIHNjYWxlLg0K Pj4gTWFqb3IgSXNzdWVzOg0KPj4gDQo+PiAxLiB0aGUgZHJhZnQgc3VnZ2VzdHMgdGhhdCBnaXZl biBhIOKAnGptczrigJ0gVVJJLCB0aGVyZSBpcyBsaXR0bGUNCj4+IGV4cGVjdGF0aW9uIHRoYXQs IHdpdGhvdXQgY2hlY2tpbmcgb24gdGhlIHZhbHVlIG9mIHRoZSDigJx2YXJpYW504oCdIGFuZA0K Pj4gZm9yIHRoZSBwcmVzZW5jZSBvZiB2ZW5kb3Itc3BlY2lmaWMgcGFyYW1ldGVycywgaXQgY2Fu IGJlIHVzZWQNCj4+IGludGVyb3BlcmFibHkgaW4gbW9yZSB0aGFuIG9uZSBpbXBsZW1lbnRhdGlv bi4gSW4gd2hpY2ggY2FzZSwgSSBoYXZlDQo+PiB0byB3b25kZXIgYWJvdXQgdGhlIGFwcHJvcHJp YXRlbmVzcyBvZiB1c2luZyBhICpVbmlmb3JtKiByZXNvdXJjZQ0KPj4gaWRlbnRpZmllciBmb3Ig d2hhdGV2ZXIgcHVycG9zZXMgYXJlIGNvbnRlbXBsYXRlZCBmb3IgdGhlc2UgdGhpbmdzOyBubw0K Pj4gbW90aXZhdGlvbnMgb3IgdXNlLWNhc2VzIGFyZSBwcm92aWRlZC4NCj4+IFRoZSBsYXN0IHBh cmFncmFwaCBvZiBzZWN0aW9uIDEgaXMgdHJvdWJsaW5nLiBGb3IgY29udmVuaWVuY2UsIEkgcXVv dGU6DQo+PiA8PDw8PA0KPj4gQXMgYSBjb25zZXF1ZW5jZSBvZiBidWlsZGluZyB1cG9uIGFuIEFQ SSwgcmF0aGVyIHRoYW4gYSBwcm90b2NvbCwgdGhlDQo+PiB1dGlsaXR5IG9mIGEgImptcyIgVVJJ IGRlcGVuZHMgb24gdGhlIGNvbnRleHQgaW4gd2hpY2ggaXQgaXMgdXNlZC4NCj4+IFRoYXQgY29u dGV4dCBpbmNsdWRlcyBhZ3JlZW1lbnQgb24gdGhlIHNhbWUgSk1TIHByb3ZpZGVyIG9yIHVuZGVy bHlpbmcNCj4+IHByb3RvY29sLCBhZ3JlZW1lbnQgb24gaG93IHRvIGxvb2sgdXAgZW5kcG9pbnRz IChKTkRJKSwgYW5kIHdoZW4gdXNpbmcNCj4+IHNlcmlhbGl6ZWQgSmF2YSBvYmplY3QgbWVzc2Fn ZXMsIHN1ZmZpY2llbnRseSBzaW1pbGFyIEphdmEgQ2xhc3MNCj4+IGVudmlyb25tZW50cyB0aGF0 IHNlcmlhbGl6ZWQgb2JqZWN0cyBjYW4gYmUgYXBwcm9wcmlhdGVseSByZWFkIGFuZA0KPj4gd3Jp dHRlbi4gVXNlcnMgb2YgdGhpcyBzY2hlbWUgbmVlZCB0byBlc3RhYmxpc2ggdGhlIG5lY2Vzc2Fy eSBzaGFyZWQNCj4+IGNvbnRleHQgcGFydHMgYXMganVzdCBlbnVtZXJhdGVkIC0gYSBjb250ZXh0 IHdoaWNoIGNhbiBzcGFuIHRoZSBnbG9iZSwNCj4+IG9yIG1lcmVseSBhIHNtYWxsIGxvY2FsIG5l dHdvcmsuIFdpdGggdGhhdCBzaGFyZWQgY29udGV4dCwgdGhpcyBVUkkNCj4+IHNjaGVtZSBlbmFi bGVzIGVuZHBvaW50IGlkZW50aWZpY2F0aW9uIGluIGEgdW5pZm9ybSB3YXksIGFuZCB0aGUgbWVh bnMNCj4+IHRvIGNvbm5lY3QgdG8gdGhvc2UgZW5kcG9pbnRzLg0KPj4gDQo+PiBHaXZlbiB0aGlz LCB3aGF0IGFyZSB0aGUgYWR2YW50YWdlcyBvZiBoYXZpbmcgYSAqVW5pZm9ybSogcmVzb3VyY2UN Cj4+IGlkZW50aWZpZXIsIGlmIHRoZXJlIGlzIG5vdCBtdWNoIGV4cGVjdGF0aW9uIG9mIHVuaWZv cm1pdHkgaW4NCj4+IGltcGxlbWVudGF0aW9ucz8NCj4+IA0KPiBJIGhhdmUgdG8gc2F5IHRoYXQg SSB3YXMgYSBiaXQgY29uY2VybmVkIGFib3V0IHRoaXMgdGV4dCBhcyB3ZWxsLCBidXQgSSBsaWtl ZCBlZGl0b3JzIGhvbmVzdHkgcmVnYXJkaW5nIHRoZSBzdGF0ZSBvZiBhZmZhaXJzLg0KPiANCj4g Q29uc2lkZXJpbmcgdGhhdCB0aGlzIFVSSSBzY2hlbWUgaXMgYWxyZWFkeSBpbiB1c2UgKGFuZCBy ZWZlcmVuY2VkIGJ5IG90aGVyIHNwZWNzKSBhbmQgY29uc2lkZXJpbmcgdGhhdCBpdCBpcyBhIHBy b3Zpc2lvbmFsIHJlZ2lzdHJhdGlvbiwgSSB0aGluayBpdCBpcyBPay4gUGVyc29uYWxseSwgSSB3 b3VsZCBtdWNoIHByZWZlciB0byByZWdpc3RlciBhIFVSSSBzY2hlbWUgYXMgcHJvdmlzaW9uYWws IHRoZW4gdG8gcmVqZWN0IHRoZSBVUkkgc2NoZW1lIHJlZ2lzdHJhdGlvbiBhbmQgcHJldGVuZCB0 aGF0IGl0IGRvZXNuJ3QgZXhpc3QuIEFzIG90aGVyIHBlb3BsZSBhbHJlYWR5IHBvaW50ZWQgb3V0 IGl0IGlzIGltcG9ydGFudCB0byByZWdpc3RlciBVUkkgc2NoZW1lcyB0byBhdCBsZWFzdCBhdm9p ZCBVUkkgc2NoZW1lIG5hbWUgY29uZmxpY3RzLg0KPiANCj4+IDIuIFNlY3Rpb24gMy4zIHNheXMg 4oCcIElmIHVzZXJzIHBsYW4gc3dpdGNoaW5nIGJldHdlZW4gSk1TIHZlbmRvcnMsDQo+PiB0aGV5 IG1pZ2h0IGFsc28gbmVlZCB0byBwbGFuIG9uIHJlZ2VuZXJhdGluZyByZXNvdXJjZXMgdGhhdCBj b250YWluDQo+PiBVUklzIGluIHRoaXMgdmVuZG9yIHNwZWNpZmljIGZvcm3igJ07IHRoaXMgc2hh cnBlbnMgbXkgY29uY2VybnMgYWJvdXQNCj4+IHRoZSBsYWNrIG9mIGludGVyb3BlcmFiaWxpdHku Li4NCj4+IA0KPj4gSeKAmW0gZ2V0dGluZyB0aGUgaW1wcmVzc2lvbiwgcmVhZGluZyB0aGlzLCB0 aGF0IOKAnGptczpqbmRp4oCdIGlzIHByb2JhYmx5DQo+PiBxdWl0ZSBpbnRlcm9wZXJhYmxlLA0K Pj4gDQo+IEkgZ290IHRoZSBzYW1lIGltcHJlc3Npb24uDQo+IA0KPj4gYnV0IHRoZSB2YXJpYW50 cyBhcmUgbWF5YmUgYSBiYWNrLWRvb3IgZm9yIHZlbmRvciBhYnVzZS4NCj4+IA0KPiBJdCBpcyBw b3NzaWJsZS4gQnV0IHBlcnNvbmFsbHksIEkgcHJlZmVyIHRvIHByb3ZpZGUgc29tZSBleHRlbnNp YmxlIGZyYW1ld29yayB0byBiZWdpbiB3aXRoIHRoYW4gdG8gbGV0IHZlbmRvcnMgZXh0ZW5kIFVS SXMgaXMgY29tcGxldGVseSB1bnByZWRpY3RhYmxlIHdheXMuDQo+IA0KPj4gTWlub3IgSXNzdWVz Og0KPj4gDQo+PiAxLiBTZWN0aW9uIDEuIE5lZWQgcmVmZXJlbmNlcyBmb3IgdGVybXMgbGlrZSBq YXZheC5qbXMuRGVzdGluYXRpb24gZm9yDQo+PiBwZW9wbGUgd2hvIGFyZW7igJl0IGZhbWlsaWFy IHdpdGggSmF2YSBwYXRobmFtZSB2b29kb28uDQo+PiANCj4+IDIuIFNlY3Rpb24gNCBwYXJhIGJl Z2lubmluZyDigJxFYWNoIHZhcmlhbnQgY2FuIGhhdmUgcXVlcnkNCj4+IHBhcmFtZXRlcnMuLi7i gJ0gLSBkaWQgeW91IGNvbnNpZGVyIHNlcGFyYXRpbmcgdGhlIHZhcmlhbnQgcHJlZml4IGZyb20N Cj4+IHRoZSByZXN0IG9mIHRoZSBwYXJhbWV0ZXIgbmFtZSB3aXRoIOKAnC7igJ0gb3Igc29tZSBv dGhlciBzeW50YXggbWFya2VyPyBJDQo+PiBub3RlIHRoYXQgeW91IHVzZSDigJxqbmRpLeKAnSBm b3IgYW5vdGhlciBjbGFzcyBvZiBwYXJhbWV0ZXIgbmFtZXMgYmVsb3cuDQo+PiANCj4+IDMuIFNh bWUgcGFyYWdyYXBoLiBTaG91bGQgdGhlIHZhcmlhbnQgYmUgdXNlZCBhcyBhIHByZWZpeCBldmVu IGlmIGl04oCZcw0KPj4gYSB2ZW5kb3Itc3VwcGxpZWQgb25lIHN0YXJ0aW5nIHdpdGgg4oCcdm5k LuKAnT8gQW4gZXhhbXBsZSBvZiB0aGlzIHdvdWxkDQo+PiBiZSBuaWNlLg0KPj4gDQo+IEkgdGhp bmsgdGhlc2UgMyBpc3N1ZXMgd2VyZSBhZGRyZXNzZWQuDQo+IA0KPj4gNC4gNC4xLjEgYW5kIHNv IG9uLCBzaG91bGQgdGhlIGRyYWZ0IGltcG9zZSBhbnkgY29uc3RyYWludHMgb24gdGhlDQo+PiBz eW50YXggb2YgdGhlc2UgcGFyYW1ldGVyIHZhbHVlcz8gUGVyaGFwcyB0aGV5IGFyZSBpbmhlcml0 ZWQgZnJvbSB0aGUNCj4+IHJlZmVyZW5jZWQgc2VjdGlvbnMgaW4gdGhlIEpNUyAxLjEgc3BlYz8g SWYgc28sIHBsZWFzZSBzYXkgc28uIEFoLCBJDQo+PiBzZWUgdGhhdCA0LjEuMyBkb2VzIHNwZWNp Znkgc29tZSBzeW50YXgsIGFsYmVpdCBsb29zZWx5OyB0aGVyZSBhcmUgYQ0KPj4gbG90IG9mIGRp ZmZlcmVudCBzeW50YXhlcyB3aGljaCBtYXkgYmUgdXNlZCB0byBzcGVjaWZ5IOKAnCBudW1iZXIN Cj4+IGJldHdlZW4gMCBhbmQgOSwgaW5jbHVzaXZl4oCdLiBBcmUgeW91IE9LIHdpdGggMHgzIG9y LCBmb3IgdGltZVRvTGl2ZSwNCj4+IOKAnDEsNTAw4oCdPw0KPj4gDQo+IEkgdGhpbmsgdGhpcyB3 YXMgYXQgbGVhc3QgcGFydGlhbGx5IGFkZHJlc3NlZC4NCj4gDQo+PiA1LiA0LjIuMSBQZXJoYXBz IGEgbm90ZSBwcmlvciB0byBsYXVuY2hpbmcgaW50byBhbGwgdGhlIHBhcmFtZXRlcnMgb24NCj4+ IHN5bnRheCBjb25zdHJhaW50cywgd2l0aCwgSeKAmW0gYXNzdW1pbmcsIG5vcm1hdGl2ZSByZWZl cmVuY2VzIGludG8gdGhlDQo+PiBKTVMgc3BlYz8NCj4+IA0KPiBBZGRyZXNzZWQuDQo+IA0KPj4g Ni4gNC4yLjIgaW5jbHVkZXMgZ3JlYXQgZ29icyBvZiBKYXZhIGNvZGUgaWxsdXN0cmF0aW5nIGhv dyB0byB1c2Ugc3VjaA0KPj4gYW4gZW5kcG9pbnQuIERvZXMgdGhpcyBub3QgY29udHJhZGljdCB3 aXRoIHRoZSBhc3NlcnRpb24gYXQgdGhlIHRvcCBvZg0KPj4gc2VjdGlvbiA0IHdoaWNoIHNheXMg 4oCcIE9wZXJhdGlvbnMgYXZhaWxhYmxlIG9uIEpNUyBkZXN0aW5hdGlvbnMgYXJlDQo+PiBmdWxs eSBhbmQgbm9ybWF0aXZlbHkgZGVmaW5lZCBieSB0aGUgSk1TIHNwZWNpZmljYXRpb24gYW5kIGFz IHN1Y2gsDQo+PiBhcmUgb3V0IG9mIHNjb3BlIGZvciB0aGlzIFVSSSBzcGVjaWZpY2F0aW9u4oCd Pw0KPj4gDQo+PiBJbiBhbnkgY2FzZSwgNC4yLjIgbmVlZHMgYSBiaXQgb2YgcHJlcGFyYXRvcnkg bGFuZ3VhZ2UgZXhwbGFpbmluZyB3aGF0DQo+PiBpdCBpcy4gSXMgaXQgbm9ybWF0aXZlIGJlaGF2 aW9yIGZvciBpbXBsZW1lbnRhdGlvbnM/IElzIGl0IHRoZXJlIGZvcg0KPj4gaWxsdXN0cmF0aXZl IHB1cnBvc2VzPyBJcyBpdCByZXF1aXJlZCB0byB1c2UgSmF2YSwgb3IgY291bGQgSSBjb2RlDQo+ PiBzb21ldGhpbmcgZXF1aXZhbGVudCBpbiBDIyBvciBSdWJ5PyBBIGZldyBwYXJhZ3JhcGhzIGlu IHRoZXJl4oCZcyBhDQo+PiBwYXNzaW5nIHJlZmVyZW5jZSB0byDigJx0aGUgZm9sbG93aW5nIChu b24tbm9ybWF0aXZlKSBjb2RlLi4u4oCdDQo+PiANCj4+IDcuIDQuMy4xLCBzZWUgY29tbWVudHMg b24gNC4yLjIgYWJvdmUuIElzIHRoaXMgZGVzY3JpcHRpb24gb2YNCj4+IHByb2dyYW1taW5nIHBy YWN0aWNlIG5vcm1hdGl2ZSwgaWxsdXN0cmF0aXZlLCBvciB3aGF0Pw0KPj4gDQo+IEkgdGhpbmsg dGhlIHVwZGF0ZWQgdGV4dCBpcyBjbGVhcmVyIG9uIHRoZXNlIDIgaXNzdWVzLg0KPiANCj4+IDgu IFNlY3Rpb24gNiwgM3JkIHBhcmE6IEkgaGF2ZW7igJl0IGV2ZXIgc2VlbiBhbnl0aGluZyBsaWtl IHRoZSBub3RlDQo+PiBhYm91dCB3aGF0IGFuIE9BU0lTIFRDIG1pZ2h0IGJlIGRvaW5nIGluIGFu IFJGQyBiZWZvcmUsIGJ1dCBwb3NzaWJseQ0KPj4gSeKAmXZlIGp1c3QgbWlzc2VkIHRoZSBleGFt cGxlcy4NCj4+IA0KPiBJIHRoaW5rIHRoaXMgcG9pbnQgd2FzIGFkZHJlc3NlZC4NCj4gDQo+PiA5 LiBTZWN0aW9uIDcsIGxhc3QgcGFyYTog4oCcQXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNCwgb3Ro ZXJzIGNhbiBkZWZpbmUNCj4+IGFkZGl0aW9uYWwgdmFyaWFudHPigJ0uLi4gdGhlcmUgaXMgbm8g ZGVzY3JpcHRpb24gaW4gU2VjdGlvbiA0IG9mIGhvdyB0bw0KPj4gZGVmaW5lIGFkZGl0aW9uYWwg dmFyaWFudHMuDQo+PiANCj4gUmlnaHQsIEkndmUgbWlzc2VkIHRoYXQuDQo+IA0KPj4gQWxzbywg d2hpbGUgdGhlIGxhbmd1YWdlIGluIHRoZSBvcGVuaW5nIG9mDQo+PiB0aGUgZHJhZnQgc3VnZ2Vz dHMgdGhhdCB0aGUgc2V0IG9mIHZhcmlhbnRzIGlzIG9wZW4tZW5kZWQsIHRoaXMgaXMgdGhlDQo+ PiBmaXJzdCBleHBsaWNpdCBtZW50aW9uIG9mIHRoaXMgcG9zc2liaWxpdHkgdGhhdCBJIGVuY291 bnRlcmVkLiBJcw0KPj4gdGhlcmUgYSByZWdpc3RyeT8NCj4+IA0KPj4gT2gsIHRoZXJlIGl0IGlz IGluIHNlY3Rpb24gOS4yLiBPSywgSSB0aGluayB0aGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlDQo+ PiBkb2MgbmVlZHMgdG8gc2F5IHRoYXQgdGhlIHNldCBvZiB2YXJpYW50cyBpcyBvcGVuLWVuZGVk IGFuZA0KPj4gdmVuZG9yLWV4dGVuc2libGUuIEl0IGFsc28gc21lbGxzIGxpa2UgYSBiaWcgaHVn ZSBob25raW5nDQo+PiBpbnRlcm9wZXJhYmlsaXR5IGhvbGUuDQo+PiANCj4gSSB0aGluayBpdCBk b2VzIG5vdy4NCj4gDQo+PiBOaXRzOg0KPj4gDQo+PiAxLiBTZWN0aW9uIDQgcGFyYSAzLCBzdXBl cmZsdW91cyBjb21tYSBhZnRlciDigJxCb3RoIHRoZSB2YXJpYW504oCdLg0KPj4gDQo+PiAyLiBT ZWN0aW9uIDQgcGFyYSBiZWdpbm5pbmcg4oCcRWFjaCB2YXJpYW50IGNhbiBoYXZlIHF1ZXJ5DQo+ PiBwYXJhbWV0ZXJzLi4u4oCdIC0gZGlkIHlvdSBjb25zaWRlciBzZXBhcmF0aW5nIHRoZSB2YXJp YW50IHByZWZpeCBmcm9tDQo+PiB0aGUgcmVzdCBvZiB0aGUgcGFyYW1ldGVyIG5hbWUgd2l0aCDi gJwu4oCdIG9yIHNvbWUgb3RoZXIgc3ludGF4IG1hcmtlcj8gSQ0KPj4gbm90ZSB0aGF0IHlvdSB1 c2Ug4oCcam5kaS3igJ0gZm9yIGFub3RoZXIgY2xhc3Mgb2YgcGFyYW1ldGVyIG5hbWVzIGJlbG93 Lg0KPj4gDQo+PiAzLiBTZWN0aW9uIDQuMSBJIGFzc3VtZSDigJxzaGFyZWTigJ0gbWVhbnMg4oCc YXZhaWxhYmxlIGluIGFsbCB2YXJpYW50c+KAnT8gSWYNCj4+IHNvLCB3aHkgbm90IHNheSBzbz8N Cj4+IA0KPiBGaXhlZC4NCj4gDQo+PiA0LiBTZWN0aW9uIDQuMSBmaXJzdCBwYXJhLCB0aGUgd29y ZCDigJxwcm9wZXJ0eeKAnSBzdWRkZW5seSBhcHBlYXJzIGZvcg0KPj4gdGhlIGZpcnN0IHRpbWUu IElzIHRoaXMgYSBzeW5vbnltIG9mIOKAnHBhcmFtZXRlcuKAnT8NCj4+IA0KPj4gNS4gU2VjdGlv biA0LjEuMSBMb3RzIG9mIHJlZmVyZW5jZXMgaGVyZSBuZWVkIHRvIGJlIHR1cm5lZCBpbnRvIFJG Qw0KPj4gc3R5bGUgd2l0aCBzcXVhcmUgYnJhY2tldHMNCj4+IA0KPiBJIHRoaW5rIFJGQyBFZGl0 b3Igd2lsbCB0YWtlIGNhcmUgb2YgdGhpcy4NCj4gDQo+PiA1LiBTYW1lIHNlY3Rpb24sIG1pc3Np bmcgZnVsbCBzdG9wIGFmdGVyIOKAnGZvbGxvd2luZyBzaGFyZWQgcGFyYW1ldGVyc+KAnS4NCj4+ IA0KPj4gNi4gNC4xLjEgUHJvYmFibHkgbW9yZSBpZGlvbWF0aWMgb2Ygbm9ybWF0aXZlIHRleHQg dG8gc2F5LCBpbnN0ZWFkIG9mDQo+PiDigJxUaGlzIE1VU1QgYmXigJ0sIOKAnFRoZSB2YWx1ZSBv ZiB0aGlzIHBhcmFtZXRlciBNVVNUIGJlLi4u4oCdDQo+PiANCj4+IDcuIDQuMS4xIE1pc3Npbmcg ZnVsbC1zdG9wIGF0IGVuZC4NCj4+IA0KPj4gOC4gNiwgMm5kIHBhcmE6IFdoYXTigJlzIGFuIOKA nFNQSeKAnT8NCj4+IA0KPiBBbGwgb2YgdGhlc2Ugd2VyZSBmaXhlZCBhcyB3ZWxsLg0KPiANCg== From tbray@textuality.com Sun Jan 30 08:45:13 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249C43A6B0A for ; Sun, 30 Jan 2011 08:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.935 X-Spam-Level: X-Spam-Status: No, score=-2.935 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 tRPNZlWi7eDy for ; Sun, 30 Jan 2011 08:45:11 -0800 (PST) Received: from mail-fx0-f49.google.com (mail-fx0-f49.google.com [209.85.161.49]) by core3.amsl.com (Postfix) with ESMTP id 5660C3A6B20 for ; Sun, 30 Jan 2011 08:45:09 -0800 (PST) Received: by fxm19 with SMTP id 19so6090199fxm.22 for ; Sun, 30 Jan 2011 08:48:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.72.197 with SMTP id n5mr4902411faj.8.1296406100500; Sun, 30 Jan 2011 08:48:20 -0800 (PST) Received: by 10.223.126.212 with HTTP; Sun, 30 Jan 2011 08:48:20 -0800 (PST) X-Originating-IP: [216.113.201.123] Received: by 10.223.126.212 with HTTP; Sun, 30 Jan 2011 08:48:20 -0800 (PST) In-Reply-To: References: <4D456A15.8080708@isode.com> Date: Sun, 30 Jan 2011 08:48:20 -0800 Message-ID: From: Tim Bray To: Alexey Melnikov Content-Type: multipart/alternative; boundary=20cf3054a4f91ae124049b1311e8 Cc: iesg@ietf.org, discuss@apps.ietf.org, derek.rokicki@softwareag.com, m8philli@uk.ibm.com Subject: Re: [apps-discuss] apps-team review of draft-merrick-jms-uri-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 16:45:13 -0000 --20cf3054a4f91ae124049b1311e8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm glad you believe all these problems were fixed: perhaps in future it would be beneficial to include the person who reported them in the fix-up email trail. As for the larger issue, I remain entirely unconvinced that this particular class of identifiers meets the expectations reasonable people have of something that claims to be a URI, but it seems the IESG disagrees with me. -Tim On Jan 30, 2011 5:41 AM, "Alexey Melnikov" wrote: Hi Tim, I am sorry I haven't replied to your message earlier (and didn't make sure that one of the editors do). Tim Bray wrote: > Dear IESG, sorry, got the wrong address for you first time around. > This also ... I have to say that I was a bit concerned about this text as well, but I liked editors honesty regarding the state of affairs. Considering that this URI scheme is already in use (and referenced by other specs) and considering that it is a provisional registration, I think it is Ok. Personally, I would much prefer to register a URI scheme as provisional= , then to reject the URI scheme registration and pretend that it doesn't exist. As other people already pointed out it is important to register URI schemes to at least avoid URI scheme name conflicts. > 2. Section 3.3 says =93 If users plan switching between JMS vendors, > they might also need to pla... I got the same impression. > but the variants are maybe a back-door for vendor abuse. > It is possible. But personally, I prefer to provide some extensible framework to begin with than to let vendors extend URIs is completely unpredictable ways. > Minor Issues: > > 1. Section 1. Need references for terms like javax.jms.Destination for > peopl... I think these 3 issues were addressed. > 4. 4.1.1 and so on, should the draft impose any constraints on the > syntax of these parameter v... I think this was at least partially addressed. > 5. 4.2.1 Perhaps a note prior to launching into all the parameters on > syntax constraints, with... Addressed. > 6. 4.2.2 includes great gobs of Java code illustrating how to use such > an endpoint. Does this ... I think the updated text is clearer on these 2 issues. > 8. Section 6, 3rd para: I haven=92t ever seen anything like the note > about what an OASIS TC migh... I think this point was addressed. > 9. Section 7, last para: =93As described in Section 4, others can define > additional variants=94...... Right, I've missed that. > Also, while the language in the opening of > the draft suggests that the set of variants is open... I think it does now. > Nits: > > 1. Section 4 para 3, superfluous comma after =93Both the variant=94. > > 2. Section 4 para... Fixed. > 4. Section 4.1 first para, the word =93property=94 suddenly appears for > the first time. Is this a ... I think RFC Editor will take care of this. > 5. Same section, missing full stop after =93following shared parameters= =94. > > 6. 4.1.1 Probably mo... All of these were fixed as well. --20cf3054a4f91ae124049b1311e8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I'm glad you believe all these problems were fixed: perhaps in futur= e it would be beneficial to include the person who reported them in the fix= -up email trail.

As for the larger issue, I remain entirely unconvinced that this particu= lar class of identifiers meets the expectations reasonable people have of s= omething that claims to be a URI, but it seems the IESG disagrees with me.<= /p>

-Tim

On Jan 30, 2011 5:41 AM, "Alexey Melnikov= " <alexey.melnikov@iso= de.com> wrote:
Hi Tim,
I am sorry I haven't replied to your message earlier (and didn't ma= ke sure that one of the editors do).



Tim = Bray wrote:

> Dear IESG, sorry, got the wrong address for you fir= st time around.
> This also ...

I have to say that I was a bit concerned about this text as well, but I lik= ed editors honesty regarding the state of affairs.

Considering that this URI scheme is already in use (and referenced by other= specs) and considering that it is a provisional registration, I think it i= s Ok. Personally, I would much prefer to register a URI scheme as provision= al, then to reject the URI scheme registration and pretend that it doesn= 9;t exist. As other people already pointed out it is important to register = URI schemes to at least avoid URI scheme name conflicts.



> 2. Section 3.3 says =93 If users plan = switching between JMS vendors,
> they might also need to pla...

I got the same impression.



> but the v= ariants are maybe a back-door for vendor abuse.
>

It is possible. But personally, I prefer to provide some extensible framewo= rk to begin with than to let vendors extend URIs is completely unpredictabl= e ways.



> Minor Issues:
>
> 1. Section 1. Need references for terms like javax.jms.Destination for=
> peopl...

I think these 3 issues were addressed.



&g= t; 4. 4.1.1 and so on, should the draft impose any constraints on the
&g= t; syntax of these parameter v...

I think this was at least partially addressed.


> 5. 4.2.1 Perhaps a note prior to launching into all the paramete= rs on
> syntax constraints, with...

Addressed.



> 6. 4.2.2 includes great g= obs of Java code illustrating how to use such
> an endpoint. Does thi= s ...

I think the updated text is clearer on these 2 issues.



> 8. Section 6, 3rd para: I haven=92t ever seen anything l= ike the note
> about what an OASIS TC migh...

I think this point was addressed.



> 9.= Section 7, last para: =93As described in Section 4, others can define
&= gt; additional variants=94......

Right, I've missed that.



> Also, w= hile the language in the opening of
> the draft suggests that the set= of variants is open...

I think it does now.



> Nits:
>> 1. Section 4 para 3, superfluous comma after =93Both the variant=94.=
>
> 2. Section 4 para...

Fixed.



> 4. Section 4.1 first para, th= e word =93property=94 suddenly appears for
> the first time. Is this = a ...

I think RFC Editor will take care of this.


> 5. Same section, missing full stop after =93following shared paramet= ers=94.
>
> 6. 4.1.1 Probably mo...

All of these were fixed as well.

--20cf3054a4f91ae124049b1311e8-- From fielding@gbiv.com Sun Jan 30 10:17:07 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C373A697A for ; Sun, 30 Jan 2011 10:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.034 X-Spam-Level: X-Spam-Status: No, score=-103.034 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 JXvsciYWpkvt for ; Sun, 30 Jan 2011 10:17:05 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id D82253A684E for ; Sun, 30 Jan 2011 10:17:05 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id BB2D5768058; Sun, 30 Jan 2011 10:20:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=R3LQgLoaN1Mf5jBk MT0dbz2fkpFTxRy+KwW4LnMxzvFSKINxQG4cJmvPaT7/wWEWfI+Q8sVV8CWhqAMP qDcgq+V/mOlVV/I8SgQzP+bkSaH0c62h7ZEVeknB2DCPzYDfUJ1fzEdvHmhN/Xh7 9YFwiRLnaI+Xwp5K7oCx76+W5nQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=JHPGBa7+9F5DMkfKHkQymkzRJF8=; b=ffDLvs1krWGGepDewOSlLF0cvZUF qmBDy5A6TxnjlTV97fk2Huf6T5MMZKlfIxcAb6qr4RWOsmqulBCBqC2a8vxguI9I MxHic+9ukU32cvRjXH/rSJ4Y/8Tq1w9OCVpnjiHlh7qr1QcERW/NOaRajXZmbc6J vIJ3qj05rU/40u0= Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (Authenticated sender: fielding@gbiv.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPA id 9133C768057; Sun, 30 Jan 2011 10:20:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <4D455380.6040103@gmail.com> Date: Sun, 30 Jan 2011 10:20:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3792F8F3-D01B-4B05-9E73-59228F09FE5C@gbiv.com> References: %3C4D26B005.2060909@gmail.com%3E <4D2C7755.5080908@gmail.com> <81F42F63D5BB344ABF294F8E80990C7902782BBA@MTV-EXCHANGE.microfocus.com> <4D455380.6040103@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1082) Cc: URI , apps-discuss@ietf.org Subject: Re: [apps-discuss] The state of 'afs' URi scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 18:17:07 -0000 On Jan 30, 2011, at 4:03 AM, Mykyta Yevstifeyev wrote: > Hello all, >=20 > I'd like to resume the discussion on 'afs' URI scheme by citing RFC = 4395: > =20 >> In some circumstances, it is appropriate to note a URI scheme that >> was once in use or registered but for whatever reason is no longer = in >> common use or the use is not recommended. In this case, it is >> possible for an individual to request that the URI scheme be >> registered (newly, or as an update to an existing registration) as >> 'historical'. Any scheme that is no longer in common use MAY be >> designated as historical; the registration should contain some >> indication to where the scheme was previously defined or = documented. >=20 > So there is a sense in moving this scheme to Historical category since = it fully matches to these guidelines. Therefore I do not consider such = action as inappropriate for the 'afs' URI scheme. No, there is no reason to publish a new document about a scheme that was never used. It is obsolete. ....Roy From evnikita2@gmail.com Sun Jan 30 21:51:13 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980663A695D; Sun, 30 Jan 2011 21:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.191 X-Spam-Level: X-Spam-Status: No, score=-3.191 tagged_above=-999 required=5 tests=[AWL=0.408, 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 1qucOIWTWCvz; Sun, 30 Jan 2011 21:51:12 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 075CD3A692C; Sun, 30 Jan 2011 21:51:11 -0800 (PST) Received: by fxm9 with SMTP id 9so5733620fxm.31 for ; Sun, 30 Jan 2011 21:54:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=p1NSJmMo2Spx5lOn8FguCccSC7OeVEgJPYRQc1WIIxc=; b=hp30BYu/IANtNXCN+/stWgCO0+96lSLbcWM6DqhVyxb3DBXbW1xI08QyWalFUGGYRd doynDB6DvbW1tIlu8T7khKZv7lW6Y5FXEBuRImc9DdgUIBBrAL60pM5c6YYH0NlfIFGu EGRTdHOPmFLTYEveW3gPSOJZUKHXOI4Ayx2PU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=uzvxMS++XEoVlEWnr6Rk7+uiQhKJNxM0xwRwSFt8r3WSmfQBA2Tu+ihZBfQw7jG2Bd sgMJmCgzoC0CHf7KNmFZAWxJwBO5WW7QeSp9piyhYOzLJy9cHR2In2CQQ3lgYIZhgfnn jhQitjtpQ7EZyLgvWSN0+gn9lUA/QCWZMSsT4= Received: by 10.223.86.71 with SMTP id r7mr5577576fal.137.1296453263575; Sun, 30 Jan 2011 21:54:23 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id o17sm7188868fal.1.2011.01.30.21.54.20 (version=SSLv3 cipher=RC4-MD5); Sun, 30 Jan 2011 21:54:21 -0800 (PST) Message-ID: <4D464EA4.7090303@gmail.com> Date: Mon, 31 Jan 2011 07:54:44 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Roy T. Fielding" References: %3C4D26B005.2060909@gmail.com%3E <4D2C7755.5080908@gmail.com> <81F42F63D5BB344ABF294F8E80990C7902782BBA@MTV-EXCHANGE.microfocus.com> <4D455380.6040103@gmail.com> <3792F8F3-D01B-4B05-9E73-59228F09FE5C@gbiv.com> In-Reply-To: <3792F8F3-D01B-4B05-9E73-59228F09FE5C@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: URI , "uri-review@ietf.org" , apps-discuss@ietf.org Subject: Re: [apps-discuss] The state of 'afs' URi scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 05:51:13 -0000 30.01.2011 20:20, Roy T. Fielding wrote: > On Jan 30, 2011, at 4:03 AM, Mykyta Yevstifeyev wrote: > >> Hello all, >> >> I'd like to resume the discussion on 'afs' URI scheme by citing RFC 4395: >> >>> In some circumstances, it is appropriate to note a URI scheme that >>> was once in use or registered but for whatever reason is no longer in >>> common use or the use is not recommended. In this case, it is >>> possible for an individual to request that the URI scheme be >>> registered (newly, or as an update to an existing registration) as >>> 'historical'. Any scheme that is no longer in common use MAY be >>> designated as historical; the registration should contain some >>> indication to where the scheme was previously defined or documented. >> So there is a sense in moving this scheme to Historical category since it fully matches to these guidelines. Therefore I do not consider such action as inappropriate for the 'afs' URI scheme. > No, there is no reason to publish a new document about a > scheme that was never used. It is obsolete. Roy, I think that the document like that may be found here: https://datatracker.ietf.org/doc/draft-melnikov-mailserver-uri-to-historic/ is suitable for 'afs' URI scheme. This is the same situation as with the 'mailserver' URI scheme. Mykyta > ....Roy > > From fielding@gbiv.com Mon Jan 31 00:25:17 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD0C3A6BBA; Mon, 31 Jan 2011 00:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.01 X-Spam-Level: X-Spam-Status: No, score=-103.01 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Q8kCxFMGANZp; Mon, 31 Jan 2011 00:25:16 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 889FD3A6BBC; Mon, 31 Jan 2011 00:25:16 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 44C6A674060; Mon, 31 Jan 2011 00:28:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=H2FNaaNK8bHaTamx T7F1J9Sh94ZsuGe9zX+l1rrI6uaxOk7/VQpurvCifqTeF9njbuLN5X6lOQLmiR6x 0BdGupoPBmqeeVlSjGW9NFMLWG8hBvsLSCk8bKMybD8LISiYT0xgIv+5xE0H7YUK myVoz8uicvADBh8BDdmPr+cO8Bg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=fQWlrTxDJSKVMnc4bW0ji/87xSY=; b=mcpAzGGViQjaKaq0cH8/lZ0fGCY0 3yzj6S7+Xn+0JbQcNCENJNQCziDz/0qEqEeYXy9vu02nZ/+51iGhhURjJG2DB2QB xrL81lRvZA2w9XOScfXgpz3eFPPhXZ5Iz9PMG5deX6T0GxmXqvw/qRVDIc85p9Ly XzXOGyudAgV0XEw= Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (Authenticated sender: fielding@gbiv.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id E457D674058; Mon, 31 Jan 2011 00:28:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <4D464EA4.7090303@gmail.com> Date: Mon, 31 Jan 2011 00:28:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7ED44745-7DBA-4372-BE39-22061DC26DF2@gbiv.com> References: %3C4D26B005.2060909@gmail.com%3E <4D2C7755.5080908@gmail.com> <81F42F63D5BB344ABF294F8E80990C7902782BBA@MTV-EXCHANGE.microfocus.com> <4D455380.6040103@gmail.com> <3792F8F3-D01B-4B05-9E73-59228F09FE5C@gbiv.com> <4D464EA4.7090303@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1082) Cc: URI , "uri-review@ietf.org" , apps-discuss@ietf.org Subject: Re: [apps-discuss] The state of 'afs' URi scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 08:25:17 -0000 On Jan 30, 2011, at 9:54 PM, Mykyta Yevstifeyev wrote: > 30.01.2011 20:20, Roy T. Fielding wrote: >> On Jan 30, 2011, at 4:03 AM, Mykyta Yevstifeyev wrote: >>=20 >>> Hello all, >>>=20 >>> I'd like to resume the discussion on 'afs' URI scheme by citing RFC = 4395: >>>=20 >>>> In some circumstances, it is appropriate to note a URI scheme that >>>> was once in use or registered but for whatever reason is no = longer in >>>> common use or the use is not recommended. In this case, it is >>>> possible for an individual to request that the URI scheme be >>>> registered (newly, or as an update to an existing registration) = as >>>> 'historical'. Any scheme that is no longer in common use MAY be >>>> designated as historical; the registration should contain some >>>> indication to where the scheme was previously defined or = documented. >>> So there is a sense in moving this scheme to Historical category = since it fully matches to these guidelines. Therefore I do not consider = such action as inappropriate for the 'afs' URI scheme. >> No, there is no reason to publish a new document about a >> scheme that was never used. It is obsolete. > Roy, >=20 > I think that the document like that may be found here: = https://datatracker.ietf.org/doc/draft-melnikov-mailserver-uri-to-historic= / is suitable for 'afs' URI scheme. This is the same situation as with = the 'mailserver' URI scheme. No, there is no reason to have that document either. We don't need these useless exercises in bit pushing -- there are plenty of other drafts that need writing about actual protocols that were (and are) used on the Web as identifiers. afs, nfs, tn3270, and mailserver are all examples of schemes that someone once thought might be a good idea, but were in fact never used on the Internet. They are obsolete. ....Roy= From evnikita2@gmail.com Mon Jan 31 03:17:00 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B815B3A6903; Mon, 31 Jan 2011 03:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.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 Ryui7MBWC0XV; Mon, 31 Jan 2011 03:16:59 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 306ED3A68ED; Mon, 31 Jan 2011 03:16:59 -0800 (PST) Received: by fxm9 with SMTP id 9so5991729fxm.31 for ; Mon, 31 Jan 2011 03:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vZCp7FujeuAN+7mUVnWqSbxxA1UL2YUM+xGWXHVphJg=; b=JcjgHrT6kd9zkTtBTjHwP5XjmmG0lcLKi6jblxnyY4WPvXdpyrbcCMUxygYkrnpxLk pQF5wfq4MbH+OLs8dL3j6eZ8d5k3mb0Plfn3PJ4f3gwhE+T2dwj55M3jI2OG60Re145p vhr7qYghuu3SiKvcE8+4aqXdZKL7E2nt//+Vw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=PJKXvJEEGe18H6Vp1Vazvd+2KfJNc4S9yNfDgFC3Bdm7sZYmvmZwVgafsux/96F1U8 yP89vpxyiTqkW+ZtP5xlfr04yXnkLqSOjA3FYlxuW94uG+OiSAtGMewPPjRIPUDjcL2J cRde+XpXcWME6oPf8TV6aXd/4t+tc2SJyj9iI= Received: by 10.223.83.4 with SMTP id d4mr122584fal.59.1296472810909; Mon, 31 Jan 2011 03:20:10 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id n2sm7292025fam.28.2011.01.31.03.20.09 (version=SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 03:20:09 -0800 (PST) Message-ID: <4D469B00.3030404@gmail.com> Date: Mon, 31 Jan 2011 13:20:32 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Roy T. Fielding" References: %3C4D26B005.2060909@gmail.com%3E <4D2C7755.5080908@gmail.com> <81F42F63D5BB344ABF294F8E80990C7902782BBA@MTV-EXCHANGE.microfocus.com> <4D455380.6040103@gmail.com> <3792F8F3-D01B-4B05-9E73-59228F09FE5C@gbiv.com> <4D464EA4.7090303@gmail.com> <7ED44745-7DBA-4372-BE39-22061DC26DF2@gbiv.com> In-Reply-To: <7ED44745-7DBA-4372-BE39-22061DC26DF2@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: URI , "uri-review@ietf.org" , apps-discuss@ietf.org Subject: Re: [apps-discuss] The state of 'afs' URi scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 11:17:00 -0000 31.01.2011 10:28, Roy T. Fielding wrote: > On Jan 30, 2011, at 9:54 PM, Mykyta Yevstifeyev wrote: >> 30.01.2011 20:20, Roy T. Fielding wrote: >>> On Jan 30, 2011, at 4:03 AM, Mykyta Yevstifeyev wrote: >>> >>>> Hello all, >>>> >>>> I'd like to resume the discussion on 'afs' URI scheme by citing RFC 4395: >>>> >>>>> In some circumstances, it is appropriate to note a URI scheme that >>>>> was once in use or registered but for whatever reason is no longer in >>>>> common use or the use is not recommended. In this case, it is >>>>> possible for an individual to request that the URI scheme be >>>>> registered (newly, or as an update to an existing registration) as >>>>> 'historical'. Any scheme that is no longer in common use MAY be >>>>> designated as historical; the registration should contain some >>>>> indication to where the scheme was previously defined or documented. >>>> So there is a sense in moving this scheme to Historical category since it fully matches to these guidelines. Therefore I do not consider such action as inappropriate for the 'afs' URI scheme. >>> No, there is no reason to publish a new document about a >>> scheme that was never used. It is obsolete. >> Roy, >> >> I think that the document like that may be found here: https://datatracker.ietf.org/doc/draft-melnikov-mailserver-uri-to-historic/ is suitable for 'afs' URI scheme. This is the same situation as with the 'mailserver' URI scheme. > No, there is no reason to have that document either. We don't need > these useless exercises in bit pushing -- there are plenty of other > drafts that need writing about actual protocols that were (and are) > used on the Web as identifiers. afs, nfs, tn3270, and mailserver are > all examples of schemes that someone once thought might be a good idea, > but were in fact never used on the Internet. They are obsolete. Roy, Since these schemes are in Provisional category, it means that they are 'waiting for specification'. If no-one specifies them, they should be moved to Historical. That's clear, IMO. Mykyta > ....Roy From paul.hoffman@vpnc.org Mon Jan 31 06:56:17 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C433A6BFF for ; Mon, 31 Jan 2011 06:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.755 X-Spam-Level: X-Spam-Status: No, score=-101.755 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] 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 L2K81xkGLlur for ; Mon, 31 Jan 2011 06:56:16 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D14DA3A6B32 for ; Mon, 31 Jan 2011 06:56:15 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0VExTCV065892 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 31 Jan 2011 07:59:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D46CE52.6030503@vpnc.org> Date: Mon, 31 Jan 2011 06:59:30 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: apps-discuss@ietf.org References: %3C4D26B005.2060909@gmail.com%3E <4D2C7755.5080908@gmail.com> <81F42F63D5BB344ABF294F8E80990C7902782BBA@MTV-EXCHANGE.microfocus.com> <4D455380.6040103@gmail.com> <3792F8F3-D01B-4B05-9E73-59228F09FE5C@gbiv.com> <4D464EA4.7090303@gmail.com> <7ED44745-7DBA-4372-BE39-22061DC26DF2@gbiv.com> In-Reply-To: <7ED44745-7DBA-4372-BE39-22061DC26DF2@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] The state of 'afs' URi scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 14:56:18 -0000 On 1/31/11 12:28 AM, Roy T. Fielding wrote: > No, there is no reason to have that document either. We don't need > these useless exercises in bit pushing -- there are plenty of other > drafts that need writing about actual protocols that were (and are) > used on the Web as identifiers. afs, nfs, tn3270, and mailserver are > all examples of schemes that someone once thought might be a good idea, > but were in fact never used on the Internet. They are obsolete. +1 On 1/31/11 3:20 AM, Mykyta Yevstifeyev wrote: > Since these schemes are in Provisional category, it means that they are > 'waiting for specification'. If no-one specifies them, they should be > moved to Historical. That's clear, IMO. -1 Mykyta, you are approximately the only person who seems to have a problem understanding that standards organizations like the IETF sometimes don't follow through on what they thought were good ideas and sometimes don't document that. Your response is to generate many useless efforts to clean up the IETF specs instead of just doing what everyone else does, which is to ask a question, find the answer, and move on. It feels like you are wasting lots of people's time for the benefit of no one other than maybe yourself. (If there are others who feel that Mykyta's efforts are worth our time, by all means speak up and I'm happy to back down here.) From julian.reschke@gmx.de Mon Jan 31 07:08:11 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022F53A6C01 for ; Mon, 31 Jan 2011 07:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.115 X-Spam-Level: X-Spam-Status: No, score=-104.115 tagged_above=-999 required=5 tests=[AWL=-1.516, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 nuSwk5og9PmX for ; Mon, 31 Jan 2011 07:08:09 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 283193A6BFD for ; Mon, 31 Jan 2011 07:08:08 -0800 (PST) Received: (qmail invoked by alias); 31 Jan 2011 15:11:21 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.134]) [217.91.35.233] by mail.gmx.net (mp006) with SMTP; 31 Jan 2011 16:11:21 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/ZCC5TjFrZ5HO2gF2LDhpiFmQ9h2JHTIzLXO/8t+ CVLqYezDAtqmf8 Message-ID: <4D46D118.6000403@gmx.de> Date: Mon, 31 Jan 2011 16:11:20 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Hoffman References: %3C4D26B005.2060909@gmail.com%3E <4D2C7755.5080908@gmail.com> <81F42F63D5BB344ABF294F8E80990C7902782BBA@MTV-EXCHANGE.microfocus.com> <4D455380.6040103@gmail.com> <3792F8F3-D01B-4B05-9E73-59228F09FE5C@gbiv.com> <4D464EA4.7090303@gmail.com> <7ED44745-7DBA-4372-BE39-22061DC26DF2@gbiv.com> <4D46CE52.6030503@vpnc.org> In-Reply-To: <4D46CE52.6030503@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The state of 'afs' URi scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 15:08:11 -0000 On 31.01.2011 15:59, Paul Hoffman wrote: > ... > Mykyta, you are approximately the only person who seems to have a > problem understanding that standards organizations like the IETF > sometimes don't follow through on what they thought were good ideas and > sometimes don't document that. Your response is to generate many useless > efforts to clean up the IETF specs instead of just doing what everyone > else does, which is to ask a question, find the answer, and move on. It > feels like you are wasting lots of people's time for the benefit of no > one other than maybe yourself. (If there are others who feel that > Mykyta's efforts are worth our time, by all means speak up and I'm happy > to back down here.) > ... +1 Speaking of which: there are URI schemes that *are* in use and should be registered (independently how "bad" we think they are); candidates are "itms" and "ical", which will probably require collaboration from Apple. Best regards, Julian From alexey.melnikov@isode.com Mon Jan 31 11:28:38 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7811B3A6C54 for ; Mon, 31 Jan 2011 11:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 sHYpfN5zsr+V for ; Mon, 31 Jan 2011 11:28:37 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 879743A6C3F for ; Mon, 31 Jan 2011 11:28:37 -0800 (PST) Received: from [192.168.0.102] ((unknown) [109.73.6.25]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 31 Jan 2011 19:31:51 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D470E07.6000300@isode.com> Date: Mon, 31 Jan 2011 22:31:19 +0300 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Julian Reschke References: %3C4D26B005.2060909@gmail.com%3E <4D2C7755.5080908@gmail.com> <81F42F63D5BB344ABF294F8E80990C7902782BBA@MTV-EXCHANGE.microfocus.com> <4D455380.6040103@gmail.com> <3792F8F3-D01B-4B05-9E73-59228F09FE5C@gbiv.com> <4D464EA4.7090303@gmail.com> <7ED44745-7DBA-4372-BE39-22061DC26DF2@gbiv.com> <4D46CE52.6030503@vpnc.org> <4D46D118.6000403@gmx.de> In-Reply-To: <4D46D118.6000403@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] The state of 'afs' URi scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:28:38 -0000 Julian Reschke wrote: > On 31.01.2011 15:59, Paul Hoffman wrote: > >> ... >> Mykyta, you are approximately the only person who seems to have a >> problem understanding that standards organizations like the IETF >> sometimes don't follow through on what they thought were good ideas and >> sometimes don't document that. Your response is to generate many useless >> efforts to clean up the IETF specs instead of just doing what everyone >> else does, which is to ask a question, find the answer, and move on. It >> feels like you are wasting lots of people's time for the benefit of no >> one other than maybe yourself. (If there are others who feel that >> Mykyta's efforts are worth our time, by all means speak up and I'm happy >> to back down here.) >> ... > > +1 > > Speaking of which: there are URI schemes that *are* in use and should > be registered (independently how "bad" we think they are); candidates > are "itms" and "ical", which will probably require collaboration from > Apple. As well as imaps:, pops: and possibly even smtp: From fielding@gbiv.com Mon Jan 31 11:29:02 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4593A6C5F; Mon, 31 Jan 2011 11:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.988 X-Spam-Level: X-Spam-Status: No, score=-102.988 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 2S677XwesIyf; Mon, 31 Jan 2011 11:29:01 -0800 (PST) Received: from homiemail-a30.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 5FB303A6C3F; Mon, 31 Jan 2011 11:29:01 -0800 (PST) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 4648421DE77; Mon, 31 Jan 2011 11:32:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=A04DAe0zAV+jFVMV nbp6f0qT3vfwSlc/Pi5XTznoHhdv/fpIy91/MCCsjVtG2AA8I3G75725aTCrsGpa IHGcymIYQLq3FPHvdZk4F8BI9i24+OxbLPS1okBlSwoVJJKVihPuZ1zdQzyQhCRQ 2Lfx6wunCgcZ3QMVNbRUu2mrwjQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=ItVmVGO7+gCRiWpxy9lfad97/YY=; b=PfJz0l5qtKqZo/ssa8fc+GAmDlFY WPxNr03Xenh5oVyYeRfgdr6OIQg+k/dm4LK7ASSilg2cJwR2eh02g1YprMHcITzP anHNMs+eB1D0LaKh+oMzOkw3yDps+svqRlwCoOQSPfvnTnLaEVZeXl9JEMKD+wYq T2bO2fUDSF8GzBs= Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (Authenticated sender: fielding@gbiv.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPA id EA8D621DE57; Mon, 31 Jan 2011 11:32:15 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <4D469B00.3030404@gmail.com> Date: Mon, 31 Jan 2011 11:32:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <321C12D4-7F60-48DC-A0D2-54682DFA5D18@gbiv.com> References: %3C4D26B005.2060909@gmail.com%3E <4D2C7755.5080908@gmail.com> <81F42F63D5BB344ABF294F8E80990C7902782BBA@MTV-EXCHANGE.microfocus.com> <4D455380.6040103@gmail.com> <3792F8F3-D01B-4B05-9E73-59228F09FE5C@gbiv.com> <4D464EA4.7090303@gmail.com> <7ED44745-7DBA-4372-BE39-22061DC26DF2@gbiv.com> <4D469B00.3030404@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1082) Cc: URI , "uri-review@ietf.org" , apps-discuss@ietf.org Subject: Re: [apps-discuss] The state of 'afs' URi scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:29:02 -0000 On Jan 31, 2011, at 3:20 AM, Mykyta Yevstifeyev wrote: > Since these schemes are in Provisional category, it means that they = are 'waiting for specification'. If no-one specifies them, they should = be moved to Historical. That's clear, IMO. No, they should be removed from the registry and allowed to be defined by some other spec in the future. There is no need to reserve the schemes of unimplemented identifier mechanisms. ....Roy From alexey.melnikov@isode.com Mon Jan 31 12:25:00 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF6E3A6C57 for ; Mon, 31 Jan 2011 12:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 x1AefjRfGATH for ; Mon, 31 Jan 2011 12:24:59 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6E3E33A6C4E for ; Mon, 31 Jan 2011 12:24:56 -0800 (PST) Received: from [192.168.0.102] ((unknown) [109.73.6.25]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 31 Jan 2011 20:28:10 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D471B36.4050503@isode.com> Date: Mon, 31 Jan 2011 23:27:34 +0300 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps-Discuss@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------060801090008010506010001" Subject: [apps-discuss] [Fwd: NomCom 2010-2011: IESG Appointments] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 20:25:00 -0000 This is a multi-part message in MIME format. --------------060801090008010506010001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------060801090008010506010001 Content-Type: message/rfc822; name="NomCom 2010-2011: IESG Appointments" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="NomCom 2010-2011: IESG Appointments" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine.isode.net (Isode M-Box/14.6a5) with LMTP; Mon, 31 Jan 2011 18:14:51 +0000 (GMT) Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external) via TCP with ESMTP id for ; Mon, 31 Jan 2011 18:14:50 +0000 X-SPF-Result: PASS rufus.isode.com: domain of ietf.org designates 64.170.98.32 as permitted sender Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 940903A6B01; Mon, 31 Jan 2011 10:11:24 -0800 (PST) X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E62DE3A6B32; Mon, 31 Jan 2011 10:11:22 -0800 (PST) From: NomCom Chair To: IETF Announcement list Subject: NomCom 2010-2011: IESG Appointments Mime-Version: 1.0 Message-Id: <20110131181122.E62DE3A6B32@core3.amsl.com> Date: Mon, 31 Jan 2011 10:11:22 -0800 (PST) X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org Hi Folks, The 2010-2011 IETF Nominating committee is pleased to announce the selection of the IESG members whose two year terms start in March 2011. The following have been selected to serve as ADs by the nominating committee for the open IESG positions and confirmed by the IAB in their role as confirming body: GEN/IETF Chair: Russ Housley Applications: Pete Resnick Internet: Ralph Droms Operations and Management: Ron Bonica Real-time Applications and Infrastructure: Robert Sparks Routing: Adrian Farrel Security: Stephen Farrell Transport: Wesley Eddy Our thanks to the incumbents who are not returning for their outstanding service, to the many qualified members of the community who offered to serve, to the community for their assistance in this process, and to the named individuals above for agreeing to serve the community on the IESG. Best Regards, Thomas Walsh nomcom-chair@ietf.org twalsh@juniper.net _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------060801090008010506010001-- From Claudio.Allocchio@garr.it Mon Jan 31 13:41:22 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF05C3A6C9E for ; Mon, 31 Jan 2011 13:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 7NEW63eQGQqV for ; Mon, 31 Jan 2011 13:41:18 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 118983A6CA9 for ; Mon, 31 Jan 2011 13:41:17 -0800 (PST) Received: from webcam1-all.garrtest.units.it (webcam1-all.garrtest.units.it [140.105.201.5]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p0VLiSwJ002079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 22:44:29 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p0VLiSwJ002079 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=S7jH7oI8r/h6Z/iSpYPqu40/RVMFUDE/3QQ25GZrLx2je2a6yqo1GOmsltPVmsbAj ptxBma/xz9nyCNrJSfXIno4qB59QDVIgNhcsCsH7LzgVsSfED4knJukoYVHRYXNRQha fr4s/+LU5h1xePBY+IeRNHli58OgGQAKMUbZr/w= Date: Mon, 31 Jan 2011 22:44:28 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@webcam1-all.garrtest.units.it To: Alexey Melnikov In-Reply-To: <4D471B36.4050503@isode.com> Message-ID: References: <4D471B36.4050503@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Apps-Discuss@ietf.org Subject: Re: [apps-discuss] [Fwd: NomCom 2010-2011: IESG Appointments] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:41:22 -0000 thanks for all your important effort, Alexey, ... and of course "welcome Mr new Director", :-) Thanks Pete for your time in doing this! ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From patrik@frobbit.se Mon Jan 31 14:50:24 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA943A6B26 for ; Mon, 31 Jan 2011 14:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.859 X-Spam-Level: X-Spam-Status: No, score=-101.859 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 8ttVY4NEmPm1 for ; Mon, 31 Jan 2011 14:50:24 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by core3.amsl.com (Postfix) with ESMTP id 935583A6B20 for ; Mon, 31 Jan 2011 14:50:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id DBEE1F60D66A; Mon, 31 Jan 2011 23:53:37 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG2hYFf5q3ka; Mon, 31 Jan 2011 23:53:37 +0100 (CET) Received: from [10.109.107.185] (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 7FB36F60D666; Mon, 31 Jan 2011 23:53:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 31 Jan 2011 22:43:34 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0B963818-B8FE-4C8D-AAD1-753546500786@frobbit.se> References: <4D471B36.4050503@isode.com> To: Claudio Allocchio X-Mailer: Apple Mail (2.1082) Cc: Apps-Discuss@ietf.org Subject: Re: [apps-discuss] [Fwd: NomCom 2010-2011: IESG Appointments] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 22:50:24 -0000 On 31 jan 2011, at 21.44, Claudio Allocchio wrote: > thanks for all your important effort, Alexey, ... >=20 > and of course "welcome Mr new Director", :-) Thanks Pete for your time = in doing this! +1 Can not say it better myself! Patrik From eric@tibco.com Mon Jan 31 15:00:13 2011 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B21D3A6B26 for ; Mon, 31 Jan 2011 15:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ht4rypHZLh3i for ; Mon, 31 Jan 2011 15:00:11 -0800 (PST) Received: from mx1-app.tibco.com (mx1-app.tibco.com [63.100.100.142]) by core3.amsl.com (Postfix) with ESMTP id D2CD33A6B20 for ; Mon, 31 Jan 2011 15:00:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,406,1291622400"; d="scan'208,217";a="20848260" Received: from tibco-5.tibco.com (HELO na-pa-fe02.na.tibco.com) ([63.100.100.5]) by mx1-app.tibco.com with ESMTP; 31 Jan 2011 15:03:20 -0800 Received: from Eric-Johnsons-MacBook-Pro.local ([10.98.36.64]) by na-pa-fe02.na.tibco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Jan 2011 15:03:17 -0800 Message-ID: <4D473FB4.2070009@tibco.com> Date: Mon, 31 Jan 2011 15:03:16 -0800 From: Eric Johnson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tim Bray References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050109060309050307060608" X-OriginalArrivalTime: 31 Jan 2011 23:03:17.0712 (UTC) FILETIME=[0C170D00:01CBC19B] X-TM-AS-Product-Ver: SMEX-10.0.0.1412-6.500.1024-17926.006 X-TM-AS-Result: No--29.838300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: derek.rokicki@softwareag.com, SM , Apps Discuss , The IESG , m8philli@uk.ibm.com, peaston@progress.com Subject: Re: [apps-discuss] apps-team review of draft-merrick-jms-uri-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 23:00:13 -0000 This is a multi-part message in MIME format. --------------050109060309050307060608 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Tim, Alexey Melnikov asked that I recreate the full email response that I managed to delete/fail to send the first time around. In any case, just as an overview, this is the URL that manages to capture the changes mostly specific to your feedback: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-merrick-jms-uri-11.txt On 12/16/10 4:01 PM, Tim Bray wrote: > I have been selected as the Applications Area Review Team reviewer for > this draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-merrick-jms-uri-10 > Title: URI Scheme for Java(tm) Message Service 1.0 > Reviewer: Tim Bray > Review Date: Dec 16, 2010 > Summary: The draft has some mechanical issues which are not > show-stoppers. I have questions whether this ought to be an RFC since > there seems very modest expectation of interoperability between > implementations; why, then, an IETF RFC, which suggests that the > resulting URIs should be useful for identification of resources on an > internetworked scale. > Major Issues: > > 1. the draft suggests that given a “jms:” URI, there is little > expectation that, without checking on the value of the “variant” and > for the presence of vendor-specific parameters, it can be used > interoperably in more than one implementation. In which case, I have > to wonder about the appropriateness of using a *Uniform* resource > identifier for whatever purposes are contemplated for these things; If nothing else, we're trying to bring uniformity to syntax and semantics for "jms" schemes that exist in the wild, and register *something*. > no > motivations or use-cases are provided. Perhaps you missed the references in section 6? The draft itself cites two other standards efforts using the JMS URI - SOAP/JMS - where the "jms" URI scheme will be used in the same place an HTTP URI might appear, and the OASIS SCA Bindings TC, where the URI indicates the destination of an SCA reference using a JMS binding. > The last paragraph of section 1 is troubling. For convenience, I quote: > <<<<< > As a consequence of building upon an API, rather than a protocol, the > utility of a "jms" URI depends on the context in which it is used. > That context includes agreement on the same JMS provider or underlying > protocol, agreement on how to look up endpoints (JNDI), and when using > serialized Java object messages, sufficiently similar Java Class > environments that serialized objects can be appropriately read and > written. Users of this scheme need to establish the necessary shared > context parts as just enumerated - a context which can span the globe, > or merely a small local network. With that shared context, this URI > scheme enables endpoint identification in a uniform way, and the means > to connect to those endpoints. > Given this, what are the advantages of having a *Uniform* resource > identifier, if there is not much expectation of uniformity in > implementations? Some answers: * One can deploy a "bridge" between two JMS providers, thus providing interoperability between two JMS implementation, such that one client is unaware that the other client is not using the same JMS provider. * Via the JCP, JMS cements an API. We're looking to establish interoperability at the level above that API, not at the level of the implementation of that API. That the implementations are not the same underneath that API ought not prevent standards efforts on top of the API that has been cemented by the JCP. We're stuck, in that our use-cases demand a URL (for example, in the place of HTTP scheme URIs in WSDL), but we're building upon an API rather than an actual protocol. In the end, we think it a better idea to register the scheme than not. > 2. Section 3.3 says “ If users plan switching between JMS vendors, > they might also need to plan on regenerating resources that contain > URIs in this vendor specific form”; this sharpens my concerns about > the lack of interoperability... > > I’m getting the impression, reading this, that “jms:jndi” is probably > quite interoperable, but the variants are maybe a back-door for vendor > abuse. Originally, we wrote the spec to only accommodate the JNDI approach. We eventually exposed three broad reasons for the variants: * The JMS API itself. The original 1.0 spec of JMS had two ways of establishing Destination objects, neither of which used JNDI (our "topic" and "queue" variants). The 1.1 version of the spec introduced the JNDI approach, and that's the obviously preferred method. * Broadest possible compatibility with existing uses of "JMS" URI schemes. In the early days of JMS, vendors defined their own ways to establish JMS Destinations, and we want to make sure that the proposed URI encompasses those possibilities, so that clients of the JMS scheme can look at the variant and know unambiguously that theh *don't* understand, rather than attempting to work with a "jms" URI, not working, and not knowing why. * Future proofing. Some JMS messaging products are based on documented protocols. Should they establish a better way of identifying JMS Destinations, and write up a new variant for doing so, this enables accessing said destinations, without revisiting the JMS URI scheme. None of the authors working on the scheme anticipate registering any new variants. Originally, we did not want an IANA registry to allow for additional variants, but previous feedback pushed us in that direction. > Minor Issues: > > 1. Section 1. Need references for terms like javax.jms.Destination for > people who aren’t familiar with Java pathname voodoo. I added [REF-JMS] here. > 2. Section 4 para beginning “Each variant can have query > parameters...” - did you consider separating the variant prefix from > the rest of the parameter name with “.” or some other syntax marker? I > note that you use “jndi-” for another class of parameter names below. We considered a lot of options here. Realistically, I can probably come up with any sort of post-hoc rationalization. Using the "jndi" prefix for the "jndi" variant, without any such separator worked out naturally based on the initial proposals we started from, followed by introducing the variants. > 3. Same paragraph. Should the variant be used as a prefix even if it’s > a vendor-supplied one starting with “vnd.”? An example of this would > be nice. Excellent point. I added an example of "vnd.example.exParameter." > 4. 4.1.1 and so on, should the draft impose any constraints on the > syntax of these parameter values? Perhaps they are inherited from the > referenced sections in the JMS 1.1 spec? If so, please say so. Ah, I > see that 4.1.3 does specify some syntax, albeit loosely; there are a > lot of different syntaxes which may be used to specify “ number > between 0 and 9, inclusive”. Are you OK with 0x3 or, for timeToLive, > “1,500”? 4.1.1 - says "PERSISTENT" or "NON_PERSISTENT". 4.1.2 & 4.13 - now indicate an expectation of decimal syntax. > 5. 4.2.1 Perhaps a note prior to launching into all the parameters on > syntax constraints, with, I’m assuming, normative references into the > JMS spec? In section 4.2.1.1, I added a reference to the Java Language Specification. Excellent catch. Thank you. > 6. 4.2.2 includes great gobs of Java code illustrating how to use such > an endpoint. Does this not contradict with the assertion at the top of > section 4 which says “ Operations available on JMS destinations are > fully and normatively defined by the JMS specification and as such, > are out of scope for this URI specification”? I changed the title of the section to read "Example of," clarified that this was an example specifically using Java, and that one "might start" with the approach that follows. > In any case, 4.2.2 needs a bit of preparatory language explaining what > it is. Is it normative behavior for implementations? Is it there for > illustrative purposes? Is it required to use Java, or could I code > something equivalent in C# or Ruby? A few paragraphs in there’s a > passing reference to “the following (non-normative) code...” I think I addressed that with the additions I noted just above. > 7. 4.3.1, see comments on 4.2.2 above. Is this description of > programming practice normative, illustrative, or what? I added the phrase "or its equivalent" to highlight that the Java methods were not the only way - especially since some vendors provide non-Java APIs. > 8. Section 6, 3rd para: I haven’t ever seen anything like the note > about what an OASIS TC might be doing in an RFC before, but possibly > I’ve just missed the examples. Since this section discusses the actual use cases, I can't really do much but note where those use cases stem from. > 9. Section 7, last para: “As described in Section 4, others can define > additional variants”... there is no description in Section 4 of how to > define additional variants. Also, while the language in the opening of > the draft suggests that the set of variants is open-ended, this is the > first explicit mention of this possibility that I encountered. Is > there a registry? > > Oh, there it is in section 9.2. OK, I think that the beginning of the > doc needs to say that the set of variants is open-ended and > vendor-extensible. It also smells like a big huge honking > interoperability hole. I added a sentence in the introduction: "Vendors defining additional variants are strongly encouraged to register them with IANA as documented in Section 9.2.1." As for the interoperability hole, I believe I addressed that above. > Nits: > > 1. Section 4 para 3, superfluous comma after “Both the variant”. Replaced much of this text based on other feedback. > 2. Section 4 para beginning “Each variant can have query > parameters...” - did you consider separating the variant prefix from > the rest of the parameter name with “.” or some other syntax marker? I > note that you use “jndi-” for another class of parameter names below. See my comment to item #2 of yours above. > 3. Section 4.1 I assume “shared” means “available in all variants”? If > so, why not say so? Added clarifying text. > 4. Section 4.1 first para, the word “property” suddenly appears for > the first time. Is this a synonym of “parameter”? Added clarifying text, which I think clears up the distinction between the parameters (in the URI), and the JMS Message properties. > 5. Section 4.1.1 Lots of references here need to be turned into RFC > style with square brackets We already reference the JMS specification, and tried to avoid repeating references when they were referenced by acronyms already defined (JMS). > 5. Same section, missing full stop after “following shared parameters”. Fixed with new text. > 6. 4.1.1 Probably more idiomatic of normative text to say, instead of > “This MUST be”, “The value of this parameter MUST be...” Fixed. > 7. 4.1.1 Missing full-stop at end. Fixed. > 8. 6, 2nd para: What’s an “SPI”? Added a parenthetical indicating the abbreviation. As I've said before, thank you very much for the wonderfully thorough review. -Eric. --------------050109060309050307060608 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Tim,

Alexey Melnikov asked that I recreate the full email response that I managed to delete/fail to send the first time around.

In any case, just as an overview, this is the URL that manages to capture the changes mostly specific to your feedback:
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-merrick-jms-uri-11.txt


On 12/16/10 4:01 PM, Tim Bray wrote: 
I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).
Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-merrick-jms-uri-10
Title: URI Scheme for Java(tm) Message Service 1.0
Reviewer: Tim Bray
Review Date: Dec 16, 2010
Summary: The draft has some mechanical issues which are not
show-stoppers. I have questions whether this ought to be an RFC since
there seems very modest expectation of interoperability between
implementations; why, then, an IETF RFC, which suggests that the
resulting URIs should be useful for identification of resources on an
internetworked scale.
Major Issues:

1. the draft suggests that given a “jms:” URI, there is little
expectation that, without checking on the value of the “variant” and
for the presence of vendor-specific parameters, it can be used
interoperably in more than one implementation. In which case, I have
to wonder about the appropriateness of using a *Uniform* resource
identifier for whatever purposes are contemplated for these things;
If nothing else, we're trying to bring uniformity to syntax and semantics for "jms" schemes that exist in the wild, and register *something*.
no
motivations or use-cases are provided.

Perhaps you missed the references in section 6? The draft itself cites two other standards efforts using the JMS URI - SOAP/JMS - where the "jms" URI scheme will be used in the same place an HTTP URI might appear, and the OASIS SCA Bindings TC, where the URI indicates the destination of an SCA reference using a JMS binding.

The last paragraph of section 1 is troubling. For convenience, I quote:
<<<<<
As a consequence of building upon an API, rather than a protocol, the
utility of a "jms" URI depends on the context in which it is used.
That context includes agreement on the same JMS provider or underlying
protocol, agreement on how to look up endpoints (JNDI), and when using
serialized Java object messages, sufficiently similar Java Class
environments that serialized objects can be appropriately read and
written. Users of this scheme need to establish the necessary shared
context parts as just enumerated - a context which can span the globe,
or merely a small local network. With that shared context, this URI
scheme enables endpoint identification in a uniform way, and the means
to connect to those endpoints.


            

          

        

      

      
Given this, what are the advantages of having a *Uniform* resource
identifier, if there is not much expectation of uniformity in
implementations?


    

    Some answers:

    
    
      
  • One can deploy a "bridge" between two JMS providers, thus
        providing interoperability between two JMS implementation, such
        that one client is unaware that the other client is not using
        the same JMS provider.
    • 
      
  • Via the JCP, JMS cements an API.  We're looking to establish
        interoperability at the level above that API, not at the level
        of the implementation of that API. That the implementations are
        not the same underneath that API ought not prevent standards
        efforts on top of the API that has been cemented by the JCP.
    • 
    

    We're stuck, in that our use-cases demand a URL (for example, in the
    place of HTTP scheme URIs in WSDL), but we're building upon an API
    rather than an actual protocol. In the end, we think it a better
    idea to register the scheme than not.

    

    

      
2. Section 3.3 says “ If users plan switching between JMS vendors,
they might also need to plan on regenerating resources that contain
URIs in this vendor specific form”; this sharpens my concerns about
the lack of interoperability...

I’m getting the impression, reading this, that “jms:jndi” is probably
quite interoperable, but the variants are maybe a back-door for vendor
abuse.


    

    

    Originally, we wrote the spec to only accommodate the JNDI
    approach.  We eventually exposed three broad reasons for the
    variants:

    
    
      
  • The JMS API itself.  The original 1.0 spec of JMS had two ways
        of establishing Destination objects, neither of which used JNDI
        (our "topic" and "queue" variants). The 1.1 version of the spec
        introduced the JNDI approach, and that's the obviously preferred
        method.
    • 
      
  • Broadest possible compatibility with existing uses of "JMS"
        URI schemes. In the early days of JMS, vendors defined their own
        ways to establish JMS Destinations, and we want to make sure
        that the proposed URI encompasses those possibilities, so that
        clients of the JMS scheme can look at the variant and know
        unambiguously that theh *don't* understand, rather than
        attempting to work with a "jms" URI, not working, and not
        knowing why.
    • 
      
  • Future proofing. Some JMS messaging products are based on
        documented protocols. Should they establish a better way of
        identifying JMS Destinations, and write up a new variant for
        doing so, this enables accessing said destinations, without
        revisiting the JMS URI scheme.
    
      
    • 
    

    None of the authors working on the scheme anticipate registering any
    new variants.

    

    Originally, we did not want an IANA registry to allow for additional
    variants, but previous feedback pushed us in that direction.

    

    

      
Minor Issues:

1. Section 1. Need references for terms like javax.jms.Destination for
people who aren’t familiar with Java pathname voodoo.


    

    

    I added [REF-JMS] here.

    

    

      
2. Section 4 para beginning “Each variant can have query
parameters...” - did you consider separating the variant prefix from
the rest of the parameter name with “.” or some other syntax marker? I
note that you use “jndi-” for another class of parameter names below.


    

    

    We considered a lot of options here. Realistically, I can probably
    come up with any sort of post-hoc rationalization. Using the "jndi"
    prefix for the "jndi" variant, without any such separator worked out
    naturally based on the initial proposals we started from, followed
    by introducing the variants.

    

    

      
3. Same paragraph. Should the variant be used as a prefix even if it’s
a vendor-supplied one starting with “vnd.”? An example of this would
be nice.


    

    Excellent point.  I added an example of "vnd.example.exParameter."

    

      
4. 4.1.1 and so on, should the draft impose any constraints on the
syntax of these parameter values? Perhaps they are inherited from the
referenced sections in the JMS 1.1 spec? If so, please say so. Ah, I
see that 4.1.3 does specify some syntax, albeit loosely; there are a
lot of different syntaxes which may be used to specify “ number
between 0 and 9, inclusive”. Are you OK with 0x3 or, for timeToLive,
“1,500”?


    

    

    4.1.1 - says "PERSISTENT" or "NON_PERSISTENT".

    

    4.1.2 & 4.13 - now indicate an expectation of decimal syntax.

    

    

      
5. 4.2.1 Perhaps a note prior to launching into all the parameters on
syntax constraints, with, I’m assuming, normative references into the
JMS spec?


    

    

    In section 4.2.1.1, I added a reference to the Java Language
    Specification.  Excellent catch.  Thank you.

    

    

      
6. 4.2.2 includes great gobs of Java code illustrating how to use such
an endpoint. Does this not contradict with the assertion at the top of
section 4 which says “ Operations available on JMS destinations are
fully and normatively defined by the JMS specification and as such,
are out of scope for this URI specification”?


    

    

    I changed the title of the section to read "Example of," clarified
    that this was an example specifically using Java, and that one
    "might start" with the approach that follows.

    

    

      
In any case, 4.2.2 needs a bit of preparatory language explaining what
it is. Is it normative behavior for implementations? Is it there for
illustrative purposes? Is it required to use Java, or could I code
something equivalent in C# or Ruby? A few paragraphs in there’s a
passing reference to “the following (non-normative) code...”


    

    

    I think I addressed that with the additions I noted just above.

    

    

      
7. 4.3.1, see comments on 4.2.2 above. Is this description of
programming practice normative, illustrative, or what?


    

    

    I added the phrase "or its equivalent" to highlight that the Java
    methods were not the only way - especially since some vendors
    provide non-Java APIs.

    

    

      
8. Section 6, 3rd para: I haven’t ever seen anything like the note
about what an OASIS TC might be doing in an RFC before, but possibly
I’ve just missed the examples.


    

    

    Since this section discusses the actual use cases, I can't really do
    much but note where those use cases stem from.

    

    

      
9. Section 7, last para: “As described in Section 4, others can define
additional variants”... there is no description in Section 4 of how to
define additional variants. Also, while the language in the opening of
the draft suggests that the set of variants is open-ended, this is the
first explicit mention of this possibility that I encountered. Is
there a registry?

Oh, there it is in section 9.2. OK, I think that the beginning of the
doc needs to say that the set of variants is open-ended and
vendor-extensible. It also smells like a big huge honking
interoperability hole.


    

    

    I added a sentence in the introduction: "Vendors defining additional
    variants are strongly encouraged to register them with IANA as
    documented in Section 9.2.1."

    

    As for the interoperability hole, I believe I addressed that above.

    

      
Nits:

1. Section 4 para 3, superfluous comma after “Both the variant”.


    

    

    Replaced much of this text based on other feedback.

    

      
2. Section 4 para beginning “Each variant can have query
parameters...” - did you consider separating the variant prefix from
the rest of the parameter name with “.” or some other syntax marker? I
note that you use “jndi-” for another class of parameter names below.


    

    

    See my comment to item #2 of yours above.

    

      
3. Section 4.1 I assume “shared” means “available in all variants”? If
so, why not say so?


    

    

    Added clarifying text.

    

    

      
4. Section 4.1 first para, the word “property” suddenly appears for
the first time. Is this a synonym of “parameter”?


    

    

    Added clarifying text, which I think clears up the distinction
    between the parameters (in the URI), and the JMS Message properties.

    

    

      
5. Section 4.1.1 Lots of references here need to be turned into RFC
style with square brackets


    

    We already reference the JMS specification, and tried to avoid
    repeating references when they were referenced by acronyms already
    defined (JMS).

    

      
5. Same section, missing full stop after “following shared parameters”.


    

    

    Fixed with new text.

    

    

      
6. 4.1.1 Probably more idiomatic of normative text to say, instead of
“This MUST be”, “The value of this parameter MUST be...”


    

    

    Fixed.

    

      
7. 4.1.1 Missing full-stop at end.


    

    

    Fixed.

    

    

      
8. 6, 2nd para: What’s an “SPI”?


    

    Added a parenthetical indicating the abbreviation.

    

    As I've said before, thank you very much for the wonderfully
    thorough review.

    

    

    -Eric.

  


--------------050109060309050307060608--

From tbray@textuality.com  Mon Jan 31 15:23:51 2011
Return-Path: 
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D523A6B26 for ; Mon, 31 Jan 2011 15:23:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.942
X-Spam-Level: 
X-Spam-Status: No, score=-2.942 tagged_above=-999 required=5 tests=[AWL=0.035,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 T7c-xC4DXX6b for ; Mon, 31 Jan 2011 15:23:50 -0800 (PST)
Received: from mail-fx0-f49.google.com (mail-fx0-f49.google.com [209.85.161.49]) by core3.amsl.com (Postfix) with ESMTP id CA9F03A6BFF for ; Mon, 31 Jan 2011 15:23:49 -0800 (PST)
Received: by fxm19 with SMTP id 19so7580479fxm.22 for ; Mon, 31 Jan 2011 15:27:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.72.6 with SMTP id k6mr6649488faj.46.1296516423891; Mon, 31 Jan 2011 15:27:03 -0800 (PST)
Received: by 10.223.126.212 with HTTP; Mon, 31 Jan 2011 15:27:03 -0800 (PST)
X-Originating-IP: [216.239.45.130]
In-Reply-To: <4D473FB4.2070009@tibco.com>
References:  <4D473FB4.2070009@tibco.com>
Date: Mon, 31 Jan 2011 15:27:03 -0800
Message-ID: 
From: Tim Bray 
To: Eric Johnson 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: derek.rokicki@softwareag.com, SM , Apps Discuss , The IESG , m8philli@uk.ibm.com, peaston@progress.com
Subject: Re: [apps-discuss] apps-team review of draft-merrick-jms-uri-10
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Jan 2011 23:23:52 -0000

Just to be clear, I'm not terribly upset; it does appear that my input
was useful, and if the IESG wants to register a URI scheme that I
personally think is a little wonky, they're totally within their
rights and in fact I'm open to the arguments about collision avoidance
and so on.   I was just baffled as a consequence of having missed the
subsequent discussion.

Thanks for taking the time to pull that together!  -Tim



On Mon, Jan 31, 2011 at 3:03 PM, Eric Johnson  wrote:
> Hi Tim,
>
> Alexey Melnikov asked that I recreate the full email response that I mana=
ged
> to delete/fail to send the first time around.
>
> In any case, just as an overview, this is the URL that manages to capture
> the changes mostly specific to your feedback:
> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-merrick-jm=
s-uri-11.txt
>
>
> On 12/16/10 4:01 PM, Tim Bray wrote:
>
> I have been selected as the Applications Area Review Team reviewer for
> this draft (for background on apps-review, please see
> http://www.apps.ietf.org/content/applications-area-review-team).
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
> Document: draft-merrick-jms-uri-10
> Title: URI Scheme for Java(tm) Message Service 1.0
> Reviewer: Tim Bray
> Review Date: Dec 16, 2010
> Summary: The draft has some mechanical issues which are not
> show-stoppers. I have questions whether this ought to be an RFC since
> there seems very modest expectation of interoperability between
> implementations; why, then, an IETF RFC, which suggests that the
> resulting URIs should be useful for identification of resources on an
> internetworked scale.
> Major Issues:
>
> 1. the draft suggests that given a =93jms:=94 URI, there is little
> expectation that, without checking on the value of the =93variant=94 and
> for the presence of vendor-specific parameters, it can be used
> interoperably in more than one implementation. In which case, I have
> to wonder about the appropriateness of using a *Uniform* resource
> identifier for whatever purposes are contemplated for these things;
>
> If nothing else, we're trying to bring uniformity to syntax and semantics
> for "jms" schemes that exist in the wild, and register *something*.
>
> no
> motivations or use-cases are provided.
>
> Perhaps you missed the references in section 6? The draft itself cites tw=
o
> other standards efforts using the JMS URI - SOAP/JMS - where the "jms" UR=
I
> scheme will be used in the same place an HTTP URI might appear, and the
> OASIS SCA Bindings TC, where the URI indicates the destination of an SCA
> reference using a JMS binding.
>
> The last paragraph of section 1 is troubling. For convenience, I quote:
> <<<<<
> As a consequence of building upon an API, rather than a protocol, the
> utility of a "jms" URI depends on the context in which it is used.
> That context includes agreement on the same JMS provider or underlying
> protocol, agreement on how to look up endpoints (JNDI), and when using
> serialized Java object messages, sufficiently similar Java Class
> environments that serialized objects can be appropriately read and
> written. Users of this scheme need to establish the necessary shared
> context parts as just enumerated - a context which can span the globe,
> or merely a small local network. With that shared context, this URI
> scheme enables endpoint identification in a uniform way, and the means
> to connect to those endpoints.
>
> Given this, what are the advantages of having a *Uniform* resource
> identifier, if there is not much expectation of uniformity in
> implementations?
>
> Some answers:
>
> One can deploy a "bridge" between two JMS providers, thus providing
> interoperability between two JMS implementation, such that one client is
> unaware that the other client is not using the same JMS provider.
> Via the JCP, JMS cements an API.=A0 We're looking to establish
> interoperability at the level above that API, not at the level of the
> implementation of that API. That the implementations are not the same
> underneath that API ought not prevent standards efforts on top of the API
> that has been cemented by the JCP.
>
> We're stuck, in that our use-cases demand a URL (for example, in the plac=
e
> of HTTP scheme URIs in WSDL), but we're building upon an API rather than =
an
> actual protocol. In the end, we think it a better idea to register the
> scheme than not.
>
> 2. Section 3.3 says =93 If users plan switching between JMS vendors,
> they might also need to plan on regenerating resources that contain
> URIs in this vendor specific form=94; this sharpens my concerns about
> the lack of interoperability...
>
> I=92m getting the impression, reading this, that =93jms:jndi=94 is probab=
ly
> quite interoperable, but the variants are maybe a back-door for vendor
> abuse.
>
> Originally, we wrote the spec to only accommodate the JNDI approach.=A0 W=
e
> eventually exposed three broad reasons for the variants:
>
> The JMS API itself.=A0 The original 1.0 spec of JMS had two ways of
> establishing Destination objects, neither of which used JNDI (our "topic"
> and "queue" variants). The 1.1 version of the spec introduced the JNDI
> approach, and that's the obviously preferred method.
> Broadest possible compatibility with existing uses of "JMS" URI schemes. =
In
> the early days of JMS, vendors defined their own ways to establish JMS
> Destinations, and we want to make sure that the proposed URI encompasses
> those possibilities, so that clients of the JMS scheme can look at the
> variant and know unambiguously that theh *don't* understand, rather than
> attempting to work with a "jms" URI, not working, and not knowing why.
> Future proofing. Some JMS messaging products are based on documented
> protocols. Should they establish a better way of identifying JMS
> Destinations, and write up a new variant for doing so, this enables
> accessing said destinations, without revisiting the JMS URI scheme.
>
> None of the authors working on the scheme anticipate registering any new
> variants.
>
> Originally, we did not want an IANA registry to allow for additional
> variants, but previous feedback pushed us in that direction.
>
> Minor Issues:
>
> 1. Section 1. Need references for terms like javax.jms.Destination for
> people who aren=92t familiar with Java pathname voodoo.
>
> I added [REF-JMS] here.
>
> 2. Section 4 para beginning =93Each variant can have query
> parameters...=94 - did you consider separating the variant prefix from
> the rest of the parameter name with =93.=94 or some other syntax marker? =
I
> note that you use =93jndi-=94 for another class of parameter names below.
>
> We considered a lot of options here. Realistically, I can probably come u=
p
> with any sort of post-hoc rationalization. Using the "jndi" prefix for th=
e
> "jndi" variant, without any such separator worked out naturally based on =
the
> initial proposals we started from, followed by introducing the variants.
>
> 3. Same paragraph. Should the variant be used as a prefix even if it=92s
> a vendor-supplied one starting with =93vnd.=94? An example of this would
> be nice.
>
> Excellent point.=A0 I added an example of "vnd.example.exParameter."
>
> 4. 4.1.1 and so on, should the draft impose any constraints on the
> syntax of these parameter values? Perhaps they are inherited from the
> referenced sections in the JMS 1.1 spec? If so, please say so. Ah, I
> see that 4.1.3 does specify some syntax, albeit loosely; there are a
> lot of different syntaxes which may be used to specify =93 number
> between 0 and 9, inclusive=94. Are you OK with 0x3 or, for timeToLive,
> =931,500=94?
>
> 4.1.1 - says "PERSISTENT" or "NON_PERSISTENT".
>
> 4.1.2 & 4.13 - now indicate an expectation of decimal syntax.
>
> 5. 4.2.1 Perhaps a note prior to launching into all the parameters on
> syntax constraints, with, I=92m assuming, normative references into the
> JMS spec?
>
> In section 4.2.1.1, I added a reference to the Java Language Specificatio=
n.
> Excellent catch.=A0 Thank you.
>
> 6. 4.2.2 includes great gobs of Java code illustrating how to use such
> an endpoint. Does this not contradict with the assertion at the top of
> section 4 which says =93 Operations available on JMS destinations are
> fully and normatively defined by the JMS specification and as such,
> are out of scope for this URI specification=94?
>
> I changed the title of the section to read "Example of," clarified that t=
his
> was an example specifically using Java, and that one "might start" with t=
he
> approach that follows.
>
> In any case, 4.2.2 needs a bit of preparatory language explaining what
> it is. Is it normative behavior for implementations? Is it there for
> illustrative purposes? Is it required to use Java, or could I code
> something equivalent in C# or Ruby? A few paragraphs in there=92s a
> passing reference to =93the following (non-normative) code...=94
>
> I think I addressed that with the additions I noted just above.
>
> 7. 4.3.1, see comments on 4.2.2 above. Is this description of
> programming practice normative, illustrative, or what?
>
> I added the phrase "or its equivalent" to highlight that the Java methods
> were not the only way - especially since some vendors provide non-Java AP=
Is.
>
> 8. Section 6, 3rd para: I haven=92t ever seen anything like the note
> about what an OASIS TC might be doing in an RFC before, but possibly
> I=92ve just missed the examples.
>
> Since this section discusses the actual use cases, I can't really do much
> but note where those use cases stem from.
>
> 9. Section 7, last para: =93As described in Section 4, others can define
> additional variants=94... there is no description in Section 4 of how to
> define additional variants. Also, while the language in the opening of
> the draft suggests that the set of variants is open-ended, this is the
> first explicit mention of this possibility that I encountered. Is
> there a registry?
>
> Oh, there it is in section 9.2. OK, I think that the beginning of the
> doc needs to say that the set of variants is open-ended and
> vendor-extensible. It also smells like a big huge honking
> interoperability hole.
>
> I added a sentence in the introduction: "Vendors defining additional
> variants are strongly encouraged to register them with IANA as documented=
 in
> Section 9.2.1."
>
> As for the interoperability hole, I believe I addressed that above.
>
> Nits:
>
> 1. Section 4 para 3, superfluous comma after =93Both the variant=94.
>
> Replaced much of this text based on other feedback.
>
> 2. Section 4 para beginning =93Each variant can have query
> parameters...=94 - did you consider separating the variant prefix from
> the rest of the parameter name with =93.=94 or some other syntax marker? =
I
> note that you use =93jndi-=94 for another class of parameter names below.
>
> See my comment to item #2 of yours above.
>
> 3. Section 4.1 I assume =93shared=94 means =93available in all variants=
=94? If
> so, why not say so?
>
> Added clarifying text.
>
> 4. Section 4.1 first para, the word =93property=94 suddenly appears for
> the first time. Is this a synonym of =93parameter=94?
>
> Added clarifying text, which I think clears up the distinction between th=
e
> parameters (in the URI), and the JMS Message properties.
>
> 5. Section 4.1.1 Lots of references here need to be turned into RFC
> style with square brackets
>
> We already reference the JMS specification, and tried to avoid repeating
> references when they were referenced by acronyms already defined (JMS).
>
> 5. Same section, missing full stop after =93following shared parameters=
=94.
>
> Fixed with new text.
>
> 6. 4.1.1 Probably more idiomatic of normative text to say, instead of
> =93This MUST be=94, =93The value of this parameter MUST be...=94
>
> Fixed.
>
> 7. 4.1.1 Missing full-stop at end.
>
> Fixed.
>
> 8. 6, 2nd para: What=92s an =93SPI=94?
>
> Added a parenthetical indicating the abbreviation.
>
> As I've said before, thank you very much for the wonderfully thorough
> review.
>
>
> -Eric.
>

From duerst@it.aoyama.ac.jp  Mon Jan 31 17:29:39 2011
Return-Path: 
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C55F3A6CAD for ; Mon, 31 Jan 2011 17:29:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.234
X-Spam-Level: 
X-Spam-Status: No, score=-100.234 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20M6ifX0XUZa for ; Mon, 31 Jan 2011 17:29:38 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id 878C53A68EA for ; Mon, 31 Jan 2011 17:29:37 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p111WmgQ014596 for ; Tue, 1 Feb 2011 10:32:48 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 35ca_1dc1_2d18562a_2da3_11e0_91e3_001d096c566a; Tue, 01 Feb 2011 10:32:48 +0900
Received: from [IPv6:::1] ([133.2.210.1]:34396) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id  for  from ; Tue, 1 Feb 2011 10:32:46 +0900
Message-ID: <4D4762A1.3070708@it.aoyama.ac.jp>
Date: Tue, 01 Feb 2011 10:32:17 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Claudio Allocchio 
References: <4D471B36.4050503@isode.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Apps-Discuss@ietf.org
Subject: Re: [apps-discuss] [Fwd: NomCom 2010-2011: IESG Appointments]
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Feb 2011 01:29:39 -0000

On 2011/02/01 6:44, Claudio Allocchio wrote:
>
> thanks for all your important effort, Alexey, ...
>
> and of course "welcome Mr new Director", :-) Thanks Pete for your time
> in doing this!

Same here, very much so, for both Alex and Pete!

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp