review of: draft-ietf-impp-cpim-pidf-05.txt
Graham Klyne <[email protected]>
| Newsgroups | gmane.ietf.impp |
|---|---|
| Message-ID | <[email protected]> |
Expires: November 2002 May 2002
Common Presence and Instant Messaging (CPIM)
Presence Information Data Format
<draft-ietf-impp-cpim-pidf-05.txt>
[...]
1. Introduction
The Common Profile for Instant Messaging (CPIM) specifications define
a set of common operations and various formats to achieve
interoperability between different Instant Messaging and Presence
protocols which meet RFC 2779 [RFC2779]. The CPIM core specification
[CPIM] defines a set of common operations and their parameters to be
supported by interworking Presence and IM protocols in order to allow
straightforward gatewaying between them. The work on CPIM Message
.................................................^^^^^^^
Suggest: delete this
Format [CPIM-MSG] defines a common format for instant messages, which
enables secure end-to-end IM exchange through the gateways.
This memo further defines the CPIM Presence Information Data Format
(PIDF) as a common presence data format for CPIM-compliant presence
protocols. The significance of the common presence format primarily
resides in the fact that it alleviates the load of gatewaying of
messages with presence data payloads. Without such a common presence
data format, a gateway must process and transform the presence data
payload from one format to another every time it gateways the
protocol messages. Such payload processing also disables the
validity of digitally signed presence data. Utilizing the common
presence data format allows secure transfer of the presence payloads
across the boundary of different protocol domains.
Minor comment: I'd put the digital signing issue ahead of gateway workload.
The format specified in this memo is intended to define the base
presence format and extensibility required by RFC 2779. It only
defines a minimal set of presence status values defined by the IMPP
Model document [RFC2778]. However, a presence application is able to
define its own status values using the extensibility framework
provided by this memo. Defining such extended status values is
beyond the scope of this memo.
Note: we need to be clear that some document (CPIM or this?) is clear
about the requirement for CPIM processors to recognize this basic presence
format.
Note also that this memo only defines the format for a presence data
payload only and how the presence data is transferred within a
specific protocol frame would be defined in actual protocol
specifications.
Slghtly confusing wording, I suggest:
[[
Note also that this memo defines only the format for a presence data
payload. How the presence data is transferred within a
specific protocol frame would be defined separately in a protocol
specification.
]]
[...]
3.1. The 'application/cpim-pidf+xml' Content Type
This memo defines a new content type "application/cpim-pidf+xml" to
represent an XML MIME entity which encodes a presence information
document conformant to this specification. Because the new content
Suggested wordsmithing of 1st sentence above:
[[
This memo defines a new content type "application/cpim-pidf+xml"
for an XML MIME entity that encodes presence information
conformant to this specification.
]]
Also suggest deleting: "Because the new content type is XML-based, "
type is XML-based, this specification follows the recommendations and
conventions described in [RFC3023], including the naming convention
of the type ('+xml' suffix) and the usage of the 'charset' parameter.
As for the 'charset' parameter, although it is defined as optional,
the use of that parameter is STRONGLY RECOMMENDED. If the 'charset'
parameter is not specified, conforming XML processors to [XML] MUST
follow the requirements in section 4.3.3 of [XML].
Suggested wordsmithing 1st sentence above:
[[
Although it is defined as optional,
use of the 'charset' parameter is STRONGLY RECOMMENDED.
]]
3.2. Presence Information Contents
This subsection outlines types of information included in an
"application/cpim-pidf+xml" type document. The real definition of the
content type will be presented in Section 4.
Suggested wordsmithing:
[[
This subsection outlines the information in an
"application/cpim-pidf+xml" document. A full definition of the
PIDF content is in Section 4.
]]
o PRESENTITY URL: specifies the "pres" URL of the PRESENTITY.
o List of presence tuples
- Status: OPEN/CLOSED for Instant Messaging or status for
other communication means.
- Communication address: communication means and contact
address of this tuple. (optional)
- Relative priority: numerical value specifying the priority
of this communication address. (optional)
- Timestamp: timestamp of the change of this tuple.(optional)
- Human readable comment: free text memo about this tuple
(optional)
o PRESENTITY human readable comment: free text memo about the
PRESENTITY (optional).
4. XML-encoded Presence Data Format
This section defines an XML-encoded presence data format of the
content type "application/cpim-pidf+xml" for presence payloads.
I don't think this section needs to be tied to the MIME content-type.
E.g. I could imagine a CPIM-compliant protocol that conveys
PIDF in a SOAP envelope. Hence, the above might be phrased:
[[
This section defines an XML-encoded presence information
data format (PIDF) for use with CPIM compliant systems.
]]
A
presence payload of this type is expected to be produced by the
PRESENTITY (the source of the PRESENCE INFORMATION) and transported
to the WATCHERS by the presence servers or gateways without any
interpretation or modification.
4.1. XML Format Definitions
An "application/cpim-pidf+xml" object is a well formed XML document.
See comments above -- I think the above sentence is technically incorrect.
I suggest:
[[
A PIDF object is a well formed XML document.
]]
It MUST have the XML declaration and it SHOULD contain an encoding
declaration in the XML declaration, e.g. "<?XML version='1.0'
encoding='UTF-8'?>". If the charset parameter of the MIME content
type declaration is present and it is different from the encoding
declaration, the charset parameter takes precedence.
What forms of character encoding are CPIM-compliant systems required to accept?
My view is that UTF-8 only should be specified, but others have different
views.
e.g. see my comments at:
http://www.imc.org/ietf-xml-use/mail-archive/msg00221.html
which were in response to Tim Bray's message at:
http://www.imc.org/ietf-xml-use/mail-archive/msg00219.html
which cites a W3C tag decision at:
http://lists.w3.org/Archives/Public/www-tag/2002Jun/0020.html
I note that the TAG decision, while coming down against general
restrictions on character encoding, does also say:
[[
For some machine-to-machine routing protocol, we accept that
restricting the encoding to UTF8/16 would be acceptable. But for
specifications designed for editing by humans (such as MathML), we
believe that this restriction should not be imposed.
]]
Tim Bray argues that full-blown generic XML parsers will (or should) be
used whenever XML appears in a protocol, and hence that it is not
appropriate to restrict the character encoding to UTF-8. I happen to
disagree -- I think specific protocol implementations may reasonably be
hand-coded and optimized to deal with a single character encoding.
[...]
4.1.6. The <note> element
The <note> element contains a string value, which is usually used for
a human readable comment. A <note> element MAY appear as a child
element of <presence> or as a child element of the <tuple> element.
In the former case, the comment is about the PRESENTITY and, in the
latter case, the comment is regarding the particular tuple.
The <note> element SHOULD have a special attribute 'xml:lang' to
specify the language used in the contents of this element as defined
in Section 2.12 of [XML]. The value of this attribute is the
language indentifier as defined by [RFC 1766]. It MAY be omitted when
the language used is implied by the larger context such as the
encoding information of the contents, e.g. the 'Shift_JIS' encoding
imples the language 'ja'.
Ouch! I'm not sure that having language implied by the character encoding
is a safe thing to do. My understanding is that language and character
encoding should, in general, be treated orthogonally.
I'd suggest something like:
[[
It MAY be omitted when
the language used is implied by the larger context such as the
encoding information of the contents, such as an xml:lang attribute on
an enclosing XML element, or a Content-language header [RFC3282] on an
enclosing MIME
wrapper.
]]
If you *really really* want to say anything more, I migth suggest:
[[
(If no explicit language information is available, implementations
MAY apply heuristics to determine the language; e.g. the 'Shift_JIS'
encoding is suggestive that the language is 'ja'.)
]]
... but I'd rather not!
4.1.7. The <timestamp> element
The <timestamp> element contains a string indicating the date and
time of the status change of this tuple. The value of this element
MUST follow the IMPP datetime format [DateTime].
While the IMPP datetime format allows use of either 'z' or 'Z' and
also 't' or 'T', XML Schema's dateTime requires using only 'T' and
'Z'. Timestamps that contain 'T' or 'Z' MUST use the capitalized
forms [XMLSchema2].
In view of last-call changes to [dateTime] I think the reference to
[XMSchema2] here is redundant, and maybe confusing to the extent that it
may be taken as a normative reference. I suggest the above two paragraphs
could be reduced to:
[[
The <timestamp> element contains a string indicating the date and
time of the status change of this tuple. The value of this element
MUST follow the IMPP datetime format [DateTime].
Timestamps that contain 'T' or 'Z' MUST use the capitalized forms.
]]
4.2. Presence Information Extensibility
[...]
4.2.3. Handling Of Unrecognized Element Names
Except as noted below, a processor of PRESENCE INFORMATION MUST
ignore any XML element with an unrecognized name (i.e. having an
unrecognized namespace URI, or an unrecognized local name within that
namespace). This includes all of the element content, even if it
appears to use recognized names.
It may be that some extensions must be understood in order for the
presence information to be properly understood. In such cases, the
element name is qualified with a mustUnderstand='true' or
mustUnderstand='1' attribute, which attribute name is associated with
the CPIM presence namespace.
NOTE: a mustUnderstand='true' or mustUnderstand='1' attribute
within an element that is being ignored is itself ignored. The
writer of nested mandatory-to-understand information is responsible
for ensuring that any enclosing element is also labelled with a
mustUnderstand='true' or mustUnderstand='1' attribute, if
necessary.
This specification defines (section 4.1) elements within the
'urn:ietf:params:xml:ns:cpim-pidf' namespace that MUST be recognized
in CPIM presence data. Processors MUST handle these as described,
even if they do not carry a mustUnderstand attribute. The XML Schema
Definition (section 4.4) indicates those elements that MUST be
present in a valid presence information document.
In view of recent list discussion, I propose to replkace the following
paragraph:
If an agent receives PRESENCE INFORMATION containing an unrecognized
element with a mustUnderstand='true' (or '1') attribute, it should
treat the entire PRESENCE INFORMATION as unrecognized and not attempt
to process it.
with:
[[
If an agent receives PRESENCE INFORMATION containing an unrecognized
element with a mustUnderstand='true' (or '1') attribute, it MUST
treat the entire enclosing element as unrecognized.
This specification defines a basic presence format that MUST be
processable by any conforming CPIM implementation. Accordingly,
the mustUnderstand attribute MUST NOT be used in a way that might
prevent a minimal implementation from understanding the basic
PIDF information. To ensure this, the mustUnderstand attribute
may be used only within optional extensions, so that non-recognition
of a mandatory extension results in no worse than ignoring the
optional extension in which it is contained.
]]
[...]
5.2. URN sub-namespace registration for 'urn:ietf:params:xml:ns:cpim-
pidf'
URI
urn:ietf:params:xml:ns:cpim-pidf
Description:
This is the XML namespace URI for XML elements defined by [RFCXXXX]
to describe CPIM presence information in application/cpim-pidf+xml
content type.
Registrant Contact
IETF, IMPP working group, <[email protected]>
Hiroyasu Sugano, <[email protected]>
I notice a problem with the XML I supplied for the namespace description:
XML
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<meta name="generator" content="Adobe GoLive 6"/>
<title>Welcome to Adobe GoLive 6</title>
</head>
The above element should be something like this:
[[
<head>
<meta http-equiv="content-type"
content="text/html;charset=utf-8"/>
<title>Namespace for CPIM presence information</title>
</head>
]]
<body>
<h1>Namespace for CPIM presence information</h1>
<h2>application/cpim-pidf+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
7. Internationalization Considerations
This memo does not specify the use of specific character encodings by
itself. However, all the processors MUST be able to use the UTF-8
encoding because it is one of the mandatory character encodings for
XML conforming processors and also RFC 2277 requires the handling of
UTF-8 for the Internet protocols [RFC2277].
Other character encodings may be used if a particular protocol or
application using this specification needs them. In this case, a
conscious decision is needed about which character encoding(s) to
allow in order to promote the interoperability.
I'm not sure that the second paragraph will wash and still maintain
interoperability between arbitrary CPIM implementations. See also my
comments above about encoding.
I think we need to specify a fixed set of encodings that all
implementations MUST accept, and MAY generate. My preference is for just
UTF-8; full XML conformance would require UTF-8 and UTF-16 (with
little-endian and big-endian forms).
8. Normative References
[...]
[DateTime] G. Klyne and C.Newman, "Date and Time on the Internet:
Timestamps", draft-ietf-impp-datetime-05.txt, Work in Progress.
This is now RFC3339
[...]
[XMLSchema2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
W3C REC-xmlschema-2, May 2001, <http://www.w3.org/TR/xmlschema-2/>.
I think [XMLSchema2] should be informative.
9. Informative References
[...]
Also add [RFC3282] (Content-language) as informative?
(See my comment above about xml:lang)
10. Authors' Addresses
[...]
Graham Klyne
Baltimore Technologies - Content Security Group,
1310 Waterside,
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom.
Telephone: +44 118 903 8000
Facsimile: +44 118 903 9000
E-mail: [email protected]
My contact details are now:
Graham Klyne
Clearswift Corporation
1310 Waterside,
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom.
Telephone: +44 11 8903 8903
Facsimile: +44 11 8903 9000
E-mail: [email protected]
...
That's it!
#g
-------------------
Graham Klyne
<[email protected]>
[reminder: [email protected] for non-technical discussions, please]