Draft: draft-ietf-sipping-profile-datasets-01
Reviewer: John-Luc Bakker [jlbakker.ietf@googlemail.com]
Review Date: 4 Sept. 2008
Review Deadline: 10 Sept. 2008
Status: pre-WGLC

Summary: This draft is on the right track but has open issues, described in the review. 

I have a few observations, questions, comments.

Comments:
==========

- Section 1, section 2, section 4.1.5: How UAs locate and retrieve profile data from local network, user, device is described in ietf-sip-session-policy-framework. However this document also recognizes profile data pertaining to applications (e.g. in definition of term "merging" section 2, and in the title of section 4.1.5). Can the UA use the same principles as defined in ietf-sip-session-policy-framework to locate and retrieve profile data from applications? Is there a need to identify profile date beyond profile data from local network, user, device? Should ietf-sip-session-policy-framework be enhanced? Section 4.1.5 does not describe the "application" as source for "profile data"?

- Section 4.1.1, section 6.1, section 5 .2. Section 4.1.1 includes "It may also be possible to tag the extensions with minimum version numbers to facilitate the user agents decision making", while section 5.2, 6.1 suggest namespaces are used to scope related properties. What use are the version numbers if namespaces are used to scope related properties? How can a policy server determine which namespaces or version numbers (within a content/MIME type) are supported by the UA?



Editorial/cleanup:
===================

- Section 5: there seems to be a problem with "...indicate all of the dataset schemas that is supports by listing all of the MIME types for the supported datasets in the SUBSCRIBE request header: Accept."
Should it read "... indicate all of the dataset schemas that are supported by listing all of the MIME types (e.g. including
application/uaprofile+xml) for the supported datasets in the SIP SUBSCRIBE request's Accept header field".

- Section 5.11.2: there seems to be a problem with "The combined property set MUST again be valid and well-formed according to the schema definitions.  A conflict occurs if the combined property set is not a well-formed document after the merging process is completed". A well-formed document conforms to all of XML's syntax rules. For example, if a start-tag appears without a corresponding end-tag, it is not well-formed. A document that is not a well-formed XML document is not a XML document. Does the conflict also occur is the well-formed XML document is not a valid XML document? Perhaps this paragraph should read "The combined property set MUST again be well-formed and valid according to the schema definitions.  A conflict occurs if the combined property set is not a well-formed or valid document after the merging process is completed."

- Section 5.12 includes an "editor's note" as follows "[Need to document common types.]"

- There are some comments in the XML and schema that needs to be removed or addressed, e.g. <!-- need to tighten this up -->, <!-- <password>123</password> --> and the commented out definition of ElementFoo.

Question for my clarification:

- Appendix A, page 27: is a <choice> NGRelax construct extensible?
Suppose a new DataIpTransport type is defined, can that new DataIpTransport type be added to DataIpTransport XML <choice> type without causing policy servers using older NGRelax schema documents to reject XML documents including the new DataIpTransport type?