draft-ietf-rescap-scenarios-00.txt   draft-ietf-rescap-scenarios-01.txt 
IETF RESCAP WG G. Klyne, Content Technologies IETF RESCAP WG G. Klyne, MIMEsweeper Group
Expires: September 2000 Internet draft 9 January 2002
RESCAP Scenarios RESCAP Scenarios
<draft-ietf-rescap-scenarios-00.txt> <draft-ietf-rescap-scenarios-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress". progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
West Coast).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2000. All Rights Reserved. Copyright (C) The Internet Society 2002. All Rights Reserved.
Abstract Abstract
This memo explores some scenarios for the resource capabaility This memo explores some scenarios for the resource capabaility
discovery protocol (RESCAP). It is intended to provide some discovery protocol (RESCAP). It is intended to provide some
grounding in specific use-cases for decisions about RESCAP goals grounding in specific use-cases for decisions about RESCAP goals
and design. and design.
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
Table of contents Table of contents
1. Introduction.............................................3 1. Introduction.............................................3
1.1 Structure of this document ...........................3 1.1 Structure of this document ...........................3
1.2 Document terminology and conventions .................3 1.2 Document terminology and conventions .................3
1.3 Discussion of this document ..........................3 1.3 Discussion of this document ..........................3
2. General issues...........................................4 2. General issues...........................................4
3. Scenarios................................................5 3. Scenarios................................................5
3.1 Mail user agent capability discovery .................5 3.1 Mail user agent capability discovery .................5
skipping to change at page 3, line 5 skipping to change at page 3, line 5
5.5 Firewall configuration disclosure ....................15 5.5 Firewall configuration disclosure ....................15
5.6 Denial of service ....................................15 5.6 Denial of service ....................................15
6. Security considerations..................................15 6. Security considerations..................................15
6.1 Authentication .......................................15 6.1 Authentication .......................................15
7. Acknowledgements.........................................15 7. Acknowledgements.........................................15
8. References...............................................16 8. References...............................................16
8. Author's address.........................................17 8. Author's address.........................................17
Appendix A: Amendment history...............................17 Appendix A: Amendment history...............................17
Full copyright statement....................................17 Full copyright statement....................................17
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
1. Introduction 1. Introduction
This memo explores some scenarios for the resource capabaility This memo explores some scenarios for the resource capabaility
discovery protocol (RESCAP). It is intended to provide some discovery protocol (RESCAP). It is intended to provide some
grounding in specific use-cases for decisions about RESCAP goals grounding in specific use-cases for decisions about RESCAP goals
and design. and design.
1.1 Structure of this document 1.1 Structure of this document
skipping to change at page 3, line 44 skipping to change at page 3, line 45
NOTE: Comments like this provide additional nonessential NOTE: Comments like this provide additional nonessential
information about the rationale for parts of this information about the rationale for parts of this
document. document.
[[[Editorial comments and questions about outstanding issues are [[[Editorial comments and questions about outstanding issues are
provided in triple brackets like this. These working comments provided in triple brackets like this. These working comments
should be resolved and removed prior to final publication.]]] should be resolved and removed prior to final publication.]]]
1.3 Discussion of this document 1.3 Discussion of this document
Discussion of this document should take place on the Instant Discussion of this document should take place on the Resource
Messaging and Presence Protocol mailing list. Please send comments Capability Protocol (RESCAP) mailing list. Please send comments
regarding this document to: regarding this document to:
<rescap@cs.utk.edu> <rescap@cs.utk.edu>
To subscribe to this list, send a message to "<rescap- To subscribe to this list, send a message to "<rescap-
request@cs.utk.edu>" containing the command "subscribe rescap" in request@cs.utk.edu>" containing the command "subscribe rescap" in
the message body. the message body.
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
To see what has gone on before you subscribed, please see the To see what has gone on before you subscribed, please see the
mailing list archive at: mailing list archive at:
ftp://cs.utk.edu/pub/rescap ftp://cs.utk.edu/pub/rescap
2. General issues 2. General issues
The RESCAP working group charter sets out the motivation and goals The RESCAP working group charter sets out the motivation and goals
for the RESCAP protocol: for the RESCAP protocol:
skipping to change at page 5, line 5 skipping to change at page 5, line 5
is to deploy it very widely. is to deploy it very widely.
(1) Resolution protocol and server overhead must be very low, as (1) Resolution protocol and server overhead must be very low, as
some applications will make very heavy use of it. some applications will make very heavy use of it.
(2) Identifiers input to the resolution service are to be (2) Identifiers input to the resolution service are to be
formatted as Uniform Resource Identifiers (URIs) containing formatted as Uniform Resource Identifiers (URIs) containing
one or more DNS domains. Note that mail addresses can be one or more DNS domains. Note that mail addresses can be
presented as mailto: URIs to meet this requirement. presented as mailto: URIs to meet this requirement.
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
(3) Facilities to support inheritance within the attribute store (3) Facilities to support inheritance within the attribute store
will be essential, as the number of identifiers may be very will be essential, as the number of identifiers may be very
large. Specifically, mechanisms are required for large. Specifically, mechanisms are required for
administrators to set default values for members of their administrators to set default values for members of their
administrative domains. administrative domains.
(4) Existing protocols will be profiled for use as part of this (4) Existing protocols will be profiled for use as part of this
service whenever possible rather than developing new service whenever possible rather than developing new
protocols. In particular: protocols. In particular:
skipping to change at page 6, line 5 skipping to change at page 6, line 5
Type of resource: Type of resource:
o a mailbox, identified by a 'mailto:' URL [1, 2]. o a mailbox, identified by a 'mailto:' URL [1, 2].
Type of metadata: Type of metadata:
o Media feature expression o Media feature expression
o Security options o Security options
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
o MIME handling options o MIME handling options
o General capabilities and preferences o General capabilities and preferences
Security threats: Security threats:
o Unauthorized access or disclosure o Unauthorized access or disclosure
o Response spoofing o Response spoofing
skipping to change at page 7, line 5 skipping to change at page 7, line 5
[[[List other kinds of metadata returned]]] [[[List other kinds of metadata returned]]]
Security threats: Security threats:
o Unauthorized access o Unauthorized access
o Response spoofing o Response spoofing
o Firewall configuration disclosure o Firewall configuration disclosure
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
3.3 Resource replica locations 3.3 Resource replica locations
Popular web and FTP resources are often replicated on different Popular web and FTP resources are often replicated on different
servers for fault tolerance and load sharing. Given a URL for one servers for fault tolerance and load sharing. Given a URL for one
copy of a resource, RESCAP might be used to find another copy. copy of a resource, RESCAP might be used to find another copy.
[[[NOTE: DNS NAPTR, etc., might be better used for this purpose]]] [[[NOTE: DNS NAPTR, etc., might be better used for this purpose]]]
Type of resource: Type of resource:
skipping to change at page 8, line 5 skipping to change at page 8, line 5
o Resource location information o Resource location information
Security threats: Security threats:
o Unauthorized access o Unauthorized access
o Response spoofing o Response spoofing
o Firewall configuration disclosure o Firewall configuration disclosure
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
3.5 Capabilities at a telephone number 3.5 Capabilities at a telephone number
Convergence between the Internet and telephone networks is leading Convergence between the Internet and telephone networks is leading
to resources and endpoints accessed from the Internet being to resources and endpoints accessed from the Internet being
identified by telephone numbers. A simple telephone number does identified by telephone numbers. A simple telephone number does
little to indicate the kinds of service available at that endpoint, little to indicate the kinds of service available at that endpoint,
or the protocols that may be used to access the facilities or the protocols that may be used to access the facilities
provided. provided.
skipping to change at page 9, line 5 skipping to change at page 9, line 5
3.6 Public key distribution 3.6 Public key distribution
To conduct secure communications with a given endpoint, a suitable To conduct secure communications with a given endpoint, a suitable
public key for that endpoint may be needed. RESCAP could be one public key for that endpoint may be needed. RESCAP could be one
useful way to publish public key information. useful way to publish public key information.
Type of resource: Type of resource:
o Any communication endpoint o Any communication endpoint
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
Type of metadata: Type of metadata:
o Security options o Security options
Security threats: Security threats:
o The usual issues associated with public key distribution. o The usual issues associated with public key distribution.
3.7 Recognized certification authorities 3.7 Recognized certification authorities
skipping to change at page 10, line 5 skipping to change at page 10, line 5
that the endpoint identification and capability exchange associated that the endpoint identification and capability exchange associated
with traditional facsimile is not provided by the e-mail protocols. with traditional facsimile is not provided by the e-mail protocols.
RESCAP may provide an alternatuve way to access such information, RESCAP may provide an alternatuve way to access such information,
particularly with respect to receiver capabilities. particularly with respect to receiver capabilities.
Even if the proposed content negotiation framework is deployed, Even if the proposed content negotiation framework is deployed,
using RESCAP to obtain capability information cam optimize the using RESCAP to obtain capability information cam optimize the
process by reducing the number of occasions on which additional process by reducing the number of occasions on which additional
message round trips will be needed. message round trips will be needed.
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
Type of resource: Type of resource:
o a mailbox, identified by a 'mailto:' URL [1, 2]. o a mailbox, identified by a 'mailto:' URL [1, 2].
Type of metadata: Type of metadata:
o Level of Internet fax support (e.g. "simple", "extended", "full", o Level of Internet fax support (e.g. "simple", "extended", "full",
"none"). "none").
skipping to change at page 11, line 5 skipping to change at page 11, line 5
o Media feature expression (especially for indicating supported o Media feature expression (especially for indicating supported
audio codecs). audio codecs).
o Security options o Security options
o MIME handling options o MIME handling options
o General capabilities and preferences o General capabilities and preferences
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
Security threats: Security threats:
o Unauthorized access or disclosure o Unauthorized access or disclosure
o Response spoofing o Response spoofing
o Data mining o Data mining
3.10 IPP printer capabilities 3.10 IPP printer capabilities
skipping to change at page 12, line 5 skipping to change at page 12, line 5
capability information. A problem is that it cxan be difficult to capability information. A problem is that it cxan be difficult to
know how far it is reasonable to go in adding supplementary know how far it is reasonable to go in adding supplementary
information to what should be a very lightweight indication of information to what should be a very lightweight indication of
"available/not-available" presence informaton. "available/not-available" presence informaton.
One way to address this problem is to restrict the presence One way to address this problem is to restrict the presence
information to genuine dynamic status information, and to use information to genuine dynamic status information, and to use
RESCAP to access any (less dynamic) supplementary information about RESCAP to access any (less dynamic) supplementary information about
a contact point described by presence information. a contact point described by presence information.
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
Type of resource: Type of resource:
o Presence information contact address -- as a URL. o Presence information contact address -- as a URL.
Type of metadata: Type of metadata:
o General preference and capability information (esp. vCard) o General preference and capability information (esp. vCard)
o Media feature expression o Media feature expression
skipping to change at page 13, line 5 skipping to change at page 13, line 5
binary values). binary values).
o S/MIME public key-certificaton key certificates - used by agents o S/MIME public key-certificaton key certificates - used by agents
acting in a certifying authority (CA) role (list of arbitrary acting in a certifying authority (CA) role (list of arbitrary
binary values). binary values).
o Resonds to requests for S/MIME signed receipts? (Boolean). o Resonds to requests for S/MIME signed receipts? (Boolean).
o Recognizes and interprets S/MIME security labels? (Boolean). o Recognizes and interprets S/MIME security labels? (Boolean).
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
o Acts as an S/MIME secure mailing list? (Boolean). o Acts as an S/MIME secure mailing list? (Boolean).
o Handles signed 'SigningCertificate' attribute? (Boolean). o Handles signed 'SigningCertificate' attribute? (Boolean).
4.2.2 OpenPGP 4.2.2 OpenPGP
OpenPGP related capabilities [6, and associated documents]. OpenPGP related capabilities [6, and associated documents].
o OpenPGP signature types that can be verified (list of strings; o OpenPGP signature types that can be verified (list of strings;
skipping to change at page 14, line 5 skipping to change at page 14, line 5
o Plain text only - MIME not recognized (Boolean). o Plain text only - MIME not recognized (Boolean).
o Supports MIME header extensions [9] (Boolean). o Supports MIME header extensions [9] (Boolean).
o Supports MIME parameter extensions [10] (Boolean). o Supports MIME parameter extensions [10] (Boolean).
o Character sets [11] displayed (String, containing CONNEG media o Character sets [11] displayed (String, containing CONNEG media
feature expression [12], containg character set feature tags [13] feature expression [12], containg character set feature tags [13]
in simple disjunctive form). in simple disjunctive form).
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
o Preferred languages [14] (String, containing CONNEG media feature o Preferred languages [14] (String, containing CONNEG media feature
expression [12], containg language feature tags [13] in simple expression [12], containg language feature tags [13] in simple
disjunctive form). disjunctive form).
o Display line length in characters (Integer). o Display line length in characters (Integer).
o Can handle MHTML [15]? (Boolean). o Can handle MHTML [15]? (Boolean).
o Can handle Content-MD5 [16]? (Boolean). o Can handle Content-MD5 [16]? (Boolean).
skipping to change at page 15, line 5 skipping to change at page 15, line 5
4.5 Resource location information 4.5 Resource location information
Resource location(s) can be described using a URL or a list of Resource location(s) can be described using a URL or a list of
URLs: URLs:
o Single location: URL (String) o Single location: URL (String)
o Multiple locations: list of URLs (List of strings). o Multiple locations: list of URLs (List of strings).
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
5. RESCAP security threats 5. RESCAP security threats
In considering security for RESCAP, note that the general In considering security for RESCAP, note that the general
presumtpion is that the information being provided is public. But presumtpion is that the information being provided is public. But
completely unrestricted access may be inappropriate because that completely unrestricted access may be inappropriate because that
would create an exposure to privacy invasion through data mining would create an exposure to privacy invasion through data mining
activities. Also, there may be requirements to disclose some activities. Also, there may be requirements to disclose some
information only within a closed community. information only within a closed community.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
o Request to server o Request to server
o Response to client o Response to client
7. Acknowledgements 7. Acknowledgements
The initial list of scenarios was largely culled from an informal The initial list of scenarios was largely culled from an informal
meeting of RESCAP working group participants, and from Paul meeting of RESCAP working group participants, and from Paul
Hoffman's RESCAP profile for mail user agents. Hoffman's RESCAP profile for mail user agents.
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
8. References 8. References
[[[Full citations to be supplied]]] [[[Full citations to be supplied]]]
[1] RFC 821, "Simple Mail Transfer Protocol" [1] RFC 821, "Simple Mail Transfer Protocol"
[2] "mailto: URL" [2] "mailto: URL"
[3] SMIME-MSG [3] SMIME-MSG
skipping to change at page 17, line 5 skipping to change at page 17, line 5
[18] RFC 2298, MDNs [18] RFC 2298, MDNs
[19] iCalendar/iMIP [19] iCalendar/iMIP
[20] Mailing list headers [20] Mailing list headers
[21] vCard format [21] vCard format
[22] RFC 2168, URN resolution and DNS NAPTR record [22] RFC 2168, URN resolution and DNS NAPTR record
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
[xx] "xxx" [xx] "xxx"
xxx, yyy xxx, yyy
Internet draft: <xxx> Internet draft: <xxx>
Work in progress, xxx yyyy Work in progress, xxx yyyy
8. Author's address 8. Author's address
Graham Klyne Graham Klyne,
Content Technologies Ltd. MIMEsweeper Group,
1220 Parkview, 1310 Waterside,
Arlington Business Park Arlington Business Park
Theale Theale
Reading, RG7 4SA Reading, RG7 4SA
United Kingdom. United Kingdom.
Telephone: +44 118 930 1300 Telephone: +44 118 930 1300
Facsimile: +44 118 930 1301 Facsimile: +44 118 930 1301
E-mail: GK@ACM.ORG E-mail: GK-ResCap@ninebynine.org
Appendix A: Amendment history Appendix A: Amendment history
00a 30-Mar-2000 Memo initially created. 00a 30-Mar-2000 Memo initially created.
01a 09-Jan-2002 Reissued to Internet-drafts, without significant
change.
TODO TODO
Full copyright statement Full copyright statement
Copyright (C) The Internet Society 1999. All Rights Reserved. Copyright (C) The Internet Society 2002. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages must be followed, or as required to translate it into languages
other than English. other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
<draft-ietf-rescap-scenarios-00.txt> RESCAP Scenarios 9 January 200
<draft-ietf-rescap-scenarios-01.txt>
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 27 change blocks. 
38 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/