Hi folks, Tuesday (27 September 2005)
Below is proposed text for inclusion in the WIMS Protocol spec:
- Miscellaneous global edits to correct some references
- Section 5 "WIMS URI Scheme"
- complete rewrite to be protocol binding neutral (except for default)
- deleted PSI query parameters section
- deleted WIMS 'id', 'object', 'resource', 'subunit' query parameters
- moved 'binding' query parameter to Appendix A (protocol bindings)
- Section 10 "Security Considerations"
- derived from the Security Considerations in WIMS (PWG 5104.2), which
is also a SOAP-based Web Services protocol
- Section 13 "Appendix A - WIMS Protocol Bindings (Normative)"
- Additions to "Normative References"
- Additions to "Informative References"
Bill - there are a number of normative (MUST or SHOULD) conformance
requirements in this new Section 8 "Security Considerations" - I suggest
we add a bullet pointing to these security conformance requirements to
our existing Section 7 "Conformance" - OK?
Comments?
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
------------------------------------------------------------------------
Global Edits
* Change '[RFC2279]' --> '[RFC3629]' (new UTF-8 reference)
* Change '[HTTPAuth]' --> '[RFC2617]' (correct reference)
* Change '[IP]' --> '[RFC791]' (correct reference)
* Change '[IPSec]' --> '[RFC2401]' (correct reference)
* Change '[TCP]' --> '[RFC793]' (correct reference)
* Change '[PWG-SM]' --> '[PWG5105.1]' (correct reference)
------------------------------------------------------------------------
5. WIMS URI Scheme
5.1. Applicability
The WIMS URI scheme MUST only be used to specify absolute URIs. The
WIMS URI scheme MUST NOT be used to specify relative URIs (they would be
meaningless). The WIMS URI scheme MUST only be used to specify the use
of the WIMS abstract protocol defined in this specification implemented
over one of the protocol bindings defined in Appendix A.
Without query parameters, the WIMS URI scheme MUST be used to identify
only a WIMS Agent or WIMS Manager as defined in this WIMS specification.
With the WIMS proxy query parameter ('legacy'), the WIMS URI scheme MAY
be used to reference other management protocols (SNMP, WBEM, etc.).
Without the WIMS binding query parameter ('binding'), the WIMS URI
scheme specifies the WIMS abstract protocol over SOAP/1.2 [SOAP1.2] over
HTTP/1.1 [RFC2616] (see Appendix A of this WIMS specification).
The WIMS URI scheme supports communication between WIMS Agents and WIMS
Managers:
* In the WIMS Agent Interface, the WIMS Agent always initiates the
connection and sends operation requests to the superior WIMS Manager.
* In the WIMS Manager Interface, the WIMS Manager always initiates the
connection and sends operation requests to the subordinate WIMS Agent.
5.2. Associated Port
A WIMS URI that does NOT specify either an alternate port or explicit
alternate binding (in the 'binding' query parameter) MUST be resolved to
IANA-assigned well-known port 80 for HTTP/1.1 [RFC2616], as registered
in [IANA-PORTREG].
See: IANA Port Numbers Registry [IANA-PORTREG].
5.3. Associated MIME Types
A WIMS URI that does NOT specify an alternate presentation layer (in the
'binding' query parameter) MUST be used to identify WIMS Agents or WIMS
Managers that support the "application/soap+xml" MIME type [RFC3902]
(for SOAP bindings) or the "text/xml" MIME type [RFC3023] (for direct
XML bindings encoded in UTF-8 [RFC3629]).
See: IANA MIME Media Types Registry [IANA-MIME].
5.4. Character Encoding
A WIMS URI MUST use [RFC3986] encoding. Every character in the
"unreserved" set [RFC3986] is equivalent to its percent encoding
[RFC3896].
5.5. Syntax
For definitive information on common URI scheme syntax and semantics,
see "Uniform Resource Identifier (URI): Generic Syntax and Semantics"
[RFC3986].
Note: The abstract protocol defined in this WIMS specification
places a limit of 1023 octets (NOT characters) on the maximum length
of a URI. WIMS Agents and WIMS Managers SHOULD be cautious about
depending on URI lengths above 255 octets, because older HTTP/1.1
implementations may not properly support these lengths.
A WIMS URI MUST be represented in absolute form, beginning with the
scheme name followed by a colon. This WIMS specification imports the
normative definitions of 'authority', 'userinfo', 'host', 'port',
'path-absolute', and 'query' from [RFC3986].
The WIMS URI scheme syntax is defined in ABNF as follows:
wimsuri = "pwg-wims:" "//" authority [ path-absolute ] [ "?" query ]
The 'authority' component is defined by [RFC3986] in ABNF as follows:
authority = [ userinfo "@" ] host [ ":" port ]
Literal IPv4 or IPv6 addresses SHOULD NOT be used in WIMS URI, for
reliability in the context of network reconfigurations, NAT/firewall
traversal, and/or mobile managed entities [RFC3986].
The 'port' element SHOULD NOT be used in a WIMS URI for a Legacy Agent
(because the port would apply to the WIMS Proxy rather than the actual
legacy protocol endpoint). See 'Legacy Agent URI Examples' later in
this WIMS specification.
A WIMS URI that does NOT specify either an alternate port or explicit
alternate binding (in the 'binding' query parameter) MUST be resolved to
IANA-assigned well-known port 80 for HTTP/1.1 [RFC2616], as registered
in [IANA-PORTREG].
The semantics of a WIMS URI are that it identifies a WIMS endpoint at a
WIMS Agent or WIMS Manager listening for incoming connections on the
specified host and resolved port, and over HTTP/1.1 [RFC2616] the
Request-URI for the identified endpoint is 'path-absolute' (possibly
qualified by one or more query parameters).
If the 'path-absolute' element is not present in a WIMS URI, it MUST be
given as "/" when used as a Request-URI for a WIMS endpoint (see section
5.1.2 of HTTP/1.1 [RFC2616]).
5.6. Query Parameters
Any of the PWG standard query parameters defined in PSI/1.0 [PWG-5104.2]
may be used in specifying a WIMS URI, although some may not always be
meaningful (e.g., the 'passive' query parameter is only meaningful for a
file transfer binding such as FTP).
Extensions to the PWG standard query parameters 'auth' (Authentication)
and 'sec' (Security) and one new PWG standard query parameter 'binding'
(Protocol Stack) are specified in Appendix A of this specification.
5.7. Examples
5.7.1. WIMS Agent URI Examples
The following are examples of well-formed WIMS URI for WIMS Agents
(e.g., for the 'agentReference' parameter in a SetSchedule request):
pwg-wims://example.com
pwg-wims://example.com/agent
pwg-wims://example.com/agent&binding=soap11.http11
5.7.2. WIMS Manager URI Examples
The following are examples of well-formed WIMS URI for WIMS Managers
(e.g., for the 'managerURI' parameter in a GetSchedule request):
pwg-wims://example.com
pwg-wims://example.com/manager
pwg-wims://example.com/manager?binding=soap12.beep
5.7.3. Legacy Agent URI Examples
The following are examples of well-formed WIMS URI for Legacy Agents
(e.g., for the 'ActionAgentReference' element in a Schedule object):
pwg-wims://example.com?legacy=snmp://bob.com
pwg-wims://example.com/agent?legacy=snmp://bob.com
5.8. Normalization and Comparisons
See section 6 'URI Normalization and Comparison' of [RFC3986].
------------------------------------------------------------------------
8. Security Considerations
This section conforms to all of the best practice recommendations in
"Guidelines for Writing RFC Text on Security Considerations" [RFC3552].
This section defines security conformance requirements applicable to all
WIMS implementations, in addition to the basic conformance requirements
specified in section 6 'WIMS Interface'. This section contains:
(a) Descriptions of the security threats applicable to all WIMS
implementations;
(b) Discussions of these security threats by reference to applicable
underlying protocol specifications (e.g., HTTP/1.1 [RFC2616]);
(c) Definitions of the corresponding security conformance requirements
applicable to all WIMS implementations.
8.1. Internet Threat Model
The following discussion of threats is adapted from section 3 of
[RFC3552].
In the Internet threat model, we assume that the end-systems engaging in
a protocol exchange have not themselves been compromised. Protecting
against an attack when one of the end-systems has itself been
compromised is extraordinarily difficult.
By contrast, we assume that the attacker has nearly complete control
of the communications channel over which the end-systems communicate.
This means that the attacker can read any PDU (Protocol Data Unit) on
the network and undetectably remove, change, or inject forged packets
onto the wire. This includes being able to generate packets that
appear to be from a trusted machine. Thus, even if the end-system
with which you wish to communicate is itself secure, the Internet
environment provides no assurance that packets which claim to be from
that system in fact are.
It's important to realize that the meaning of a PDU is different at
different layers. At the IP layer [RFC791], a PDU means an IP packet.
At the TCP layer [RFC793], it means a TCP segment. At higher layers
it means some kind of higher layer PDU. For instance, at the SOAP layer
[SOAP1.2], it means a single SOAP request or response message, while at
the HTTP layer [RFC2616], it means a single HTTP request or response
message.
8.1.1. Passive Attacks
In a passive attack, the attacker reads packets off the network but
does not write them. The simplest way to mount such an attack is to
simply be on the same LAN as the victim. On most common LAN
configurations, including Ethernet, 802.3, and FDDI, any machine on
the wire can read all traffic destined for any other machine on the
same LAN. Note that switching hubs make this sort of sniffing
substantially more difficult, since traffic destined for a machine
only goes to the network segment that machine is located on.
Wireless communications channels deserve special consideration,
especially with the recent and growing popularity of wireless-based
LANs, such as those using 802.11. Since the data is simply broadcast
on well known radio frequencies, an attacker simply needs to be able
to receive those transmissions. Such channels are especially
vulnerable to passive attacks. Although many such channels include
cryptographic protection, it is often of very poor quality.
Passive attacks described in [RFC3552] and considered in WIMS are:
(1) Confidentiality Violations - exposure of private business data:
(a) WIMS implementations over HTTP/1.1 [RFC2616] or BEEP [RFC3080]
MUST support TLS/1.0 [RFC2616]; and
(b) WIMS implementations over email (SMTP/IMAP4/POP3) MUST support
S/MIME [RFC3851] or OpenPGP [RFC3156].
(2) Password Sniffing - exposure of passwords by an attacker who can
monitor messages on the wire:
(a) WIMS implementations MUST NOT transfer cleartext passwords over
unencrypted channels; and
(b) WIMS implementations SHOULD throttle login attempts from a given
user (e.g., no more than three attempts per minute).
(3) Offline Cryptographic Attacks - dictionary attacks on password-based
challenge/response protocols such as HTTP Digest defined in
[RFC2617] by an attacker who can record a sequence of messages off
the wire:
(a) WIMS implementations over HTTP/1.1 [RFC2616] MUST support
TLS/1.0 [RFC2246]; and
(b) WIMS implementations over BEEP [RFC3080] MUST support TLS/1.0
[RFC2246] and SASL [RFC2222].
8.1.2. Active Attacks
In an active attack, the attacker writes packets to the network and may
read responses from the network. Active attacks that involve sending
forged packets but not receiving any responses are called 'blind
attacks'.
When IP [RFC791] is used without IPSec [RFC2401], there is no
authentication for the sender address. Active attacks that involve
forging an IP packet with a false source address are called 'spoofing
attacks'.
An IP packet with a forged source address may sometimes be screened out
by the network infrastructure. For instance, many packet filtering
firewalls screen out all packets with source addresses on the internal
network that arrive on the external interface. Note that this provides
no protection against an attacker who is inside the firewall. In
general, protocol designers should assume that attackers can forge IP
packets.
Not all active attacks require forging addresses. For example, the TCP
SYN denial of service attack does not require disguising the sender's
address. However, it is common practice to disguise one's address in
order to conceal one's identity if an attack is discovered.
Active attacks described in [RFC3552] and considered in WIMS are:
(1) Message Replay Attacks - transaction replays by an attacker who can
record a sequence of messages off the wire.
(2) Message Insertion Attacks - message insertion by an attacker who can
monitor a sequence of messages on the wire.
(3) Message Deletion Attacks - message deletion by and attacker who can
intercept messages on the wire.
(4) Message Modification Attacks - message modification by an attacker
who can intercept messages on the wire.
(*) For protection against attacks (1) to (4) above:
(a) All WIMS implementations MUST validate WIMS application protocol
sequence numbers;
(b) WIMS implementations over HTTP/1.1 [RFC2616] or BEEP [RFC3080]
MUST support TLS/1.0 [RFC2246] and SHOULD always use TLS data
integrity services; and
(c) WIMS implementations over email (SMTP/IMAP4/POP3) MUST support
S/MIME [RFC3851] or OpenPGP [RFC3156].
(5) Denial-Of-Service Attacks - resource blocking by an attacker who can
generate high-volume message traffic (for example, numerous incoming
TCP [RFC793] connections from the same remote host or domain):
(a) All WIMS implementations MUST take the active measures against
denial-of-service attacks recommended for their implemented
protocol stack(s); and
(b) All WIMS implementations SHOULD report denial-of-service attacks
to network management stations and/or management personnel.
(6) Man-In-The-Middle Attacks - session hijacking by an attacker who can
intercept and insert messages on the wire:
(a) All WIMS implementations SHOULD perform mutual authentication
during session startup;
(b) WIMS implementations over HTTP/1.1 [RFC2616] MUST support
TLS/1.0 [RFC2246] and SHOULD perform both client and server
authentication during TLS startup using public key certificates;
(c) WIMS implementations over BEEP [RFC3080] MUST support TLS/1.0
[RFC2246] and SHOULD perform server authentication during TLS
startup and client authentication via SASL using public key
certificates; and
(d) WIMS implementations over email (SMTP/IMAP4/POP3) MUST support
S/MIME [RFC3851] or OpenPGP [RFC3156] and SHOULD perform both
initiator and responder authentication via public key
certificates.
8.2. Enterprise Threat Model
In the enterprise threat model, we can no longer assume that the
end-systems engaging in a protocol exchange have not themselves been
compromised. Physical security of workstations and imaging systems in
an enterprise network is often the weakest point of security defenses.
For example, print jobs typically produce hardcopy, which an attacker
can simply steal.
Network security problems are actually worse in an enterprise network.
Firewalls and border routers no longer provide any useful protection.
Users and administrators who deploy WIMS-enabled products in enterprise
networks:
(a) SHOULD enforce the use of mutual authentication by all deployed
WIMS-enabled products;
(b) SHOULD enforce the use of TLS/1.0 by WIMS implementations over
HTTP/1.1 [RFC2616] or BEEP [RFC3080]; and
(c) SHOULD enforce the use of S/MIME [RFC3851] or OpenPGP [RFC3156] by
WIMS implementations over email (SMTP/IMAP4/POP3).
8.3. Mobile Threat Model
In the mobile threat model, we can no longer defend against attackers
based on physical network topology. Mobile clients may access home,
business, or commercial WIMS-enabled products via:
(1) Public Wireless - Cellular ISPs, IEEE 802.11 wireless Ethernet 'hot
spots' in airports, etc.
(2) Local Wireless - Bluetooth/IRDA-enabled laptops and printers, etc.
Users and administrators who deploy WIMS-enabled products in mobile
networks:
(a) SHOULD enforce the use of mutual authentication by all deployed
WIMS-enabled products;
(b) SHOULD enforce the use of TLS/1.0 by WIMS implementations over
HTTP/1.1 [RFC2616] or BEEP [RFC3080];
(c) SHOULD enforce the use of S/MIME [RFC3851] or OpenPGP [RFC3156] by
WIMS implementations over email (SMTP/IMAP4/POP3); and
(d) SHOULD consider the use of IPSec [RFC2401] which offers significant
security advantages in mobile networks.
8.4. HTTP Threat Model
WIMS implementations over HTTP/1.1 [RFC2616] are vulnerable to the
threats described in section 15 'Security Considerations' of [RFC2616].
8.5. BEEP Threat Model
WIMS implementations over BEEP [RFC3080] are vulnerable to the threats
described in section 9 'Security Considerations' of [RFC3080].
8.6. Email Threat Model
WIMS implementations over email are vulnerable to threats described in:
(a) section 7 'Security Considerations' of SMTP [RFC2821];
(b) section 5 'Security Considerations' of the Internet Message Format
[RFC2822];
(c) section 11 'Security Considerations' of IMAP4 [RFC3501]; and
(d) section 13 'Security Considerations' of POP3 [RFC1939].
------------------------------------------------------------------------
13. Appendix A - WIMS Protocol Bindings (Normative)
PWG well-known WIMS protocol bindings are defined in this section. One
new PWG standard URI query parameter 'binding' is defined, to support
multiple protocol bindings for the WIMS URI scheme (or any other imaging
system/service URI scheme). The PWG standard query parameters 'auth'
(authentication) and 'sec' (security) defined in PSI/1.0 [PWG5104.2] are
updated with new keyword values to support non-HTTP protocol bindings.
WIMS standard bindings always require the current versions of underlying
protocols (e.g., SOAP/1.2). WIMS compatibility bindings may require
previous versions (e.g., SOAP/1.1). A conforming WIMS implementation:
(a) MUST implement one or more of the WIMS standard bindings;
(b) SHOULD implement the WIMS default binding (for interoperability);
(c) MAY implement one or more of the WIMS compatibility bindings; and
(d) MAY implement one or more vendor-specific bindings.
13.1. PWG Standard URI Query Parameters
13.1.1. 'auth'
Client authentication mechanism required to access this URI (see section
4.4.2 'uri-authentication-supported' in IPP/1.1 [RFC2911]), for example:
pwg-wims://example.com/manager?auth=digest
Well-known values are:
'none': no user authentication (i.e., 'anonymous').
'basic': user authenticated via HTTP basic [RFC2617].
'certificate': user authenticated via PKI certificate [RFC3280].
'diameter': user authenticated via Diameter [RFC3588].
'digest': user authenticated via HTTP digest [RFC2617].
'kerberos': user authenticated via Kerberos V5 [RFC4120].
'login': user authenticated via login protocol operation (same as
'requesting-user-name' in IPP/1.1 [RFC2911]).
'otp': user authenticated via One-Time Password [RFC2289].
'radius': user authenticated via RADIUS [RFC2865].
'sasl': user authenticated via SASL [RFC2222].
'srp': user authenticated via Secure Remote Password (SRP) [RFC2945].
13.1.2. 'binding'
Protocol binding required to access this URI, for example:
pwg-wims://manager@example.com?bind=soap11.email
Well-known values are:
'none': no protocol binding (i.e., 'not specified').
'soap11.beep': SOAP/1.1 [SOAP1.1] over BEEP [RFC3080] per [RFC3288].
'soap11.email': SOAP/1.1 [SOAP1.1] over email (SMTP/IMAP4/POP3).
'soap11.http11': SOAP/1.1 [SOAP1.1] over HTTP/1.1 [RFC2616].
'soap12.beep': SOAP/1.2 [SOAP1.2] over BEEP [RFC3080] per [RFC3288bis].
'soap12.email': SOAP/1.2 [SOAP1.2] over email (SMTP/IMAP4/POP3) per
[SOAP1.2-EMAIL]
'soap12.http11': SOAP/1.2 [SOAP1.2] over HTTP/1.1 [RFC2616].
'xml.email': Direct XML [XML] over email (SMTP/IMAP4/POP3).
'xml.http11': Direct XML [XML] over HTTP/1.1 [RFC2616].
13.1.3. 'sec'
Security mechanism required to access this URI (see section 4.4.3
'uri-security-supported' in IPP/1.1 [RFC2911]), for example:
pwg-wims://example.com/manager?auth=digest&sec=tls
Well-known values are:
'none': no security mechanism (i.e., 'anonymous').
'pgp': communications message security via OpenPGP [RFC3156].
'smime': communications message security via S/MIME [RFC3851].
'ssl3': communications channel security via SSL3 [SSL].
'tls': communications channel security via TLS/1.0 [RFC2246].
13.2. SOAP Standard Bindings
This section defines the standard bindings of the WIMS protocol over
SOAP (Simple Object Access Protocol).
13.2.1. soap12.beep (standard)
This WIMS standard binding consists of the WIMS application layer
protocol running over SOAP/1.2 [SOAP1.2] over BEEP [RFC3080] as
specified in [RFC3288bis]. If WSDL is used to generate the SOAP
messages, then WSDL/2.0 [WSDL2.0] SHOULD be used.
13.2.2. soap12.email (standard)
This WIMS standard binding consists of the WIMS application layer
protocol running over SOAP/1.2 [SOAP1.2] over email (SMTP/IMAP4/POP3) as
specified in [SOAP1.2-EMAIL]. If WSDL is used to generate the SOAP
messages, then WSDL/2.0 [WSDL2.0] SHOULD be used.
13.2.3. soap12.http11 (standard - default)
This is the default for interpretation of a WIMS URI without a WIMS
binding query parameter ('binding').
This WIMS standard binding consists of the WIMS application layer
protocol running over SOAP/1.2 [SOAP1.2] over HTTP/1.1 [RFC2616]. If
WSDL is used to generate the SOAP messages, then WSDL/2.0 [WSDL2.0]
SHOULD be used.
13.3. SOAP Compatibility Bindings
This section defines the compatibility bindings of the WIMS protocol
over SOAP (Simple Object Access Protocol).
13.3.1. soap11.beep (compatibility)
This WIMS compatibility binding consists of the WIMS application layer
protocol running over SOAP/1.1 [SOAP1.1] over BEEP [RFC3080] as
specified in [RFC3288]. If WSDL is used to generate the SOAP messages,
then WSDL/1.1 [WSDL1.1] SHOULD be used.
13.3.2. soap11.email (compatibility)
This WIMS compatibility binding consists of the WIMS application layer
protocol running over SOAP/1.1 [SOAP1.1] over email (SMTP/IMAP4/POP3).
If WSDL is used to generate the SOAP messages, then WSDL/1.1 [WSDL1.1]
SHOULD be used.
13.3.3. soap11.http11 (compatibility)
This WIMS compatibility binding consists of the WIMS application layer
protocol running over SOAP/1.1 [SOAP1.1] over HTTP/1.1 [RFC2616]. If
WSDL is used to generate the SOAP messages, then WSDL/1.1 [WSDL1.1]
SHOULD be used.
13.4. XML Standard Bindings
This section defines the standard bindings of the WIMS protocol over
direct XML (Extensible Markup Language).
13.4.1. xml.email (standard)
This WIMS standard binding consists of the WIMS application layer
protocol running over direct XML [XML] using the WIMS Message schema
over email (SMTP/IMAP4/POP3).
13.4.2. xml.http11 (standard)
This WIMS standard binding consists of the WIMS application layer
protocol running over direct XML [XML] using the WIMS Message schema
over HTTP/1.1 [RFC2616].
------------------------------------------------------------------------
[for addition to Normative References section]
[RFC1939] Myers, J., Rose, M. "Post Office Protocol V3 (POP3)",
RFC 1939, May 1996.
[RFC2222] Myers, J. "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[RFC2289] Haller, N., Metz, C., Nesser, P., Straw, M. "One-Time Password
System", RFC 2289, February 1998.
[RFC2821] Klensin, J. "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Klensin, J. "Internet Message Format", RFC 2822, April 2001.
[RFC2865] Rigney, C., Willens, S., Rubens, A., Simpson, W. "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[RFC3023] Murata, M., St. Laurent, S., Kohn, D. "XML Media Types",
RFC 3023, January 2001.
[RFC3080] Rose, M. "Blocks Extensible Exchange Protocol Core", RFC 3080,
March 2001.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., Roessler, T. "MIME
Security with OpenPGP", RFC 3156, August 2001.
[RFC3280] Polk, W., Ford, W., Solo, D. "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3280, April 2002.
[RFC3288bis] Rose, M. "Using the Simple Object Access Protocol (SOAP) in
Blocks Extensible Exchange Protocol (BEEP)",
<draft-mrose-rfc3288bis-02.txt>, May 2005 (IESG approved).
[RFC3501] Crispin, M. "Internet Message Access Protocol V4R1 (IMAP4)",
RFC 3501, March 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko J.
"Diameter Base Protocol", RFC 3588, September 2003.
[RFC3629] Yergeau, F. "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003.
[RFC3851] Ramsdell, B. "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
[RFC4120] Neuman, C., Yu, T., Hartman, S., Raeburn, K. "Kerberos
Network Authentication Service (V5)", RFC 4120, July 2005.
[SOAP1.2] See [SOAP12-1] and [SOAP12-2].
[SOAP1.2-EMAIL] "SOAP Version 1.2 Email Binding", W3C Note, July 2002.
------------------------------------------------------------------------
[for addition to Informative References section]
[RFC3288] O'Tuathail, E., Rose, M. "Using the Simple Object Access
Protocol (SOAP) in Blocks Extensible Exchange Protocol
(BEEP)", RFC3288, June 2002.
[RFC3902] Baker, M., Nottingham, M. "The 'application/soap+xml' Media
Type", RFC 3902, September 2004.
------------------------------------------------------------------------
[entire Bibliography section is erroneous]
Move all Bibliography references to Normative or Informative References
as appropriate from usage in WIMS specification.
------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Tue Sep 27 2005 - 09:42:49 EDT