Notes, SIMPLE Session 2,
IETF 60
Reported by Dean Willis
Topic: XCAP -- Jonathan
Rosenberg
---------------------------------
Slides presented.
Changes since last rev
reviewed.
Changes were discussed also
on list. No questions or comments raised
in meeting.
Issue: DELETE idempotency.
Discussion: Could we do away with the
positional syntax and use a
".next" style iterator? Discussion
followed. Initial
Conclusion: Will add text to spec that describes URI
constructor constraints for
delete idempotency. This led to extended
discussion -- is idempotency
really required here? Key issue: What
happens when you have issued
a command and lose network access before
the response is returned? If
the request is not processed
idempotently, there is no
way to just reissue it. Heated debate
followed. Comment: In
choosing to use HTTP with DELETE as done. we
have chosen to use the
entire implied infrastructure, including HTTP
proxies. HTTP proxies can
retry these commands on your behalf, without
your knowledge or consent,
and if the requests are not idempotent,
this will break the
application. Restatement of proposal: Soften the
requirement of a server to
enforce idempotency to only enforce it in
the presence of an ETag in
an If-Match header.
Issue: XPath Namespace
Context. Extended discussion followed, with no
conclusions. Author will
research and bring up on list.
Issue: ETag and DELETE. When
a resource is deleted, it doesn't
exist. But some servers
return the ETag of the deleted
element. Several options
proposed in slides. Meeting proposed fourth
option: DELETE response
contain a body that references some related
resource, presumably the
parent. The third proposal, the "MODIFY TO
EMPTY" approach, was
universally recognized as "crap". Comment: Unless
we are introducing
transactions across multiple requests, we are
simply going to have this
problem. Final Proposal: XCAP will have
normative ref to xcap-diff
format and will state that if a DELETE
request includes an accept
header for that MIME type then the server
SHOULD return a diff body
that indicates the etag of the resource
following the DELETE
operation.
Issue: Caching. Proposal:
Add discussion of caching issues to XCAP
document.
Topic: XCAP List, Jonathan
Rosenberg
------------------------------------
Slides presented.
Four issues to be discussed.
Question on whether
indirection URI in a rls-service document has to
point to XCAP or can point
to other destination -- author will
consider.
Topic: Resource List
Document, Jonathan Rosenberg
-------------------------------------------------
Issue: Embedded vs external
lists. Proposed: retain as is. Poll on
readership: about twenty
people indicated they had read it. No
objection to proposal.
Issue: Simpler structure.
Proposed retain as is. No objections.
Issue: Membercode attribute
proposed by Hiller draft. Problem: Schema
doesn't allow attribute
extensibility. Proposal: Add attribute
extensibility. Comment: We
need to go through the extensibility
discussion for everything.
Question: Can the membercode be done as an
element instead of an
attribute? This needs to be reviewed in the
Hiller draft. (probably not,
as it seems to be used with XZCAP
selection). Question: How
can we develop extensibility guidelines
for consistency? Discussion
followed.
Topic: XCAP Package/DIFF,
Jonathan Rosenberg
--------------------------------------------
Slides presented.
Document is readically
changed, including a great deal of
rfeconcilaition with Config
Framework. Changes reviewed in
presentation.
Question: Is the providing
of a starting point ETag in addition to a
diff helpful? Yes, otherwise
you don't know whether an intermediate
change was missed that would
make the sequence of changes not add up.
Issue: Relationship to
directory. Proposed that this restructure makes
a seperate directory
unneeded. Poll indicates that about twentyfive
people in meeting had read
the document. Further list discussion on
proposal is appropriate.
Topic: XCAP Directory,
Miguel-Angel Garcia Martin
-------------------------------------------------
Comment: The
heirarchicalization is inconsistent with XCAP.
Comment: The size is going
to be hard to compute.
Discussion: The
functionality seems to be needed. The question is how
to implement. Is
rls-services adequate? Need to evaluate rls-services
against this requirements
raised in this document. comment: The config
framework truly does what
this does -- give me all the servcies
related to me. The
rls-services document is a related thing, that
provides an index of the
documents related to me, in a linkage
tree. As there may be
unreferenced documents, rls-services may not get
everything. Author is to vet requirements against
rls and config
work.
Topic: PIDF-ICE, Jon
Peterson
-----------------------------
Slides presented.
Idea is to get the
information that one would request from ICE through
presence, allowing evaluation
of probability as to whether a real-time
multimedia session
establishment might succeed. This could be of use
to users making contact
decisions.
Discussion: This seems to
have value as a presence accuracy enhancer,
and some would like to see
it move forward. There seems to be a
general consensus to follow
this work in SIMPLE.
Topic: Presence Data Model,
Jonathan Rosenberg
----------------------------------------------
Slides presented.
Goal is to establish a
common understanding of what opresence
documents mean in order to
achieve interoperability.
Issue: One vs. many
Presentity. Model allows one presentity per
document. Proposal to handle
conflicts at attribute level. No comments
from meeting.
Issue: Devices or Not. We
now have a definition of device clear enough
to understand what we are
debating, but not clear enough for a final
definition. Open issues
remain around distributed devices.
Comment: We need to simplify
the use-purpose of the device tuple. This
probably includes some kind
of device identifier that allows the UI to
display an appropriate icon.
If one doesn't actually use this
description to guess device
properties, the information is
useful. Discussion: There is
a useful correlation property, when a
user can see that a specific
device offers multiple services. Debate
continued on whether the
device classification (like PDA, mobile
phone) implies enough about
the utilization characteristics. Further
discussion deferred.
Comment: It seems like the
presnetity being modeled is seen as a
collection of devices, and
this doesn't really give the correct
picture. Discussion: We are
modeling the user, its services, and the
devices forming the context
on which those services execute.
Issue: Resources and
capabilities. Design team believes that
association of resources nad
capabilitiesare not useful as part of
"device" and are
probably mroe useful as part of "service".
Issue: Correlation. Design
team conclusion is that the state of a
given service cannot in
general be inferred from knowledge of the
state of other services
executing on the same device. Comment: This
relates to the use of
user-supplied identfiers, e.g. cellphone vs
mobile. The key thing is
that services are identified by URIs, and
these URIs can be mapped to
devices under applicaton
control. Question: Do we
have in mind that certain elements will be
used only with certain tuple
types? Proposed: Go through RPID, and for
each thing, describe where
it can be and what the limitations are.
Issue: Idle. Discussion on
restricting the amount of information going
to the watcher. Counterpoint
that this needs to not be restricted,
but well-defined. Comment:
Less is better to display, in most
cases.
Discussion on whether this
work will delay anything. We are not
anticipating changes that
would restructure any of the related
documents.
Comment: Restricting
presence to people is speciesism. Discussion: The
idea is to model things that
have human-like properties, as opposed to
places or organizations.
This discussion proceeded to devolve into
pseudoreligiosity and was
deferred to the list.
Poll: Do we believe, as a
group, that this model is the one that we
want to pursue, at least in
a directional basis? None opposed noted.