XCAP Open Issues
May
2004 Interim
Jonathan
Rosenberg
dynamicsoft
Issue 1: Schema
Extensibility
Problem
Schema awareness
used for two purposes
Document validation
Determining where to
insert
Requiring schema
awareness limits extensibility
PIDF extensions for
example
Proposal
Schema awareness
only used for validation
Where to insert
must be specified by client
Benefits
Eliminates some of
the PUT magic
Allows
extensibility (resulting data just wont be validated)
Can still validate
parts that are known
No disagreements on
the list
No additional comments
in meeting. Agreed.
Issue 2: Positional
Insertions
Currently, no way
to insert an element in a specific place
Goes on end if its
an insert
Problems
A big one if schema
awareness not used to determine where to insert
A limitation for
schemas where position is significant (i.e., CPL)
Proposal
Allow the *
operator to select all children of a node
Allow multiple
predicates (i.e., multiple [])
Allow name()
function as a predicate to pick an element by name
These allow
positional insertions
Was agreed on list
Henning: Minimum
implementation threshold too high. Need customer input for some of the more
high level functionality. Is this one of those things? Could be done by replace
all, or delete and insert.
Ted: Where is the
line? XCAP rather than XPATH. One of simplifying functions was to treat XML
docs as if they were a store of resources. Can be referenced by their place in
a hierarchy. Instead of handling positional insertions, know where appropriate
place is to do a full fetch and return. Easier in one view to do it this way,
but requires more download and upload.
Henning: Propose
levels of optional capability. i) Simple flat listing. ii) 1st level
insertions only. iii) Every client and server has to support all functionality.
Jonathan: Not in
favour of options.
Jonathan: Look at
primary customers: Presence auth, XCAP, CPCP do they need it?
Cullen: Should not
stray into multiple positional insertions, should stick to single insertions.
Rohan: Should not
agree new capabilities without concrete examples of usefulness.
Hisham: Not efficient
from air interface.
Henning: Documents not
necessarily large anyway.
Hisham: Ordering of
elements may matter.
Jonathan: This wont
work for that, but if this matters, then document should be designed to avoid
this. Need an order of priority field. XCAP will work with all schema, but
works better with some schema than others.
Henning: Number of
reasons why SQL is more trivial than this.
Ted; How many
customers do we need to prove it works. Doing it in SIMPLE was to constrain it
to a small set of applications. We are trying to optimize for a specific
application domain. Thus manipulation of schema is acceptable if it makes
things simpler.
No agreement on
whether we need this or not. Do an analysis on existing schema and see what
impacts are.
Issue 3: PUT v. POST
Is
what were doing a PUT or a POST?
Currently
is unclear because
The
server can modify data
Modeled
as a virtual application ugly
PUT
litmus test
GET(PUT(x))=x
Idempotence
POST
is a slippery slope, will invite scrutiny
Adam: Why cannot use
random 64 bit identifier. Near enough unique.
Adam: Why would a client ever do the first
two steps (PUT w/o needed data; 409, body suggests data, without data
change).
Jonathan: We have a requirement.
If you don't like it, maybe we should change the requirement.
Cullen: Thinks this is
a non-requirement, and leads to things we dont want.
Dean: Would it be nice
to have the namespace as dense as possible?
Agreed: Client will
always provide data, and the server will then reject it if necessary. Therefore
no case when the client does not provide data.
Proposed Server Data
Method
Drawing the Line
User PUTs data, server doesnt modify, no validation at all
User PUTs data, server doesnt modify, but it will reject
the request if its invalid for any reason schema, URI uniqueness, etc.
User PUTs data, server modifies data before storing
Conclusion: Put is
good and we should stick with it. This repeats concensus that we already have
from last meeting. Post not to be used.
Issue 4: Element Separator
The issue that
wont die
History:
?
Problems with
proxies
Not a good model
#
Executed locally, we
need server based
Nothing
Hard to implement
~
Might exist in host
path component (there is precedent)
Desired characteristics
Disallowed in XML
names
Allowed in HTTP URI
abs_path
Usually not used in
host paths
Does existence in
host paths matter?
HTTP Text
A transparent proxy MUST NOT
rewrite the "abs_path" part of the received Request-URI when
forwarding it to the next inbound server, except as noted above to replace a
null abs_path with "/". Note: The "no rewrite" rule
prevents the proxy from changing the meaning of the request when the origin
server is improperly using a non-reserved URI character for a reserved purpose.
Implementors should be aware that some pre-HTTP/1.1 proxies have been known to
rewrite the Request-URI.
Picking
RFC2396
mark characters are {- _ . ! ~ * ( ) }
Of
these XML disallows {! ~ * ( ) _ (alone) . (alone)
Proposal:
single quote
Mandate
that this cant appear anywhere in document selector
XCAP
is all about constraining URI structure
Ted: Does it have to
be a single character. Proposes ~~
Jonathan: No.
Henning: Quotation
marks delimit in HREF.
Other comments that
quotes get changed by word into other things.
Conclusion: Agreed
that ~~ will be used as the delimiter.
Issue 5: Multiple
Insertions
Problem(?)
XCAP currently
allows manipulation of a single element or attribute at a time
Requires multiple
operations to add several buddies
Some have
complained about this limitation
Proposal on list to
allow for manipulation (get, insert, modify) of multiple elements
URI Structure
Interpretation
URI
represents a resource that is a view of a portion of the document
GET on
the URI returns that view
PUT on
the URI sets the view to the value in the body
Key
Constraint
Series
of URI components represent the URI after document modification is done
Needed
for idempotence
Idempotence Defined
idempotence
is the quality of something that has the same effect if used multiple times as
it does if used only once
HTTP
PUT and GET are idempotent
Question
How to find out
where to insert each element so that the URIs match those elements in the final
document?
Dont want to
search!
Idea: implement as
a series of individual operations
Question: when does
a series of individual PUT operations give you the property that it is
equivalent to a PUT of the view?
i.e., when is this
idempotent?
Proving Idempotence
Basic
proof
Assume
PUT of an individual element is idempotent
A
sequence is idempotent if, after the sequence
Each
URI points to the same element
Value
of the element is the same
Doing
the sequence at once is the same as one at a time if there are no errors in
between
Proving Idempotence
URI points to the same element if
No other modification touches its grandparents or higher
antecedents
Parent has changed only by having new children
New children dont interfere with the way the element is
addressed
Dont get inserted
before it, if it is addressed positionally
Dont have same
attributes as used to address it
Content of the URI is the same if
No other modification touches that element
No other modification touches its children
Example Problem Case
Server
side algorithm I Try and Fail
Put
each element, one at a time
Execute
an internal GET on each URI in the request
Each
has to return one thing
Series
of elements has to be the same as body of PUT
Server Side Algorithm II -
Verify
Need
to verify the properties discussed previously
These
are hard to verify
For example,
checking ancestry seems O(N2) where N is number of elements inserted
Checking
1c grows with complexity of ways of addressing element
Do we want this?
Jonathan: Do not want
to do multiple insertions in the initial version of the document.
Henning: XML database
work is already in progress elsewhere. Should not do amateur database design
here.
Hisham: Gave example
of dial out list and dial in list to identify issue where we need this.
Cullen: Can be done as
two PUTs.
Jonathan: Use multiple
PUTs, Etags, careful schema design, etc, rather than do this.
Aki: Should not do
this.
Aki/Jonathan: 2
options:
- Same data that appears twice and need to
put both in. Fix is schema needs to index on these things.
- If flat buddy list where need to add 20
buddies at one, do sequence of 20 PUTs without Etags, and if careful in
schema design, then pipeline approach gives efficiency.
Keith: Are we
recording any guidance where we identify careful schema design as the solution?
Jonathan: Have
proposed this but some do not like it.
Conclusion: Do not do
multiple insertions. Will put guidance on careful schema design in the
document.
Issue 5a: Multiple
Attributes
So
far, its been about multiple elements
What
about inserting multiple attributes?
If we
want it, XML-based attribute list body may make sense
Allows
you to return more than one
However
XML is not needed for that
Recommendation:
no
Based on previous
conclusion (issue 5), we will not go there.
Issue 6:
Selecting Elements by Text Content
Problem (?)
Currently, elements
can be selected by
Position
Attribute value
No way to select an
element by text content
Requires schema to
put all relevant indexing data into attributes, even when content would be
better
Issue 6 Proposal
Add the [.=X]
predicate
Can then ask for an
element by content
All is not rosy!
What if element
content is very large (e.g., paragraph of text)
Will be hard to
index
May not want to
store locally (Joel)
Same could be true
for attributes, though!
Meta-Issue
Only want to select
on things which are known to be indices
The things that are
indices are application usage specific
XCAP selection
rules are not application usage specific
Approaches
1. Allow
application usages to define indices for their data
Complicates general
purpose xcap code
Improves
performance
Allows efficient
purpose specific implementations
2. Allow
attribute or content indices, leave it to clients to only use useful things as
indices
3. Allow
attribute indices, still leaving it to clients to only use useful things as
indices, less likely to be problems
Option 3 is dont
allow for content based selection.
Cullen: Does this only
apply for text content? Mixed elements are out. Lot of hassle in doing this and
absolutely no requirement for doing it.
Jonathan: Constrain
schema into not doing this.
Rohan: Unless someone
can come up with a use case should not do this.
Brian: Also thinks
should not go this way. Taking it outside scope of the protocol. Trying to
match things within an XML tag. Could accomplish it by grabbing the entire ACL
list.
Conclusion: Will not
select elements by text content.
Issue 7: Unique Hops
is it legal to have an XCAP
reference of the form
.../document/aTags/aTag/bTags/bTag[@at1="1"]
Issue 7 Considerations
Can eliminate this
by mandating unique results in each step
Server thus needs
to check this
Hard if youre
using off-the-shelf Xpath
Desirable if you
are implementing from scratch
Performance better
if each step has unique result
Proposal: mandate
uniqueness at each step
Proposal is not to
allow XCAP references with multiple levels with non-uniqueness, but to mandate
uniqueness at each step. If use XPATH implementation, then this is allowed.
Jonathan thinks it is not a good route to use XPATH to develop XCAP.
Hisham: If any element
has max occurs of 1, then do not need. If more than one, then have to use id.
Jonathan: This does
require scheme awareness.
Conclusion: Agreed
will not allow XCAP references with multiple levels with non-uniqueness, but to
mandate uniqueness at each step.
Future action is to
check to see if can enforce this constraint without requiring a check of the
instance document.
Reminder: Etags
Current
specification doesnt reflect consensus from IETF 59
Consensus was
Application usages
define scope of an etag
One choice is
applies to whole document
Other choices each
buddy list in a document has its own
This is not
mandatory behavior
If client guesses
wrong, may need to refetch broader scope
Details
Scope is defined
by parent
All children of that
parent have a different scope
Parent has to exist
in each document, or if not, scopes need to be declared for each parent that
could exist
A change in an
element implies gives it etag X, and
All other elements
and attributes in the same scope get that etag
All elements in
higher scopes get that etag
Siblings do not get that etag
Issue 8:
Finding out scope of change
Problem
Document has two
buddy lists, X and Y
X has etag=1, Y has
etag=1, doc has etag=1
Two xcap clients, A
and B have full doc and etag
A does conditional
PUT to X conditioned on etag=1
Succeeds, updates
X. New etag for X is 2, Y is 1, doc is 2
B does a
conditional PUT to X conditioned on etag=1
Fails
Question: how does
B know whether
Only X changed
So only X needs GET
to sync up
Entire document
changed
Entire document
needs to be GET to sync up
Issue 8 Solutions
Solution A
Use SIP event
package, it will tell you what changed and the new etag
Solution B
Client assumes only
innermost scope
If it was wrong,
later PUTs in a broader scope will fail, in that case, get the next most
encompassing scope
Orthogonal to
Solution A
Solution C
Some kind of
indication in the body of the 412
Not clear its
allowed
Solution D
Go back to document wide etags
Not yet placed on the
list.
Rohan: If not yet
found out what document wide Etag is, then use solution B.
Ted: Presumption is
that each individual resource has an individual Etag. When X updated, no
presumption that there is a change in Etag for Y. Only the fact that we have an
enclosing resource conception causes some knowledge of some other change. If
think that it has changed, then conditional GET on Y is available. Sticking to
a solution that is as close as possible to original Etag design is preferred.
If so, solution A is out of contention; we need something in XCAP itself.
Solution B is correct compared to solution D; talking about resources as
opposed to documents.
Aki: How do we keep
the data synchronized? Make a get for each individual buddy list separately. If
Etag has changed, then get error code.
Conclusion: Put to
list.
Issue 9:
Knowing Supported Namespaces
Previously,
it was important to know supported namespaces on server
Client
had to be sure server knew them for XCAP to work
Now,
its not so important
If
server doesnt know, no validation
Do we
want a way for the client to discover this?
Maybe
defer for later
Not covered.
Known To-Dos
Change MIME types
to xcap specific ones, rather than application/xml-fragment-body and
application/xml-attribute-value
Terminology rework:
xcap resources, not xcap servers
More examples(?)
Match AUID grammar
with URI grammar
Clarify default
namespace behavior
Document URI
escaping and update examples
Clarify redirection
behavior
Clarify filename
extension behavior
Document
if-none-match * to avoid creating new document but otherwise allow modification
Look at WebDav 409 body
format useful to us (doesnt seem so, but more work needed)
Insertions go in at
the end if position is not specified
Update etag
behavior etag scope is defined by application usage
Presence Authorization
Rules
Authorization Document
Format
Current Set
Conditions
<identity> -
AOR of watcher
<anonymous> -
watcher is anonymous
<sphere> -
from common policy
Actions
<sub-handling>
Block deny
Confirm winfo
Polite-Block lie
Allow - OK
New transformation
type: inclusion-set
Set of rules that
identify to which tuple a permission is applied
Transformations
<provide-contact-uri>
Inclusion set
<provide-activity>
Inclusion set
<provide-tuples>
Inclusion set
<provide-class>
Inclusion set
<provide-contact-type>
Inclusion set
<provide-relationship>
Inclusion set
<provide-sphere>
Inclusion set
<idle-detail>
No-time: leave off
time
Full: include time
<provide-idle>
Inclusion set
<provide-placetype>
Inclusion set
<provide-privacy>
Inclusion set
<provide-unknown-status>
Next slide
Provide Unknown Status
Only
applies to content for which there is no schemas for explicit permissions known
to the server
Avoids
overlap with semantic approaches that can be defined later
Spec calls out an open
issue not on the slides. Two ways in which rule can appear. Need to couple this
with a discovery mechanism.
Henning: Another
solution would be to never extend the ruleset. Anything in the future has to be
done as listed on this slide. Another alternative is to avoid discovering the
namespaces.
Henning: Not made a
distinction between multiple facets of a condition.
What is a Tuple
RPID talks about four
types
Device
Phone, PDA, PC
Service
Telephony, IM, SMS,
email
Presentity
The user themselves
In-Person
The user as a
communications medium
However
These are still not
defined
Its hard to decide
whether RPID attributes apply to one and/or the other
Device problems
What is the meaning
of the contact URI
In-Person
How different from
presentity?
Proposed Model
Mapping the Model to PIDF
Presentity
status appears in a tuple with no contact
Each
service is modeled with a tuple
A
tuple can have a <device> element which indicates one or more devices and
their characteristics on which that service resides
Device
is thus another tuple attribute like the others
Henning: Determination
is made by fallible devices, therefore no guarantee that presented status is
correct.
Rohan: Do we mean
device or instance?
Adam: If running two
different client types, have one device.
Benefit of this Model
Easy transformation
to device view
A pivot operation
which unions together services that have the same device
Device isnt special
as a presence attribute for pivot!
Resulting document
is still a list of tuples, each representing a service
Easy transformation
to presentity view
A pivot that just
unions everything together
Result is a document
with one tuple with a contact representing one service, communications
Eliminates need for
contact-type
Tuple with no
contact element is presentity and in-person
Tuples with contacts
are services
Allows us to differentiate
what status information belongs in which places
Child of
<device>
In tuples with no
contact
In tuples with
contact
Benefits of Model
Nice tool for
correlating services that exist on the same device
Device ID would be
a meaningful URN
For phones, the tel
URI
Allows correlation
of device information received from non-presence sources (i.e., GPRS
connectivity state) to affected services
Allows differentiation of published data received from
different devices (my PC publishing available for IM vs. my cell phone
publishing that)
Proposed Path Forward
Remove
contact-type from RPID
Remove
attributes that are device specific
Clarify
presentity/service difference through contact URI presence/absence
Proceed
with result
Produce
a separate document introducing device concept and device attributes
Proceed
with Roberts examples document that elaborates on this
Discussion as to
whether device is a physical device or two instances of some abstract thing
running on a physical device.
Conclusion: Tuple with
contact id represents a service rather than a device. Tuple without contact
represents presentity or in-person. Discussion of device identifiers would be
dealt with in later documentation with its own set of open issues.
Event Filtering
Hisham
Khartabil
SIMPLE
WG
Interim
Meeting, Boston
24th
May, 2004
hisham.khartabi@nokia.com
Functional Description Issue (1)
A SUBSCRIBE request is allowed
to carry multiple filters. Need to add text that disallows more than 1 filter
per resource to be specified (eg: If the subscribe is for a list)
SUBSCRIBE sip:myfirends@domain.com SIP/2.0
<?xml
version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:pidf="urn:ietf:params:xml:ns:pidf">
<filter id="8439" uri="sip:sarah@domain.com">
<what>
<include>//pidf:tuple/pidf:status/pidf:basic</include>
</what>
</filter>
<filter id="999" uri="sip:sarah@domain.com">
<what>
<include
type="namespace">urn:ietf:params:xml:ns:pidf</include>
<exclude>//pidf:tuple/pidf:note</exclude>
</what>
</filter>
</filter-set>
Conclusion:
Do not allow more than one filter per resource.
Functional Description Issue (2)
Current
text: If the URI indicated by the filter is for one resource who's URI is NOT
one of the URIs that result from a lookup, by the RLS, on the Request-URI, the filter is propagated to
all the fanned out subscriptions.
List2 on RLS2 has:
Functional Description Issue (2)
RLS1 receives the following
SUBSCRIBE request
SUBSCRIBE sip:List1@example1.com SIP/2.0
<?xml
version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:pidf="urn:ietf:params:xml:ns:pidf">
<filter id="999" uri="sip:sarah@example1.com">
<what>
<include
type="namespace">urn:ietf:params:xml:ns:pidf</include>
<exclude>//pidf:tuple/pidf:note</exclude>
</what>
</filter>
<filter id="8439" uri="sip:alice@example2.com">
<what>
<include>//pidf:tuple/pidf:status/pidf:basic</include>
</what>
</filter>
</filter-set>
Functional Description Issue (2)
Currently, this is propagated
to RLS2
SUBSCRIBE sip:List2@example2.com SIP/2.0
<?xml
version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:pidf="urn:ietf:params:xml:ns:pidf">
<filter id="999" uri="sip:sarah@example1.com">
<what>
<include
type="namespace">urn:ietf:params:xml:ns:pidf</include>
<exclude>//pidf:tuple/pidf:note</exclude>
</what>
</filter>
<filter
id="8439" uri="sip:alice@example2.com">
<what>
<include>//pidf:tuple/pidf:status/pidf:basic</include>
</what>
</filter>
</filter-set>
Functional Description Issue (2)
Suggestion:
if a filter is destined to a resource that is part of list that is outside the
administrative domain of an RLS, then that filter is propagated. The rest are
consumed.
SUBSCRIBE sip:List2@example2.com SIP/2.0
<?xml
version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:pidf="urn:ietf:params:xml:ns:pidf">
<filter id="8439" uri="sip:alice@example2.com">
<what>
<include>//pidf:tuple/pidf:status/pidf:basic</include>
</what>
</filter>
</filter-set>
Adam:
Preventing loops of resource lists. Need to make sure have not stripped out
information that is used for determining this looping.
Functional Description Issue (2)
What
if the list last was:
List2 on RLS2 has:
Proposal
1: Only propagate filters that are for resources not under an RLSs
administrative domain. The rest are consumed
Proposal 2: Propagate all filters for resources
that the RLS did not find an entry for in a list, including resources under its
own administrative domain
Jonathan:
Lots of looping issues follow same argument as in SIP. Deal with list looping
with a subscription count header.
Adam: Doing
spirals rather than loops in resource lists doesn't make sense. RLS are B2BUA,
which are inherently not specified, and can go off into some other protocol
which are not required to carry this info.
Hisham:
This is out of scope of this issue, should have been dealt with in event-lists.
Rohan:
Propose that do not propagate any of the filters. Filter is consumed by 1st
RLS.
Cullen: If
I subscribe to set of filters, I expect it to make sure that these are
executed. Contract between user and first RLS.
Jonathan:
Therefore one option is to propagate as it so chooses, but this is not
specified.
Adam:
Therefore Adam needs text for the event-list draft covering this.
Conclusion:
None. Take to list.
Functional Description Issue (3)
Need to clarify that a filter
for an individual resource overrides a domain filter.
<?xml version="1.0"
encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:pidf="urn:ietf:params:xml:ns:pidf">
<filter id="8439" uri="sip:example1.com">
<what>
<include>//pidf:tuple/pidf:status/pidf:basic</include>
</what>
</filter>
<filter id="999" uri="sip:bob@example1.com">
<what>
<include
type="namespace">urn:ietf:params:xml:ns:pidf</include>
<exclude>//pidf:tuple/pidf:note</exclude>
</what>
</filter>
</filter-set>
Conclusion: A filter for an individual
resource overrides a domain filter.
Filter Format Issues (1)
<?xml
version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:pidf="urn:ietf:params:xml:ns:pidf">
<filter id=8439" uri="sip:alice@example1.com>
<what>
<include>//pidf:tuple/pidf:note</include>
</what>
</filter>
</filter-set>
When
removing a filter, a subscriber must explicitly do so by specifying the filter
ID along with the remove attribute set to True.
<?xml
version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter>
<filter
id="8439" remove=True/>
</filter-set>
Filter Format Issues (1)
Problem:
How does a subscriber replace a filter?
<?xml
version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:pidf="urn:ietf:params:xml:ns:pidf">
<filter
id="8439" uri="sip:alice@example1.com
remove=True/>
<filter
id="8440" uri="sip:alice@example1.com>
<what>
<include>//pidf:tuple/pidf:status/pidf:basic</include>
</what>
</filter>
</filter-set>
Filter Format Issues (1)
Proposal 1: disallow
inclusion of uri attribute when removing a filter
<?xml
version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:pidf="urn:ietf:params:xml:ns:pidf">
<filter
id="8439" remove=True/>
<filter
id="8440" uri="sip:alice@example1.com>
<what>
<include>//pidf:tuple/pidf:status/pidf:basic</include>
</what>
</filter>
</filter-set>
Proposal 2: Allow a
filter to be replaced using the same filter id
<?xml
version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:pidf="urn:ietf:params:xml:ns:pidf">
<filter id=8439" uri="sip:alice@example1.com>
<what>
<include>//pidf:tuple/pidf:status/pidf:basic</include>
</what>
</filter>
</filter-set>
Henning:
Proposal 2 seems cleaner.
Hisham:
Also his proposal.
Conclusion: A filter is replaced using the
same filter id.
Side discussion of VISIT versus SEND while
waiting. No conclusion.
Partial publication.
Missed from PUBLISH method. Is in PUBLISH
requirements draft (now expired) REQ10.
Proposes to reuse the content format of the
partial notification work in order to solve this requirement in PUBLISH.
Alternative is to break published document
up between multiple virtual PUAs rather than one actual PUA.
Robert: Suggestion that there may be
aifferent threat model between partial publish and partial notification.
Discussion could not identify an explicit
case.
Will call on list within next 4 weeks to
see if should be working group item.