SIMPLE IETF 64
Notes reported by Dean Willis

Chaired by Robert Sparks, Hisham Khartabil
0900-1130 Friday November 11, 2005
Vancouver, BC, Canada


Summary:

- MSRP will change by altering the fixed size of non-SEND requests and adding
  text describing end-to-end communication with mutual TLS and self-signed
  certs. Both the base and relay drafts are expected to be submitted for
  publication within the next few weeks

- The working group agreed to adopt draft-urpalainen-simple-xml-patch-ops as a
  working group item addressing the needs of the partial-* drafts and for
  xcap-diff.

- XCAP will be pulled from the RFC editor queue and bugs around extensibility
  and namespace selection requiring minor changes will be fixed. There are a
  couple of more major changes, in particular reopening whether XCAP allows
  conditional insertions, under discussion. We will coordinate with OMA as we
  discuss those proposals.

- Presence Authorization is essentially done, depending only on closing the
  open issues in the common-policy work and aligning with the final version of
  that draft.

- The partial-* drafts are ready for last call.

- IMDN is progressing, issues are being closed

- New drafts:

    - The PIDF Connections proposal was well received, and several suggestions
      for improvement were made during the session.  Additional list discussion
      is encouraged.
    - Feedback on the Resource Information List proposal was that significant
      thought to security will need to go into any revision of this draft
    - The XCAP profile proposal stirred active, inconclusive, debate over
      several subtopics. Further discussion was sent to the list.


-------

Full Notes:
Topic: Revised agenda presented by chairs.
Slides presented.

Issue: Status reviewed by chairs. 

Issue: MSRP update

Will increased fixed size. Will add section describing endpoints with mutual
TLS and self-signed certs. Will  then send to IESG. There may be a discussion
on the sizes. This should happen in next few weeks.

Topic: IMDN
Led by Eric Burger
Slides Presented

draft-burger-sipping-imdn-02

6 open issues raised and discussed on list

Issue 1: Security of notification

Several proposals offered relating to encryption of message body 
(listed in slides). 

Room polled for preference. Ted stated preference for "encrypt body if message
was encrypted". Recommendation accepted unanimously by room but will be
reviewed on list.

Issue 2: Sender Keeping State

Suggested that we not change from what the draft says. Noted that point
"minimum info from IMDN" is critical, and we can do things like validate that a
specific message arrived with current text. Noted also that clienst are likely
to throw away IMDNs for which they don't have stored state. Suggested that we
adjust wording in draft to not talk about state, but about the minimization of
information in IMDN itself.

Issue 3: No Disposition time in IMDN

Question (Cullen): Is there another date around that would have to be
reconciled? Suggested that the draft should say "Don't trust any dates but what
you get from the transport protocol. Question: How does this affect record
requirements for financial industries? Answer: draft says "don't do this with
IMDN". Other workarounds exist.

Issue 4: Recipient of IMDN can appear to be different from sender.

draft suggests authenticated transport for IM transport. Question raised: There
are use cases for sending IMDN via different transport than message. For
example, MSRP answering machine that stores a message for later playback might
use email for IMDN or other non-session thing. Ted suggest that we "minimize
complexity". Poll: Anybody here need this feature? None in room. Resolved to
double-check this on list.

Issue 5: Deleted State

Proposed that we drop deleted state altogether from design. Poll: Does anybody
want to keep "deleted" as a reporting state? Cullen reports that he thinks
somebody was using this, possibly reported in Paris and in the financial
sector. Resolved to discuss on list.

Issue 6: Report Consolidation

Proposed to say no but retain placeholder for future extension. Suggested it is
important that relays NOT explode IMDNs.  Relaying through multiple B2BUAs was
discussed. Chair declares consensus on behalf of proposal.

Issue: Does anyone care? Miguel reports that OMA MWG is looking at this. Adam
reports that he has customer requirements for this and will be implementing it
and would like it to be standardized. Keith clarifies 3GPP position as being in
a feasibility study with no official dependencies.  Ben also reports a need for
standardization. Poll: Who in the room will work on this: Chair reports
"enough". Poll: Adopt as WG item? Unanimous response in favor.


Topic: XML Patch Ops BoF

chairs report on discussion in this BoF. The BoF was not interested in building
a general xml diff tool. Compromise agreed to move forward with our drafts and
roughly what Jari has in his diff tools now.


Topic: XCAP
Led by Jonathan Rosenberg
Slides Presented

draft-ietf-simple-xcap-07 was in RFC Ed queue. Proposed that we yank from
queue, revise to fix XCAP namespace issue and several reported bugs and
extensibility problem and namespace problem.

The -08 version includes text to fix these things. Slides review the changes. 

Changes not noted here received no counter-discussion in meeting.

Issue: Whitespace vs comment nodes.  

Proposal is questionable in use of mixed text and will be discussed on list.

Issue: Document Selector. 

Noted (Derek) that OMA does similar things but has their own names. Proposed
that we coordinate with OMA on these conventions. Author, chairs, and liaison
tasked to work this out.

Issue: Namespace proposal.   

Get and Namespaces. Proposed that we reject canonical XML approach. Use
proposal 2 for blind insertions.  Discussed possibility of requiring server to
munge namespaces appropriately in some depth (it basically doesn't work).
Several people spoke in favor of proposal from slides.


Issue; The Insertion Problem. 

Proposed to make non-extant resources extant but empty if the parent exists.
Question: This would appear to break conditional tests "does this element
exist?". Discussion revealed that that the logic for the test changes (test on
element not resource but can still be implemented. Proposed that it is worth
writing a draft about and discussing. Noted by Ted Hardie that a change of this
magnitude would require a full recycle through the IETF publication review
process. Further discussion on requirements and mechanism and implications
followed. Joel noted that this breaks the ability to "Insert this buddy if I
haven't used the name already", which might be important. Question: Is it
possible to fix XCAP for OMA now, and leave the "insertion problem" for later
as an extension? We can ask OMA if this would work for them, but it remains
unclear as to whether this WG will accept the approach. Jonathan will write
this up and communicate it with WG and OMA.


Topic: Presence Authorization
led by Jonathan Rosenberg
slides presented

Relates to conclusions in geopriv on common policy.

Henning suggests "3897 and be done with it".

Issue: Anonymity. Can't currently differentiate "unauthenticated" and
       "anonymous".  

Poll: Do we agree to maintain text that does not differentiate anonymous for
now? Response appears to be unanimous. The plan forward is that Hannes will
revise common-policy soon, and then Jonathan will revise this draft to match.


Topic: XCAP Diff
led by Jonathan Rosenberg
Slides presented

draft-simple-change-log will be essentially abandoned unless we bog down with
current mechanism completely. 

Issue: Extending xcap-diff. 

Two approaches described. Discussion followed. There seems to be some kind of
issue with Approach 1. The conclusion is dependent on the related change
proposal discussed in the slide and cannot be determined at this time. Noted
that HTTP responses require a Content-Length, which breaks one of the ideas
discussed. 


Topic: Partial PIDF
led by Jari Urpalaienen
Slides Presented

Changes from -03 reviewed

Poll: Does anyone believe that these drafts are not ready for WGLC? None
opposed. Chairs plan to announce WGLC within next few weeks.


Topic: Simplified XCAP profile
led by Rohan Mahy
Slides presented

Lighweight profile discussed.

Henning is averse to the protocol fragmentation he sees resulting from this
approach, and doens't want to have to build on a generic XML database.

Jonathan thinks it is useful to talk about client simplifications, but that
simplifying the server will create interop problems and effectively multiple
different protocols for different usages. 

Jari believes that the additional server code needed to implement the full xcap
to be minimal.

Robert suggests that this doesn't really break the XCAP model. Each profile is
simply a declaration of policy.

Keith asks whether this approach actually increases the client complexity by
requiring it to negotiate and understand profiles. 

Jonathan noted that this would appear to require updates of the list usages and
other documents in order to reference the profile document.

Derek worries that this might increase client complexity via a requirement to
annotate the tree for the profile.

Dan suggests that this approach is a natural optimization towards launching and
deploying XCAP services sooner rather than later.

Keith suggested that we're not talking about a profile, but a change to
normative behavior and therefore not a profile.

Joel reports that previous attempts to build restricted implementations have
often failed due to a mismatch between what the clients want to do and what the
profile does.

Ted asks if this is something we could accomplish by declaring these as
different "XCAP applications" (AUIDs) .

Henning suggests a compromise possibility. Perhaps these "profiles" constitute
a recommended set of operations that clients should stick to that would be
"efficient" on the server, and that if clients step back to the more complex
operations, it might be reasonable to do the "full functions" via a slower,
brute force manner.

Adam notes that the server functionality is not lost in absolute terms with
these profiles, but might require the client to send a larger data set in order
to meet the function.

Poll: is it worth exploring XCAP ideas relating to depth restriction on
servers? The result was declared inconclusive by the chairs.


Topic: Resource Information List
led by Rocky Wang
Slides presented

General idea is on providing a mechanism for informing watchers about partial
subscription satisfaction.

Chair encourages participants to read this draft.

Noted that there is a privacy consideration raised by revealing the information
that a watcher is not allowed to see, and that any future revision will need to
explore this issue

Topic: PIDF Connections
Led by Jussi Ala-Kurikka
Slides presented

Attempts to describe relative cost to correspondent of exercising a particular
device tuple as described in PIDF.

Jonathan suggests that the draft provides useful assistance in tuple selection.
He cautions that trying to express the absolute cost is likely to cause
problems.  he would like to add this as a WG item, but would prefer to defer it
until more of the current work is finished.

Henry notes that there seems to be some overlap between this work and
lower-layer efforts at layer 2, and that the draft is timely.

Robert (not as chair) thinks that the draft is interesting and that the authors
should resist the temptation to over-extend the information expressed. However,
he would prefer not to offer the draft for adoption by the WG at this time.

Henning notes that the access-network bandwidth is often not the limiting
factor. he thinks the useful information can be presented as one bit for "costs
this user" and a few more for order-of-magnitude ranges on bandwidth.