From lisa.dusseault@gmail.com Mon Feb 1 15:17:03 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 046333A69C3 for ; Mon, 1 Feb 2010 15:17:03 -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.001, 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 iFnWscmfGjWf for ; Mon, 1 Feb 2010 15:17:02 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B7C4E3A69B6 for ; Mon, 1 Feb 2010 15:17:01 -0800 (PST) Received: by vws1 with SMTP id 1so1515403vws.31 for ; Mon, 01 Feb 2010 15:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=FArn566DGTEq1fSG1VHTvJ5Fr09T84t9kgp81yqEqzU=; b=HS4IP1Y6bADbXuSiFa6SBTftNcM7FGtAN/r9/BacuTLshxlRkw1mtNK9poxZ2tn8CK LnPHZNJnKbhwsB6EPaDzuVZkA3/bzR5J/kHuBdqPWCh1kw+KG3tP/+QF4I2o+ToSEiDZ fPp/2mUJ4pimuElgfryvX6lHX4fz3y7DJ9txI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=kK8NkwXQmJVcFaFaGkjgQ0zbx1b8puo877gxjQVJEh0hXacBIbrqeLI9y/4ws/jeJ7 Bd5LBkTxpTCIm8s3/Jf7ej0vHqXGLvTen/mjaeT5Xl/JKLErqTFE2l4jYorCVA2B58BD OqR07C4Hy5JGexY4B7X9dBH9TVa2iM2GuSbv0= MIME-Version: 1.0 Received: by 10.220.128.1 with SMTP id i1mr6612670vcs.83.1265066254695; Mon, 01 Feb 2010 15:17:34 -0800 (PST) Date: Mon, 1 Feb 2010 15:17:34 -0800 Message-ID: Subject: Lisa's Apps Area Activity Report for Dec 2009 & Jan 2010 From: Lisa Dusseault To: "Lisa Dusseault's Chairs" , Apps Discuss Content-Type: multipart/alternative; boundary=001636e1e82eba7ce8047e9230a0 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, 01 Feb 2010 23:17:03 -0000 --001636e1e82eba7ce8047e9230a0 Content-Type: text/plain; charset=ISO-8859-1 *News, Updates* HTTPSTATE, HYBI, MARF and IRI WGs have been approved & created 6LOWAPP still in chartering process *Document Status and Progress* *Active documents, my action:* - draft-bryan-metalink (PS): In IESG Evaluation -- a couple DISCUSS issues have been resolved and ADs need to close them - draft-ietf-idnabis-bidi (PS): One DISCUSS remaining which appears to be resolved in the document - draft-hammer-oauth (Info): IESG Evaluation, one DISCUSS to clear - draft-ietf-idnabis-mappings (Info): Working with chair on how to determine WG consensus for status of this doc Active documents, waiting on other: *- draft-giralt-schac-ns (Info): Revised ID needed* - draft-larmouth-oid-uri (PS): Revised ID Needed (response to expert review & my own questions) - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and writeup - draft-nottingham-http-link-header (PS): Waiting for revision from authors *Finished processing -- new in RFC Ed queue and new RFCs* - draft-ietf-idnabis-protocol (PS): approved - draft-ietf-idnabis-defs (PS): approved - draft-ietf-idnabis-tables (PS): approved - draft-ietf-idnabis-rationale (Info): approved - draft-bryan-http-digest-algorithm-values-update (Info): approved - draft-morg-status-in-list (PS): approved - draft-melnikov-imap-keywords (PS): Approved - draft-nottingham-site-meta (PS): approved - draft-freed-sieve-in-xml (PS): approved *Other* - draft-montemurro-gsma-imei-urn (Exp): New version of draft not received before draft expiration --> change state to "dead" *WG Status* ALTO: little activity CALSIFY: WGLC for draft-ietf-calsify-rfc2447bis-07 completed and new draft -08 issued in January. HTTPBIS: Resolving direct WG issues one by one; discussing various non-WG issues like cross-site scripting also. HTTPSTATE: Starting work and discussing how to word stuff in the drafts HYBI: Just approved; debate on process for coordinating with WHATWG begun as well as lots of tech discussion. IDNABIS: Most of the WG documents were put into IESG Evaluation and approved. draft-idnabis-mappings remains. OAUTH: Discussion of WRAP requirements & authentication requirements SIEVE: renewed activity over adopting a couple more docs --001636e1e82eba7ce8047e9230a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable News, Updates
HTTPSTATE, HYBI, MARF and IRI WGs have been approve= d & created
6LOWAPP still in chartering process

Document = Status and Progress

Active documents, my action:
- dra= ft-bryan-metalink (PS): In IESG Evaluation -- a couple DISCUSS issues have = been resolved and ADs need to close them
- draft-ietf-idnabis-bidi (PS): One DISCUSS remaining which appears to be r= esolved in the document
- draft-hammer-oauth (Info): IESG Evaluation, on= e DISCUSS to clear
- draft-ietf-idnabis-mappings (Info): Working with ch= air on how to determine WG consensus for status of this doc

Active documents, waiting on other:
- draft-giralt-schac-ns (Inf= o): Revised ID needed
- draft-larmouth-oid-uri (PS): Revised ID Need= ed (response to expert review & my own questions)
- draft-reschke-we= bdav-post (Exp): Cyrus Daboo is doing shepherd review and writeup
- draft-nottingham-http-link-header (PS): Waiting for revision from authors=

Finished processing -- new in RFC Ed queue and new RFCs
-= draft-ietf-idnabis-protocol (PS): approved
- draft-ietf-idnabis-defs (P= S): approved
- draft-ietf-idnabis-tables (PS): approved
- draft-ietf-idnabis-rational= e (Info): approved
- draft-bryan-http-digest-algorithm-values-update (In= fo): approved
- draft-morg-status-in-list (PS): approved
- draft-meln= ikov-imap-keywords (PS): Approved
- draft-nottingham-site-meta (PS): approved
- draft-freed-sieve-in-xml (= PS): approved

Other
- draft-montemurro-gsma-imei-urn (Exp= ): New version of draft not received before draft expiration --> change = state to "dead"

WG Status

ALTO: little activity
CALSIFY: WGLC for draf= t-ietf-calsify-rfc2447bis-07 completed and new draft -08 issued in January.=
HTTPBIS: Resolving direct WG issues one by one; discussing various non-= WG issues like cross-site scripting also.
HTTPSTATE: Starting work and discussing how to word stuff in the drafts
= HYBI: Just approved; debate on process for coordinating with WHATWG begun a= s well as lots of tech discussion.
IDNABIS: Most of the WG documents wer= e put into IESG Evaluation and approved. =A0draft-idnabis-mappings remains.=
OAUTH: Discussion of WRAP requirements & authentication requirements SIEVE: renewed activity over adopting a couple more docs
--001636e1e82eba7ce8047e9230a0-- From stpeter@stpeter.im Wed Feb 3 12:22:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C26D3A6978; Wed, 3 Feb 2010 12:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 VVePV6-5y5Ug; Wed, 3 Feb 2010 12:22:14 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3D4A33A6A3C; Wed, 3 Feb 2010 12:22:11 -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 A833740332; Wed, 3 Feb 2010 13:22:53 -0700 (MST) Message-ID: <4B69DB1C.3090200@stpeter.im> Date: Wed, 03 Feb 2010 13:22:52 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: newprep@ietf.org Subject: proposed charter for "NewPrep" WG X-Enigmail-Version: 1.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040904080906020108060704" Cc: "apps-discuss@ietf.org" , XMPP , sasl mailing list , IETF discussion list 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, 03 Feb 2010 20:22:15 -0000 This is a cryptographically signed message in MIME format. --------------ms040904080906020108060704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The following is a proposed charter for a "NewPrep" WG to work on replacements for stringprep profiles in application and security protocols such as XMPP and SASL. We plan to hold a BoF at IETF 77 to explore whether it makes sense to form a working group on this topic. If you are interested, please join the newprep@ietf.org list: https://www.ietf.org/mailman/listinfo/newprep My apologies for cross-posting; please send replies to newprep@ietf.org. Thanks! Peter ###### Proposed Charter for NewPrep WG Last Updated: 2010-01-14 Problem Statement The handling of non-ASCII strings in Internet protocols is a difficult problem that has still not been solved in a generalized way. In 2002, the IETF defined a method for preparation and comparison of internationalized strings that could be re-used by various applications. This method, stringprep (RFC 3454), has been re-used in several Internet protocols that have defined "profiles" of stringprep, namely: - The Nameprep profile (RFC 3490) for use in Internationalized Domain Names (IDNs) - The iSCSI profile (RFC 3722) for use in Internet Small Computer Systems Interface (iSCSI) Names - The Nodeprep and Resourceprep profiles (RFC 3920) for use in the Extensible Messaging and Presence Protocol (XMPP) - The Policy MIB profile (RFC 4011) for use in the Simple Network Management Protocol (SNMP) - The SASLprep profile (RFC 4013) for use in the Simple Authentication and Security Layer (SASL) - The trace profile (RFC 4505) for use with the SASL ANONYMOUS mechanism In completing revisions to the IDN technology, the IETF's IDNAbis WG decided to move away from the use of stringprep in domain names, instead defining sets of allowed and disallowed characters based on Unicode character properties (often called an "inclusion approach") rather than defining explicit mappings of Unicode characters as in stringprep (an "exclusion approach"). Although the IDNAbis WG had its reasons for moving away from stringprep, and some of those reasons might not apply to other applications (e.g., usernames in XMPP or usernames and passwords in SASL), other reasons might apply more generally. In particular, stringprep depends on a particular version of Unicode (3.2) and cannot be upgraded to a new Unicode version without revising the core stringprep technology. However, any move away from stringprep by existing profiles would introduce backward compatibility issues and migration challenges, which need to be weighed against the benefits of a new string preparation technology. Objectives The goal of this group is to assess whether an "inclusion approach" similar to that taken in the revisions to Internationalized Doman Names (IDNs) is appropriate for other stringprep profiles. Such an approach would involve: - A tiered model of permitted characters, especially the three categories of valid, disallowed, and unassigned characters - Protocol-specific lists of valid characters - Potentially a reduction in the number of characters that are permitted in usernames, passwords, and other identifiers - Application of the foregoing concepts to existing profiles in ways that respect the significant differences between those profiles The group will analyze existing stringprep profiles to assess if it is appropriate for them to move to an inclusion approach. If so, based on consensus the group will do one of the following with regard to each existing profile: 1. Directly complete a replacement for the profile, if it does not fall within the scope of another active working group. 2. Collaborate with another active working group on developing a replacement for its profile or profiles. 3. Advise the authors of profiles that were produced outside the context of any working group regarding how to proceed. Deliverables 1. Analysis of existing stringprep profiles. 2. Revisions to one or more existing stringprep profiles. Milestones To follow. ###### --------------ms040904080906020108060704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDIwMzIwMjI1MlowIwYJKoZIhvcNAQkEMRYEFPYcBegh0x5iEyZhddPu hkowbnt8MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAmMhkkJmDXXlMIsJOfkkyC3bFhJ2i/ddleybCTLcw DNFPxoDb3maSPjSetJ/ZTvC7BLfKuqDFm2DpH4C7sUoq+Tr3mHhVVcovGIN6OFdI8F0OxZC2 F+HbkfK4+8SyHOeqe1bn+i/qnNGTIMiFBiUqqvTrDXGcWR9ekI/y2K6AyS6Pzd57vxATaPL7 VT+ESDK4EL+jYO2PwEClJsz1evxgClLRzLmINoysUrD4KgDcwUwPsfah0G3sNzrRka5Ccv6C mG67346mU0vCuqnMsBMr/RyRWdxk5043MLxkCsQJ2Kw27hqAKQJy1ZU/4W0qyfQDRiQuma8Q KhxV1IwJxqjUmgAAAAAAAA== --------------ms040904080906020108060704-- From masinter@adobe.com Wed Feb 3 16:44:31 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ABB53A67E9 for ; Wed, 3 Feb 2010 16:44:31 -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 UkgQh6-+ZtjB for ; Wed, 3 Feb 2010 16:44:29 -0800 (PST) Received: from psmtp.com (exprod6ob109.obsmtp.com [64.18.1.22]) by core3.amsl.com (Postfix) with ESMTP id 58A243A6765 for ; Wed, 3 Feb 2010 16:44:29 -0800 (PST) Received: from source ([192.150.11.134]) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKS2oYmKyIj9rigQE2BLEyFyY6MxXOMan+@postini.com; Wed, 03 Feb 2010 16:45:13 PST Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id o140bF18008603; Wed, 3 Feb 2010 16:37:20 -0800 (PST) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id o140j27p016848; Wed, 3 Feb 2010 16:45:04 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Wed, 3 Feb 2010 16:45:03 -0800 From: Larry Masinter To: Eran Hammer-Lahav , Apps Discuss Date: Wed, 3 Feb 2010 16:44:58 -0800 Subject: RE: I-D Action:draft-nottingham-site-meta-05.txt Thread-Topic: I-D Action:draft-nottingham-site-meta-05.txt Thread-Index: AcqKOhRPicuasJ7QQlWwxKHcX49x4QAEpIXgAARqcMAGtOkgMA== Message-ID: References: <20091229224501.E41803A6848@core3.amsl.com> <90C41DD21FB7C64BB94121FBBC2E72343787E67EDF@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343787E67EDF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 00:44:31 -0000 My comment, Eran, was editorial. I've had this in my mailbox and not replied because I keep on stumbling over: > "Metadata is a word or phrase, not a technical term." This is a technical document. It defines a mechanism, and says it is good for "metadata". It doesn't define the term "metadata", although that's the use case.... =20 "a method for locating host metadata". > In the context of this draft, it generally means "information about". The document doesn't say that. That wouldn't be so bad if the use of the term corresponded to the common use of the term "metadata", but it doesn't match. > I don't see the need for the document to say anything > more than it currently does. Effective human communication means that a document that uses terms should=20 * attempt to use terms with their conventional meaning * in the case of possible confusion (conventional meaning is ambiguous, or the document's usage doesn't match the conventional meaning), the document should define the term. > It would be a waste of everyone's time if the > process of reviewing and approving=20 > registrations will involve a discussion=20 > of the metadata-ness of the proposed document. What a bizarre idea. How about something simple, like changing the Abstract to say: This memo describes a method for locating host metadata for Web-based protocols. In this document, the word "metadata" is used in the general sense of "information about". [1] http://tools.ietf.org/html/draft-hammer-hostmeta > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Larry Masinter > Sent: Thursday, December 31, 2009 11:18 AM > To: Lisa Dusseault; Apps Discuss > Subject: RE: I-D Action:draft-nottingham-site-meta-05.txt >=20 > There's a lot of confusion about the use of the term "metadata". In this = case, > the term is being used for something that might more appropriately be see= n > as "default metadata for resources at a site" rather than "site metadata"= . I > know it's not really the job of this document to clear up all of the conf= usion > around metadata, but I think it would be better if this document were to > include at least a sentence or two explaining how its use of "metadata" > is not a close match, for example, to the the primary definition in: > http://en.wikipedia.org/wiki/Metadata >=20 > or even > http://www.w3.org/DesignIssues/Metadata.html > or > http://www.w3.org/2001/tag/group/track/issues/63 >=20 > Larry > -- > http://larry.masinter.net >=20 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Lisa Dusseault > Sent: Thursday, December 31, 2009 8:55 AM > To: Apps Discuss > Subject: Fwd: I-D Action:draft-nottingham-site-meta-05.txt >=20 > FYI, >=20 > This document is currently in IESG Evaluation with a few DISCUSS issues t= o be > cleared. One of the ADs asked whether this draft had been widely reviewe= d > and I wasn't sure it had been posted here though it has definitely been > discussed on HTTPBIS and in W3C lists. This draft proposes a namespace f= or a > mechanism that can be useful for HTTP-based applications, e.g. if it were > available and accepted 5-10 years ago, it would have been an alternative = for > some of the bootstrapping problems of WebDAV and CalDAV. >=20 > See also http://tools.ietf.org/html/draft-hammer-hostmeta-05 for an > example of use of this namespace. >=20 > Lisa >=20 > ---------- Forwarded message ---------- > From: > Date: Tue, Dec 29, 2009 at 2:45 PM > Subject: I-D Action:draft-nottingham-site-meta-05.txt > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Defining Well-Known URIs > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Nottingham, E. Hammer-Lahav > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-nottingham-site-meta-05.tx= t > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 8 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-12-29 >=20 > This memo defines a path prefix for "well-known locations", "/.well- > known/" in selected URI schemes. >=20 > Status of this Memo >=20 > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering Task > Force (IETF), its areas, and its working groups. =A0Note that other group= s may > also distribute working documents as Internet- Drafts. >=20 > Internet-Drafts are draft documents valid for a maximum of six months and > may be updated, replaced, or obsoleted by other documents at any time. = =A0It > is inappropriate to use Internet-Drafts as reference material or to cite = them > other than as "work in progress." >=20 > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. >=20 > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. >=20 > This Internet-Draft will expire on July 3, 2010. >=20 > Copyright Notice >=20 > Copyright (c) 2009 IETF Trust and the persons identified as the document > authors. =A0All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal Provisions > Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of publicati= on of > this document. =A0Please review these documents carefully, as they descri= be > your rights and restrictions with respect to this document. =A0Code > Components extracted from this document must include Simplified BSD > License text as described in Section 4.e of the Trust Legal Provisions an= d are > provided without warranty as described in the BSD License. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Interne= t- > Draft. >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > 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 _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From mnot@mnot.net Wed Feb 3 21:31:19 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DEEB3A67A5 for ; Wed, 3 Feb 2010 21:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[AWL=-1.288, 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 o6IZLnCA+r9F for ; Wed, 3 Feb 2010 21:31:18 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 1B20C3A62C1 for ; Wed, 3 Feb 2010 21:31:17 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.26.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BF7C422E1F3; Thu, 4 Feb 2010 00:31:55 -0500 (EST) Subject: Re: editorial LC comments on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B585EFF.2080104@gmx.de> Date: Thu, 4 Feb 2010 16:31:50 +1100 Content-Transfer-Encoding: 7bit Message-Id: <7885A4CC-0040-45FD-9749-2204DA072845@mnot.net> References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B585EFF.2080104@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 05:31:19 -0000 On 22/01/2010, at 1:04 AM, Julian Reschke wrote: > Section 9.1., paragraph 9: > OLD: > > [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying > Languages", RFC 4646, September 2006. > > NEW: > > [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", BCP 26, RFC 5226, > May 2008. Did you mean to replace 4646 with 5646 here? Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Feb 3 22:17:25 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E6D3A6CB1 for ; Wed, 3 Feb 2010 22:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.976 X-Spam-Level: X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[AWL=-1.377, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ea+bm-aYJVx5 for ; Wed, 3 Feb 2010 22:17:24 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 324003A69B4 for ; Wed, 3 Feb 2010 22:17:23 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.26.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BF61722E1F3; Thu, 4 Feb 2010 01:18:01 -0500 (EST) Subject: Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B596B30.1030400@gmx.de> Date: Thu, 4 Feb 2010 17:17:58 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <3FB0E494-EE9C-46F8-A924-2768C730763A@mnot.net> References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B58574B.4050204@gmx.de> <4B596B30.1030400@gmx.de> To: "Julian F. Reschke" , Roy Fielding X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 06:17:25 -0000 I think perhaps you need to talk to Roy about that... At the moment, my intent is to remove 'rev' from the BNF and state how = new parameters can be added (either by updating the document, for = parameters common to many relation types, or on a per-type / = per-application basis).=20 On 22/01/2010, at 8:09 PM, Julian Reschke wrote: >>> Later on, in the section about HTML4 we find = (): >>>=20 >>> HTML4 also has a "rev" parameter for links that allows a link's >>> relation to be reversed. The Link header does not define a >>> corresponding "rev" parameter to allow the expression of these = links >>> in HTTP headers, due to the confusion this mechanism causes as well >>> as conflicting interpretations (briefly, some hold that rev = reverses >>> the direction of the link, while others that it reverses the >>> semantics of the relation itself). >>>=20 >>> I have to admit that I'm still not sure what *in practice* the = difference between reversing the link direction and reversing the link = semantics actually is. (Example?) >> I can add a brief example for the latter. >=20 > Please. >=20 >>> So my preference would be to actually define the rev parameter = consistently with this, and then to discourage it's use due to the other = good reasons we heard about that (such as HTML authors typing "rev" = instead of "rel"). >> As previous discussed (quite a bit), HTML2 defines REV as having = reversed *semantics*, while HTML4 talks about it creating a "reverse = link" -- which are very different things. This feels like a rat hole to = me (thus my attempts to navigate around it). >=20 > Again, HTML 2 defines it as: >=20 > REV > same as the REL attribute, but the semantics of the > relationship are in the reverse direction. A link from A > to B with REL=3D"X" expresses the same relationship as a > link from B to A with REV=3D"X". An anchor may have both > REL and REV attributes. >=20 > () >=20 > That totally sounds like "reverse link" to me. So, I really really = think there's less confusion than some people claim. -- Mark Nottingham http://www.mnot.net/ From annevk@opera.com Thu Feb 4 01:36:06 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484C13A69BB for ; Thu, 4 Feb 2010 01:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.885 X-Spam-Level: X-Spam-Status: No, score=-6.885 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 tDbqrdB-cq2e for ; Thu, 4 Feb 2010 01:36:05 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 14DB23A68C4 for ; Thu, 4 Feb 2010 01:36:04 -0800 (PST) Received: from annevk-t60 (5355737B.cable.casema.nl [83.85.115.123]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id o149X3Eo008267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Feb 2010 09:33:05 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Mark Nottingham" , "Julian F. Reschke" , "Roy Fielding" Subject: Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B58574B.4050204@gmx.de> <4B596B30.1030400@gmx.de> <3FB0E494-EE9C-46F8-A924-2768C730763A@mnot.net> Date: Thu, 04 Feb 2010 10:36:47 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Anne van Kesteren" Organization: Opera Software ASA Message-ID: In-Reply-To: <3FB0E494-EE9C-46F8-A924-2768C730763A@mnot.net> User-Agent: Opera Mail/10.10 (Linux) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 09:36:06 -0000 On Thu, 04 Feb 2010 07:17:58 +0100, Mark Nottingham wrote: > At the moment, my intent is to remove 'rev' from the BNF and state how > new parameters can be added (either by updating the document, for > parameters common to many relation types, or on a per-type / > per-application basis). +1 -- Anne van Kesteren http://annevankesteren.nl/ From duerst@it.aoyama.ac.jp Thu Feb 4 02:56:00 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3993A6D63 for ; Thu, 4 Feb 2010 02:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=-2.232, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bPRS2joeca7 for ; Thu, 4 Feb 2010 02:55:59 -0800 (PST) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id 24B083A6D56 for ; Thu, 4 Feb 2010 02:55:58 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id o14AuWtk010649 for ; Thu, 4 Feb 2010 19:56:33 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 54a1_f4a62ff4_117b_11df_a2b5_001d096c566a; Thu, 04 Feb 2010 19:56:32 +0900 Received: from [IPv6:::1] ([133.2.210.1]:42485) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 4 Feb 2010 19:56:33 +0900 Message-ID: <4B6AA7DE.9070805@it.aoyama.ac.jp> Date: Thu, 04 Feb 2010 19:56:30 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: Apps mail archive server down? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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, 04 Feb 2010 10:56:00 -0000 I'm trying to access http://mail.apps.ietf.org/ietf/charsets/maillist.html, but http://mail.apps.ietf.org/ as such seems to be down. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From julian.reschke@gmx.de Thu Feb 4 07:57:42 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B43E3A6C4E for ; Thu, 4 Feb 2010 07:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.682 X-Spam-Level: X-Spam-Status: No, score=-4.682 tagged_above=-999 required=5 tests=[AWL=-2.083, 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 rAj96ZRbhasB for ; Thu, 4 Feb 2010 07:57:41 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EE2B628C0FA for ; Thu, 4 Feb 2010 07:57:40 -0800 (PST) Received: (qmail invoked by alias); 04 Feb 2010 15:58:25 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp056) with SMTP; 04 Feb 2010 16:58:25 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX196mSgstBt6hSEFXZZoNNQPLgVVJeh4AZcDSpmEjf 21MZmcAya2rAtI Message-ID: <4B6AEE99.4080901@gmx.de> Date: Thu, 04 Feb 2010 16:58:17 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Mark Nottingham Subject: Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B58574B.4050204@gmx.de> <4B596B30.1030400@gmx.de> <3FB0E494-EE9C-46F8-A924-2768C730763A@mnot.net> In-Reply-To: <3FB0E494-EE9C-46F8-A924-2768C730763A@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.70999999999999996 Cc: Apps Discuss , Roy Fielding , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 15:57:42 -0000 Mark Nottingham wrote: > I think perhaps you need to talk to Roy about that... > > At the moment, my intent is to remove 'rev' from the BNF and state how new parameters can be added (either by updating the document, for parameters common to many relation types, or on a per-type / per-application basis). -1 / +1 Yes, the extensibility point should be documented. But no, rev should be documented. RFC 2068 already defines what it is, so the only thing an extension could ever do is to re-introduce that definition. There may be good reasons to *discourage* it's use, but that's really different from not defining it at all. I think we should park this issue until we know what happens with the anchor parameter; after all, a link relation using rel= can always be rewritten into one using anchor=. Best regards, Julian From mnot@mnot.net Thu Feb 4 16:07:44 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A8728C1F3 for ; Thu, 4 Feb 2010 16:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.045 X-Spam-Level: X-Spam-Status: No, score=-4.045 tagged_above=-999 required=5 tests=[AWL=-1.446, 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 xoOrjYTjWJSe for ; Thu, 4 Feb 2010 16:07:43 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 0EE3F28C1F7 for ; Thu, 4 Feb 2010 16:07:43 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.26.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EF61422E247; Thu, 4 Feb 2010 19:08:23 -0500 (EST) Subject: Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <1C573F35-D767-4219-BF65-2E28A0C0205D@gbiv.com> Date: Fri, 5 Feb 2010 11:08:20 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <9693EC6E-520B-4878-AC5D-4BBFF59FEAD3@mnot.net> References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B58574B.4050204@gmx.de> <4B596B30.1030400@gmx.de> <3FB0E494-EE9C-46F8-A924-2768C730763A@mnot.net> <1C573F35-D767-4219-BF65-2E28A0C0205D@gbiv.com> To: Roy T. Fielding X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 00:07:44 -0000 On 05/02/2010, at 9:07 AM, Roy T. Fielding wrote: > On Feb 3, 2010, at 10:17 PM, Mark Nottingham wrote: >=20 >> At the moment, my intent is to remove 'rev' from the BNF and state = how new parameters can be added (either by updating the document, for = parameters common to many relation types, or on a per-type / = per-application basis).=20 >=20 > I think we are going around in circles. Yes, I've been feeling that way for some time now... > The normal way to document a > deprecated protocol feature is to include it in the ABNF and state > that it is deprecated in the prose. Just like obs-text in HTTP. > Otherwise, we'll just keep getting asked "what happened to rev?" =20 Please make a proposal with text.=20 Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Thu Feb 4 16:23:16 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC3328C10D for ; Thu, 4 Feb 2010 16:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.1 X-Spam-Level: X-Spam-Status: No, score=-4.1 tagged_above=-999 required=5 tests=[AWL=-1.501, 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 rlmbvDEdj1FB for ; Thu, 4 Feb 2010 16:23:14 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 2966C28C0F4 for ; Thu, 4 Feb 2010 16:23:13 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.26.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0525422E1F3; Thu, 4 Feb 2010 19:23:59 -0500 (EST) Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B62D875.102@gmx.de> Date: Fri, 5 Feb 2010 11:23:56 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <7B248F44-44D9-4054-84A2-E9C4C5C251E1@mnot.net> References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> <4B596450.7020001@gmx.de> <4B62D875.102@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 00:23:16 -0000 On 29/01/2010, at 11:45 PM, Julian Reschke wrote: > Mark Nottingham wrote: >> ... >> If that's the case, you're saying that whether the anchor is allowed = is really a property of the relation type, not the application, aren't = you? ... >=20 > First of all, I'd prefer to distinguish between (A) "must be = processed" and (B) "may be processed, otherwise link must be rejected = altogether". >=20 > I see two purposes for the anchor parameter: >=20 > 1) Making a statement about a subset of the context resource, by = specifying a fragment identifier >=20 > 2) Making a statement about a different resource than the context = resource, such as >=20 > 2a) because the context is anonymous (such as the response body for a = 204, see = ), or >=20 > 2b) because a reverse link is exposed (anchor as workaround for = missing rev parameter) >=20 > I'm still not sure why we would ever make special cases here, except = for the known bugs in current implementations of the Link header where = anchor is ignored (so mainly Mozilla/Opera for stylesheet links). = Optimally, we just work with the vendors to get the bugs fixed. >=20 > If that's not possible, allowing an opt-out per relation type might = work, as long as behavior (B) would still be allowed. Is there any = relation !=3D "stylesheet" for which this would be relevant? I think most of them. E.g., what happens when my weblog http://www.mnot.net/blog/ contains a link header Link: ; rel=3D"service"; = anchor=3D"http://www.intertwingly.net/blog/" ? After Sam visits my blog, should his browser (assuming it supports = Atompub) use my site for editing next time he wants to post something? Likewise, what happens after I put this link header in all of my = responses? Link: ; rel=3D"self"; = anchor=3D"http://www.google.com/" ? Or better yet: Link: ; rel=3D"payment"; = anchor=3D"http://www.amazon.com/" While it may be that browsers in general won't "remember" this = information, that doesn't mean that we should specify things so that = they're encouraged to handle these things, knowing full well that they = won't. Opt-in seems much more sane that opt-out here, at least for = different resources. -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Fri Feb 5 02:35:41 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8EF3A6991 for ; Fri, 5 Feb 2010 02:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.55 X-Spam-Level: X-Spam-Status: No, score=-4.55 tagged_above=-999 required=5 tests=[AWL=-1.951, 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 quAkYCbT869P for ; Fri, 5 Feb 2010 02:35:40 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CAABB3A69B9 for ; Fri, 5 Feb 2010 02:35:39 -0800 (PST) Received: (qmail invoked by alias); 05 Feb 2010 10:36:27 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp065) with SMTP; 05 Feb 2010 11:36:27 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+EIVoMxriEOZHuw2vY0V57/x/u8vuFVWL4OdCyet i+CApPa15oD3RJ Message-ID: <4B6BF4A4.1060600@gmx.de> Date: Fri, 05 Feb 2010 11:36:20 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: IETF Apps Discuss , HTTP Working Group Subject: rfc2231-in-http: token characters, was: FYI: I-D Action:draft-reschke-rfc2231-in-http-08.txt References: <20100119113001.B5DD23A686C@core3.amsl.com> <4B55A549.7040904@gmx.de> In-Reply-To: <4B55A549.7040904@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53000000000000003 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, 05 Feb 2010 10:35:41 -0000 Julian Reschke wrote: > Hi, > > I have updated the draft with feedback I got during the informal "last > call" that ended yesterday (I added a statement about the relation RFC > 2388, and added information about existing implementations). > > See diffs at > . > > Next, I'll send a publication request to the Apps Area Directors. > > Best regards, Julian > ... In the meantime it was discovered that the allowed characters inside RFC2231-encoded parameter values differ from what RFC 2231 specifies. There are two reasons for that: 1) token in RFC 2616 disallows "{" and "}", while token in MIME (RFC 2231 and RFC 2045) does not; thus these are disallowed in rfc2231-in-http as well, and 2) I was disallowing more characters then I wanted to, and also allowed ":" which shouldn't have been there. For 1) I have added an explanation, simply pointing out the difference () For 2), I have now changed the ABNF so that all characters from RFC2616's token, except for the special characters used in 2231 ("*", "%", "'"), are allowed. () I'm planning to submit a new draft early next week, and then to get to IETF LC soonish. Best regards, Julian PS: also I have started work on tools that allow sanity checks on ABNF productions, such as "set A is expected to be identical to set (B \ C)", so things like that can be checked more easily in the future. From cfinss@dial.pipex.com Fri Feb 5 04:14:36 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B483A6D78; Fri, 5 Feb 2010 04:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZbPvUg4gYrS; Fri, 5 Feb 2010 04:14:35 -0800 (PST) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id BE51D3A6D7A; Fri, 5 Feb 2010 04:14:34 -0800 (PST) X-Trace: 290869756/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.186/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.186 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUEACiaa0s+vGS6/2dsb2JhbACCJiyFKIkAxi4Mgi+CEQQ X-IronPort-AV: E=Sophos;i="4.49,413,1262563200"; d="scan'208";a="290869756" X-IP-Direction: IN Received: from 1cust186.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.186]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Feb 2010 12:15:20 +0000 Message-ID: <004201caa654$6f5e5fc0$0601a8c0@allison> From: "tom.petch" To: "Michelle Cotton" , "Lars Eggert" References: Subject: Re: [tsvwg] [Fwd: Re: AD review: draft-ietf-tsvwg-port-randomization-05] Date: Fri, 5 Feb 2010 09:28:44 +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 Cc: tsvwg , apps-discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 12:14:36 -0000 ----- Original Message ----- From: "Michelle Cotton" To: "Fernando Gont" ; "Lars Eggert" Cc: "tsvwg" Sent: Monday, February 01, 2010 11:39 PM Fernando/Lars, Following-up on the thread below. Port Number requests are rejected for many reasons. Here are three of the most common reasons: 1 - Duplicates a function or protocol already in existence 2 - Is the secure version of a port already applied for or already in existence 3 - Port applied for is of local use only and traffic does not flow over the public Internet In general, a port number request is granted when an applicant can show a well-defined, public Internet protocol. The port must identify a named service that allows sessions to be created over the public Internet. The protocol, in a successful application, will be sufficiently documented to ensure that it is not local or a version of another service already in use. I hope this information helps. Please let me know if there is anything I can clarify. Michelle How straightforward and clear the above paragraphs are. Honest. Brilliant. I need to say this because recently I was critical of draft-ietf-tsvwg-iana-ports-04 for the lack of just this information, for describing the bureaucracy of port assignment/allocation/registration/reservation/request/grant........ without a) explaining what if anything is the difference between these terms b) describing what the point of the bureaucracy is. Your paragraphs above do more good than the whole of section 7, so please ditch section 7, include something along the lines above, and place it right at the front of the I-D, section 2. I would place reasons for granting before reasons for rejecting but otherwise I would change little. Tom Petch Michelle IANA On 1/27/10 11:20 AM, "Fernando Gont" wrote: >> Have there any cases in which use of a port has been rejected? > > Yes. > >> If so, what has been that reason? > > Depends :-) Maybe IANA can give some examples. > >> And what has been the criteria for actually "granting" the use of >> ports (as the above)? > > Satisfying the Expert Reviewer. From julian.reschke@gmx.de Fri Feb 5 04:23:53 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28FE3A6C42 for ; Fri, 5 Feb 2010 04:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.555 X-Spam-Level: X-Spam-Status: No, score=-4.555 tagged_above=-999 required=5 tests=[AWL=-1.956, 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 xt-cFSH+akvs for ; Fri, 5 Feb 2010 04:23:52 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5160C28C101 for ; Fri, 5 Feb 2010 04:23:51 -0800 (PST) Received: (qmail invoked by alias); 05 Feb 2010 12:24:41 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp043) with SMTP; 05 Feb 2010 13:24:41 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18dR+1TPLAdrwrSrSTjuOxmLRO4cidmnNFNFzyTUc 4DO+zLDKj/KE0k Message-ID: <4B6C0E00.8080405@gmx.de> Date: Fri, 05 Feb 2010 13:24:32 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: "Roy T. Fielding" Subject: Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B58574B.4050204@gmx.de> <4B596B30.1030400@gmx.de> <3FB0E494-EE9C-46F8-A924-2768C730763A@mnot.net> <1C573F35-D767-4219-BF65-2E28A0C0205D@gbiv.com> In-Reply-To: <1C573F35-D767-4219-BF65-2E28A0C0205D@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58999999999999997 Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 12:23:53 -0000 Roy T. Fielding wrote: > On Feb 3, 2010, at 10:17 PM, Mark Nottingham wrote: > >> At the moment, my intent is to remove 'rev' from the BNF and state how new parameters can be added (either by updating the document, for parameters common to many relation types, or on a per-type / per-application basis). > > I think we are going around in circles. The normal way to document a > deprecated protocol feature is to include it in the ABNF and state > that it is deprecated in the prose. Just like obs-text in HTTP. > Otherwise, we'll just keep getting asked "what happened to rev?" Indeed. > ... > A reverse link would show up as a potential transition from B if > you are currently at B. That terminology is from hypertext research > where link servers would maintain a database of all links. That is > why the HTML4 definition is confusing to folks who have worked with > traditional hypertext systems, since the Web does not maintain reverse > links (other than via external services like a CMS or Google). > > Anyways, it doesn't matter whether people are confused or not. > What matters is that the HTML2 definition of rev defines how the > technology actually works, whereas the HTML4 definition adds a > bunch of hand-waving and then misuses hypertext terminology in > order to explain what it "means" -- the result is neither technically > correct nor consistent with other hypertext systems, even if it > can be read the same way if we twist our heads a certain direction, > close one eye, and pretend we are in Kansas. > ... HTML5 doesn't have rev anymore anyway (well, unless the WG changes this again) So why don't we just say that "rev" means what HTML2 used to say, and be done with it? BR, Julian From julian.reschke@gmx.de Fri Feb 5 04:37:49 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACABF3A6EA3 for ; Fri, 5 Feb 2010 04:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.559 X-Spam-Level: X-Spam-Status: No, score=-4.559 tagged_above=-999 required=5 tests=[AWL=-1.960, 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 NZ21XM4aynwp for ; Fri, 5 Feb 2010 04:37:48 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D7F4E3A6EDA for ; Fri, 5 Feb 2010 04:37:47 -0800 (PST) Received: (qmail invoked by alias); 05 Feb 2010 12:38:36 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp045) with SMTP; 05 Feb 2010 13:38:36 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX188uQ5xmzI8yfhYpyqnpqYwrb1Epwd8oweiDkURAf GodEdrtoCZ7r+Z Message-ID: <4B6C1144.4090502@gmx.de> Date: Fri, 05 Feb 2010 13:38:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Mark Nottingham Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> <4B596450.7020001@gmx.de> <4B62D875.102@gmx.de> <7B248F44-44D9-4054-84A2-E9C4C5C251E1@mnot.net> In-Reply-To: <7B248F44-44D9-4054-84A2-E9C4C5C251E1@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.56000000000000005 Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 12:37:49 -0000 Mark Nottingham wrote: > On 29/01/2010, at 11:45 PM, Julian Reschke wrote: > >> Mark Nottingham wrote: >>> ... >>> If that's the case, you're saying that whether the anchor is allowed is really a property of the relation type, not the application, aren't you? ... >> First of all, I'd prefer to distinguish between (A) "must be processed" and (B) "may be processed, otherwise link must be rejected altogether". >> >> I see two purposes for the anchor parameter: >> >> 1) Making a statement about a subset of the context resource, by specifying a fragment identifier >> >> 2) Making a statement about a different resource than the context resource, such as >> >> 2a) because the context is anonymous (such as the response body for a 204, see ), or >> >> 2b) because a reverse link is exposed (anchor as workaround for missing rev parameter) >> >> I'm still not sure why we would ever make special cases here, except for the known bugs in current implementations of the Link header where anchor is ignored (so mainly Mozilla/Opera for stylesheet links). Optimally, we just work with the vendors to get the bugs fixed. >> >> If that's not possible, allowing an opt-out per relation type might work, as long as behavior (B) would still be allowed. Is there any relation != "stylesheet" for which this would be relevant? > > > I think most of them. > > E.g., what happens when my weblog > http://www.mnot.net/blog/ > contains a link header > Link: ; rel="service"; anchor="http://www.intertwingly.net/blog/" > ? > After Sam visits my blog, should his browser (assuming it supports Atompub) use my site for editing next time he wants to post something? That's an excellent example. I do agree that - in general - we don't want to be able to affect . So the choices here are: a) Processing anchor, detecting the authority conflict, and ignoring the link, or b) ignoring anchor, and pretending we have --service--> What I'm trying to say is that we never ever want b). So I'm fine with clients ignoring the link header altogether because it contains anchor, but simply ignoring the anchor parameter, but processing the rest seems to be a very bad idea. > Likewise, what happens after I put this link header in all of my responses? > Link: ; rel="self"; anchor="http://www.google.com/" > ? > > Or better yet: > Link: ; rel="payment"; anchor="http://www.amazon.com/" > > While it may be that browsers in general won't "remember" this information, that doesn't mean that we should specify things so that they're encouraged to handle these things, knowing full well that they won't. Opt-in seems much more sane that opt-out here, at least for different resources. Well, maybe we've been agreeing all the time, and just the spec text needs tuning. So again: a recipient MUST resolve the anchor parameter against the context IRI (*), producing a new context. It MAY ignore the link if the resulting context looks suspicious (maybe something like same-domain could be recommended here). Best regards, Julian (*) + handle the case where there's no context IRI From touch@ISI.EDU Fri Feb 5 08:47:24 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57ED428C1DC; Fri, 5 Feb 2010 08:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Lc+xttL9eQkX; Fri, 5 Feb 2010 08:47:23 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 75A5B3A687B; Fri, 5 Feb 2010 08:47:23 -0800 (PST) Received: from [75.214.178.5] (5.sub-75-214-178.myvzw.com [75.214.178.5]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o15GkXiB015202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Feb 2010 08:46:34 -0800 (PST) Message-ID: <4B6C4B69.20402@isi.edu> Date: Fri, 05 Feb 2010 08:46:33 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tom.petch" Subject: Re: [tsvwg] [Fwd: Re: AD review: draft-ietf-tsvwg-port-randomization-05] References: <004201caa654$6f5e5fc0$0601a8c0@allison> In-Reply-To: <004201caa654$6f5e5fc0$0601a8c0@allison> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2E8135001CBFA1866A76D80D" X-MailScanner-ID: o15GkXiB015202 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: apps-discuss , Michelle Cotton , tsvwg 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, 05 Feb 2010 16:47:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2E8135001CBFA1866A76D80D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tom, The problem is that the two ideas (the list below, vs. Sec 7) have completely different purposes. Section 7 describe IANA policies and changes therein. The above describes expert review, which is a separate matter. I hesitate to encode expert review rules - even the "most common" ones - because then can too easily change, and putting them in a doc promotes them as static. Further, this doc is about IANA issues, not the expert review process. Joe tom.petch wrote: > ----- Original Message ----- > From: "Michelle Cotton" > To: "Fernando Gont" ; "Lars Eggert" > > Cc: "tsvwg" > Sent: Monday, February 01, 2010 11:39 PM >=20 >=20 > Fernando/Lars, >=20 > Following-up on the thread below. >=20 > Port Number requests are rejected for many reasons. Here are three of = the most > common reasons: >=20 > 1 - Duplicates a function or protocol already in existence > 2 - Is the secure version of a port already applied for or already in e= xistence > 3 - Port applied for is of local use only and traffic does not flow ove= r the > public Internet >=20 > In general, a port number request is granted when an applicant can show= a > well-defined, public Internet protocol. The port must identify a named= service > that allows sessions to be created over the public Internet. The proto= col, in a > successful application, will be sufficiently documented to ensure that = it is not > local or a version of another service already in use. >=20 > I hope this information helps. Please let me know if there is anything= I can > clarify. >=20 > >=20 > Michelle >=20 > How straightforward and clear the above paragraphs are. Honest. Brill= iant. >=20 > I need to say this because recently I was critical of > draft-ietf-tsvwg-iana-ports-04 > for the lack of just this information, for describing the bureaucracy o= f port > assignment/allocation/registration/reservation/request/grant........ > without > a) explaining what if anything is the difference between these terms > b) describing what the point of the bureaucracy is. >=20 > Your paragraphs above do more good than the whole of section 7, so plea= se ditch > section 7, include something along the lines above, and place it right = at the > front of the I-D, section 2. I would place reasons for granting before= reasons > for rejecting but otherwise I would change little. >=20 > Tom Petch >=20 > >=20 >=20 > Michelle > IANA >=20 > On 1/27/10 11:20 AM, "Fernando Gont" wrote: >=20 >>> Have there any cases in which use of a port has been rejected? >> Yes. >> >>> If so, what has been that reason? >> Depends :-) Maybe IANA can give some examples. >> >>> And what has been the criteria for actually "granting" the use of >>> ports (as the above)? >> Satisfying the Expert Reviewer. --------------enig2E8135001CBFA1866A76D80D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAktsS2kACgkQE5f5cImnZrt3dwCg1VFxtbDxRtTU5tU9H5+65dyp h/0AoOEOvVJAwHRH4DtfRbb0m0Z+s4uz =PSR7 -----END PGP SIGNATURE----- --------------enig2E8135001CBFA1866A76D80D-- From fernando@gont.com.ar Fri Feb 5 08:59:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40843A6F46; Fri, 5 Feb 2010 08:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, 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 Kc-iPO7-mHok; Fri, 5 Feb 2010 08:59:20 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id E0DBB3A6F3F; Fri, 5 Feb 2010 08:59:17 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 667C56B6B4E; Fri, 5 Feb 2010 14:00:09 -0300 (ART) Received: from [192.168.0.100] (144-174-17-190.fibertel.com.ar [190.17.174.144]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o15H02k4014625; Fri, 5 Feb 2010 14:00:03 -0300 Message-ID: <4B6C4E92.7040302@gont.com.ar> Date: Fri, 05 Feb 2010 14:00:02 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch Subject: Re: [tsvwg] [Fwd: Re: AD review: draft-ietf-tsvwg-port-randomization-05] References: <004201caa654$6f5e5fc0$0601a8c0@allison> <4B6C4B69.20402@isi.edu> In-Reply-To: <4B6C4B69.20402@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 05 Feb 2010 14:00:08 -0300 (ART) Cc: Michelle Cotton , tsvwg , apps-discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 16:59:20 -0000 Joe Touch wrote: > I hesitate to encode expert review rules - even the "most common" ones - > because then can too easily change, and putting them in a doc promotes > them as static. Further, this doc is about IANA issues, not the expert > review process. The question is not about how the expert review is performed, but rather about if that review is even possible (e.g., for closed protocols). If that review is not possible, then there's no way to decide on granting vs. rejecting the ports, and thus IANA is not really assigning the ports, but rather registering them (registering their use). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Fri Feb 5 09:06:08 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADAED3A6F55; Fri, 5 Feb 2010 09:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlQvVJLiMEE4; Fri, 5 Feb 2010 09:06:07 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id D44413A6DD7; Fri, 5 Feb 2010 09:06:07 -0800 (PST) Received: from [75.214.178.5] (5.sub-75-214-178.myvzw.com [75.214.178.5]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o15H5How018805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Feb 2010 09:05:19 -0800 (PST) Message-ID: <4B6C4FCC.3060302@isi.edu> Date: Fri, 05 Feb 2010 09:05:16 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tsvwg] [Fwd: Re: AD review: draft-ietf-tsvwg-port-randomization-05] References: <004201caa654$6f5e5fc0$0601a8c0@allison> <4B6C4B69.20402@isi.edu> <4B6C4E92.7040302@gont.com.ar> In-Reply-To: <4B6C4E92.7040302@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig45D18553576E708A0F7611BC" X-MailScanner-ID: o15H5How018805 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Michelle Cotton , tsvwg , apps-discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 17:06:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig45D18553576E708A0F7611BC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Fernando, Fernando Gont wrote: > Joe Touch wrote: >=20 >> I hesitate to encode expert review rules - even the "most common" ones= - >> because then can too easily change, and putting them in a doc promotes= >> them as static. Further, this doc is about IANA issues, not the expert= >> review process. >=20 > The question is not about how the expert review is performed, but rathe= r > about if that review is even possible (e.g., for closed protocols). First, expert review is advisory only. IANA decides based on that input, but isn't bound to it. Second, closed protocols still need to explain something about what they do, i.e., their basic commands, packet size ranges, support for versioning, use of congestion control for UDP variants, etc. Specifics aren't needed to do the review, and applications always contain the needed info - even for closed protocols. > If that review is not possible, then there's no way to decide on > granting vs. rejecting the ports, and thus IANA is not really assigning= > the ports, but rather registering them (registering their use). The above might clarify that point. IANA is assigning, by your distinctio= n. Joe --------------enig45D18553576E708A0F7611BC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAktsT8wACgkQE5f5cImnZrv8CQCgqgDhkXPETbEYLq+nZPaZh4xu 33gAn1LYYJRAxaikUK5BOk7yRX6NTYvc =fmD7 -----END PGP SIGNATURE----- --------------enig45D18553576E708A0F7611BC-- From fielding@gbiv.com Thu Feb 4 14:06:46 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F421728C0CE for ; Thu, 4 Feb 2010 14:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOY2O1RsmSAA for ; Thu, 4 Feb 2010 14:06:45 -0800 (PST) Received: from spaceymail-a4.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 1DFE23A6E61 for ; Thu, 4 Feb 2010 14:06:45 -0800 (PST) Received: from [192.168.1.66] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) by spaceymail-a4.g.dreamhost.com (Postfix) with ESMTP id AA0D1161472; Thu, 4 Feb 2010 14:07:32 -0800 (PST) Subject: Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <3FB0E494-EE9C-46F8-A924-2768C730763A@mnot.net> Date: Thu, 4 Feb 2010 14:07:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1C573F35-D767-4219-BF65-2E28A0C0205D@gbiv.com> References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B58574B.4050204@gmx.de> <4B596B30.1030400@gmx.de> <3FB0E494-EE9C-46F8-A924-2768C730763A@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Fri, 05 Feb 2010 09:27:02 -0800 Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 22:06:46 -0000 On Feb 3, 2010, at 10:17 PM, Mark Nottingham wrote: > At the moment, my intent is to remove 'rev' from the BNF and state how = new parameters can be added (either by updating the document, for = parameters common to many relation types, or on a per-type / = per-application basis).=20 I think we are going around in circles. The normal way to document a deprecated protocol feature is to include it in the ABNF and state that it is deprecated in the prose. Just like obs-text in HTTP. Otherwise, we'll just keep getting asked "what happened to rev?" =20 > On 22/01/2010, at 8:09 PM, Julian Reschke wrote: >>> As previous discussed (quite a bit), HTML2 defines REV as having = reversed *semantics*, while HTML4 talks about it creating a "reverse = link" -- which are very different things. This feels like a rat hole to = me (thus my attempts to navigate around it). >>=20 >> Again, HTML 2 defines it as: >>=20 >> REV >> same as the REL attribute, but the semantics of the >> relationship are in the reverse direction. A link from A >> to B with REL=3D"X" expresses the same relationship as a >> link from B to A with REV=3D"X". An anchor may have both >> REL and REV attributes. >>=20 >> () >>=20 >> That totally sounds like "reverse link" to me. So, I really really = think there's less confusion than some people claim. A reverse link would show up as a potential transition from B if you are currently at B. That terminology is from hypertext research where link servers would maintain a database of all links. That is why the HTML4 definition is confusing to folks who have worked with traditional hypertext systems, since the Web does not maintain reverse links (other than via external services like a CMS or Google). Anyways, it doesn't matter whether people are confused or not. What matters is that the HTML2 definition of rev defines how the technology actually works, whereas the HTML4 definition adds a bunch of hand-waving and then misuses hypertext terminology in order to explain what it "means" -- the result is neither technically correct nor consistent with other hypertext systems, even if it can be read the same way if we twist our heads a certain direction, close one eye, and pretend we are in Kansas. ....Roy From touch@ISI.EDU Sat Feb 6 12:16:48 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC343A6CA8; Sat, 6 Feb 2010 12:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 gQnR7U5diJjW; Sat, 6 Feb 2010 12:16:47 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 479063A6803; Sat, 6 Feb 2010 12:16:47 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o16KHAJr016318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Feb 2010 12:17:11 -0800 (PST) Message-ID: <4B6DCE46.1030501@isi.edu> Date: Sat, 06 Feb 2010 12:17:10 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Alfred_=3F?= Subject: Re: [tsvwg] [port-srv-reg] "assigned" ( vs. "registered"), and relates issues References: <201001151840.TAA14644@TR-Sys.de> In-Reply-To: <201001151840.TAA14644@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC4F046E2A15A409102301647" X-MailScanner-ID: o16KHAJr016318 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org, apps-discuss@ietf.org, port-srv-reg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2010 20:16:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC4F046E2A15A409102301647 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Alfred, Taking this up a level to summarize. there are two points. Let me know if this is consistent with your understanding... Joe ------ #1 -- I think (correct me if wrong) that you want service names without assigned port numbers, to be registered only for specific protocols. For services with assigned port numbers, we assign a triple: namestring transport portnum There's no one index to that triple. The index is the pair, i.e.: namestring,transport -> unique portnum For services, I can see why we would assign (or, in this case, register):= namestring transport ------ #2 -- There's an interesting question of 'who gets to add transport protocols to a service that exists', regardless of whether the service has a port or not. I think IANA can handle that as it happens. I had been assuming that ownership of that was done at the time the service name was assigned, but that clearly needs potential override for abandoned services, e.g. ------ --------------enigC4F046E2A15A409102301647 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkttzkYACgkQE5f5cImnZrsWtACcCbqEnE2UHdZ6LHrnEcX/F31C +X4AmwYQ/FSHOnUBBXaD+d8lP9OOnuiI =dBH1 -----END PGP SIGNATURE----- --------------enigC4F046E2A15A409102301647-- From touch@ISI.EDU Sat Feb 6 14:46:02 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E613A6F8B; Sat, 6 Feb 2010 14:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, J_CHICKENPOX_62=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 qwy7QyQk3WKO; Sat, 6 Feb 2010 14:46:00 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id F14A03A67ED; Sat, 6 Feb 2010 14:45:59 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o16Mk6d0010960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Feb 2010 14:46:07 -0800 (PST) Message-ID: <4B6DF12D.9070808@isi.edu> Date: Sat, 06 Feb 2010 14:46:05 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Alfred_=3F?= Subject: Re: [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 (fwd) References: <200912281732.SAA12969@TR-Sys.de> In-Reply-To: <200912281732.SAA12969@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig784C8AD06B03EE4661588AE2" X-MailScanner-ID: o16Mk6d0010960 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: namedroppers@ops.ietf.org, draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG, tsvwg@ietf.org, apps-discuss@ietf.org, port-srv-reg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2010 22:46:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig784C8AD06B03EE4661588AE2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, I completely agree with the abstract and the first bullet of section 1.1, and section 1.2 EXCEPT in proposing the extension (appendix A). I don't think adding an extension "clarifies"; this doc ought to focus on the clarification issue, and would be useful if doing so. Specific comments below, though IMO the structural issues are worth addressing *before* the specific comments indicated. Joe --------------- =2E.. > Clarification of DNS SRV Owner Names > draft-gudmundsson-dnsext-srv-clarify-00 =2E.. > 1.1. Problem Statement >=20 > RFC 2782 says that the source of names for "Service" and "Proto" is > "Assigned Numbers" (STD2) or a locally defined repository. >=20 > However, upon reflection, both alternatives do not seem to make > particular sense: >=20 > o The STD2 series of documents was obsoleted by RFC 3232 [RFC3232] > and IANA registration publication was handed over to on-line > registries maintained by IANA. Unfortunately it is not explicitl= y > explained in RFC 2782 which section of STD2 it is referring to, > nor does RFC 3232 help. By common knowledge, RFC 2782 referred t= o > the Keyword columns of the "Protocol Numbers" and "Port Numbers" >=20 >=20 >=20 > Gudmundsson & Hoenes Expires July 1, 2010 [Page 3= ] > =0C > Internet-Draft SRV Prefix Clarifications December 200= 9 >=20 >=20 > IANA registries, respectively. >=20 > As SRV records contain the port where each server provides the > service, the outmost utility of SRV RRs is for services that do > not have a registered port number.=20 or where they are provided on ports other than the registered one. > Also, the number of ports > available is small compared to the possible number of service > names that could be registered. Therefore, the "Port Number" > registry needs a more strict registration policy and is not the > proper place for registering service names for use with SRV > resource records. This implies that service names with assigned ports would not be used with SRVs; this is not required by the SRV spec. It also implies that SRV names are somehow independent of the port number registry, but the IANA ports doc ID formalizes the unification of these two namespaces. > o Having locally defined lists of service and/or protocol names > would equally allow to list the full service information in such > local databases and thus make the usage of SRV records redundant.= This language is awkward, and the logic is backwards. It's like saying "you don't need the DNS because you can have hosts.txt". SRV can replace /etc/services (with the appropriate changes to standards); the converse is not true, so "equal" may be misleading. > In any case, this scenario is not applicable for publicly > available services where potential clients are not under the > control of the authority offering the services, and hence most > probably would have no access to the proper "locally provided" > information. The reader is reminded that locally maintained > database solutions generally scale very poorly, and that this onc= e > was the major momentum for the deployment of the Domain Name replace 'momentum' with 'impetus' (or motivation?) > System. As above, confusing and may need rewording. I'm not sure what you're primary point is. > 1.2. Objective for this Document and its Companions I completely agree with this section, but subsequent sections diverge from this objective IMO. =2E.. > 2. General Considerations for SRV Service Prefixes >=20 > SRV Service Prefixes SHOULD consist of exactly two labels. When do they not? Is it even possible they do not? > If the specification of a particular application/service indicates > that this service is to be provided at a specific registered port > number and does not mention DNS SRV based service discovery, > prospective clients SHOULD NOT assume the existence of SRV records I'd go with "MUST NOT" assume (isn't that in the SRV spec?) > for this application, unless the client has hints available that > indicate otherwise -- for instance by means of configuration. In > this case, only the rules of Sections 3 and 4 apply. No need for the rest of the sentence (unless...); in that case, there is no assumption. > If the specification of a particular application/service does mentio= n > dynamic service discovery based on DNS SRV records but does not > specify otherwise in a precise and unambiguous manner, the rules of > Sections 3 and 4 apply. In this case, a prospective client SHOULD > look up the DNS for the appropriate SRV records for the intended > Service Domain. ******** =46rom here down (see trailing ********, i.e., all of the rest of section= 3), the discussion diverges from the main point of this doc, and introduces a new concept of layered services. That may be a useful concept to explore, but belongs in a separate document, and IMO is premature. > Some services can be carried equivalently in different encapsulation= s > using higher-level "substrate" protocols like HTTP, BEEP, SOAP, SIP,= > XMPP, some of which in turn can be carried over different transport > protocols. In this case, it is possible that certain servers for an= > application only support specific protocol stacks, or that a Service= > Domain provides a different set of servers for each protocol stack. > Consequently, there occasionally is a need to specify such details i= n > the SRV Service Prefix. Since the Protocol Label is intentionally > restricted (Section 3), this information has to be carried in the > Service Label for this application. Interesting idea, but currently SRVs and port numbers are assigned to the entirety of layers 5-7 (and any shims therein). This proposes a completely new structure for services that should be considered as a separate issue, and IMO is far too premature to consider for deployment. > There are two possibilities to achieve this goal: >=20 > a. If there is only a small number of "substrate" protocols to > distinguish, it is RECOMMENDED that the application designers > register multiple Service Names with IANA in the "Service Names > and Port Numbers" registry [RFCyyyy], which usually will start > with the same characters and contain a suffix attached with a > hyphen embedded in the name. The 15-char limit doesn't support this option. There are far too many current names that do not have this sort of syntax. Finally, any structure in the service layering should be supported in the SRV system, not in the syntax of the namespace. > One disadvantage of this solution is the length limitation > imposed on the Service Name by [RFCyyyy] (15 characters, see >=20 >=20 >=20 > Gudmundsson & Hoenes Expires July 1, 2010 [Page 6= ] > =0C > Internet-Draft SRV Prefix Clarifications December 200= 9 >=20 >=20 > Section 4). Also, [RFCyyyy] recommends that -- notwithstanding > some very popular, and mostly legacy cases -- each service ought= > to be represented by a *single* Service Name. If the service is= > the same and only the substrate used is different, this solution= > arguably is in conflict with [RFCyyyy]. >=20 > b. If the number of substrate stacks to be supported is larger, or > if the 'canonical' labels that the application designers prefer > would result in exceeding the maximum length of Service Names, o= r > if multi-layer substrates shall be represented, or if the "uniqu= e > Service Name per service" argument is deemed important, an > extension scheme is needed for the construction of Service Label= s > for such exceptional services. This goes outside the scope of the IANA ports doc; service names are 15 chars in that doc, and that doc doesn't address extension services. This is premature. > The non-normative Appendix A proposes a scheme for extended > Service Labels that does not pollute the namespace of Service > Names and hence adheres to the uniqueness and collision-freeness= > requirements of [RFCyyyy]. The basic Service Name can be easily= > extracted from these extended Service Labels, as they employ a > separator character not allowed in Service Names to attach > qualifier(s) to a 'basic' Service Label as specified in > Section 4. >=20 > Application designers who want to make use of that scheme MUST > independently and unambiguously specify the application of that > scheme for their service and ensure that a reference to the > document containing this specification (if different from the > document specifying the basic service) is added to the entry for= > that service in the "Service Names and Port Numbers" IANA > registry, following the registration procedures of [RFCyyyy]. >=20 > To re-iterate, absent such explicit, registered specification, > the rules of Section 4 (and, of course, Section 3 as well) still= > apply in these cases. >=20 > Application protocol designers ought to keep service discovery > simple. The fewer alternatives a prospective client has to consider= > and the fewer choices he has to find suitable SRV records, the faste= r > the service discovery can be performed, because it needs fewer DNS > queries on average and thus incurs less latency. If alternative > transports and/or variations of the service are really needed to be > distinguished by service discovery, to foster interoperablity there > SHOULD always be defined a default version supported by all clients > and servers, and configured in the DNS, thus allowing an orderly > fallback in case client preferences cannot be accommodated. Fallback is a property of a protocol; each service has different requirements for such backward compatibility. If such a default or fallback is assumed, then the SRV system should have a flag indicating that. Port numbers are not intended to have any hierarchy or alternates of services, so such a fallback is not appropriate to indicate there. (each service group can do this, but it's not realistic to write a SHOULD unless you know when it is violated and can enforce it; there's no requirement to explain when protocols are grouped or have defaults, so requiring application designers to do this begs the question of how). ******** (i.e., to end of section 3) =2E.. > 4. Standard Service Labels >=20 > Absent a normative document specifying otherwise, the SRV Service > Label for a specific service/application SHOULD be in the form of a > "Standard SRV Servcie Label" as specified in this section. >=20 > Standard SRV Service Labels MUST be formed by prepending an > underscore character ("_") to the Service Name of an application >=20 >=20 >=20 > Gudmundsson & Hoenes Expires July 1, 2010 [Page 8= ] > =0C > Internet-Draft SRV Prefix Clarifications December 200= 9 >=20 >=20 > protocol registered in the IANA "Service Names and Port Numbers" > registry [RFCyyyy]. >=20 > Note that in order to make use of DNS based service discovery using > SRV records, the application/service does *not* need an IANA-assigne= d > port number (which would also be filed in the IANA "Service Names an= d > Port Numbers" registry). >=20 > The port numbers carried in the RDATA portion of the SRV records are= > locally assigned within the Service Domain; in case the service > indeed has an IANA-assigned (default) port number, the locally IANA-assigned is not indicated as "default". There's no mechanism that specifies it as a default. > assigned port number MAY coincide with that default port number, > unless the documentation of the service specifies otherwise (it may > say "MUST", "SHOULD", or recommend *against* using the default). >=20 > As all domain name labels, SRV Service Labels are matched in a case-= > insensitive manner. >=20 > [RFCyyyy] restricts IANA-registered Service Names to 15 characters i= n > "ldh-syntax", informally: The rest of this section should be dropped. Just cite the IANA doc. If/when the IANA spec changes, so should this. It's a bad idea to copy requirements into a separate doc. =2E.. > Appendix A offers a scheme for "Extended SRV Service Labels" that ca= n > be adopted by service specifications that cannot contend with these > restrictions, and which seek for a versatile naming scheme not > violating the provisions of [RFCyyyy]. IMO this appendix should be offered and its necessity argued in a separate document. > 5. Service Discovery Client Considerations >=20 > Implementations making use of dynamic service discovery based on DNS= > SRV records for a particular application/service will construct a > prioritized list of applicable Service Prefixes, following the > guidelines in the two subsections below. This appears to be describing new user-side requirements for the use of SRVs. This needs further discussion in the WG; I don't think such a prioritized list should be required. --- I don't understand why the remainder of this section (below) is needed; you're just restating how to use SRVs, and the SRV spec should have said that. Didn't it? > To form the QNAME(s) for DNS SRV lookup, each Service Prefix is > concatenated (with a period as the label separator character) to the= > FQDN of the Service Domain the application is interested in. >=20 > Depending on application strategy and perhaps local policy > (configuration), the DNS queries with QCLASS=3DIN and QTYPE=3DSRV ca= n be > performed serially or in parallel -- to decrease the latency in the > case higher priority queries do not succeed in finding matching SRV > record(s). > > The answers obtained are processed as specified in RFC 2782 > [RFC2782], subject to the preferences of the service client for > transport and/or "substrate" protocols. If necessary, the Target > domain names obtained are then queried for address records (i.e., at= > the time of this writing, A and/or AAAA RRs) to determine the networ= k > layer addresses to be contacted over the corresponding transport > protocol using the port number contained in the 'Port' element of th= e > respective SRV record. >=20 > Note: RFC 2782 [RFC2782] on page 7 imprecisely indicates the client= > "[SHOULD] ... try to connect to the (protocol, address, service)"= > tuple. Since at the transport layer the port number needs to be > used, not the service (name?), and to let the order of the tuple >=20 >=20 >=20 > Gudmundsson & Hoenes Expires July 1, 2010 [Page 10= ] > =0C > Internet-Draft SRV Prefix Clarifications December 200= 9 >=20 >=20 > components follow the protocol layers, it should refer to > "(address, protocol, port)" tuples. >=20 > 5.1. Protocol Label Selection >=20 > Some services are defined to operate over only one transport > protocol. In this case the application MUST use the appropriate > transport label in forming the Service Prefix for SRV record lookup.= >=20 > If a service can operate over multiple transport protocols, then the= > specification of the service might indicate an order of preference, > or local policy may supply it. Any service can provide a specific > order in the Notes section of the "Service Names and Port Numbers" > registry, during registration or via registration update [RFCyyyy]. I don't agree; prioritization should be a property of the SRV records, not in the notes. This seems like an extension of the protocol. > Absent such information, the following priority order SHOULD be used= Absent what information? The "notes" aren't in the SRV records, so as such they ought to always be absent at the endpoint - so the rest of this is the only real recommendation here, and it's a tautology (endpoints should use only what they can use). > as appropriate, based on what transports are defined and registered > for the service, and supported by the client: _udp, _tcp, _sctp, > _dccp. >=20 > 5.2. Service Label Selection >=20 > Absent service specific documentation saying otherwise or hints > available to the client (e.g., by configuration), the following > recommendations SHOULD be followed. >=20 > If an application/service has a single registered Service Name, a > prospective client uses the Standard Service Label derived from it > according to Section 4. >=20 > Contrary to the strong recommendation in RFC 2782 [RFC2782], several= > legacy services have been assigned more than one Service Name in the= > past. For instance, the well-know "systat" service is also referred= > to as "users" service, the DNS service, "domain", is also referred t= o > as "nameserver" or "dns", "rlp" is also denoted as "resource", the > WhoIs service is identified by "whois" and "nicname", the web servic= e > uses "http" or "www", "kerberos" is also indicated by "kdc", and the= > PCMail service has been assigned the equivalent Service Names > "pcmail-srv" and "pcmail". > In all these cases, the "Service Names and Port Numbers" registry > will clearly indicate which name is the primary one and which names > are considered aliases. I don't see why this should be expected or is necessary, except for the deprecated names whose syntax needed to change based on the IANA ports doc. Please explain. > Unless a prospective client has specific hints available (e.g., by > configuration) indicating that a specific alias name ought to be > tried preferentially, the primary Service Name SHOULD be used, and i= t > also SHOULD be tried if the lookup of an alias name fails. I don't see what this accomplishes. It seems an unnecessarily restriction= =2E The rest of this section should be moved to the separate doc arguing for extended names... > If a service/application supports different well marked instances > identified by different Service Names or a related specification has= >=20 >=20 >=20 > Gudmundsson & Hoenes Expires July 1, 2010 [Page 11= ] > =0C > Internet-Draft SRV Prefix Clarifications December 200= 9 >=20 >=20 > introduced the usage of extended Service Labels for discovery of thi= s > service (e.g., making use of the scheme specified in Appendix A), th= e > specifications SHOULD always also define a single default service > instance, and hence a default Service Label or Service Name (that ca= n > be used to construct the the corresponding Standard Service Label). > Prospective clients MAY follow any service instance selection policy= > desired (by implementation, deployment, or configuration), but SHOUL= D > be prepared to fall back to the default service instance if the SRV > record lookup for preferred service instance(s) fails. >=20 >=20 > 6. Provisioning of SRV records >=20 > DNS zone administrators SHOULD support (and encourage) the > provisioning of SRV records related to the basic domains they manage= =2E > Dynamic DNS Update ([RFC2136], [RFC3007]) is an option, but this is > out of scope for this document. IMO, SRV provisioning ought to be outside the scope of this doc entirely. The rest of this section is not related to the indicated focus of this doc, and if needed should be in another (third) document. =2E.. > 7. Security Considerations >=20 > This document does not have any specific security implications. Agreed. > However it is hoped that the more orderly, and more frequent use of > SRV-based dynamic service discovery, based on the rules clarified in= > this documents and the establishment of a unified service registry, > will provide valuable information for administrators and security > policy makers, to the benefit of the overall security of the > Internet. I have no idea why this should be true; can you explain? The rest of this section can be omitted; it does not add to the first sentence of this entire section, which says it all IMO. > 8. IANA Considerations >=20 > This document has no IANA actions. >=20 >=20 > 9. References >=20 > 9.1. Normative References >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for > specifying the location of services (DNS SRV)", RFC 2782,= > February 2000. >=20 > [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax > Specifications: ABNF", STD 68, RFC 5234, January 2008. >=20 > [RFCyyyy] Cotton, M., Eggert, L., Mankin, A., Touch, J., and M. >=20 >=20 >=20 > Gudmundsson & Hoenes Expires July 1, 2010 [Page 13= ] > =0C > Internet-Draft SRV Prefix Clarifications December 200= 9 >=20 >=20 > Westerlund, "Internet Assigned Numbers Authority (IANA) > Procedures for the Management of the Service Name and > Transport Protocol Port Number Registry", > draft-ietf-tsvwg-iana-ports-04 (work in progress), > December 2009. >=20 > 9.2. Informative References >=20 > [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, > August 1980. >=20 > [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, > RFC 793, September 1981. >=20 > [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying th= e > location of services (DNS SRV)", RFC 2052, October 1996. >=20 > [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, > "Dynamic Updates in the Domain Name System (DNS UPDATE)",= > RFC 2136, April 1997. >=20 > [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic > Update", RFC 3007, November 2000. >=20 > [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by > an On-line Database", RFC 3232, January 2002. >=20 > [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and= > G. Fairhurst, "The Lightweight User Datagram Protocol > (UDP-Lite)", RFC 3828, July 2004. >=20 > [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. > Rose, "DNS Security Introduction and Requirements", > RFC 4033, March 2005. >=20 > [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram > Congestion Control Protocol (DCCP)", RFC 4340, March 2006= =2E >=20 > [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadma= p > for Transmission Control Protocol (TCP) Specification > Documents", RFC 4614, September 2006. >=20 > [RFC4960] Stewart, R., "Stream Control Transmission Protocol", > RFC 4960, September 2007. >=20 > [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for= > the Protocol Field", BCP 37, RFC 5237, February 2008. >=20 >=20 >=20 >=20 > Gudmundsson & Hoenes Expires July 1, 2010 [Page 14= ] > =0C > Internet-Draft SRV Prefix Clarifications December 200= 9 >=20 >=20 > [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design > Choices When Expanding the DNS", RFC 5507, April 2009. >=20 >=20 > Appendix A. Extended SRV Service Labels >=20 > This non-normative Section defines a versatile extension scheme for > SRV Service Labels that can be incorporated by reference in > specifications of service discovery procedures for applications that= > cannot contend with Standard Service Labels as specified in > Section 4. >=20 > A.1. Motivation and Solution Space >=20 > Sections 2 and 4 identify scenarios of applications/services that > might reasonably wish to use an extended scheme for forming their > Service Labels, in particular to identify protocol layers > (encapsulation layers, "substrate" protocols) stacked between the > transport protocol and the application protocol itself, without > having to register a multitude of Service Names in the "Service Name= s > and Port Numbers" registry and hence being bound to the 15-character= > name size limit. Other scenarios with similar requirements have bee= n > mentioned in recent work-in-progress in the IETF. >=20 > For being useful, a scheme for extended Service Labels must allow (a= ) > to easily determine that a label obeys to this scheme and (b) to > unambiguously extract the underlying Service Name and the added > extension components (henceforth: Qualifiers) from the full label, > whereas at the same time the scheme needs to ensure that it does not= > pollute the name space of Service Names and that thereby the > uniqueness of registered Service Names is not disturbed. >=20 > As restated in Section 4, the syntax of Service Names from [RFCyyyy]= > does not allow the underscore ("_") character, which in turn already= > is used as a prefix character for SRV Service and Protocol Labels > serving to distinguish these labels from 'ordinary' domain name > components. Therefore, a manifest method to construct extended > Service Labels is to concatenate the given Service Name and > Qualifiers, prepending each component by an underscore character. >=20 > A.2. Specification >=20 > Thus, we arrive at the following syntax for Extended Service Labels,= > extending the ABNF from Section 4: >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Gudmundsson & Hoenes Expires July 1, 2010 [Page 15= ] > =0C > Internet-Draft SRV Prefix Clarifications December 200= 9 >=20 >=20 > serv-label =3D/ ext-serv-label >=20 > ext-serv-label =3D USC service-name 1*( USC serv-qualifier ) > ; total size limited to 63 characters >=20 > serv-qualifier =3D 1*(l-d-h) > ; also conforming to the rule >=20 > Hypothetical example: > Assume an application with registered Service Name "foohoo" for > transport over SCTP is served for the domain "ext.example". Also= > assume that this service needs to be qualified by the keywords > (service qualifiers) (1) "barbar" and (2) "aanne". > Then the corresponding Extended SRV Service Label will be: >=20 > _fooho_barbar_aanne >=20 > and the full SRV owner name will be: >=20 > _fooho_barbar_aanne._sctp.ext.example >=20 > Application designers who want to make use of this scheme need to > precisely document the values supported and refer > normatively to this section. Any such specification SHOULD indicate= > a mandatory-to-implement default form of the service that will be > represented by the Standard Service Label for this service, per > Section 4. This allows for an easy fallback strategy for clients of= > such service that are not interested in particular variants of the > service, or when the service variant preferred by the client is not > offered at a particular Service Domain and hence not represented by > an SRV record in the DNS. > Absent such application-specific documentation, always the Standard > Service Labels specified in Section 4 are used. >=20 > A.3. Applicability >=20 > Each application/service making use of this mechanism inherits from > its registered Service Name a distinct namespace, and its designers > must manage this 'private' namespace of valid Extended Service Label= s > according to their needs. For instance, there is no central IANA > registry for such namespaces. The application is still identified b= y > its Service Name, and the related leading standard Service Label par= t > is to be used for policy decisions. >=20 > If the service qualifiers are used to indicate intermediate layers, > the application-specific service discovery specification SHOULD > specify that the qualifiers be given in protocol stacking order; if > substrate protocols used have their own registered Service Name, it >=20 >=20 >=20 > Gudmundsson & Hoenes Expires July 1, 2010 [Page 16= ] > =0C > Internet-Draft SRV Prefix Clarifications December 200= 9 >=20 >=20 > is strongly RECOMMENDED that these Service Names be used to identify= > the corresponding qualifiers. >=20 > The companion document [TBD] contains examples of legacy use cases > specified in the IETF that preferably should migrate to this scheme > and thereby, it instantiates these recommendations. >=20 >=20 > Authors' Addresses >=20 > Olafur Gudmundsson > Shinkuro Inc. > 4922 Fairmont Avenue, Suite 250 > Bethesda, MD 20814 > USA >=20 > Email: ogud@ogud.com >=20 >=20 > Alfred Hoenes > TR-Sys > Gerlinger Str. 12 > Ditzingen D-71254 > Germany >=20 > Email: ah@TR-Sys.de >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Gudmundsson & Hoenes Expires July 1, 2010 [Page 17= ] > =0C --------------enig784C8AD06B03EE4661588AE2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAktt8S0ACgkQE5f5cImnZrtPvQCg9m+BaST1GZAuSOv5g8BWBMr3 09cAoP1IUUU/9KgmYws7eeEkOIr6ETsZ =4kw4 -----END PGP SIGNATURE----- --------------enig784C8AD06B03EE4661588AE2-- From mnot@mnot.net Sun Feb 7 22:13:29 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A331E3A6809 for ; Sun, 7 Feb 2010 22:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.087 X-Spam-Level: X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[AWL=-2.347, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8g9fD0qFSEc for ; Sun, 7 Feb 2010 22:13:27 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 19D683A68E9 for ; Sun, 7 Feb 2010 22:13:26 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.26.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 609DD22E1EB; Mon, 8 Feb 2010 01:14:19 -0500 (EST) Subject: Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B6C0E00.8080405@gmx.de> Date: Mon, 8 Feb 2010 17:14:11 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <86A801C9-1195-4ABE-9F49-A452993A78A0@mnot.net> References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B58574B.4050204@gmx.de> <4B596B30.1030400@gmx.de> <3FB0E494-EE9C-46F8-A924-2768C730763A@mnot.net> <1C573F35-D767-4219-BF65-2E28A0C0205D@gbiv.com> <4B6C0E00.8080405@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , "Roy T. Fielding" , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 06:13:30 -0000 On 05/02/2010, at 11:24 PM, Julian Reschke wrote: >=20 > HTML5 doesn't have rev anymore anyway (well, unless the WG changes = this again) >=20 > So why don't we just say that "rev" means what HTML2 used to say, and = be done with it? Because (IMO) implementation experience has shown that rev=3D is = horribly confusing* to developers, and will cause more problems than it = solves; it's much better to just register a different relation (even if = that does offend those who like tidiness).=20 I'd be OK with putting it in the BNF, giving the HTML2 explanation, and = deprecating it in prose, though.=20 * For those who dispute this, have a look at blog and other discussions = of rev=3Dcanonical; it tripped up a lot of people. -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Mon Feb 8 00:23:24 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8AF3A72D3 for ; Mon, 8 Feb 2010 00:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=-0.887, 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 dn0IOzKdOgpV for ; Mon, 8 Feb 2010 00:23:23 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CDA3F3A72D0 for ; Mon, 8 Feb 2010 00:23:22 -0800 (PST) Received: (qmail invoked by alias); 08 Feb 2010 08:24:22 -0000 Received: from p508FE62C.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.230.44] by mail.gmx.net (mp053) with SMTP; 08 Feb 2010 09:24:22 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/rGZofDcjr0TdK2ALHqRJPgPM0MuW6eWxhilGk2x alHOH7z2ZxkunO Message-ID: <4B6FCA33.9050600@gmx.de> Date: Mon, 08 Feb 2010 09:24:19 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Mark Nottingham Subject: Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B58574B.4050204@gmx.de> <4B596B30.1030400@gmx.de> <3FB0E494-EE9C-46F8-A924-2768C730763A@mnot.net> <1C573F35-D767-4219-BF65-2E28A0C0205D@gbiv.com> <4B6C0E00.8080405@gmx.de> <86A801C9-1195-4ABE-9F49-A452993A78A0@mnot.net> In-Reply-To: <86A801C9-1195-4ABE-9F49-A452993A78A0@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.62 Cc: Apps Discuss , "Roy T. Fielding" , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 08:23:24 -0000 Mark Nottingham wrote: > > On 05/02/2010, at 11:24 PM, Julian Reschke wrote: >> HTML5 doesn't have rev anymore anyway (well, unless the WG changes this again) >> >> So why don't we just say that "rev" means what HTML2 used to say, and be done with it? > > Because (IMO) implementation experience has shown that rev= is horribly confusing* to developers, and will cause more problems than it solves; it's much better to just register a different relation (even if that does offend those who like tidiness). > > I'd be OK with putting it in the BNF, giving the HTML2 explanation, and deprecating it in prose, though. > ... That sounds good to me. Best regards, Julian From julian.reschke@gmx.de Mon Feb 8 06:50:07 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E402E3A73F3 for ; Mon, 8 Feb 2010 06:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.783 X-Spam-Level: X-Spam-Status: No, score=-4.783 tagged_above=-999 required=5 tests=[AWL=-2.184, 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 G8+dwElZZ0Y9 for ; Mon, 8 Feb 2010 06:50:06 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 28F133A73F8 for ; Mon, 8 Feb 2010 06:50:05 -0800 (PST) Received: (qmail invoked by alias); 08 Feb 2010 14:51:07 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp067) with SMTP; 08 Feb 2010 15:51:07 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19Oc85ltgpO1zl4fQh79XOnfqg/RHi/8e4mKVeMzB X4KU/P1ayngo9x Message-ID: <4B7024D9.5010809@gmx.de> Date: Mon, 08 Feb 2010 15:51:05 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: IETF Apps Discuss , HTTP Working Group Subject: FWD: I-D Action:draft-reschke-rfc2231-in-http-09.txt References: <20100208144502.5069E3A71D4@core3.amsl.com> In-Reply-To: <20100208144502.5069E3A71D4@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.56999999999999995 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 14:50:08 -0000 Hi, this draft addresses two issues that were brought up last week: - there was a bug in the ABNF for (extended) attribute values, disallowing certain characters that should have been allowed, and allowing one character that shouldn't have been allowed - it points out that "token" in HTTP and MIME are different in a subtle way, and clarifies that it's really using the HTTP token production Best regards, Julian Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Application of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP) Header Fields > Author(s) : J. Reschke > Filename : draft-reschke-rfc2231-in-http-09.txt > Pages : 14 > Date : 2010-02-08 > > By default, message header field parameters in Hypertext Transfer > Protocol (HTTP) messages can not carry characters outside the ISO- > 8859-1 character set. RFC 2231 defines an escaping mechanism for use > in Multipurpose Internet Mail Extensions (MIME) headers. This > document specifies a profile of that encoding suitable for use in > HTTP header fields. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-reschke-rfc2231-in-http-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From A.Hoenes@TR-Sys.de Sun Feb 14 17:27:47 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9BEB3A7A7B; Sun, 14 Feb 2010 17:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.849 X-Spam-Level: X-Spam-Status: No, score=0.849 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6W99mvRcNDD; Sun, 14 Feb 2010 17:27:46 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 341B93A7A79; Sun, 14 Feb 2010 17:27:44 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA106697336; Mon, 15 Feb 2010 02:28:56 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id CAA13369; Mon, 15 Feb 2010 02:28:54 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201002150128.CAA13369@TR-Sys.de> Subject: Re: [tsvwg] [port-srv-reg] "assigned" (vs. "registered"), and relates issues To: touch@ISI.EDU Date: Mon, 15 Feb 2010 02:28:53 +0100 (MEZ) In-Reply-To: <4B6DCE46.1030501@isi.edu> from Joe Touch at Feb "6, " 2010 "12:17:10" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: tsvwg@ietf.org, apps-discuss@ietf.org, port-srv-reg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 01:27:48 -0000 > Hi, Alfred, > > Taking this up a level to summarize. there are two points. Let me know > if this is consistent with your understanding... > > Joe Joe, as already mentioned in an intermediate short note, I apologize for having run out of time and the resulting delay for my response. > ------ > #1 -- I think (correct me if wrong) that you want service names without > assigned port numbers, to be registered only for specific protocols. Yes. I'm not aware of the evolution of your intent to enter a substantial set of names into the registry that are not related to specific applications/services run over the IETF transports covered by the registry -- e.g. the lot of 'garbage' from the legacy RFC 952 registry, "Protocol and Service Names") including some of the names. If it is still intended to file these names in the registry as well, these, and only these, blocking/name-grabbing entries should be unrelated to any transport. To recall, I would very much appreciate _not_ mixing different name spaces in this manner. Protocol names should only appear in the IANA Protocol Numbers registry. Having a rule at layer 8 for IANA to not admit protocol names as service names would be fine from my point of view, but showing these in the registry will inevitably cause more confusion and make the presentation of the Service Names & Port Numbers registry more complicated than necessary. > > For services with assigned port numbers, we assign a triple: > > namestring transport portnum > > There's no one index to that triple. The index is the > pair, i.e.: > > namestring,transport -> unique portnum > > For services, I can see why we would assign > (or, in this case, register): > > namestring transport Yes, the IANA database might contain (for clarity) a special symbol for {no default port assigned}, say "-none-" , giving the mapping namestring,transport -> "-none-" I also have asked several times (without getting an answer so far) whether it would be technically possible for IANA in an easy manner to present on their web site different 'views' (in database terminology) on the data set of the registry, in particular one sorted by service name and transport protocol (the "index pair" you indicated above), and one (inverted) view sorted by port number. Both views would be very valuable for different purposes, e.g. for looking for a 'cool' new service name not already present in the registry, and for picking preferred port numbers for new registrations. What is the state of the art here? > > ------ > #2 -- There's an interesting question of 'who gets to add transport > protocols to a service that exists', regardless of whether the service > has a port or not. > > I think IANA can handle that as it happens. I had been assuming that > ownership of that was done at the time the service name was assigned, > but that clearly needs potential override for abandoned services, e.g. Yes, that seems reasonable at first glance. (And this question again reinforces that it is wise to deal with services with and without default port numbers in the same manner, as far as possible, both by the nature of the 'service' concept, and for savings in rule sets, exceptions, and bureaucracy.) Preferably, such new entry should be supported by documentation, from which it needs to be unambiguously clear that the request relates to the same service/application as the original registration. For now, the new rules _reserve_ {service, transport} pairs for all (current and future) transport protocols not mentioned in the primary request to IANA for a given , isn't it? And the rules specify that the service name shall _identify_ the application; hence adding new transports later should require evidence that the new request to IANA indeed is for the same application, or otherwise these premises could not be maintained. If the original owner is no longer reachable and did not actively transfer ownership of the registration, the evidence needs to be provided by the documentation -- preferably an additional Ref. to be added to the registry entry, or a replacement Ref. in case of a revised specification that covers the previous transports (already registered for the application) and also defines the additional transport(s) for the application, for which registration is sought. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From alexey.melnikov@isode.com Wed Feb 17 10:49:47 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A33228C1AF for ; Wed, 17 Feb 2010 10:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 lyOcWAuu3gnT for ; Wed, 17 Feb 2010 10:49:46 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2C18228C1A9 for ; Wed, 17 Feb 2010 10:49:46 -0800 (PST) Received: from [172.16.2.170] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 17 Feb 2010 18:51:24 +0000 Message-ID: <4B7C3A89.6070505@isode.com> Date: Wed, 17 Feb 2010 18:50:49 +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: Apps Discuss Subject: Alexey's Apps Area Activity Report for November 2009-mid February 2010 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: alexey-melnikov-chairs@tools.ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 18:49:47 -0000 Approved the following BOFs in Anaheim: - NewPrep (updates to StringPrep and its profiles) - IRDE (Internet Registration Escrow) - DECADE - I hope this will become a WG before Anaheim. Document Status and Progress: Active documents, my action: - draft-ietf-tsvwg-iana-ports (BCP) - need to re-review - draft-gudmundsson-dns-srv-iana-registry - need to re-review - draft-reschke-rfc2231-in-http (Proposed Standard) - need to do AD review Active documents in IETF LC or IESG review: - draft-allbery-afs-srv-records (Proposed Standard) - in IESG review - draft-gould-rfc4310bis (Proposed Standard) - in IESG review (the following telechat) - draft-ietf-vcarddav-carddav (Proposed Standard) - past IESG review, waiting for draft-ietf-tsvwg-iana-ports to be done In RFC Editor's queue: draft-dusseault-http-patch (Proposed Standard) draft-ietf-eai-downgraded-display (Experimental) draft-ietf-eai-imap-utf8 (Experimental) - in AUTH48 draft-ietf-eai-pop (Experimental) - in AUTH48 draft-ietf-webdav-bind (Experimental) draft-klensin-ftp-registry (Proposed Standard) draft-reschke-rfc2731bis (Informational) draft-roach-sip-http-subscribe (Proposed Standard) Published as RFCs: - draft-ietf-vcarddav-webdav-mkcol (Proposed Standard) - RFC 5689 - RFC 3848 progressed to Draft Standard Active documents, waiting on others: - draft-cridland-acap-vendor-registry (Proposed Standard) - New revision needed. - draft-duerst-mailto-bis - IETF LC ended, need a new revision - draft-denenberg-mods-etc-media-types (Proposed Standard) - New revision needed. - draft-desruisseaux-caldav-sched (Proposed Standard) - performed AD review, new revision needed - draft-hethmon-mcmurray-ftp-hosts (Proposed Standard) - performed AD review, new revision needed draft-zeilenga-ldap-dontusecopy (Proposed Standard) - performed AD review, new revision needed - draft-daboo-srv-email (Proposed Standard) - waiting for draft-saintandre-tls-server-id-check to be updated before progressing this document - draft-dawkins-ldapext-subnot - performed informal review - draft-burnett-pronunciation-alphabet-registry (None) - waiting for authors to address comments from a Language Tag expert reviewer (Doug Ewell) - draft-ietf-eai-mailinglist (Experimental) - waiting for updated draft and write-up before initiating IETF LC List of DISCUSSes I am currently holding: Old: draft-ietf-sip-certs-09.txt draft-ietf-dime-diameter-qos-13.txt draft-ietf-mmusic-connectivity-precon-06.txt draft-ietf-sipping-rtcp-summary-08.txt draft-moriarty-post-inch-rid-10.txt draft-ietf-pkix-new-asn1-07.txt draft-drage-sipping-service-identification-03.txt draft-mraihi-inch-thraud-09.txt New or recently updated (last 3 weeks): draft-gennai-smime-cnipa-pec-05.txt draft-bryan-metalink-28.txt draft-josefsson-kerberos5-starttls-08.txt New as of this week: draft-ietf-geopriv-lis-discovery-13.txt draft-ietf-geopriv-geo-uri-04.txt draft-ietf-dhc-dhcpv4-vendor-message-01.txt draft-ietf-dhc-dhcpv6-vendor-message-01.txt Cleared DISCUSSes: draft-ietf-bfd-base draft-ietf-ntp-ntpv4-proto draft-wilde-sms-uri draft-ietf-ospf-manet-or draft-housley-tls-authz-extns draft-ietf-nea-pa-tnc draft-ietf-nea-pb-tnc draft-ietf-mmusic-sdp-capability-negotiation draft-ietf-netconf-partial-lock draft-ietf-calsify-2446bis draft-peterson-rai-rfc3427bis draft-ietf-avt-rtcpssm draft-ietf-ipfix-export-per-sctp-stream draft-ietf-ntp-dhcpv6-ntp-opt draft-ietf-mip4-generic-notification-message draft-ietf-pkix-ta-format Other activities/actions: Done: - IRI and MARF WG were charted - LTRU and Lemonade WG were closed - Finished writing response to YAM pre-evaluation of 1652bis, after various discussions with the YAM WG and IESG - Reviewed application/3gpp-ims+xml MIME type registration for IESG - Reviewed some MIME type registration from W3C (I don't remember which now) - draft-ietf-sasl-scram (my own document) in RFC Editor's queue - draft-melnikov-sasl-scram-ldap (my own document) in RFC Editor's queue - draft-melnikov-imap-keywords (my own document) in RFC Editor's queue - SASL GS2 approved for publication (acting as a document shepherd, not as the responsible AD) - draft-sharikov-idn-reg - performed review for independent submission to RFC Editor Ongoing: - Discussing BOFs for Anaheim (NewPrep (updates to StringPrep and its profiles), IRDE (Internet Registration Escrow), DECADE) - Need to finish iMIP draft [ietf-calsify-rfc2447bis] (my own document) My action: - Need to review OAuth document regarding possible reuse of SCRAM - Need to post 4954bis (SMTP AUTH) in order to start moving it to Draft Standard - draft-ietf-sieve-external-lists (my own document) - needs updating. Thanks to Barry Leiba for picking this up. Waiting for others: - Suggestion to move LMTP to Standard Track (Ned Freed agreed to update the document, then responded that John Myers is interested to do this himself. Chris Newman agreed to shepherd it) - Suggestion to convert MIME BNF to ABNF and publish as a separate draft (Ned Freed agreed to do this) WG Status: 1) EAI - Resolved IESG issues with Downgraded display document with help from Barry Leiba. WGLC on EAI mailing list document ended. Lots of discussions about what to do with downgrade document when moving to Standards Track/discussions about rechartering. 2) VWRAP - authors working on updated drafts, all of them are individual submissions for now. 3) YAM - Dave Crocker updated 1652bis preevaluation document, updated 1652bis based on IESG pre-evaluation. WGLC on 5321bis pre-evaluation document. Some side discussions about use of DNS SRV records for email. 4) MORG - SORTDISPLAY in WGLC in December. Losts of discussions about multimailbox search, XLIST (Gmail's extension) and other documents recently. 5) VCARDDAV - vCardDAV document is effectively done, but it is blocked on DNS Ports and Service's registry document (draft-ietf-tsvwg-iana-ports). Some discussions on use of geo: URIs, non-gregorian dates, etc. From alexey.melnikov@isode.com Wed Feb 17 11:05:25 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72853A7D93 for ; Wed, 17 Feb 2010 11:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 rlKhZnekjwAc for ; Wed, 17 Feb 2010 11:05:24 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BA3903A7D8D for ; Wed, 17 Feb 2010 11:05:24 -0800 (PST) Received: from [172.16.2.170] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 17 Feb 2010 19:07:03 +0000 Message-ID: <4B7C3E36.7040708@isode.com> Date: Wed, 17 Feb 2010 19:06:30 +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: Apps Discuss Subject: Re: Alexey's Apps Area Activity Report for November 2009-mid February 2010 References: <4B7C3A89.6070505@isode.com> In-Reply-To: <4B7C3A89.6070505@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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, 17 Feb 2010 19:05:25 -0000 Alexey Melnikov wrote: > List of DISCUSSes I am currently holding: > Old: > draft-ietf-sip-certs-09.txt > draft-ietf-dime-diameter-qos-13.txt > draft-ietf-mmusic-connectivity-precon-06.txt > draft-ietf-sipping-rtcp-summary-08.txt > draft-moriarty-post-inch-rid-10.txt > draft-ietf-pkix-new-asn1-07.txt Actually this is relatively new, my appologies for mis-classification. > draft-drage-sipping-service-identification-03.txt > draft-mraihi-inch-thraud-09.txt From touch@ISI.EDU Wed Feb 17 20:16:58 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414BE28C2A4; Wed, 17 Feb 2010 20:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMSGzdCS6pxm; Wed, 17 Feb 2010 20:16:57 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0EBFE28C2BB; Wed, 17 Feb 2010 20:16:57 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o1I4Hsp3023815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Feb 2010 20:17:57 -0800 (PST) Message-ID: <4B7CBF72.3040209@isi.edu> Date: Wed, 17 Feb 2010 20:17:54 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= Subject: Re: [tsvwg] [port-srv-reg] "assigned" (vs. "registered"), and relates issues References: <201002150128.CAA13369@TR-Sys.de> In-Reply-To: <201002150128.CAA13369@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig69FE17B3D770C6D236610714" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org, apps-discuss@ietf.org, port-srv-reg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 04:16:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig69FE17B3D770C6D236610714 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Alfred, Alfred =EF=BF=BD wrote: >> Hi, Alfred, >> >> Taking this up a level to summarize. there are two points. Let me know= >> if this is consistent with your understanding... >> >> Joe >=20 > Joe, > as already mentioned in an intermediate short note, I apologize for > having run out of time and the resulting delay for my response. >=20 >=20 >> ------ >> #1 -- I think (correct me if wrong) that you want service names withou= t >> assigned port numbers, to be registered only for specific protocols. >=20 > Yes. >=20 >=20 > I'm not aware of the evolution of your intent to enter a substantial > set of names into the registry that are not related to specific > applications/services run over the IETF transports covered by the > registry -- e.g. the lot of 'garbage' from the legacy RFC 952 registry,= > "Protocol and Service Names") including some of the names. I don't understand the reference to RFC 952 in this context. Even in that RFC, all examples give the service name with its corresponding transport. > If it is still intended to file these names in the registry as well, > these, and only these, blocking/name-grabbing entries should be > unrelated to any transport. Can you give an example, or point to the list? > To recall, I would very much appreciate _not_ mixing different > name spaces in this manner. Protocol names should only appear > in the IANA Protocol Numbers registry. Having a rule at layer 8 > for IANA to not admit protocol names as service names would be fine > from my point of view, but showing these in the registry will > inevitably cause more confusion and make the presentation of the > Service Names & Port Numbers registry more complicated than necessary. I think I understand your goal, which is to avoid entries like: HTTP it should always be: HTTP SCTP 80 HTTP TCP 80 when, e.g., we define a new transport (ANEWTP), we would then need to decide how it affects the existing tables. One view would be "enter only for protocols as defined". Another might be "enter anywhere TCP exists", i.e., to create the following entry: HTTP ANEWTP 80 We can do this at "layer 8" as you suggest. >> For services with assigned port numbers, we assign a triple: >> >> namestring transport portnum >> >> There's no one index to that triple. The index is the >> pair, i.e.: >> >> namestring,transport -> unique portnum >> >> For services, I can see why we would assign >> (or, in this case, register): >> >> namestring transport >=20 > Yes, the IANA database might contain (for clarity) a special symbol > for {no default port assigned}, say "-none-" , > giving the mapping > namestring,transport -> "-none-" OK with me (I don't think I debated this). > I also have asked several times (without getting an answer so far) > whether it would be technically possible for IANA in an easy manner to > present on their web site different 'views' (in database terminology) > on the data set of the registry, in particular one sorted by service > name and transport protocol (the "index pair" you indicated above), > and one (inverted) view sorted by port number. Both views would be > very valuable for different purposes, e.g. for looking for a 'cool' > new service name not already present in the registry, and for picking > preferred port numbers for new registrations. >=20 > What is the state of the art here? I think we did ask for this. It's fairly easy to spit out a table that lets you sort on any individual column, but I'm not sure how easy it is to sort on "pairs" of columns. >> ------ >> #2 -- There's an interesting question of 'who gets to add transport >> protocols to a service that exists', regardless of whether the service= >> has a port or not. >> >> I think IANA can handle that as it happens. I had been assuming that >> ownership of that was done at the time the service name was assigned, >> but that clearly needs potential override for abandoned services, e.g.= >=20 > Yes, that seems reasonable at first glance. >=20 > (And this question again reinforces that it is wise to deal with > services with and without default port numbers in the same manner, > as far as possible, both by the nature of the 'service' concept, > and for savings in rule sets, exceptions, and bureaucracy.) >=20 > Preferably, such new entry should be supported by documentation, > from which it needs to be unambiguously clear that the request > relates to the same service/application as the original registration. That need not be the case when defining a transport that provides a superset of the capabilities of an existing transport. In that case, it may be desirable, as above, to say "add everywhere TCP exists", or somesuch. SCTP should, e.g., be sufficient to support any TCP service, and DCCP should be sufficient to support any UDP service, both by design.= > For now, the new rules _reserve_ {service, transport} pairs for all > (current and future) transport protocols not mentioned in the primary > request to IANA for a given , isn't it? I don't think we mention that explicitly. We do hold the {transport, number} pair for all other transports not assigned, and we already expect that we would assign those other pairs only for the owner of the initial pair. As above, I think this is already something we can trust IANA to handle at Layer 8, and not necessarily codify explicitly. > And the rules specify that the service name shall _identify_ the > application; hence adding new transports later should require evidence > that the new request to IANA indeed is for the same application, > or otherwise these premises could not be maintained. Technically, the {name, transport} pair identifies the application; there are plenty of apps for which the UDP service is owned by, but does not match the TCP service. We've been discouraging that in recent registrations, though. > If the original owner is no longer reachable and did not actively > transfer ownership of the registration, the evidence needs to be > provided by the documentation -- preferably an additional Ref. to be > added to the registry entry, or a replacement Ref. in case of a > revised specification that covers the previous transports (already > registered for the application) and also defines the additional > transport(s) for the application, for which registration is sought. Agreed, but I think as above that this can be trusted to IANA's oversight= =2E Joe --------------enig69FE17B3D770C6D236610714 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkt8v3IACgkQE5f5cImnZruHzgCg8JzAkG0o/qFN6ddA14xv+Gu3 8TQAoL932RIb4OTDC06o49joubbSjB/X =z1mN -----END PGP SIGNATURE----- --------------enig69FE17B3D770C6D236610714-- From A.Hoenes@TR-Sys.de Thu Feb 18 17:42:26 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9E2328C19B; Thu, 18 Feb 2010 17:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.243 X-Spam-Level: X-Spam-Status: No, score=0.243 tagged_above=-999 required=5 tests=[AWL=0.992, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, GB_I_LETTER=-2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Emd+swPrJtHS; Thu, 18 Feb 2010 17:42:24 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id B6D0628C188; Thu, 18 Feb 2010 17:42:21 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA138783825; Fri, 19 Feb 2010 02:43:45 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id CAA21850; Fri, 19 Feb 2010 02:43:44 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201002190143.CAA21850@TR-Sys.de> Subject: Re: [tsvwg] [port-srv-reg] "assigned" (vs. "registered"), and relates issues To: touch@ISI.EDU Date: Fri, 19 Feb 2010 02:43:44 +0100 (MEZ) In-Reply-To: <4B7CBF72.3040209@isi.edu> from Joe Touch at Feb "17, " 2010 "08:17:54" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, apps-discuss@ietf.org, port-srv-reg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 01:42:26 -0000 Joe, thanks again for your feedback. Responses inline. [Joe] >>> ------ >>> #1 -- I think (correct me if wrong) that you want service names without >>> assigned port numbers, to be registered only for specific protocols. >> [AH] >> Yes. >> >> >> I'm not aware of the evolution of your intent to enter a substantial >> set of names into the registry that are not related to specific >> applications/services run over the IETF transports covered by the >> registry -- e.g. the lot of 'garbage' from the legacy RFC 952 registry, >> "Protocol and Service Names") including some of the names. > [Joe] > I don't understand the reference to RFC 952 in this context. Even in > that RFC, all examples give the service name with its corresponding > transport. I'll try to recollect the essential points from previous message exchanges, supplying every detail related to the RFC952/WKS registry. I once had complained about inappropriate new registrations carried out in the WKS registry. In his response, on Wed, 11 Nov 2009 13:02:41 +0900, Lars Eggert wrote (to the full distribution list): |> I assume you're referring to |> http://www.iana.org/assignments/service-names here. |> ... |> We're referring to it as a source |> of grandfathered service names, and our ID actually asks IANA to |> determine if that registry can be retired after that has happened |> (Section 10). |> |> The reason we do this is that some of these may actually still be in |> use somewhere, and hence should not be available for new registrations. That registry says, in its heading: | Registry Name: Protocol And Service Names | Reference: [RFC952] | Registration Procedures: Not defined | | Note: | These are the Official Protocol Names as they appear in the Domain | Name System WKS records and the NIC Host Table. Their use is | described in [RFC952]. | | A protocol or service may be up to 40 characters taken from the set | of uppercase letters, digits, and the punctuation character hyphen. | It must start with a letter, and end with a letter or digit. [ You might note the *40* character limit there! ] The *BIG* trouble is that the WKS records per STD 13 do not carry the same content as the legacy Host Table. So the initial flaw was maintaining a shared registry of keywords for both purposes when the DNS got traction and the WKS RR was invented to carry the Well-known Service (port) bitmap for each host -- with much collateral damage (see below). The Full STD 13 refers to the registry, so it cannot be deprecated easily. We might Update STD 13 and fully deprecate the WKS record type in DNSEXT, but the WG is not interested very much in such work currently, as it has more important work items. In my response on Wed, 11 Nov 2009 12:19:51 +0100 (MEZ), I explained: |> These services are represented by the mnemonics in the registry |> in the presentation (zone/master file) format of WKS RRs and by a |> bit map in the WKS RR binary / on-the-wire format, and in practice, |> the translation is built in into DNS server implementations. An in response to a related note (regarding the new entries there) from Magnus Westerlund, I wrote on Wed, 11 Nov 2009 12:36:25 +0100 (MEZ), |>> The only registry that can be interpreted as being the service name |>> in RFC 1700 is the registry that currently are in: |>> http://www.iana.org/assignments/service-names |> |> That reasoning has been 100% correct at the time of publication |> of RFC 1700, because it predates NAPTR and SRV by years. |> |> ... |> |> It is not expected that DNS server software will adopt these |> registrations because it would blow up the bit map in WKS to |> unreasonable size, that was intended for "Well-Known" services |> (ports 0..255 at the time of RFC 1035). Therefore I question |> the utility of performing this registration. Subsequently, I had clarified a misconception about SRV RRs vs. WKS RRs (mail exchange on Nov 12, omitted most parts here for brevity). |> WKS had been created in the effort to migrate the data from the |> ARPANET "NIC Host Table" into the DNS and thereby separating address |> info from Well-Known Service info. |> (BSD created the /etc/hosts file that did not contain the list of |> WKSes for all listed hosts any more, and /etc/services listing the |> service_name-to-port mappings for locally "interesting" services -- |> no more per-known-host offered WKS lists; that information was fed |> into the DNS via the WKS RR.) |> |> It looks like you also got caught in one of the temptive traps |> awaiting visitors of the IANA site, with so many registries having |> titles making it hard to guess correctly at first glance what they |> are good for. |> |> ... |> |> ..., a domain server conforming to RFC 1035 needs to be able to |> read zone (master) files containing WKS records in the presentation |> form and to translate the keywords (commonly uppercase-only) into |> bit positions. Whenever a secondary authoritative server transfers |> a zone copy from a prmary server, it needs to translate from |> on-the-wire format to presentation format to store the zone content |> into a local file that can be used to reload the zone after a server |> restert. |> Given the infrastructure nature of the DNS and the underspecified |> syntax of the IANA registry file making it rather unsuitable for |> automated lookup, online lookup of the registry whenever a DNS |> server starts up or updates a zone file does not make sense. |> That's why in many DNS server implementations the WKS table is |> hardcoded or loaded from a file shipped by the vendor and rarely |> updated in deployments. Later on, it has been confirmed to us that your intent was to import the whole content of the service-names registry into the new Service Names and Port Numbers registry. Therefore, I performed a detailed analysis of the content of that registry, and distributed a message to the iana-ports authors list at Thu, 19 Nov 2009 21:48:34 +0100 (MEZ). The body of that message said, and that should answer some of your questions below ... -------- begin of original message -------- Folks, I have taken a more detailed look at the legacy IANA "service-names" registry that indicates in its preamble that it is based on RFC 952 and shall be used for DNS WKS records and the (historic) "NIC Host Table". Currently, it has 168 entries, and it's a mess. It apparently mixes identifiers at various layers without notice. Thus, it is not appropriate to mix "all" in. I strongly recommend against importing from it, with only a few exceptions. a) Many entries already exactly correspond to entries in the Port# registry -- up to the case used for the service name. I have identified 71 such entries (including the provisional entries for TURN / TURNS) that would not add new information. b) Since that registry originates from RFC 952, it also contains a lot of entries corresponding to entries in the *protocol-numbers* registry; these do not make sense for the remaining purpose of the registry indicated in the heading (WKS RRs), and also do not belong into the "Service over Transport over IP" registry. I have identified 45 such entries. c) The 3 entries for IEEE Mobility services (MIH*) do not make sense there, as already explained, since they do not correspond to assigned port numbers, but these should become registered service names, according to RFC-to-be 5679. d) Several entries are for "IP over ", for PPP and SLIP, protocols over IEEE 802.2 like ARP, and even for one IP option and one TCP option. There's also an entry for the historical DCNET (ICS over ICMP or GGP, RFC 778). The ~20 entries I found in this category do not make sense in any "Service over Transport over IP" registry. e) There are also a few entries that seem to identify mere data formats and hence do not belong in any such registry. I have counted 5 such entries. f) There are a couple of entries that might be candidates to add alias service names, e.g. "RIP" for "route", "LOC-SRV" for "srvloc", "MAIL" for "smtp", "PCMAIL" for "pcmail-srv", "SUN-RPC" for "sunrpc", "USERS" for "systat". A few similar entries are ambiguous, because the underlying service has multiple ports registered; it might be useful to take these names as aliases for the corresponding server-port (indeed, some legacy protocols have client ports registered), if there's a unique choice, e.g. "BOOTP" for "bootps". The striking ambiguous cases are "NETRJS" and "FCONFIG". However, the former seems to be far OBE, and the latter seems to be represented to sufficient detail in the present port number registry. g) Roughly a dozen entries seem to refer to very historical protocols -- some of which apparently specific for the historical ARPANET --, and hence not worth being added into a modern registry, e.g. "NETED" (RFC 569). My overall recommendation, without having performed more detailed investigations on historical protocols, is to only import the few potential alias names explicitly mentioned in f) above. -------- end of original message -------- Since you asked for more examples: for e) look at "MIB" and "SMI" and entries with "Format" in the Description; for g), "LDP" is another example (not the modern one, "Loader Debugger Protocol"!). >From this classification, it should be clear that importing names from the RFC 952 / WKS registry into the new registry should be done with extreme care. *Most* of the (non-duplicate) keywords there do *not* correspond to some "service over IETF transport". The only arguments that could be given were to prohibit services to be registered with such names, and to register a few non-canonical alias names for legacy services. Any user of the new registry should be able at first glance to distinguish such pseudo entries from 'workable' entries. Section 5 of your draft contains rules for service name aliases including the requirement to designate a primary name and to mark aliases in the registry. > >> If it is still intended to file these names in the registry as well, >> these, and only these, blocking/name-grabbing entries should be >> unrelated to any transport. > > Can you give an example, or point to the list? As an example from above, take SLIP. That's a "layer 2" to run IP over. It has never been a "Protocol" (from the Protocol Numbers registry) nor a service over some transport over IP. "SlIP" would have made some limited sense in the Host Table (for human readers), but has not been usable for WKS. If (an only if) you really want to have an entry for SLIP, it MUST NOT be associated with any transport protocol nor a port number. That should be evident. > >> To recall, I would very much appreciate _not_ mixing different >> name spaces in this manner. Protocol names should only appear >> in the IANA Protocol Numbers registry. Having a rule at layer 8 >> for IANA to not admit protocol names as service names would be fine >> from my point of view, but showing these in the registry will >> inevitably cause more confusion and make the presentation of the >> Service Names & Port Numbers registry more complicated than necessary. > > I think I understand your goal, which is to avoid entries like: > > HTTP > > it should always be: > > HTTP SCTP 80 > HTTP TCP 80 > > when, e.g., we define a new transport (ANEWTP), we would then need to > decide how it affects the existing tables. One view would be "enter only > for protocols as defined". Another might be "enter anywhere TCP exists", > i.e., to create the following entry: > > HTTP ANEWTP 80 > > We can do this at "layer 8" as you suggest. I see a mismatch between your arguments and your draft text; there is (almost) no "layer 8" needed: The Introduction of draft-ietf-tsvwg-iana-ports-04 says: | This document brings the IANA procedures for TCP and UDP in line with | those for SCTP and DCCP, resulting in a single process that | requesters and IANA follow for all requests for all transport | protocols, including those not yet defined. | | [...] | | [...] Section 8 discusses the specifics of these | procedures and processes that requesters and IANA follow for all | requests for all current and future transport protocols. Section 7.2 "Updated Principles" mentions: | IANA will begin assigning protocol numbers for only those transport | protocols explicitly included in a registration request. This ends | the long-standing practice of automatically assigning a port number | to an application for both TCP and a UDP, even if the request is for | only one of these transport protocols. [...] | | [...] When applications start supporting the use of some of | those additional transport protocols, their implementors MUST request | IANA to convert the reservation into an assignment. [...] Hence, the rules are in place, and I conclude that the only decision to be made at introduction of ANEWTP were to open the registry for this new transport protocol, and new specifications and registration requests could start to introduce new entrise of the latter kind into the registry. I have omitted the additional rules for port number assignment that are spelled out in the draft in a manner consistent with the above rules. [ BTW: looking for "transport"/"protocol", I found that the draft repeatedly uses "protocol number[s]" or even "address[es]" where it should say "port number[s]" -- ex: see the text quoted above. ] > >>> For services with assigned port numbers, we assign a triple: >>> >>> namestring transport portnum >>> >>> There's no one index to that triple. The index is the >>> pair, i.e.: >>> >>> namestring,transport -> unique portnum >>> >>> For services, I can see why we would assign >>> (or, in this case, register): >>> >>> namestring transport >> >> Yes, the IANA database might contain (for clarity) a special symbol >> for {no default port assigned}, say "-none-" , >> giving the mapping >> namestring,transport -> "-none-" > > OK with me (I don't think I debated this). Well, the information must be stored somehow, and visually presented on the IANA site. This was a suggestion that avoids whitespace, which might be of some benefit for human readers and automatic tools (that will be invented, I'm sure) to operate on the registry content. > >> I also have asked several times (without getting an answer so far) >> whether it would be technically possible for IANA in an easy manner to >> present on their web site different 'views' (in database terminology) >> on the data set of the registry, in particular one sorted by service >> name and transport protocol (the "index pair" you indicated above), >> and one (inverted) view sorted by port number. Both views would be >> very valuable for different purposes, e.g. for looking for a 'cool' >> new service name not already present in the registry, and for picking >> preferred port numbers for new registrations. >> >> What is the state of the art here? > > I think we did ask for this. It's fairly easy to spit out a table that > lets you sort on any individual column, but I'm not sure how easy it is > to sort on "pairs" of columns. :-) ?? Even decades old UNIX/POSIX `sort` allows multiple sort keys. In this case, I assume IANA will use some type of backend database system, and that will certainly allow similar operations. > >>> ------ >>> #2 -- There's an interesting question of 'who gets to add transport >>> protocols to a service that exists', regardless of whether the service >>> has a port or not. >>> >>> I think IANA can handle that as it happens. I had been assuming that >>> ownership of that was done at the time the service name was assigned, >>> but that clearly needs potential override for abandoned services, e.g. >> >> Yes, that seems reasonable at first glance. >> >> (And this question again reinforces that it is wise to deal with >> services with and without default port numbers in the same manner, >> as far as possible, both by the nature of the 'service' concept, >> and for savings in rule sets, exceptions, and bureaucracy.) >> >> Preferably, such new entry should be supported by documentation, >> from which it needs to be unambiguously clear that the request >> relates to the same service/application as the original registration. > > That need not be the case when defining a transport that provides a > superset of the capabilities of an existing transport. In that case, it > may be desirable, as above, to say "add everywhere TCP exists", or > somesuch. SCTP should, e.g., be sufficient to support any TCP service, > and DCCP should be sufficient to support any UDP service, both by design. Two remarks: o I've never seen an application implementer implementing support of a transport that had not been specified somewhere; thus, it really should be left to registrants to request the addition of new entries. o Should there ever arise the need to indeed perform such exceptional action (with a 100% upwards compatible transport protocol), that will require specific documentation and IESG action anyway. We should not attempt to provide rules that will likely never be needed, or else, if needed for some reason or the other, turn out to be insufficient -- cf. Murphy's Law! > >> For now, the new rules _reserve_ {service, transport} pairs for all >> (current and future) transport protocols not mentioned in the primary >> request to IANA for a given , isn't it? > > I don't think we mention that explicitly. We do hold the {transport, That should be done for clarity. > number} pair for all other transports not assigned, and we already > expect that we would assign those other pairs only for the owner of the > initial pair. > > As above, I think this is already something we can trust IANA to handle > at Layer 8, and not necessarily codify explicitly. Since it would make the rules modular and orthogonal, I don't hesitate to assume that the ruleset will not become more complicated thereby -- to the contrary, it will be easier to understand and implement. > >> And the rules specify that the service name shall _identify_ the >> application; hence adding new transports later should require evidence >> that the new request to IANA indeed is for the same application, >> or otherwise these premises could not be maintained. > > Technically, the {name, transport} pair identifies the application; > there are plenty of apps for which the UDP service is owned by, but > does not match the TCP service. We've been discouraging that in recent > registrations, though. IMO that distinction between service and application is falling short of hair-splitting; there's no need for it in the draft, if you follow your analysis above that the primary key to the registry is the {name, transport} pair. > >> If the original owner is no longer reachable and did not actively >> transfer ownership of the registration, the evidence needs to be >> provided by the documentation -- preferably an additional Ref. to be >> added to the registry entry, or a replacement Ref. in case of a >> revised specification that covers the previous transports (already >> registered for the application) and also defines the additional >> transport(s) for the application, for which registration is sought. > > Agreed, but I think as above that this can be trusted to IANA's > oversight. That is already covered to some degree in the draft, in the snippet from 7.2 quoted above: | [...] When applications start supporting the use of some of | those additional transport protocols, their implementors MUST request | IANA to convert the reservation into an assignment. [...] (Note: this clause would not be compatible with your statement above that I had alluded as "falling short of hair-splitting" -- here you clearly say that an application can start supporting another transport, hence the concept of "application" is not bound to the transport. > > Joe Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From mnot@mnot.net Thu Feb 18 18:02:24 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A79C28C1A6 for ; Thu, 18 Feb 2010 18:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[AWL=-1.302, 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 BXTeWqq2cmaM for ; Thu, 18 Feb 2010 18:02:22 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 7659128C182 for ; Thu, 18 Feb 2010 18:02:22 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.189.113]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9033E509DD; Thu, 18 Feb 2010 21:03:59 -0500 (EST) Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B6C1144.4090502@gmx.de> Date: Fri, 19 Feb 2010 13:03:54 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5C1BFD92-7E8D-4ABF-A986-03ADC50A18CD@mnot.net> References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> <4B596450.7020001@gmx.de> <4B62D875.102@gmx.de> <7B248F44-44D9-4054-84A2-E9C4C5C251E1@mnot.net> <4B6C1144.4090502@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 02:02:24 -0000 OLD: The anchor parameter MUST be ignored by consuming implementations, = unless its use is specified by the application in use. NEW: Links with the anchor parameter MUST be ignored by consuming = implementations, unless its use is specified by the application and/or = relation type in use. works? On 05/02/2010, at 11:38 PM, Julian Reschke wrote: > Mark Nottingham wrote: >> On 29/01/2010, at 11:45 PM, Julian Reschke wrote: >>> Mark Nottingham wrote: >>>> ... >>>> If that's the case, you're saying that whether the anchor is = allowed is really a property of the relation type, not the application, = aren't you? ... >>> First of all, I'd prefer to distinguish between (A) "must be = processed" and (B) "may be processed, otherwise link must be rejected = altogether". >>>=20 >>> I see two purposes for the anchor parameter: >>>=20 >>> 1) Making a statement about a subset of the context resource, by = specifying a fragment identifier >>>=20 >>> 2) Making a statement about a different resource than the context = resource, such as >>>=20 >>> 2a) because the context is anonymous (such as the response body for = a 204, see = ), or >>>=20 >>> 2b) because a reverse link is exposed (anchor as workaround for = missing rev parameter) >>>=20 >>> I'm still not sure why we would ever make special cases here, except = for the known bugs in current implementations of the Link header where = anchor is ignored (so mainly Mozilla/Opera for stylesheet links). = Optimally, we just work with the vendors to get the bugs fixed. >>>=20 >>> If that's not possible, allowing an opt-out per relation type might = work, as long as behavior (B) would still be allowed. Is there any = relation !=3D "stylesheet" for which this would be relevant? >> I think most of them. >> E.g., what happens when my weblog >> http://www.mnot.net/blog/ >> contains a link header >> Link: ; rel=3D"service"; = anchor=3D"http://www.intertwingly.net/blog/" >> ? >> After Sam visits my blog, should his browser (assuming it supports = Atompub) use my site for editing next time he wants to post something? >=20 > That's an excellent example. I do agree that - in general - we don't = want to be able to affect = . >=20 > So the choices here are: >=20 > a) Processing anchor, detecting the authority conflict, and ignoring = the link, or >=20 > b) ignoring anchor, and pretending we have = --service--> >=20 > What I'm trying to say is that we never ever want b). >=20 > So I'm fine with clients ignoring the link header altogether because = it contains anchor, but simply ignoring the anchor parameter, but = processing the rest seems to be a very bad idea. >=20 >> Likewise, what happens after I put this link header in all of my = responses? >> Link: ; rel=3D"self"; = anchor=3D"http://www.google.com/" >> ? >> Or better yet: >> Link: ; rel=3D"payment"; = anchor=3D"http://www.amazon.com/" >> While it may be that browsers in general won't "remember" this = information, that doesn't mean that we should specify things so that = they're encouraged to handle these things, knowing full well that they = won't. Opt-in seems much more sane that opt-out here, at least for = different resources. >=20 > Well, maybe we've been agreeing all the time, and just the spec text = needs tuning. >=20 > So again: a recipient MUST resolve the anchor parameter against the = context IRI (*), producing a new context. It MAY ignore the link if the = resulting context looks suspicious (maybe something like same-domain = could be recommended here). >=20 > Best regards, Julian >=20 > (*) + handle the case where there's no context IRI -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Fri Feb 19 01:29:40 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE87328C0E0 for ; Fri, 19 Feb 2010 01:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=-0.775, 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 1PBf2rWvTJNG for ; Fri, 19 Feb 2010 01:29:40 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 93EF23A7946 for ; Fri, 19 Feb 2010 01:29:39 -0800 (PST) Received: (qmail invoked by alias); 19 Feb 2010 09:31:23 -0000 Received: from p508FC732.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.199.50] by mail.gmx.net (mp005) with SMTP; 19 Feb 2010 10:31:23 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1//J7thhqn/d9rF6XCpz/WVv5cPNUXnO3gvy1yNT5 EtcUvBYE8Mm8e1 Message-ID: <4B7E5A62.6080304@gmx.de> Date: Fri, 19 Feb 2010 10:31:14 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Mark Nottingham Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> <4B596450.7020001@gmx.de> <4B62D875.102@gmx.de> <7B248F44-44D9-4054-84A2-E9C4C5C251E1@mnot.net> <4B6C1144.4090502@gmx.de> <5C1BFD92-7E8D-4ABF-A986-03ADC50A18CD@mnot.net> In-Reply-To: <5C1BFD92-7E8D-4ABF-A986-03ADC50A18CD@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 09:29:40 -0000 On 19.02.2010 03:03, Mark Nottingham wrote: > OLD: > The anchor parameter MUST be ignored by consuming implementations, unless its use is specified by the application in use. > > NEW: > Links with the anchor parameter MUST be ignored by consuming implementations, unless its use is specified by the application and/or relation type in use. > > works? That's better, in that it clarifies that the anchor parameter never ever can be ignored. However, it still delegates the decision to the "fuzzy" term "application" or the relation type registration (why would that be involved?). How about: "The presence of the anchor parameter affects the context IRI. Thus, consumers either MUST ignore all links that include the anchor parameter, or process it according to . In the latter case, the resulting context IRI can identify an entirely different resource, in which case consumers MAY choose to ignore the link." Best regards, Julian From touch@ISI.EDU Fri Feb 19 14:25:10 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC2C3A803B; Fri, 19 Feb 2010 14:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 aou9UAAUKHel; Fri, 19 Feb 2010 14:25:09 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id B09A83A7F20; Fri, 19 Feb 2010 14:25:09 -0800 (PST) Received: from [192.168.1.97] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o1JMPupd009111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 14:25:57 -0800 (PST) Message-ID: <4B7F0FF4.5050904@isi.edu> Date: Fri, 19 Feb 2010 14:25:56 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Alfred_=3F?= Subject: Re: [tsvwg] [port-srv-reg] "assigned" (vs. "registered"), and relates issues References: <201002190143.CAA21850@TR-Sys.de> In-Reply-To: <201002190143.CAA21850@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig93656F3FB7879E36815AD4C3" X-MailScanner-ID: o1JMPupd009111 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org, apps-discuss@ietf.org, port-srv-reg@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 22:25:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig93656F3FB7879E36815AD4C3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Alfred, I support the proposed cleanup of the WKS entries as you have outlined. > [ BTW: looking for "transport"/"protocol", I found that the draft > repeatedly uses "protocol number[s]" or even "address[es]" where > it should say "port number[s]" -- ex: see the text quoted above. ] Understood - we should take a cleanup pass at that issue. --- Regarding how to present the information: > Well, the information must be stored somehow, and visually > presented on the IANA site. This was a suggestion that avoids > whitespace, which might be of some benefit for human readers > and automatic tools (that will be invented, I'm sure) to operate > on the registry content. Presenting the information in a format for automated tools need not exactly match the format presented for human readers - we could, e.g., export it as either XML (that might be rendered either way), or post it as a more structured database (maybe even define a MIB for it?). --- Regarding output that allows "sort on each column": > Even decades old UNIX/POSIX `sort` allows multiple sort keys. > In this case, I assume IANA will use some type of backend database > system, and that will certainly allow similar operations. In some web systems you can do this in how you click on the HTML output; the sort function is supported in the javascript/etc, not necessarily requiring a backend database capability. I was describing potential limits to that common javascript/etc code, not to a full-blown back-end. IMO, simple sort provided by javascript/etc is fine, but I don't want to burden IANA with arbitrary sorts that users can do themselves on the raw data if desired. --- Regarding when to add entries for new transports: > Two remarks: >=20 > o I've never seen an application implementer implementing support > of a transport that had not been specified somewhere; > thus, it really should be left to registrants to request the > addition of new entries. >=20 > o Should there ever arise the need to indeed perform such exceptional > action (with a 100% upwards compatible transport protocol), that > will require specific documentation and IESG action anyway. > We should not attempt to provide rules that will likely never be > needed, or else, if needed for some reason or the other, turn out > to be insufficient -- cf. Murphy's Law! We don't need these as rules - these can be handled by IANA as they see fit, IMO. >>> For now, the new rules _reserve_ {service, transport} pairs for al= l >>> (current and future) transport protocols not mentioned in the primary= >>> request to IANA for a given , isn't it? >> >> I don't think we mention that explicitly. We do hold the {transport, >=20 > That should be done for clarity. The current document is intended to explain the process for asking for things, not the process by which IANA manages things per se. I.e., it defines the user interface to IANA, not the mechanism by which IANA works. That level of detail is not needed IMO. >> number} pair for all other transports not assigned, and we already >> expect that we would assign those other pairs only for the owner of th= e >> initial pair. >> >> As above, I think this is already something we can trust IANA to handl= e >> at Layer 8, and not necessarily codify explicitly. >=20 > Since it would make the rules modular and orthogonal, I don't hesitate > to assume that the ruleset will not become more complicated thereby > -- to the contrary, it will be easier to understand and implement. As above - this focuses on how IANA does its job, not how they interact with users. I don't think this document does a lot about specifying IANA internal operations, nor should it IMO. >>> And the rules specify that the service name shall _identify_ the >>> application; hence adding new transports later should require evidenc= e >>> that the new request to IANA indeed is for the same application, >>> or otherwise these premises could not be maintained. >> >> Technically, the {name, transport} pair identifies the application; >> there are plenty of apps for which the UDP service is owned by, but >> does not match the TCP service. We've been discouraging that in recent= >> registrations, though. >=20 > IMO that distinction between service and application is falling short > of hair-splitting; there's no need for it in the draft, if you follow > your analysis above that the primary key to the registry is the > {name, transport} pair. That's what we all understood, I thought. However, it doesn't make a lot of sense, e.g., to allow: joetp tcp joe touch's new transport protocol joetp udp joe smith's new transport protocol IMO, even though the whole protocol is described by the {name,transport} pair, the name alone ought to be somewhat 'owned' and 'reserved' for consistent use by one owner across transports. However, I trust that to IANA's implementation of registration, not part of what needs to be described in this doc. Joe --------------enig93656F3FB7879E36815AD4C3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkt/D/QACgkQE5f5cImnZruBWQCg/RLmH2f1w/50vantQC10GBTY iP4AoM7ityXvBMkiuwatOrWcmrSi7wBr =yFMn -----END PGP SIGNATURE----- --------------enig93656F3FB7879E36815AD4C3-- From GK@ninebynine.org Sat Feb 20 00:00:55 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781103A80CD for ; Sat, 20 Feb 2010 00:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 Z8HTBAGBf5Fm for ; Sat, 20 Feb 2010 00:00:54 -0800 (PST) Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by core3.amsl.com (Postfix) with ESMTP id 713813A7D11 for ; Sat, 20 Feb 2010 00:00:53 -0800 (PST) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1NikIU-0000SS-2f; Sat, 20 Feb 2010 08:02:42 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NikIU-0003LU-1t; Sat, 20 Feb 2010 08:02:42 +0000 Message-ID: <4B7E53B8.6070805@ninebynine.org> Date: Fri, 19 Feb 2010 09:02:48 +0000 From: Graham Klyne User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "apps-discuss@ietf.org" , Julian Reschke Subject: draft-reschke-rfc2231-in-http security considerations Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 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, 20 Feb 2010 08:00:55 -0000 Reviewing: http://www.ietf.org/id/draft-reschke-rfc2231-in-http-09.txt I note that the security considerations section says nothing about possible character "spoofing" - i.e. making a displayed prompt or value appear to be something other than it is. E.g. Non-ASCII characters have been used to set up exploits involving dodgy URIs that may appear to a user to be legitimate. #g From julian.reschke@gmx.de Mon Feb 22 06:59:25 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B8B28C1EE for ; Mon, 22 Feb 2010 06:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.669 X-Spam-Level: X-Spam-Status: No, score=-4.669 tagged_above=-999 required=5 tests=[AWL=-2.070, 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 3c7kjDXxWN4W for ; Mon, 22 Feb 2010 06:59:24 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5CC073A8296 for ; Mon, 22 Feb 2010 06:59:23 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2010 15:01:17 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp022) with SMTP; 22 Feb 2010 16:01:17 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/iElxmAGvivg1ZZOhQIQov863/uinuwkalgxHzEM vM30z5fKmoGtKQ Message-ID: <4B829C3C.3070901@gmx.de> Date: Mon, 22 Feb 2010 16:01:16 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: IETF Apps Discuss , HTTP Working Group Subject: FYI: IETF LC for draft-reschke-rfc2231-in-http References: <20100222140422.2EFC728C125@core3.amsl.com> In-Reply-To: <20100222140422.2EFC728C125@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59999999999999998 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, 22 Feb 2010 14:59:25 -0000 On 22.02.2010 15:04, The IESG wrote: > The IESG has received a request from an individual submitter to consider > the following document: > > - 'Application of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP) > Header Fields ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2010-03-22. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-reschke-rfc2231-in-http-10.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17647&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce Hi there, this spec is now in Last Call, ending March, 22. A few issues are open, and those are summarized in Appendix D. I'm particularly looking for feedback on: - parameter-abnf In Section 3.2: Type: change julian.reschke@greenbytes.de (2010-02-20): The ABNF for reg-parameter and ext-parameter is ambiguous, as "*" is a valid token character; furthermore, RFC 2616's "attribute" production allows "*" while RFC 2231's does not. (reported by Alexey Melnikov). julian.reschke@greenbytes.de (2010-02-21): Proposal: restrict the allowable character set in parameter names to exclude "*" (and maybe even more non-name characters?). Also, consider extending the set of value characters (for the right hand side) to allow more characters that can be unambiguously parsed outside quoted strings, such as "/". and - iso8859 In Section 3.2: Type: change julian.reschke@greenbytes.de (2010-02-20): The protocol could be further simplified by mandating UTF-8 only (reported by Alexey Melnikov). On the other hand and not surprisingly, testing shows that ISO-8859-1 support is widely implemented. The author is looking for community feedback on this choice. Feedback on these specific issues would be appreciated, Julian From dhc@dcrocker.net Mon Feb 22 08:20:35 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7F628C0F4 for ; Mon, 22 Feb 2010 08:20:35 -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 QURnWYQYZpzs for ; Mon, 22 Feb 2010 08:20:31 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 9436D3A8148 for ; Mon, 22 Feb 2010 08:20:31 -0800 (PST) Received: from [192.168.1.11] (ppp-67-124-90-197.dsl.pltn13.pacbell.net [67.124.90.197]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o1MGMPsv004235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Feb 2010 08:22:30 -0800 Message-ID: <4B82AF43.1090304@dcrocker.net> Date: Mon, 22 Feb 2010 08:22:27 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: discuss@apps.ietf.org Subject: LDAP outcome entry Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10431/Mon Feb 22 05:25:31 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 22 Feb 2010 08:22:30 -0800 (PST) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 16:20:36 -0000 Folks, I'd like to get a consensus assessment on the LDAP entry in the IETF Outcomes wiki: Specifically: 1. Origin: LDAP is an X.500 derivative, but it indeed might be more accurate to describe it as having been a fresh IETF effort that used X.500 as input. This would explain the current entry's Origina setting. Does anyone disagree with the current entry's claim that LDAP originated in the IETF? 2. Usage: My impression is that LDAP is hugely deployed and used within enterprises, so that the ++ is correct. Yes? I'm curious about the listing's asserting significant derivative work. While it makes sense there would be this, I'd like to get confirmation here. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From lear@cisco.com Mon Feb 22 08:44:18 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F63528C31F for ; Mon, 22 Feb 2010 08:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=4.060, BAYES_00=-2.599, 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 wi4mnM7cDViC for ; Mon, 22 Feb 2010 08:44:17 -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 35F5D28C129 for ; Mon, 22 Feb 2010 08:44:17 -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: Au0AAB9DgkuQ/uCWe2dsb2JhbACDBZd+FQEBCwskBhykfYgZj1eBMoJVZAQ X-IronPort-AV: E=Sophos;i="4.49,519,1262563200"; d="scan'208";a="57392016" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 22 Feb 2010 16:46:15 +0000 Received: from dhcp-10-55-94-208.cisco.com (dhcp-10-55-94-208.cisco.com [10.55.94.208]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1MGkFAe000858; Mon, 22 Feb 2010 16:46:15 GMT Message-ID: <4B82B4D6.8000508@cisco.com> Date: Mon, 22 Feb 2010 17:46:14 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2pre) Gecko/20100120 Lanikai/3.1a1 MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: LDAP outcome entry References: <4B82AF43.1090304@dcrocker.net> In-Reply-To: <4B82AF43.1090304@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: discuss@apps.ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 16:44:18 -0000 Hi Dave, As I see it there are two parts to LDAP- the transport and the schema. If you were to break it up as such, you could say that the transport had little to do with X.500 and the schema can be said to be a derivative work, based on experimental experiences of the Quippu folk, led by Marshall Rose & Steve Kille. Eliot On 2/22/10 5:22 PM, Dave CROCKER wrote: > Folks, > > I'd like to get a consensus assessment on the LDAP entry in the IETF > Outcomes wiki: > > > > > Specifically: > > > 1. Origin: LDAP is an X.500 derivative, but it indeed might be more > accurate to describe it as having been a fresh IETF effort that used > X.500 as input. This would explain the current entry's Origina > setting. Does anyone disagree with the current entry's claim that > LDAP originated in the IETF? > > > 2. Usage: My impression is that LDAP is hugely deployed and used > within enterprises, so that the ++ is correct. Yes? I'm curious > about the listing's asserting significant derivative work. While it > makes sense there would be this, I'd like to get confirmation here. > > > Thanks. > > d/ From dhc@dcrocker.net Mon Feb 22 08:48:03 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B23028C32D for ; Mon, 22 Feb 2010 08:48:03 -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 e-FXlq8Cmfp4 for ; Mon, 22 Feb 2010 08:48:02 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 4305C28C129 for ; Mon, 22 Feb 2010 08:48:02 -0800 (PST) Received: from [192.168.1.11] (ppp-67-124-90-197.dsl.pltn13.pacbell.net [67.124.90.197]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o1MGnuba007087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Feb 2010 08:50:01 -0800 Message-ID: <4B82B5B6.9090006@dcrocker.net> Date: Mon, 22 Feb 2010 08:49:58 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Eliot Lear Subject: Re: LDAP outcome entry References: <4B82AF43.1090304@dcrocker.net> <4B82B4D6.8000508@cisco.com> In-Reply-To: <4B82B4D6.8000508@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10432/Mon Feb 22 06:59:38 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 22 Feb 2010 08:50:01 -0800 (PST) Cc: discuss@apps.ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 16:48:03 -0000 Eliot, Thanks for the followup. Your note makes sense. If folks agree, can one of you LDAP devotees modify the existing entry to match this? d/ On 2/22/2010 8:46 AM, Eliot Lear wrote: > Hi Dave, > > As I see it there are two parts to LDAP- the transport and the schema. > If you were to break it up as such, you could say that the transport had > little to do with X.500 and the schema can be said to be a derivative > work, based on experimental experiences of the Quippu folk, led by > Marshall Rose & Steve Kille. > > Eliot > > On 2/22/10 5:22 PM, Dave CROCKER wrote: >> Folks, >> >> I'd like to get a consensus assessment on the LDAP entry in the IETF >> Outcomes wiki: >> >> >> >> >> Specifically: >> >> >> 1. Origin: LDAP is an X.500 derivative, but it indeed might be more >> accurate to describe it as having been a fresh IETF effort that used >> X.500 as input. This would explain the current entry's Origina >> setting. Does anyone disagree with the current entry's claim that LDAP >> originated in the IETF? >> >> >> 2. Usage: My impression is that LDAP is hugely deployed and used >> within enterprises, so that the ++ is correct. Yes? I'm curious about >> the listing's asserting significant derivative work. While it makes >> sense there would be this, I'd like to get confirmation here. >> >> >> Thanks. >> >> d/ > -- Dave Crocker Brandenburg InternetWorking bbiw.net From steve.kille@isode.com Mon Feb 22 09:20:59 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFA6A28C119 for ; Mon, 22 Feb 2010 09:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2RmbIwTtDyQ for ; Mon, 22 Feb 2010 09:20:58 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BC46E28C0E5 for ; Mon, 22 Feb 2010 09:20:57 -0800 (PST) Received: from Liathach (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 22 Feb 2010 17:22:56 +0000 From: "Steve Kille" To: "'Eliot Lear'" , References: <4B82AF43.1090304@dcrocker.net> <4B82B4D6.8000508@cisco.com> In-Reply-To: <4B82B4D6.8000508@cisco.com> Subject: RE: LDAP outcome entry Date: Mon, 22 Feb 2010 17:22:52 -0000 Message-ID: <01dd01cab3e3$acba9ea0$062fdbe0$@kille@isode.com> X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqz3pBjUSRDGQP2Syakw7e+wbF28wAAf8Gw MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-gb X-Mailman-Approved-At: Mon, 22 Feb 2010 09:28:17 -0800 Cc: 'Steve Kille' , discuss@apps.ietf.org, 'Erik Andersen' , 'Kurt Zeilenga' 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, 22 Feb 2010 17:20:59 -0000 Dave, Eliot, This got passed to me twice, so let me share a few thoughts. I'm cc'ing Kurt Zeilenga, who edited the last round of LDAP core specs, and Erik Anderson who leads ongoing X.500 standardization 1. LDAP was originally designed as a lightweight protocol to access X.500 servers. (Tim Howes and Wengyik Yeong deserve a mention here). 2. In LDAPv3, it was decoupled from X.500 to the extent that a server implementing LDAP has no requirement to implement any of the X.500 protocols. 3. Technically, LDAP is very much based on X.500, and references X.500. It is not an independent specification. I consider it as alternate to the X.500 DAP (which can now be used directly over TCP without an OSI stack). X.500 defines the service and information model. 4. LDAP is a client access protocol only. In a distributed directory, it can be used with proprietary distribution (e.g., Microsoft AD) or with X.500 (which defines server to server protocols and access control). (IETF attempts to standardize access control and server/server protocols were abandoned). 5. Ongoing LDAP and X.500 standardization is tightly coordinated. Changes were made in X.500(2009) to align it to LDAP! 6. I view that LDAP is very successful (although I am biased). The most widely deployed servers are LDAP only. All X.500 servers that I know of support LDAP, and use it as a primary client access mechanism. X.500 is offered by large vendors (CA and Siemens) as well as smaller companies, and is important in deployments that need open server/sever interworking. Hope this is of some help Regards Steve > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Eliot Lear > Sent: 22 February 2010 16:46 > To: dcrocker@bbiw.net > Cc: discuss@apps.ietf.org > Subject: Re: LDAP outcome entry > > Hi Dave, > > As I see it there are two parts to LDAP- the transport and the schema. > If you were to break it up as such, you could say that the transport > had > little to do with X.500 and the schema can be said to be a derivative > work, based on experimental experiences of the Quippu folk, led by > Marshall Rose & Steve Kille. > > Eliot > > On 2/22/10 5:22 PM, Dave CROCKER wrote: > > Folks, > > > > I'd like to get a consensus assessment on the LDAP entry in the IETF > > Outcomes wiki: > > > > > > > > > > Specifically: > > > > > > 1. Origin: LDAP is an X.500 derivative, but it indeed might be more > > accurate to describe it as having been a fresh IETF effort that used > > X.500 as input. This would explain the current entry's Origina > > setting. Does anyone disagree with the current entry's claim that > > LDAP originated in the IETF? > > > > > > 2. Usage: My impression is that LDAP is hugely deployed and used > > within enterprises, so that the ++ is correct. Yes? I'm curious > > about the listing's asserting significant derivative work. While it > > makes sense there would be this, I'd like to get confirmation here. > > > > > > Thanks. > > > > d/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From dhc@dcrocker.net Mon Feb 22 09:53:37 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007A028C335 for ; Mon, 22 Feb 2010 09:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 F8KtkaGfeeMO for ; Mon, 22 Feb 2010 09:53:35 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id DE6F528C1C9 for ; Mon, 22 Feb 2010 09:53:35 -0800 (PST) Received: from [192.168.1.11] (ppp-67-124-90-197.dsl.pltn13.pacbell.net [67.124.90.197]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o1MHtTQc012825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Feb 2010 09:55:34 -0800 Message-ID: <4B82C513.9080705@dcrocker.net> Date: Mon, 22 Feb 2010 09:55:31 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Steve Kille Subject: Re: LDAP outcome entry References: <4B82AF43.1090304@dcrocker.net> <4B82B4D6.8000508@cisco.com> <01dd01cab3e3$acba9ea0$062fdbe0$@kille@isode.com> In-Reply-To: <01dd01cab3e3$acba9ea0$062fdbe0$@kille@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10432/Mon Feb 22 06:59:38 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 22 Feb 2010 09:55:35 -0800 (PST) Cc: discuss@apps.ietf.org, 'Erik Andersen' , 'Kurt Zeilenga' , 'Eliot Lear' X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 17:53:37 -0000 Steve, Thanks! I'd class your response as meaning that there need to be some changes to the Outcomes wiki and given your knowledge of the topic, doubt anyone is likely to assert different facts. The changes should be done by you or someone with an LDAP background. (I don't have nearly enough, plus I generlly want to encourage others to make changes.) some inline comments: On 2/22/2010 9:22 AM, Steve Kille wrote: > Dave, Eliot, > > This got passed to me twice, so let me share a few thoughts. I'm cc'ing > Kurt Zeilenga, who edited the last round of LDAP core specs, and Erik > Anderson who leads ongoing X.500 standardization > > 1. LDAP was originally designed as a lightweight protocol to access X.500 > servers. (Tim Howes and Wengyik Yeong deserve a mention here). > > 2. In LDAPv3, it was decoupled from X.500 to the extent that a server > implementing LDAP has no requirement to implement any of the X.500 > protocols. This suggests that LDAPv3 should get its own entry, to mark the differences from earlier version? > 3. Technically, LDAP is very much based on X.500, and references X.500. It > is not an independent specification. I consider it as alternate to the > X.500 DAP (which can now be used directly over TCP without an OSI stack). > X.500 defines the service and information model. > > 4. LDAP is a client access protocol only. In a distributed directory, it > can be used with proprietary distribution (e.g., Microsoft AD) or with X.500 > (which defines server to server protocols and access control). (IETF > attempts to standardize access control and server/server protocols were > abandoned). > > 5. Ongoing LDAP and X.500 standardization is tightly coordinated. > Changes were made in X.500(2009) to align it to LDAP! This prompted me to send a suggestion to the IAB that we should have a public listing of accomplishments that result of our liaison relationships. (Fax-over-Email was the first, but there have been others.) > 6. I view that LDAP is very successful (although I am biased). The most > widely deployed servers are LDAP only. All X.500 servers that I know of > support LDAP, and use it as a primary client access mechanism. X.500 is > offered by large vendors (CA and Siemens) as well as smaller companies, and > is important in deployments that need open server/sever interworking. The intent behind + vs. ++ on the wiki is to distinguish between achieving some real adoption, versus achieving massive adoption (within the Target Segment.) While LDAP is widely deployed -- for example in clients -- I don't have a feel for just how much actual /usage/ there is in enterprises. Is it really massive? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From steve.kille@isode.com Mon Feb 22 10:01:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4334428C35D for ; Mon, 22 Feb 2010 10:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oxfr9Mb9QLZy for ; Mon, 22 Feb 2010 10:01:19 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4A22F28C35C for ; Mon, 22 Feb 2010 10:01:19 -0800 (PST) Received: from Liathach (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 22 Feb 2010 18:03:17 +0000 From: "Steve Kille" To: References: <4B82AF43.1090304@dcrocker.net> <4B82B4D6.8000508@cisco.com> <01dd01cab3e3$acba9ea0$062fdbe0$@kille@isode.com> <4B82C513.9080705@dcrocker.net> In-Reply-To: <4B82C513.9080705@dcrocker.net> Subject: RE: LDAP outcome entry Date: Mon, 22 Feb 2010 18:03:14 -0000 Message-ID: <01e501cab3e9$501cd860$f0568920$@kille@isode.com> X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqz6E0NQOljnyYvSaezeDLRNjy+PAAAHzgA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-gb Cc: discuss@apps.ietf.org, 'Erik Andersen' , 'Kurt Zeilenga' , 'Eliot Lear' 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, 22 Feb 2010 18:01:20 -0000 > -----Original Message----- > From: Dave CROCKER [mailto:dhc@dcrocker.net] > Sent: 22 February 2010 17:56 > To: Steve Kille > Cc: 'Eliot Lear'; discuss@apps.ietf.org; 'Kurt Zeilenga'; 'Erik > Andersen' > Subject: Re: LDAP outcome entry > > Steve, > > Thanks! > > I'd class your response as meaning that there need to be some changes > to the > Outcomes wiki and given your knowledge of the topic, doubt anyone is > likely to > assert different facts. The changes should be done by you or someone > with an > LDAP background. (I don't have nearly enough, plus I generlly want to > encourage > others to make changes.) I don't think I'm going to have time to do this > > This suggests that LDAPv3 should get its own entry, to mark the > differences from > earlier version? No, although I think the evolution is worth noting > While LDAP is widely deployed -- for example in clients -- I don't have > a feel > for just how much actual /usage/ there is in enterprises. Is it really > massive? I find it hard to judge, although it seems clear to me that a lot of organizations use it, if only as a consequence of AD. My sense is that it ends up getting deployed, albeit without much visibility in a lot of places. My disappointment, is that its use between organizations is limited. This seems a pity, as it could enable better sharing of information, and in particular give access to X.509 certs to facilitate end to end encryption, esp with S/MIME Steve From salvatore.loreto@ericsson.com Tue Feb 23 03:57:23 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C91E28C12B for ; Tue, 23 Feb 2010 03:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[AWL=-0.411, 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 mzGS2gXxR0Ax for ; Tue, 23 Feb 2010 03:57:22 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 2C2693A83B2 for ; Tue, 23 Feb 2010 03:57:22 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-57-4b83c31b0a1f Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id FE.EC.31641.B13C38B4; Tue, 23 Feb 2010 12:59:23 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 12:59:22 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 12:59:22 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A9AD624D8 for ; Tue, 23 Feb 2010 13:59:22 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 74D9A21A41 for ; Tue, 23 Feb 2010 13:59:22 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 36BE1219C4 for ; Tue, 23 Feb 2010 13:59:22 +0200 (EET) Message-ID: <4B83C319.8060206@ericsson.com> Date: Tue, 23 Feb 2010 13:59:21 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: draft-loreto-http-bidirectional-02 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 23 Feb 2010 11:59:22.0595 (UTC) FILETIME=[A33C1330:01CAB47F] X-Brightmail-Tracker: AAAAAA== 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, 23 Feb 2010 11:57:23 -0000 Hi there, we have just submitted a new version of the "Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP" draft: http://www.ietf.org/staging/draft-loreto-http-bidirectional-02.txt (as HyBi wg is not supposed to take care of the issue any more, we are moving for the time being the discussion to the app-area) feedback, comments and suggestions are very welcome cheers /Sal Salvatore Loreto www.sloreto.com From julian.reschke@gmx.de Tue Feb 23 08:21:11 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693E428C148 for ; Tue, 23 Feb 2010 08:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[AWL=-1.905, 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 E2q1Tc9j62ow for ; Tue, 23 Feb 2010 08:21:10 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2F1C528C0EB for ; Tue, 23 Feb 2010 08:21:10 -0800 (PST) Received: (qmail invoked by alias); 23 Feb 2010 16:23:12 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp061) with SMTP; 23 Feb 2010 17:23:12 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX185wdURjxE5ce7DVqoFvAWx4MNLOATo8rA0c0PVRK 9BzFTZ9Bw8Tf9N Message-ID: <4B8400E8.6030202@gmx.de> Date: Tue, 23 Feb 2010 17:23:04 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Graham Klyne Subject: Re: draft-reschke-rfc2231-in-http security considerations References: <4B7E53B8.6070805@ninebynine.org> In-Reply-To: <4B7E53B8.6070805@ninebynine.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58999999999999997 Cc: "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 16:21:11 -0000 On 19.02.2010 10:02, Graham Klyne wrote: > Reviewing: > http://www.ietf.org/id/draft-reschke-rfc2231-in-http-09.txt > > I note that the security considerations section says nothing about > possible character "spoofing" - i.e. making a displayed prompt or value > appear to be something other than it is. E.g. Non-ASCII characters have > been used to set up exploits involving dodgy URIs that may appear to a > user to be legitimate. > ... Good catch. Would the following work for you? -- snip -- 5. Security Considerations The format described in this document makes it possible to transport non-ASCII characters, and thus enables character "spoofing" scenarios, in which a displayed value appears to be something other than it is. Furthermore, there are known attack scenarios relating to decoding UTF-8. See Section 10 of [RFC3629] for more information on both topics. -- snip -- Best regards, Julian From GK-lists@ninebynine.org Tue Feb 23 00:12:54 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A718128C550 for ; Tue, 23 Feb 2010 00:12:54 -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 wnXBNR9nQ8xY for ; Tue, 23 Feb 2010 00:12:53 -0800 (PST) Received: from relay5.mail.ox.ac.uk (relay5.mail.ox.ac.uk [163.1.2.163]) by core3.amsl.com (Postfix) with ESMTP id 2689C28C23C for ; Tue, 23 Feb 2010 00:12:53 -0800 (PST) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay5.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1Njpuv-0007iv-JJ; Tue, 23 Feb 2010 08:14:53 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Njpuv-0002nf-20; Tue, 23 Feb 2010 08:14:53 +0000 Message-ID: <4B838DBB.4060804@ninebynine.org> Date: Tue, 23 Feb 2010 08:11:39 +0000 From: Graham Klyne User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: LDAP outcome entry References: <4B82AF43.1090304@dcrocker.net> In-Reply-To: <4B82AF43.1090304@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 X-Mailman-Approved-At: Tue, 23 Feb 2010 09:52:34 -0800 Cc: discuss@apps.ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 08:12:54 -0000 Dave CROCKER wrote: > 2. Usage: My impression is that LDAP is hugely deployed and used within > enterprises, so that the ++ is correct. Yes? I'm curious about the > listing's asserting significant derivative work. While it makes sense > there would be this, I'd like to get confirmation here. Some work I'm doing at the moment seems to indicate that Microsoft's active directory service is significantly a combination of Kerberos and LDAP. To the extent that AD "supports" LDAP, the ++ would seem to be justified [1]. AFAICT, LDAP is also widely deployed for authorization data in SSO environments like University networks. It also appears to be a popular authorization framework for use with Samba. #g -- [1] "AD added many features, the most important of which was LDAP support" -- http://www.symas.com/documents/Adam-Eval1-0.pdf, cited by wikipedia page on AD From aaron@serendipity.cx Tue Feb 23 11:06:58 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF7728C1CA for ; Tue, 23 Feb 2010 11:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBYjYS0s8jMF for ; Tue, 23 Feb 2010 11:06:57 -0800 (PST) Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by core3.amsl.com (Postfix) with ESMTP id E9CA63A7D92 for ; Tue, 23 Feb 2010 11:06:56 -0800 (PST) Received: from mail-pw0-f49.google.com (mail-pw0-f49.google.com [209.85.160.49]) by slice.serendipity.cx (Postfix) with ESMTPSA id A6D07110100 for ; Tue, 23 Feb 2010 11:16:03 -0800 (PST) Received: by pwj2 with SMTP id 2so2717584pwj.22 for ; Tue, 23 Feb 2010 11:08:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.107.10 with SMTP id j10mr1557652rvm.282.1266952134070; Tue, 23 Feb 2010 11:08:54 -0800 (PST) In-Reply-To: <4B838DBB.4060804@ninebynine.org> References: <4B82AF43.1090304@dcrocker.net> <4B838DBB.4060804@ninebynine.org> From: Aaron Stone Date: Tue, 23 Feb 2010 11:08:34 -0800 Message-ID: <1629dc8c1002231108s49c3ce70lda09b38eeb6f6a20@mail.gmail.com> Subject: Re: LDAP outcome entry To: Graham Klyne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: discuss@apps.ietf.org, dcrocker@bbiw.net 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, 23 Feb 2010 19:06:58 -0000 On Tue, Feb 23, 2010 at 12:11 AM, Graham Klyne wr= ote: > Dave CROCKER wrote: >> >> 2. =A0Usage: My impression is that LDAP is hugely deployed and used with= in >> enterprises, so that the ++ is correct. =A0Yes? =A0I'm curious about the >> listing's asserting significant derivative work. =A0While it makes sense= there >> would be this, I'd like to get confirmation here. > > Some work I'm doing at the moment seems to indicate that Microsoft's > active directory service is significantly a combination of Kerberos and > LDAP. > To the extent that AD "supports" LDAP, the ++ would seem to be justified > [1]. Active Directory is a combination of Kerberos, LDAP, and Windows RPCs for domain control. The LDAP part is quite interoperable since first release in Windows 2000, the Kerberos part has become increasingly interoperable, and the Windows RPCs and CIFS are now supported by Samba (though I don't think CIFS ever made it off the ground for open standardization). I managed a fairly large Win2k domain, wrote several LDAP authenticated web applications, and LDAP authentication for a mail system, from 2001 to 2004, so I can definitely attest to deployment and usefulness of this combination. > AFAICT, LDAP is also widely deployed for authorization data in SSO > environments like University networks. Yep, my university and every company I've been at. > It also appears to be a popular > authorization framework for use with Samba. I wish it were easier to deploy small setups for home and small business users, though :\ > #g > -- > > [1] "AD added many features, the most important of which was LDAP support= " > -- http://www.symas.com/documents/Adam-Eval1-0.pdf, cited by wikipedia > page on AD > > > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From dhc@dcrocker.net Tue Feb 23 14:41:48 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0845828C3A3 for ; Tue, 23 Feb 2010 14:41:48 -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 c9t5J65TF8KR for ; Tue, 23 Feb 2010 14:41:46 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id EB18D28C39E for ; Tue, 23 Feb 2010 14:41:46 -0800 (PST) Received: from [172.16.31.147] (69-170-63-170.static-ip.telepacific.net [69.170.63.170]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o1NMhfta002199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 14:43:49 -0800 Message-ID: <4B845A18.5010603@dcrocker.net> Date: Tue, 23 Feb 2010 14:43:36 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Aaron Stone Subject: Re: LDAP outcome entry References: <4B82AF43.1090304@dcrocker.net> <4B838DBB.4060804@ninebynine.org> <1629dc8c1002231108s49c3ce70lda09b38eeb6f6a20@mail.gmail.com> In-Reply-To: <1629dc8c1002231108s49c3ce70lda09b38eeb6f6a20@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10442/Tue Feb 23 14:09:42 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 23 Feb 2010 14:43:50 -0800 (PST) Cc: discuss@apps.ietf.org, dcrocker@bbiw.net, Graham Klyne X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 22:41:48 -0000 Folks, Thanks for the followup on this. Here are the claims I am hearing: 1. LDAP is very widely deployed and used in Enterprises. 2. Among that set, it has become a critical infrastructure service. 2. LDAP is not (widely) deployed or used across the open Internet, for use between random pairs. I am not sure whether there are restrictions that should be applied, about the /type/ of Enterprise that is popular for LDAP use. I'd guess medium-to-large Enterprises, more than small, but could imagine otherwise. It's probably not essential to get agreement on this, but the agreement might solidify agreement about whether LDAP is essential. If #1 and #2 are correct, I'd guess that LDAP should get a ++, rather than a +. Do folks agree? Disagree? d/ ps. I'm still hoping someone who is deep in LDAP deployment and history can partition the entry into appropriate, distinct entries. -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Tue Feb 23 14:43:56 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA83828C3A4 for ; Tue, 23 Feb 2010 14:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7zCqwlt2N78 for ; Tue, 23 Feb 2010 14:43:55 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id EC14828C39E for ; Tue, 23 Feb 2010 14:43:54 -0800 (PST) Received: from dhcp-64-101-72-201.cisco.com (dhcp-64-101-72-201.cisco.com [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9045640126; Tue, 23 Feb 2010 15:45:58 -0700 (MST) Message-ID: <4B845AA5.7040602@stpeter.im> Date: Tue, 23 Feb 2010 15:45:57 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: LDAP outcome entry References: <4B82AF43.1090304@dcrocker.net> <4B838DBB.4060804@ninebynine.org> <1629dc8c1002231108s49c3ce70lda09b38eeb6f6a20@mail.gmail.com> <4B845A18.5010603@dcrocker.net> In-Reply-To: <4B845A18.5010603@dcrocker.net> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050105060702010302050203" Cc: discuss@apps.ietf.org, Graham Klyne 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, 23 Feb 2010 22:43:56 -0000 This is a cryptographically signed message in MIME format. --------------ms050105060702010302050203 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/23/10 3:43 PM, Dave CROCKER wrote: >=20 > Folks, >=20 > Thanks for the followup on this. >=20 >=20 > Here are the claims I am hearing: >=20 > 1. LDAP is very widely deployed and used in Enterprises. >=20 > 2. Among that set, it has become a critical infrastructure service. >=20 > 2. LDAP is not (widely) deployed or used across the open Internet, for > use between random pairs. >=20 > I am not sure whether there are restrictions that should be applied, > about the /type/ of Enterprise that is popular for LDAP use. I'd guess= > medium-to-large Enterprises, more than small, but could imagine > otherwise. It's probably not essential to get agreement on this, but > the agreement might solidify agreement about whether LDAP is essential.= >=20 > If #1 and #2 are correct, I'd guess that LDAP should get a ++, rather > than a +. >=20 > Do folks agree? Disagree? +1 to ++ :) --------------ms050105060702010302050203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDIyMzIyNDU1N1owIwYJKoZIhvcNAQkEMRYEFKjt4BvB5Gg4VfRRlxLi DgJmDQO6MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEALnG4/SZLKaD+NkiVAiBpEWXMgiQ5UnwtSh8Wji0a 6zThLZgPPb97r+hHprXYEU24uoIjwEy3DD75Pfgb5V1y4Og7V2DLNlEQj4itgQutNXBX6VCK uJIWKDuRjO52P7ORX+UZJEkLaXXpOIXV1rkjUVv6rpjcXhtX3KielFu7rZKUfwlzcWex4r3T IYs2Ve9J9iEOOa9aKCSZKw6ztQ3zcr2DkJJzJtlcqyc0L0pBY2ltiJ8Bjs8H98Np26EwlWUn OKp8tIoqtPohQvaXN8LdOmWARWBVzLWs1UzlLRdqDU5p4fBHKbdi6Ry8wTBAGmrwYGnYQoyD /P8cH4SJhCLLbwAAAAAAAA== --------------ms050105060702010302050203-- From alexey.melnikov@isode.com Wed Feb 24 14:43:27 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF0A3A7349 for ; Wed, 24 Feb 2010 14:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWt0QJOlwN3u for ; Wed, 24 Feb 2010 14:43:26 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 92FAB3A68ED for ; Wed, 24 Feb 2010 14:43:23 -0800 (PST) Received: from [172.16.2.194] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 24 Feb 2010 22:45:31 +0000 Message-ID: <4B85ABE7.5020208@isode.com> Date: Wed, 24 Feb 2010 22:44:55 +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: Apps-Discuss@ietf.org Subject: Proposed topics for the Apps Area meeting MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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, 24 Feb 2010 22:43:27 -0000 Please send your proposals to Lisa, Peter and myself (or at least one of us). As usual, we also like to quickly talk about Apps area BOFs: IRDE and NewPrep. So some time for them will be added to the agenda automatically. From roessler@gmail.com Wed Feb 24 11:34:16 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4FA128C150 for ; Wed, 24 Feb 2010 11:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBDw58gk8Tvg for ; Wed, 24 Feb 2010 11:34:16 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 04D493A857A for ; Wed, 24 Feb 2010 11:34:15 -0800 (PST) Received: by gwb10 with SMTP id 10so1868696gwb.31 for ; Wed, 24 Feb 2010 11:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=DcW2RLOEYmVM3qMO0pJBPGpzVa0cnlg7rmqoxvb91Qs=; b=SSgbYCoQk3Z76l6lTyCToosmv3VJmTDRDsKqgKktFu+LockXaoQOkY3LrBbzXS1W3R ASQEJKD7Qo/jBdTb7GCfLwkdAUiSo4DwlsCno19kQ5qnQo/s6Hlw3wd7yjn+Wy7raj61 hkZcuLUNelYCj72f5d7p0mxEA5ISI5akUSKDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oc+QsOQa6v9Qn+QR8wjs/+B2XQiHTS+S69I4foAbAw7KvdH9YK97V8+zbC7pyxP4tN 90ft5pfJtrakk0ZcTn5q+tbOno+hv9OBU+fdlGDh0wRYQ9yQUZFBwQiI3ob6yUDkjVxx uROZYC4gmO6uTGF6GpXmUqicNSsEd8nhxPpt4= MIME-Version: 1.0 Received: by 10.100.24.40 with SMTP id 40mr531845anx.56.1267040180743; Wed, 24 Feb 2010 11:36:20 -0800 (PST) Date: Wed, 24 Feb 2010 20:36:20 +0100 Message-ID: <4c80fa21002241136y629dda22l1d7617eb25250af8@mail.gmail.com> Subject: draft-reschke-rfc2231-in-http: section 4.2, Error Handling From: Thomas Roessler To: apps-discuss@ietf.org, Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 25 Feb 2010 08:41:27 -0800 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 19:35:34 -0000 Reviewing http://www.ietf.org/id/draft-reschke-rfc2231-in-http-10.txt, section 4.2 says: Header specifications that include parameters should also specify whether same-named parameters can occur multiple times. If repetitions are not allowed (and this is believed to be the common case), the specification should state whether regular or the extended syntax takes precedence. In the latter case, this could be used by producers to use both formats without breaking recipients that do not understand the syntax. Leaving the choice of precedence to the header specification implies that parsers need to special-case. It would seem reasonable to make a choice in this specification that for properties which can only occur once, the traditional syntax takes precedence. From mnot@mnot.net Thu Feb 25 20:42:55 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D0B28C4D8 for ; Thu, 25 Feb 2010 20:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.976 X-Spam-Level: X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[AWL=-1.377, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lzQv2rjgQMH for ; Thu, 25 Feb 2010 20:42:54 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 97C4228C267 for ; Thu, 25 Feb 2010 20:42:54 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.189.113]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D7804509DC; Thu, 25 Feb 2010 23:45:00 -0500 (EST) Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B7E5A62.6080304@gmx.de> Date: Fri, 26 Feb 2010 15:44:57 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> <4B596450.7020001@gmx.de> <4B62D875.102@gmx.de> <7B248F44-44D9-4054-84A2-E9C4C5C251E1@mnot.net> <4B6C1144.4090502@gmx.de> <5C1BFD92-7E8D-4ABF-A986-03ADC50A18CD@mnot.net> <4B7E5A62.6080304@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 04:42:55 -0000 What's here? I still don't see where the decision is made... at = worst, this makes it seem like consumers can make an arbitrary decision = as to whether to process a link with an anchor. This is where I am now: Links with the anchor parameter MUST be ignored by consuming = implementations, unless their use is explicitly specified. On 19/02/2010, at 8:31 PM, Julian Reschke wrote: > On 19.02.2010 03:03, Mark Nottingham wrote: >> OLD: >> The anchor parameter MUST be ignored by consuming implementations, = unless its use is specified by the application in use. >>=20 >> NEW: >> Links with the anchor parameter MUST be ignored by consuming = implementations, unless its use is specified by the application and/or = relation type in use. >>=20 >> works? >=20 > That's better, in that it clarifies that the anchor parameter never = ever can be ignored. >=20 > However, it still delegates the decision to the "fuzzy" term = "application" or the relation type registration (why would that be = involved?). >=20 > How about: >=20 > "The presence of the anchor parameter affects the context IRI. Thus, = consumers either MUST ignore all links that include the anchor = parameter, or process it according to . In the latter case, the = resulting context IRI can identify an entirely different resource, in = which case consumers MAY choose to ignore the link." >=20 > Best regards, Julian >=20 >=20 -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Fri Feb 26 01:47:18 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA8528C11E for ; Fri, 26 Feb 2010 01:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[AWL=-0.779, 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 4Gg1Ruk2YV2s for ; Fri, 26 Feb 2010 01:47:17 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 951C928C11A for ; Fri, 26 Feb 2010 01:47:16 -0800 (PST) Received: (qmail invoked by alias); 26 Feb 2010 09:49:28 -0000 Received: from p508FCB96.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.203.150] by mail.gmx.net (mp066) with SMTP; 26 Feb 2010 10:49:28 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/krm9lJ9HkajPjmS9onx5iRJYqTwZ49nwU3Ojw/p g2UiXV3Sm0Q3rU Message-ID: <4B879921.9060900@gmx.de> Date: Fri, 26 Feb 2010 10:49:21 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Mark Nottingham Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> <4B596450.7020001@gmx.de> <4B62D875.102@gmx.de> <7B248F44-44D9-4054-84A2-E9C4C5C251E1@mnot.net> <4B6C1144.4090502@gmx.de> <5C1BFD92-7E8D-4ABF-A986-03ADC50A18CD@mnot.net> <4B7E5A62.6080304@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59999999999999998 Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 09:47:18 -0000 On 26.02.2010 05:44, Mark Nottingham wrote: > What's here? I still don't see where the decision is made... at worst, this makes it seem like consumers can make an arbitrary decision as to whether to process a link with an anchor. would point to text that states how to resolve against the context IRI when present. And yes, I think consumers can make an almost arbitrary decision about it -- either they ignore the syntax they don't grok, or they process it as specified (where there's really only a single way to process them). > This is where I am now: > > Links with the anchor parameter MUST be ignored by consuming implementations, unless their use is explicitly specified. That doesn't work for me, as it makes it sound that somebody needs to do additional work to "specify" it. Who? And what? The only thing that needs to be said is that the anchor param modifies the context, and recipients are allowed to ignore it if the resolved context IRI differs from the original one. So how about (adding more context): "The anchor parameter overrides this with another URI, such as a fragment of this resource, or a third resource (i.e., when the anchor value is an absolute URI). If the anchor parameter's value is a relative URI, parsers MUST resolve it as per [RFC3986], Section 5. Note that any base URI from the body's content is not applied. Note that the presence of the anchor parameter affects the context IRI. Thus, consumers either MUST ignore all links that include the anchor parameter, or process it according to its definition above. In the latter case, the resulting context IRI can identify an entirely different resource, in which case consumers can choose to ignore the link." (We might have to tune the paragraph for the case where the context resource is anonymous, though) > ... Best regards, Julian From julian.reschke@gmx.de Fri Feb 26 08:02:06 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A6428C1AC for ; Fri, 26 Feb 2010 08:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.363 X-Spam-Level: X-Spam-Status: No, score=-4.363 tagged_above=-999 required=5 tests=[AWL=-1.764, 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 0ELAfKjUiCIC for ; Fri, 26 Feb 2010 08:02:04 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BEE1C28C1B0 for ; Fri, 26 Feb 2010 08:02:03 -0800 (PST) Received: (qmail invoked by alias); 26 Feb 2010 16:04:17 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 26 Feb 2010 17:04:17 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+b6GhBlEmbEEmu49HErnqzDiLHG9Fw6LBsrQeAc6 1uZ/hmQk7yVqh4 Message-ID: <4B87F0FB.6090605@gmx.de> Date: Fri, 26 Feb 2010 17:04:11 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Thomas Roessler Subject: Re: draft-reschke-rfc2231-in-http: section 4.2, Error Handling References: <4c80fa21002241136y629dda22l1d7617eb25250af8@mail.gmail.com> In-Reply-To: <4c80fa21002241136y629dda22l1d7617eb25250af8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59999999999999998 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 16:02:06 -0000 On 24.02.2010 20:36, Thomas Roessler wrote: > Reviewing http://www.ietf.org/id/draft-reschke-rfc2231-in-http-10.txt, > section 4.2 says: > > Header specifications that include parameters should also specify > whether same-named parameters can occur multiple times. If > repetitions are not allowed (and this is believed to be the common > case), the specification should state whether regular or the extended > syntax takes precedence. In the latter case, this could be used by > producers to use both formats without breaking recipients that do not > understand the syntax. > > Leaving the choice of precedence to the header specification implies > that parsers need to special-case. It would seem reasonable to make a > choice in this specification that for properties which can only occur > once, the traditional syntax takes precedence. That would rule out the use case where the traditional syntax is used as a fallback for clients that do not support the new syntax, as discussed in that section: "Header specifications that include parameters should also specify whether same-named parameters can occur multiple times. If repetitions are not allowed (and this is believed to be the common case), the specification should state whether regular or the extended syntax takes precedence. In the latter case, this could be used by producers to use both formats without breaking recipients that do not understand the syntax. Example: foo: bar; title="EURO exchange rates"; title*=utf-8''%e2%82%ac%20exchange%20rates In this case, the sender provides an ASCII version of the title for legacy recipients, but also includes an internationalized version for recipients understanding this specification -- the latter obviously should prefer the new syntax over the old one." is a test case that shows that using this technique, both variants can be served to clients, and those that understand the ext-parameter encoding will indeed pick the "better" parameter. Unfortunately, this appears to depend on parameter ordering, which I didn't want to mention in this spec. Maybe I should? Best regards, Julian PS: tracked as . From roessler@gmail.com Fri Feb 26 09:40:52 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF21628C279 for ; Fri, 26 Feb 2010 09:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr6fKKchWp2L for ; Fri, 26 Feb 2010 09:40:52 -0800 (PST) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id 14A1F28C264 for ; Fri, 26 Feb 2010 09:40:51 -0800 (PST) Received: by gxk6 with SMTP id 6so159969gxk.14 for ; Fri, 26 Feb 2010 09:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=hjeWuXjkgMm+qZ7ySoS+7CewKKYCHcT0hvg7/hP61z8=; b=mjsA7sP52G0s8puwHd31B9Dei7cw+G8IKq8spN3A5O9fwUNQOwu0DhrjpXgTp8CWwN 46VmBEuTcaIQAqcxcMnwNnm7vEHkZ+HuKT+BC7ENl6BBz7nVhFe7Jvz8EYMvcKWdQ+Yg O+XLoaU1qm9SvYVuAg1XCmV09kd1Zk1FZnS1U= 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=BRB5Ej7fHQWlfCChYIJ7+cpn1HKj6bYcFd7XM6pzToAhTrn4Oq7AQXxpVrSLVQJhXV tY/diQUJ4tmMYckWXEU08nLxCpBM1P6xFWo2VGMZpQlKblwQ2wJfZkZ214NQiWKS8xBy B860jFPlg4kr+WJY6z8ku/FwKLV4j51v4WkG0= MIME-Version: 1.0 Sender: roessler@gmail.com Received: by 10.101.130.13 with SMTP id h13mr1181566ann.47.1267206179190; Fri, 26 Feb 2010 09:42:59 -0800 (PST) In-Reply-To: <4B87F0FB.6090605@gmx.de> References: <4c80fa21002241136y629dda22l1d7617eb25250af8@mail.gmail.com> <4B87F0FB.6090605@gmx.de> Date: Fri, 26 Feb 2010 18:42:59 +0100 X-Google-Sender-Auth: de688597a1f16000 Message-ID: <4c80fa21002260942g3aacf02ak20510ca9d9c0659@mail.gmail.com> Subject: Re: draft-reschke-rfc2231-in-http: section 4.2, Error Handling From: Thomas Roessler To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 17:40:53 -0000 On Fri, Feb 26, 2010 at 5:04 PM, Julian Reschke wrote: >> Leaving the choice of precedence to the header specification implies >> that parsers need to special-case. It would seem reasonable to make a >> choice in this specification that for properties which can only occur >> once, the traditional syntax takes precedence. > > That would rule out the use case where the traditional syntax is used as a > fallback for clients that do not support the new syntax, as discussed in > that section: > > "Header specifications that include parameters should also specify whether > same-named parameters can occur multiple times. If repetitions are not > allowed (and this is believed to be the common case), the specification > should state whether regular or the extended syntax takes precedence. In the > latter case, this could be used by producers to use both formats without > breaking recipients that do not understand the syntax. That's a compelling argument for choosing "new style takes precedence" in the spec; I don't know of good arguments the other way. My main point is that I think we should make a choice (and either of the possible choices sounds reasonable), not which of the specific choices it should be. From mnot@mnot.net Sun Feb 28 03:22:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7116B3A8708 for ; Sun, 28 Feb 2010 03:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KjzbjA956GN for ; Sun, 28 Feb 2010 03:22:14 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 520363A7507 for ; Sun, 28 Feb 2010 03:22:14 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.189.113]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E5F22509DA; Sun, 28 Feb 2010 06:22:06 -0500 (EST) Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4B879921.9060900@gmx.de> Date: Sun, 28 Feb 2010 22:22:02 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <7D7C8ED7-F5B0-4B2A-89B8-26BB4D469ADE@mnot.net> References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> <4B596450.7020001@gmx.de> <4B62D875.102@gmx.de> <7B248F44-44D9-4054-84A2-E9C4C5C251E1@mnot.net> <4B6C1144.4090502@gmx.de> <5C1BFD92-7E8D-4ABF-A986-03ADC50A18CD@mnot.net> <4B7E5A62.6080304@gmx.de> <4B879921.9060900@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1077) Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2010 11:22:15 -0000 I think we're saying the same thing here, but your text seems to rely = upon the reader to understand that it's underspecified purposefully (the = "syntax they don't grok"), whereas I'd like to surface that in the = document. I know it's a bit messy, but there *is* a concept of something that says = "when you're using links for X, this is valid, this isn't."=20 I.e., consumers don't just pick a number from /dev/random to determine = whether or not they pay attention to links with anchor parameters; it's = written down somewhere, based on what they're doing with the link.=20 I hesitate to make this into a big deal, especially since we're so close = (I think) to having this out the door, but letting clients make an = arbitrary decision is horrible for interoperability. If I'm using a link = header to tell a web browser where a stylesheet is, I should be able to = expect that different implementations will behave the same way with = regard to it. On 26/02/2010, at 8:49 PM, Julian Reschke wrote: > On 26.02.2010 05:44, Mark Nottingham wrote: >> What's here? I still don't see where the decision is made... at = worst, this makes it seem like consumers can make an arbitrary decision = as to whether to process a link with an anchor. >=20 > would point to text that states how to resolve against the = context IRI when present. >=20 > And yes, I think consumers can make an almost arbitrary decision about = it -- either they ignore the syntax they don't grok, or they process it = as specified (where there's really only a single way to process them). >=20 >> This is where I am now: >>=20 >> Links with the anchor parameter MUST be ignored by consuming = implementations, unless their use is explicitly specified. >=20 > That doesn't work for me, as it makes it sound that somebody needs to = do additional work to "specify" it. Who? And what? The only thing that = needs to be said is that the anchor param modifies the context, and = recipients are allowed to ignore it if the resolved context IRI differs = from the original one. >=20 > So how about (adding more context): >=20 > "The anchor parameter overrides this with another URI, such as a = fragment of this resource, or a third resource (i.e., when the anchor = value is an absolute URI). If the anchor parameter's value is a = relative URI, parsers MUST resolve it as per [RFC3986], Section 5. Note = that any base URI from the body's content is not applied. >=20 > Note that the presence of the anchor parameter affects the context = IRI. Thus, consumers either MUST ignore all links that include the = anchor parameter, or process it according to its definition above. In = the latter case, the resulting context IRI can identify an entirely = different resource, in which case consumers can choose to ignore the = link." >=20 > (We might have to tune the paragraph for the case where the context = resource is anonymous, though) >=20 > > ... >=20 > Best regards, Julian -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Sun Feb 28 12:22:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C19328C18D for ; Sun, 28 Feb 2010 12:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTwvDTMzdfFc for ; Sun, 28 Feb 2010 12:22:27 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 405163A89A3 for ; Sun, 28 Feb 2010 12:22:24 -0800 (PST) Received: (qmail invoked by alias); 28 Feb 2010 20:22:00 -0000 Received: from p508FD845.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.216.69] by mail.gmx.net (mp066) with SMTP; 28 Feb 2010 21:22:00 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/966tgZ+H9w0XJH/Jg1+O+rSetxpL15BfvpVn13n tdVRIJRpNk9ag0 Message-ID: <4B8AD05F.7080005@gmx.de> Date: Sun, 28 Feb 2010 21:21:51 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Mark Nottingham Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt References: <20100119053002.5CD613A683B@core3.amsl.com> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> <4B596450.7020001@gmx.de> <4B62D875.102@gmx.de> <7B248F44-44D9-4054-84A2-E9C4C5C251E1@mnot.net> <4B6C1144.4090502@gmx.de> <5C1BFD92-7E8D-4ABF-A986-03ADC50A18CD@mnot.net> <4B7E5A62.6080304@gmx.de> <4B879921.9060900@gmx.de> <7D7C8ED7-F5B0-4B2A-89B8-26BB4D469ADE@mnot.net> In-Reply-To: <7D7C8ED7-F5B0-4B2A-89B8-26BB4D469ADE@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.60999999999999999 Cc: Apps Discuss , HTTP Working Group X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2010 20:22:28 -0000 On 28.02.2010 12:22, Mark Nottingham wrote: > I think we're saying the same thing here, but your text seems to rely upon the reader to understand that it's underspecified purposefully (the "syntax they don't grok"), whereas I'd like to surface that in the document. Not sure. The thing I didn't like in your proposal is that it sounds like somebody (who?) needs to do something special to make the anchor parameter work. > I know it's a bit messy, but there *is* a concept of something that says "when you're using links for X, this is valid, this isn't." > > I.e., consumers don't just pick a number from /dev/random to determine whether or not they pay attention to links with anchor parameters; it's written down somewhere, based on what they're doing with the link. > > I hesitate to make this into a big deal, especially since we're so close (I think) to having this out the door, but letting clients make an arbitrary decision is horrible for interoperability. If I'm using a link header to tell a web browser where a stylesheet is, I should be able to expect that different implementations will behave the same way with regard to it. I think we agree that a recipient can't ignore the anchor parameter, right? -- and that's what the two UA impls of the Link header currently do. What the spec needs to say in some way is: "either process the anchor parameter, or ignore all links that contain it" With respect to the stylesheet example: let's assume that I want to add an extension to my server that attaches stylesheet links to 404 response bodies (where the context resource is anonymous, as described in ). Let's further assume that the people who did specify "stylesheet" didn't think of this use case. How do I get that working later on, then? Best regards, Julian