idnits 2.17.1 draft-young-md-query-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 17, 2017) is 2468 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Young, Ed. 3 Internet-Draft Independent 4 Intended status: Informational July 17, 2017 5 Expires: January 18, 2018 7 Metadata Query Protocol 8 draft-young-md-query-07 10 Abstract 12 This document defines a simple protocol for retrieving metadata about 13 named entities, or named collections of entities. The goal of the 14 protocol is to profile various aspects of HTTP to allow requesters to 15 rely on certain, rigorously defined, behaviour. 17 This document is a product of the Research and Education Federations 18 (REFEDS) Working Group process. 20 Editorial Note (To be removed by RFC Editor before publication) 22 Discussion of this draft takes place on the MDX mailing list 23 (mdx@lists.iay.org.uk), which is accessed from [MDX.list]. 25 XML versions, latest edits and the issues list for this document are 26 available from [md-query]. 28 The changes in this draft are summarized in Appendix A.8. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 18, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Notation and Conventions . . . . . . . . . . . . . . . . 3 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Protocol Transport . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Transport Protocol . . . . . . . . . . . . . . . . . . . 4 66 2.2. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.4. Request Headers . . . . . . . . . . . . . . . . . . . . . 4 69 2.5. Response Headers . . . . . . . . . . . . . . . . . . . . 5 70 2.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . 5 71 2.7. Base URL . . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.8. Content Negotiation . . . . . . . . . . . . . . . . . . . 6 73 3. Metadata Query Protocol . . . . . . . . . . . . . . . . . . . 6 74 3.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.2.1. Request by Identifier . . . . . . . . . . . . . . . . 7 77 3.2.2. Request All Entities . . . . . . . . . . . . . . . . 8 78 3.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 8 79 3.2.4. Example Request and Response . . . . . . . . . . . . 8 80 4. Efficient Retrieval and Caching . . . . . . . . . . . . . . . 9 81 4.1. Conditional Retrieval . . . . . . . . . . . . . . . . . . 9 82 4.2. Content Caching . . . . . . . . . . . . . . . . . . . . . 9 83 4.3. Content Compression . . . . . . . . . . . . . . . . . . . 9 84 5. Protocol Extension Points . . . . . . . . . . . . . . . . . . 10 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 6.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 10 87 6.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 10 88 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . 10 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 93 9.2. Informative References . . . . . . . . . . . . . . . . . 12 94 Appendix A. Change Log (to be removed by RFC Editor before 95 publication) . . . . . . . . . . . . . . . . . . . . 13 96 A.1. Since draft-lajoie-md-query-01 . . . . . . . . . . . . . 13 97 A.2. Since draft-young-md-query-00 . . . . . . . . . . . . . . 13 98 A.3. Since draft-young-md-query-01 . . . . . . . . . . . . . . 14 99 A.4. Since draft-young-md-query-02 . . . . . . . . . . . . . . 14 100 A.5. Since draft-young-md-query-03 . . . . . . . . . . . . . . 14 101 A.6. Since draft-young-md-query-04 . . . . . . . . . . . . . . 14 102 A.7. Since draft-young-md-query-05 . . . . . . . . . . . . . . 15 103 A.8. Since draft-young-md-query-06 . . . . . . . . . . . . . . 15 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 106 1. Introduction 108 Many clients of web-based services are capable of consuming 109 descriptive metadata about a service in order to customize or obtain 110 information about the client's connection parameters. While the form 111 of the metadata (e.g., JSON, XML) and content varies between services 112 this document specifies a set of semantics for HTTP ([RFC7230] et 113 seq.) that allow clients to rely on certain behavior. The defined 114 behavior is meant to make it easy for clients to perform queries, to 115 be efficient for both requesters and responders, and to allow the 116 responder to scale in various ways. 118 The Research and Education Federations group ([REFEDS]) is the voice 119 that articulates the mutual needs of research and education identity 120 federations worldwide. It aims to represent the requirements of 121 research and education in the ever-growing space of access and 122 identity management. 124 From time to time REFEDS will wish to publish a document in the 125 Internet RFC series. Such documents will be published as part of the 126 RFC Independent Submission Stream [RFC4844]; however the REFEDS 127 working group sign-off process will have been followed for these 128 documents, as described in the REFEDS Participant's Agreement 129 [REFEDS.agreement]. 131 This document is a product of the REFEDS Working Group process. 133 1.1. Notation and Conventions 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [BCP14]. 139 This document makes use of the Augmented BNF metalanguage defined in 140 [STD68]. 142 1.2. Terminology 144 entity: A single logical construct for which metadata may be 145 asserted. Generally this is a network accessible service. 147 metadata: A machine readable description of certain entity 148 characteristics. Generally metadata provides information such as 149 end point references, service contact information, etc. 151 2. Protocol Transport 153 The metadata query protocol seeks to fully employ the features of the 154 HTTP protocol. Additionally this specification makes mandatory some 155 optional HTTP features. 157 2.1. Transport Protocol 159 The metadata query protocol makes use of the HTTP protocol 160 ([RFC7230]) to transmit requests and responses. The underlying HTTP 161 connection MAY make use of any appropriate transport protocol. In 162 particular, the HTTP connection MAY make use of either TCP or TLS at 163 the transport layer. See the Security Considerations section for 164 guidance in choosing an appropriate transport protocol. 166 2.2. HTTP Version 168 Requests from clients MUST NOT use an HTTP version prior to version 169 1.1. Responders MUST reply to such requests using status code 505, 170 "HTTP Version Not Supported". 172 Protocol responders MUST support requests using HTTP version 1.1, and 173 MAY support later versions. 175 2.3. HTTP Method 177 All metadata query requests MUST use the GET method. 179 2.4. Request Headers 181 All metadata query requests MUST include the following HTTP headers: 183 Accept - this header MUST contain the content-type identifying the 184 type, or form, of metadata to be retrieved. See section 5.3.2 of 185 [RFC7231]. 187 All metadata query requests SHOULD include the following HTTP 188 headers: 190 Accept-Charset, see section 5.3.3 of [RFC7231] 192 Accept-Encoding, see section 5.3.4 of [RFC7231] 194 A metadata request to the same URL, after an initial request, MUST 195 include the following header: 197 If-None-Match, see section 3.2 of [RFC7232]. 199 2.5. Response Headers 201 All successful metadata query responses (even those that return no 202 results) MUST include the following headers: 204 Content-Encoding - required if, and only if, content is 205 compressed. See section 3.1.2.2 of [RFC7231]. 207 Content-Type, see section 3.1.1.5 of [RFC7231]. 209 ETag, see section 2.3 of [RFC7232]. 211 All metadata retrieval responses SHOULD include the following 212 headers: 214 Cache-Control, see section 5.2 of [RFC7234]. 216 Content-Length, see section 3.3.2 of [RFC7230] 218 Last-Modified, see section 2.2 of [RFC7232]. 220 2.6. Status Codes 222 This protocol uses the following HTTP status codes: 224 200 "OK" - standard response code when returning requested 225 metadata 227 304 "Not Modified" - response code indicating requested metadata 228 has not been updated since the last request 230 400 "Bad Request" - response code indicating that the requester's 231 request was malformed in some fashion 233 401 "Unauthorized" - response code indicating the request must be 234 authenticated before requesting metadata 235 404 "Not Found" - indicates that the requested metadata could not 236 be found; this MUST NOT be used in order to indicate a general 237 service error. 239 405 "Method Not Allowed" - response code indicating that a non-GET 240 method was used 242 406 "Not Acceptable" - response code indicating that metadata is 243 not available in the request content-type 245 505 "HTTP Version Not Supported" - response code indicating that 246 HTTP/1.1 was not used 248 2.7. Base URL 250 Requests defined in this document are performed by issuing an HTTP 251 GET request to a particular URL ([STD66]). The final component of 252 the path to which requests are issued is defined by the requests 253 specified within this document. A base URL precedes such paths. 254 Such a base URL: 256 o MUST contain the scheme and authority components. 258 o MUST contain a path component ending with a slash ('/') character. 260 o MUST NOT include a query component. 262 o MUST NOT include a fragment identifier component. 264 2.8. Content Negotiation 266 As there may be many representations for a given piece of metadata, 267 agent-driven content negotiation is used to ensure the proper 268 representation is delivered to the requester. In addition to the 269 required usage of the Accept header a responder SHOULD also support 270 the use of the Accept-Charset header. 272 3. Metadata Query Protocol 274 The metadata query protocol retrieves metadata either for all 275 entities known to the responder or for a named collection based on a 276 single "tag" or "keyword" identifier. A request returns information 277 for none, one, or a collection of entities. 279 3.1. Identifiers 281 The query protocol uses identifiers to "tag" metadata for single- and 282 multi-entity metadata collections. The assignment of such 283 identifiers to a particular metadata document is the responsibility 284 of the query responder. If a metadata collection already contains a 285 well known identifier it is RECOMMENDED that such a natural 286 identifier is used when possible. Any given metadata collection MAY 287 have more than one identifier associated with it. 289 An identifier used in the query protocol is a non-empty sequence of 290 arbitrary 8-bit characters: 292 id = 1*idchar 293 idchar = %x00-ff ; any encodable character 295 3.2. Protocol 297 3.2.1. Request by Identifier 299 A metadata query request for all entities tagged with a particular 300 identifier is performed by issuing an HTTP GET request to a URL 301 constructed as the concatenation of the following components: 303 o The responder's base URL. 305 o The string "entities/". 307 o A single identifier, percent-encoded appropriately for use as a 308 URL path segment (see sections 2.1 and 3.3 of [STD66]). 310 For example, with a base URL of "http://example.org/mdq/", a query 311 for the identifier "foo" would be performed by an HTTP GET request to 312 the following URL: 314 http://example.org/mdq/entities/foo 316 Correct encoding of the identifier as a URL path segment is critical 317 for interoperability. In particular: 319 The character '/' MUST be percent-encoded. 321 The space character MUST be encoded as '%20' and MUST NOT be 322 encoded as '+' as would be required in a query parameter. 324 For example, with a base URL of "http://example.org/mdq/", a query 325 for the identifier ""blue/green+light blue"" would be performed by an 326 HTTP GET request to the following URL: 328 http://example.org/mdq/entities/blue%2Fgreen+light%20blue 330 3.2.2. Request All Entities 332 A metadata query request for all entities known to the responder is 333 performed by issuing an HTTP GET request to a URL constructed as the 334 concatenation of the following components: 336 o The responder's base URL. 338 o The string "entities". 340 For example, with a base URL of "http://example.org/mdq/", a query 341 for all entities would be performed by an HTTP GET request to the 342 following URL: 344 http://example.org/mdq/entities 346 3.2.3. Response 348 The response to a metadata query request MUST be a document that 349 provides metadata for the given request in the format described by 350 the request's Accept header. 352 The responder is responsible for ensuring that the metadata returned 353 is valid. If the responder can not create a valid document it MUST 354 respond with a 406 status code. An example of such an error would be 355 the case where the result of the query is metadata for multiple 356 entities but the request content type does not support returning 357 multiple results in a single document. 359 3.2.4. Example Request and Response 361 The following example demonstrates a metadata query request using a 362 base URL of "http://metadata.example.org/service/" and the identifier 363 "http://example.org/idp". 365 GET /service/entities/http:%2F%2Fexample.org%2Fidp HTTP/1.1 366 Host: metadata.example.org 367 Accept: application/samlmetadata+xml 369 Example Metadata Query Request 371 HTTP/1.x 200 OK 372 Content-Type: application/samlmetadata+xml 373 ETag: "abcdefg" 374 Last-Modified: Thu, 15 Apr 2010 12:45:26 GMT 375 Content-Length: 1234 377 378 380 .... 382 Example Metadata Query Response 384 4. Efficient Retrieval and Caching 386 4.1. Conditional Retrieval 388 Upon a successful response the responder MUST return an ETag header 389 and MAY return a Last-Modified header as well. Requesters SHOULD use 390 either or both, with the ETag being preferred, in any subsequent 391 requests for the same resource. 393 In the event that a resource has not changed since the previous 394 request, the responder SHOULD send a 304 (Not Modified) status code 395 as a response. 397 4.2. Content Caching 399 Responders SHOULD include cache control information with successful 400 (200 status code) responses, assuming the responder knows when 401 retrieved metadata is meant to expire. The responder SHOULD also 402 include cache control information with 404 Not Found responses. This 403 allows the requester to create and maintain a negative-response 404 cache. When cache controls are used only the 'max-age' directive 405 SHOULD be used. 407 4.3. Content Compression 409 As should be apparent from the required request and response headers 410 this protocol encourages the use of content compression. This is in 411 recognition that some metadata documents can be quite large or 412 fetched with relatively high frequency. 414 Requesters SHOULD support, and advertise support for, gzip 415 compression unless such usage would put exceptional demands on 416 constrained environments. Responders MUST support gzip compression. 417 Requesters and responders MAY support other compression algorithms. 419 5. Protocol Extension Points 421 The Metadata Query Protocol is extensible using the following 422 protocol extension points: 424 o Profiles of this specification may assign semantics to specific 425 identifiers, or to identifiers structured in particular ways. 427 o Profiles of this specification may define additional paths (other 428 than "entities" and "entities/") below the base URL. 430 6. Security Considerations 432 6.1. Integrity 434 As metadata often contains information necessary for the secure 435 operation of interacting services it is RECOMMENDED that some form of 436 content integrity checking be performed. This may include the use of 437 TLS at the transport layer, digital signatures present within the 438 metadata document, or any other such mechanism. 440 6.2. Confidentiality 442 In many cases service metadata is public information and therefore 443 confidentiality is not required. In the cases where such 444 functionality is required, it is RECOMMENDED that both the requester 445 and responder support TLS. Other mechanisms, such as XML encryption, 446 MAY also be supported. 448 6.3. Authentication 450 All responders which require client authentication to view retrieved 451 information MUST support the use of HTTP basic authentication 452 ([RFC7235], [RFC2617]/[I-D.basicauth]) over TLS. Responders SHOULD 453 also support the use of X.509 client certificate authentication. 455 7. IANA Considerations 457 This document has no actions for IANA. 459 8. Acknowledgements 461 The editor would like to acknowledge the following individuals for 462 their contributions to this document: 464 Scott Cantor (The Ohio State University) 466 Leif Johansson (SUNET) 467 Thomas Lenggenhager (SWITCH) 469 Joe St Sauver (University of Oregon) 471 Tom Scavo (Internet2) 473 Special acknowledgement is due to Chad LaJoie (Covisint) for his work 474 in editing previous versions of this specification. 476 9. References 478 9.1. Normative References 480 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, March 1997. 483 [I-D.basicauth] 484 Reschke, J., "The 'Basic' HTTP Authentication Scheme", 485 draft-ietf-httpauth-basicauth-update-07 (work in 486 progress), February 2015. 488 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 489 Leach, P., Luotonen, A., and L. Stewart, "HTTP 490 Authentication: Basic and Digest Access Authentication", 491 RFC 2617, June 1999. 493 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 494 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 495 2014. 497 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 498 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 500 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 501 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 503 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 504 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 505 2014. 507 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 508 (HTTP/1.1): Authentication", RFC 7235, June 2014. 510 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 511 Resource Identifier (URI): Generic Syntax", STD 66, 512 RFC 3986, January 2005. 514 [STD68] Crocker, D. and P. Overell, "Augmented BNF for Syntax 515 Specifications: ABNF", STD 68, RFC 5234, January 2008. 517 9.2. Informative References 519 [md-query] 520 Young, I., Ed., "md-query Project", 521 . 523 [MDX.list] 524 Young, I., Ed., "MDX Mailing List", 525 . 527 [REFEDS] Research and Education Federations, "REFEDS Home Page", 528 . 530 [REFEDS.agreement] 531 Research and Education Federations, "REFEDS Participant's 532 Agreement", . 535 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 536 Series and RFC Editor", RFC 4844, July 2007. 538 Appendix A. Change Log (to be removed by RFC Editor before publication) 540 A.1. Since draft-lajoie-md-query-01 542 Adopted as base for draft-young-md-query-00. 544 Updated author and list of contributors. 546 Changed ipr from "pre5378Trust200902" to "trust200902", submission 547 type from IETF to independent and category from experimental to 548 informational. 550 Added empty IANA considerations section. 552 Minor typographical nits but (intentionally) no substantive content 553 changes. 555 A.2. Since draft-young-md-query-00 557 Split into two documents: this one is as agnostic as possible around 558 questions such as metadata format and higher level protocol use 559 cases, a new layered document describes the detailed requirements for 560 SAML support. 562 Rewrite Section 3.2.1 to clarify construction of the request URL and 563 its relationship to the base URL. 565 Added Section 2.1 to clarify that the transport protocol underlying 566 HTTP may be either TCP or SSL/TLS. 568 Clarify position on HTTP versions (Section 2.2) which may be used to 569 underly this protocol. 571 Added Change Log modelled on draft-ietf-httpbis-http2. 573 Added a reference to [STD68]. Use ABNF to describe request syntax. 574 Replace transformed identifier concept with extended identifiers 575 (this also resulted in the removal of any discussion of specific 576 transformed identifier formats). Add grammar to distinguish basic 577 from extended identifiers. 579 Changed the required response when the result can not be validly 580 expressed in the requested format from 500 to 406. 582 Removed the '+' operator and all references to multiple identifiers 583 in queries. If more complex queries are required, these will be 584 reintroduced at a different path under the base URL. 586 Added a section describing Protocol Extension Points. 588 A.3. Since draft-young-md-query-01 590 Added REFEDS RFC stream boilerplate. 592 Tidied up some normative language. 594 A.4. Since draft-young-md-query-02 596 Introduced a normative reference to [STD66]. 598 Reworked the definition of the base URL so that a non-empty path 599 ending with '/' is required. This allows the definition of request 600 URLs to be simplified. 602 Clarified the definition of the base URL to exclude a query 603 component; corrected the terminology for the fragment identifier 604 component. 606 Added the definition for the query for all entities in Section 3.2.2. 608 Corrected an example in Section 3.2.4 to include the required double 609 quotes in the value of an ETag header. Added text to clarify the 610 base URL and identifier being used in the example. 612 Simplified the definition of identifiers, so that any non-empty 613 identifier is accepted and no semantics are defined for particular 614 structures. Extended syntaxes such as the "{sha1}" notation for 615 transformed identifiers are now left to profiles. 617 Remove incidental references to SSL. 619 Remove status code 501 ("not implemented") as it is no longer 620 referenced. 622 A.5. Since draft-young-md-query-03 624 Correct a typo in the identifier grammar. 626 A.6. Since draft-young-md-query-04 628 Updated to rely on the new definition of HTTP/1.1 in [RFC7230] et 629 seq. instead of RFC 2616. 631 Corrected Section 3.2.3 to indicate that the request contains an 632 Accept header, not a Content-Type header. 634 Added an Editorial Note to help direct readers back to the 635 discussion. 637 A.7. Since draft-young-md-query-05 639 Remove unnecessary percent-encoding of a ':' character in the example 640 in Section 3.2.4. 642 Removed use of the ambiguous term "URL-encoded" in Section 3.2.1. 643 Instead, indicate that the encoding must correspond to the rules for 644 encoding a URL path segment specifically, and call out some of the 645 more important implications arising from that. Added a new example 646 illustrating these implications. 648 Updated the description of conditional retrieval in Section 4.1 to 649 make the use of a 304 (Not Modified) status code a normative but non- 650 mandatory obligation on the responder, not simply a description of 651 what the requester will receive. 653 A.8. Since draft-young-md-query-06 655 No substantive changes. 657 Author's Address 659 Ian A. Young (editor) 660 Independent 662 EMail: ian@iay.org.uk