Presence Authorization Rules
draft-ietf-simple-presence-rules-10

[Ballot discuss]
y questions:
- I assume RFC4745 has not been implemented prior to this I-D as it's a framework?

DISCUSS:
- Interop issue: What parts of this spec are REQUIRED to implement by servers?  Hint: XCAP !

- Security issue: There should be more expectations also on what parts of this spec are REQUIRED to implement by clients, because if a client fails to display to the user that some field is allowed, the user can't figure out what's actually private and what isn't.  Thus clients MUST be capable of displaying to users, all the elements that are allowed and to whom, including the unknown attribute thingy.

- Section 3.1.1.2, at least the parts about anonymous requests and possibly the whole section, would be better in RFC4745 than in this document, right?

- Interop and security Issue: Section 3.3.2.14  Provide Unknown Attribute. Can a client rely on a server honouring a  field?  In order for the client to have any confidence that the server will do what it's instructed to do, the spec needs to REQUIRE servers to reject any documents containing provide-* fields that the server can't recognize or may be unable to honour. 

- Security Issue, section 9: The requirements on server and implementation need to be clarified.  "Server" is ambiguous and it could be interpreted as a server implementation or as a site.  Current best practice is to state that implementations MUST support HTTP Digest and TLS, both clients and servers, although an instance of a client or server may be configured not to use HTTP Digest.  It's sites that SHOULD authenticate with HTTP digest or something else which provides similar protection from password-sniffing.

[Ballot discuss]
I raised a last call comment questioning the RFC 3967 down-reference
to RFC 3325; I saw no comments in support of that down reference.
Having read the documents more closely, I think this down reference
would be an end-run around the standards process.  This document is
making complex normative rules involving a technology that the IETF
explicitly decided not to put on the standards track.

Moreover the approach taken is architecturally bad.  This document
enumerates each of the SIP authentication schemes that exists today,
including ones not on the standards track and provides rules for each
of them.  However we have sufficient experience to suggest that SIP
authentication has been expanded over the years and may be expanded in
the future.  A better approach that would provide both for future
extensibility and for a more reasonable way to reference
non-standards-track schemes would be to introduce an abstract concept
of a sip authenticated identity set (p-asserted-identity supports two
identities) and to describe how various mechanisms manipulate that
abstract state.  Then, the description for p-asserted-identity could
be moved out into its own informational document.

[Ballot comment]
INTRODUCTION, paragraph 13:
>    This
>    specification defines an Extensible Markup Language (XML) document
>    format for expressing presence authorization rules.

  Was there an XML-directorate review? (Is that directorate even alive?)


Section 3.3.2.1., paragraph 1:
>    , and it is a boolean type.  If its value is

  Nit: s/boolean/Boolean/ (named after Boole - also elsewhere in the doc)

IANA Last Call Comments:

The IANA notes that some of the IANA actions in
this document depend upon the approval of other
Internet Drafts.

Upon approval of this document, IANA will complete
three actions.

First, the IANA will register a new XCAP Application
Usage ID (AUID) in the registry created by the
approval of the document: draft-ietf-simple-xcap.

AUID NAME AUID Description
pres-rules Presence rules are documents that
describe the permissions that a presentity has
granted to users that seek to watch their presence.

Second, in the XML Namespace registry located at:

http://www.iana.org/assignments/xml-registry/ns.html
the IANA will add a new XML Namespace called pres-rules
and use the definition located in section 10.2 of the
approved document as the namespace.

Third, in the XML schema registry located at:
http://www.iana.org/assignments/xml-registry/schema.html
the IANA will add a new XML schema called pres-rules
and use the definition located in section 6 of the
approved document as the schema.

IANA understands that these are the only IANA Actions
required upon approval of the document.

IANA Last Call Comments:

The IANA notes that some of the IANA actions in this document
depend upon the approval of other Internet Drafts.

Upon approval of this document, IANA will complete three actions.

First, the IANA will register a new XCAP Application Usage
ID (AUID) in the registry created by the approval of the document: draft-ietf-simple-xcap.

AUID NAME AUID Description
pres-rules Presence rules are documents that describe the
permissions that a presentity has granted to users that seek
to watch their presence.

Second, in the XML Namespace registry located at:
http://www.iana.org/assignments/xml-registry/ns.html
the IANA will add a new XML Namespace called pres-rules and
use the definition located in section 10.2 of the approved
document as the namespace.

Third, in the XML schema registry located at:
http://www.iana.org/assignments/xml-registry/schema.html
the IANA will add a new XML schema called pres-rules and use
the definition located in section 6 of the approved document
as the schema.

IANA understands that these are the only IANA Actions required
upon approval of the document.

PROTO Write-up

1.a) The chairs have reviewed this version of the ID and
ask that the IESG consider it for publication.

1.b) This document has been sufficiently reviewed by the
working group.

1.c) The chairs do not believe further cross-area review
is needed. The document extensively makes use of the common-policy
document produced in geopriv where the editor of this document is
a co-author of the common-policy document. The document also
normatively references XCAP as the manipulation protocol. The XCAP
protocol is a product of the SIMPLE WG also.

This document was ready a long time ago but was awaiting for RPID
and common-policy to complete due to the strong dependency. The former is
in AUTH 48 hours and the latter is with the IESG.

1.d) This document completes a set of required documents needed by
implementers in order to have a fully functioning SIMPLE presence
system with subscriptions, publishing and authorisation. There are no
concerns from the WG chairs.

1.e) This document reflects a strong consensus position from
the working group.

1.f) There have been no indications of intent to appeal.

1.g) This document adheres to ID-nits.

1.h) The document appropriately splits references into
Informative/Normative.

1.i) Announcement Writeup

Technical Summary

There are three functions in a presence system; namely subscriptions, publishing
and notifications. Authorization is a key function in presence systems.
Authorization policies, also known as authorization rules, specify what presence
information, when sending notifications, can be given to which watchers,
and when. This specification defines an XML document format for expressing
presence authorization rules. Such a document can be manipulated by clients
using XCAP, although other techniques are permitted.

Working Group Summary

This document reflects WG consensus. It defines the Presence Authorisation
rules. Censensus was particularly strong. This document heavily depends on
draft-ietf-geopriv-common-policy defined by the geopriv WG.

Protocol Quality

Hisham Khartabil was the PROTO shepherd for this document.