NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 16-Feb-99
Chair(s):
Robert Moskowitz <rgm@icsa.net>
Pat Egen <pregen@egenconsulting.com>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>
Applications Area Advisor:
Keith Moore <moore@cs.utk.edu>
Mailing Lists:
General Discussion:ietf-calendar@imc.org
To Subscribe: ietf-calendar-request@imc.org
In Body: [SUBSCRIBE/UNSUBSCRIBE in Message body]
Archive: http://www.imc.org/ietf-calendar/mail-archive/
Description of Working Group:
Calendaring and group scheduling products are well established for organizational use, but they usually are limited to exchange of information among users of the same system, usually within the boundaries of a single organization. This working group will pursue development of standards to enable different products to interoperate and to work across organizational boundaries. This work will include the development of MIME content types to represent common objects needed for calendaring and group scheduling transactions and access protocols between systems and between clients and servers. The working group will also consider and recommend solutions to the security issues concerning the exchange of calendar information between network entities.
The group will exist to create standards that make calendaring and scheduling software significantly more useful and to enable a new class of solutions to be built that are only viable if open standards exist. The Calendaring and Scheduling Working Group is chartered to focus on Internet standards for three basic problems facing group scheduling and calendaring users today. These include the following:
1. A standard content type for capturing calendar event and to-do information. The content type should be suitable as a MIME message entity that can be transferred over MIME based email systems or HTTP World Wide Web. The basic objects along with their representation using MIME will be specified in the document entitled "Core Object Specification".
2. A standard peer-to-peer protocol for common calendaring and group scheduling transactions. For example, these may include exchanging over the Internet, event-requests, reply to event-requests, cancellation notices for event-requests, requesting free/busy time and replying to free/busy time requests between different calendaring products. The working group will undertake this work in two phases, with the first phase focusing on meeting requests and the second phase on free-busy time. To the extent that the peer-to-peer protocol has requirements related to security, the working group will attempt to apply existing Internet standards for authentication, and to assure privacy and integrity of sensitive calendaring information. The protocol for the interoperable transactions will be specified in a document called "Calendar Interoperability Protocol" in the milestone list.
3. A standard access protocol to allow for the management of calendars, events and to-dos over the Internet. This protocol will be specified in the document called "Calendar Access Protocol" in the milestone list.
This working group effort should be developed and stabilized with a 6-9 months since there has been considerable prior work done in this area. This prior body of work includes:
* Distributed Scheduling Protocol (CHRONOS) IETF Working Group * ISO/IEC SC18 Distributed Office Application for Calendaring, Scheduling and Appointments * MHS Alliance Calendaring and Scheduling Interoperability Protocol (CSIP) * X.400 API Association (XAPIA) Calendaring and Scheduling API (CSA) and Calendaring and Scheduling Interoperabilty Specification (CSIS) * X/Open Consortium Calendaring and Scheduling (XCS) Implementor's Specification * Versit vCalendar format
The working group will focus on harmonizing, evolving and developing protocols and algorithms based on this work. The process is subject to extension if many new features are added, or more revision is needed.
Goals and Milestones:
Done |
|
Submit core object specification as Internet-Draft. |
Done |
|
Submit first Internet-Draft of Calendar Interoperability Protocol. |
Done |
|
Submit second draft of core object specification as Internet-Draft. |
Jun 97 |
|
Submit revised Internet-Draft of Calendar Interoperability Protocol. |
Jun 97 |
|
Submit core object specification to IESG for consideration as a Proposed Standard. |
Aug 97 |
|
Submit Calendar Interoperability Protocol to IESG for consideration as a Proposed Draft. |
Apr 98 |
|
Submit Internet-Draft on Calendar Access Protocol to IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· Calendar attributes for vCard and LDAP
· Internet Calendar Model Specification
Request For Comments:
RFC |
Status |
Title |
RFC2445 |
PS |
Internet Calendaring and Scheduling Core Object Specification (iCalendar) |
RFC2446 |
PS |
iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries |
RFC2447 |
PS |
iCalendar Message-based Interoperability Protocol (iMIP) |
CALSCH Working Group minutes:
15-Mar-99, 3:30PM - 5:30PM
Pat Egen and Robert Moskowitz - chairs
Agenda:
- Assign Volunteer Scribe: Alex Taler of CS&T and Bruce Kahn of Iris
- CAP Requirements: WG last call status
- XML/ICAL syntax resolution
- iRIP Update
- iTIP Identified issues/defects
- CAP Design Group status update
As of now, rough consensus on XML vs iCal is to stick w/iCal for syntax. In the future we may consider moving to XML.
After delta changes to CAP Requirements are in, it will not go to RFC but kept for historical reasons
IRIP discussion: Steve Manseur & Andre Courtemanche.
Issues from IETF 43:
- Resolved queuing issues in new draft
- Editorial fixes
- Revised draft to list
Remaining issues:
- Overlap between iRIP and CAP:
- Keep similar syntaxes so can sub/super set features. Uses are still semi-
- disparate. Need to get feedback from Steve on how to best differentiate them
- Request & responses are now tagged so can do > 1 request/response at a time
- Fan out response in multiple MIME blocks so data won't have to be merged into
- 1 block. Now each CalID will return separate MIME block(s)
Authentication/security Issues:
- Trusted relationship between iRIP servers not sufficient. Will want to borrow
- CAP authentication info/schema to re-use it.
- May need to authenticate users as opposed to calendars; a new concept for us.
- Others to be posted to the list
New Editorial issues based on new draft
- Will try to keep CAP and iRIP similar features in sync as they progress
Next steps:
- New draft by next IETF and one by 15-Apr-99.
- Track CAP progress
iTIP & iMIP Defects: Steve M. & Frank Dawson
- These solutions will be submitted to revise iTIP drafts.
Overloading iTIP REQUEST:
- Current method used for invite, reschedule, update, confirm, reply to refresh.
- A reschedule and/or update are semantically different than confirm or Reply to REFRESH
- Propose: New CONFIRM method to be used to (a) reply to a REFRESH and (b) notify participants of any changes to ATTENDEE or ORGANIZER. All other "reschedule" or "update" changes MUST use REQUEST method.
Identify sender of iTIP COUNTER:
- Can't identify who COUNTER came from because all of the ATTENDEEs will appear in the method.
- Propose: Only specify ORGANIZER and countering ATTENDEE in method.
- Caveat: Can still forward or delegate a REQUEST to change participants. However, only the ORGANIZER can remove a participant.; This removes functionality and can be done w/an iMIP header but won't work for all iTIP. Will revisit how to best do this on the list.
Intolerant iMIP receiver:
- MIP specifies numerous MIME encapsulations for iCal/iTIP msgs. It doesn't require that an implementation MUST be able to receive each of them. This is leading to interop problems w/different CUAs.
- Propose: A conforming iMIP implementation MUST be able to receive each of the MIME encapsulations shown in the iMIP examples.; It does not have to GENERATE them, just RECEIVE them! Why not just use multipart alternative instead of multipart mixed. A minimal MIME compliant mailer must grok multipart mime so this may be moot.
Adding/deleting ATTENDEE:
- If ORGANIZER adds or deletes an ATTENDEE, do they really have to send the reschedule to all of the other ATTENDEEs?
- Propose: No, they can send the REQUEST w/the new ATTENDEE info to just the new ATTENDEE. It is up to the CUA. It is an implementation dependent issue if the SEQUENCE number needs to be incremented when you add/delete an ATTENDEE. iCal does not require SEQUENCE rev if a new ATTENDEE is added so this won't break iCal or cause a revision there.
CAP Design Group discussion: Frank Dawson
Tomorrow's session will be tutorial on what the design group and the list have been working on.
Topics:
- Status of interim work
- Proposed schedule for work in 99
- CAP design summary (Continued tomorrow)
Design Goals:
- Leverage iCal and iTIP work
- Design to CAP Reqs doc
- Validate reqs wherever possible;
- Some deferred stuff was pulled in (ie VCARs) based on WG list feedback.
- Keep list active in providing feedback and consensus (vs "telling" them what the WG have done)
- Submit draft for July IETF mtg
Activities:
- 2 interim meetings: NYC 2/99 @ Morgan Stanley & Menlo Park 3/99 @ Sun
- Identified design approach for CAP data model, addressing, system model, state diagram, query, calendar access rights and command set
- Changes to reqs doc (moving in access rights, server fan out, the concept of a 'user')
- Need to gain closure on transport
- Poll of audience shows about 25% to 33% of the folks are new to CalSched so we went over the data and system model.
Data Model:
CS (calendar Store):
vTZs (timezones)
Properties (CS owners authids, CS's local time or time info, etc)
vCARs (access rights)
Calendar(s):
Calendar(s)
Calendar Properties ()
vCARs
vEvents
vAlarms
vTodos
vAlarms
vJournals
Questions from the floor and answers:
Calendars can have Calendars within them and the "parent" of the 'top' one has the CS as its parent. CS is what the CUA connects to.
What is meaning of "sub calendars"? Use inheritance of vCARs from parents, etc to see what access a user has.
Does naming imply hierarchy (ie: subcalendars vs parents): Calendar addresses have opaque names and hierarchy is NOT based on any schema of the CALID format so no, no implications! Names are just pretty human readable indicators for reference.
What is use of "sub calendars": To emulate how people organize their time, or other info. For example, my "soccer" calendar and my "work" calendar can be subcalendars of my main calendar. Other examples are parent calendar of a building and then subcalendars of resources in it. This model is a relationship model, not a storage model for data.
vCARs are inherited down but info is NOT inherited up! There are lots of client side and undiscovered issues to consider still. Needs to be thought out more and covered on the list!
Should multi-value PARENT properties be allowed? There are inheritance issues to consider WRT vCARs before just saying yes. There are also issues of having 'split' or disparate stores that contain the sub calendars (ie: Kids store on the ISP and my store at work!)
Would aliases for calendars be useful? What about mulitple personas? This can have/require multiple authIDs and names, etc to pull together.
Can CAP be used by 1 CUA to access > 1 CS at a time? Yep.
Is Group calendar support something to pull into initial release too? Is it necessary in the protocol or can it be done by CUA? Group Calendar = aggregate > 1 calendar into 1. VCARs could be used to emulate this but its ugly! An aggregate calendar could be an actual calendar instead of just an aggregate one. This needs to be taken to the list too.
CAP Addressing Model discussion:
A CalUID conforming to RFC 1738:
caluid = [<scheme>://[csid][:<port]/]<relativeCalUID>
<scheme> = "cap"
<relativeCalUID> = < any 7bit UIS-ASCII identifier>
Examples:
cap://calendar.example.com/user1
user1 (relative to the CS; equivalent to the one above)
cap://calendar.example.com/conferenceRoomA
cap://calendar.example.com/923345346-foo
RFC 1738 obsoleted by ~RFC 2368 CAP System Model:
Internet SMTP/MIME + iTIP is really CUA <-> CUA but it could be CS->CUA as well. iMIP could be used between CS1 and CS2 but then its addressing CS2, not CUA 2 Need to clarify what is mandatory and what is not in the model.
Fan out IS a requirement of CAP now.
CAP between CS1 and CS2: If CS acts as CUA then is it Fan out or not? Isn't this just a requirement for a fatter CS? If iMIP is a requirement then why is CAP between CS's of any use (if there is no authentication between all CS's)?
There was lots of discussion on this that will be brought up on the list.
The State Diagram was drawn.
Questions from the floor and answers:
What good is CAPABILITY in RTS state? Why not... Its nonsensical in this mode as a CUA should have up front checks not 'spur of the moment'.
What is the use of CONTINUEs? To handled bounded latency issues. Latency is not that bad on low latency intranets but can be larger on internet due to routers, etc. Clients on high latency connections will want to avoid the RTS state.
Missing assorted links in diagram from last revision. Frank to revise based on notes from last 2 interim meetings.
Need comment on how to handle tagging and multithreading, etc. Could be problems w/queued requests and reauthentcation, etc.
Next, there was a description of a Query:
Based on SQL clause/statements
Specified in a VQUERY component
Example:
BEGIN:VQUERY
QUERYID:Read today's event
QUERY: Select=UID,DTSTAT,DTEND,SUMMARY;FROM=VEVENT;Where=DTEND >=
19990315T143000Z and DTSTART <= 19990315233000Z; orderby=dtstart
asc, dtend, summary, uid
END:vQUERY
Question/Answers:
Why is it not just SQL? We already have concept of name=value so use it. Still, why just not use SQL?? Don't want to get raw SQL data that doesn't map 100% to iCal. Stuff in SQL may not be desirable now (ie: weighting of results) but may want later. If we use SQL syntax then we gain an already understood behavior; We just didn't want to get the mods that we'd have to make to avoid non-doable stuff (ie: "today"); There could be problems w/vendor extensions of SQL that dont interop so a strict separate syntax prevents that. Revisit on the list (did in Dec 98 but no responses). Pat asked for feedback on the list.
Calendar Access Rights:
Need to decide on the granularity of the CARs; property level, entry level, etc.
Specified calendar access for: Given authenticated calendar user (PRINCIPAL) and either: Particular calendar access policy (POLICY) or; Particular set of calendar operations (ACTION), Relation to a set of calendar components, calendar properties, component properties, property parameters (OBJECT), Particular property or parameter values (VALUE).
Specified in vCAR calendar component
No rights assumed; must be given them! There is no way to revoke rights (yet?) Need feedback on how to manage this.
Can I set VCARs that say "Frank can only edit my calendar between 3/15 and 3/19"? You can filter based on property values but not for this case in particular. Suggestion was it could be attempted using ROLEs.
Example:
BEGIN:VCAR
CARID:Read public events
GRANT: PRINCIPAL=foo;ACTION=READ;OBJECT=VEVENT
DENY:PRINCIPAL=foo;ACTION=READ;OBJECT=CLASS;VALUE=Private,
Confidential
END:VCAR
This example grants public R access to all docs and revokes access to Private or Confidential CLASS valued items How can I create a VCAR that prevents FOO from reading the CLASS: property?
How about: DENY:PRINCIPAL=foo;ACTION=*;OBJECT=CLASS
Can a properties value be used to govern a vCAR? Yes. Unclear how this is
different from above except the missing VALUE=;
What about adding a new SCOPE parameter to target the scale to filter out: property, doc, etc
How about a SCOPE property for the right (all components, etc)??
Do we want to add expressions to build "Give Frank Access from 3/15/to 3/19" to the VCARs? What about adding ranges of values, etc.??.. Take to list as we need more input on this. This will be done by Tony Small.
Policy support is mandatory, Grammar is optional. Assorted proposals will be posted to list with indicator as to status within the WG (ie: draft, proposed for CAP v1, etc).
CAP Command Format:
CUA command request format:
<label> <command> [<command data>]
CS command response format:
<label> <response code> [<response data>]
Example
C: 10 Create VCALENDAR cap://cal.foo.com/
S: 10 2.0
Are labels required?? Take to list about tagging.
Proposed Sched of Work for 1999:
2 final interim mtgs (will be announced on the list)
4/27 & 28 Lotus (Atlanta)
6/8 & 9 CS&T (Montreal)
Produce CAP draft by 45th IETF cut off date. Review/comment on CAP v1
The Area Director informed us to be careful and limit our interim meetings. The meetings must be a working group meeting, not a design team meeting. All discussions should also be on the list.
Tuesday, 16-Mar-1999, 1:15PM - 2:15 PM
Agenda:
CAP Design Status continuation
Transport issues
Recap of yesterday: Frank D. & Pat Egen
Several design examples were presented. The command list was shown:
abort, authenticate, capability, continue, create, delete (permanent (tombstone properties are available)) disconnect, generatedUID (server generates (globally?) unique id for a client), modify, move (optional) move a calendar, NOOP, READ, senddata
There are lots of latent issues w/tombstones and/or not... Need to request additional feedback from list on their use or not.
CREATE Sample (on cal.example.com):
Example #1:
C: 10 CREATE VCALENDAR cap://cal.example.com/ relcal4 ://bobo.ex.com
relcalBoo
S: 10 6.0 cap://cal.example.com/
S: 10 2.0 cap://cal.example.com/relcal4
S: 10 3.1.4 cap://bobo.ex.com/
S: 10 6.2 cap://cal.example.com/relcalBoo
C: 10 CREATE VCALENDAR cap://cal.example.com/relcal8 relcal9
S: 10 3.1.5 cap://cal.example.com/relcal8
S: 2.0 cap://cal.example.com/relcal9
C: 10 SENDATA
S: 10 2.0.1
C: Content-Type: text/calendar; method=create; component=vCommand C: Content-Transfer-Encoding: 7bit C:
C: BEGIN: vCalendar
C: VERSION:2.1
C: METHOD: CREATE
C: BEGIN:vCommand
C: BEGIN:vCalendar
C: RELCALUID:relcalZ
C: NAME;CHARSET=US-ascii;Language=en-us:Bill's Soccer Team
C: OWNER:CAPCAR:bill
C: OWNER:CAPCAR:mary
C: CALMASTER:mailto:bill@example.com
C: PREFERRED-TZID: US_PST
C: BEGIN:VCAR
C: CARID:12345
C: GRANT;cn="Bill Jones":principal=capcar:bill;action=all;object=all
C: GRANT;cn="Mary Jones":principal=capcar:mary;action=read;object=all
C: END:VCAR
C: END:VCOMMAND
C: END:VCALENDAR
C: .
S: 10 6.0 cap://cal.example.com/
S: 10 2.0 cap://cal.example.com/relcal4 cap://cal.example.com/recalZ
S: 10 3.1.4 cap://bobo.ex.com
S: 10 6.2 cap://cal.example.com/relcalBoo
S: 10 3.1.5 cap://cal.example.com/relcal8
S: 10 7.0 cap://cal.example.com/relcal9
Questions:
Is there a problem w/a variable length entry line (ie: denial of service attacks)? Not really if you use CRLF delimitation. However this approach is not condusive to tagged data and multithreading in some ways.
Are numeric response codes good or bad? The dot notation is good for expansion but not good for users. Then again what does 3.6.1.2.6.2.2 mean if I don't grok it?? Using character strings avoids < or > comparison of values that DRUMS had hassles with. Some like human readable formats ie: forbidden.no_auth. This can be useful for some but iTIP has a code;explain text;opt arg text format. Perhaps the response needs to be more iTIPish. Use of numbers is consistant w/RFCs for iCal, iTIP, iMIP. Take back to list for continued dialog.
Why have tagged commands? To allow pipelining or batching further down the line in case we want to add it some day. There are still some issues (like w/SWITCH) to be worked out. Also, the tag is used to match data w/prior commands (ie SENDATA to all CREATEs).
What about problems like C: 10 CREATE and then C: 10 DELETE and then
C: 10 SENDATA? Its a problem w/tagging and will revisit. (Its not IMAP like tagging, its different!). There are concerns about SENDATA being atomic and not allowing tagged data to be sent. Tagging data (unlike IMAP) could be a performance issue/boost. Also avoid CRLF.CRLF for data deliniation so tagging wont crash something else.
The new OWNER property is a TBD propety for handling naming of users. Paul Hill will be sending draft to list on naming users.
Why use MIME headers that duplicate the actions encoded in the SENDATA? Its duplication of info so why do it? Design is just like iTIP that has info in MIME header and in the data.
The CREATE command does not do the actual creation; its just a probe to see if it is possible so the CUA can do it or not. The actual create is done in the iCal data. Is this iTIP overhead necessary? What worked for iTIP may not be necessary now. Perhaps rename CREATE to something more apropo. Let the list discuss further.
Second BEGIN: VCALENDAR is to indicate what we are creating... Will this toss base iCal parsers that do parsing before parameter matching, checking etc?? Why not use a simple new property like ITEM-TYPE:...?? (Otherwise we violate iCal RFC!)
The reply codes do not jive before and after for some cases like it now exists when it didnt before. The intent was to do this. Add mandatory "S: final msg" line so client knows when server is done.
What about having a SIZE indicator of some time for the SENDATA command so CUA can tell CS what is coming so it can allow/reject w/o wasting time/bandwidth. Good idea.
What about a different EOD than CRLF.CRLF?? Possible. Ask the list.
Example #2: (Same as #1 but no RELCALID)
C: 10 CREATE VCALENDAR cap://cal.example.com/ relcal4 ://bobo.ex.com
relcalBoo
S: 10 6.0 cap://cal.example.com/
S: 10 2.0 cap://cal.example.com/relcal4
S: 10 3.1.4 cap://bobo.ex.com/
S: 10 6.2 cap://cal.example.com/relcalBoo
C: 10 CREATE VCALENDAR cap://cal.example.com/relcal8 relcal9
S: 10 3.1.5 cap://cal.example.com/relcal8
S: 2.0 cap://cal.example.com/relcal9
C: 10 SENDATA
S: 10 2.0.1
C: Content-Type: text/calendar; method=create; component=vCommand C: Content-Transfer-Encoding: 7bit C:
C: BEGIN: vCalendar
C: VERSION:2.1
C: METHOD: CREATE
C: BEGIN:vCommand
C: BEGIN:vCalendar
C: NAME;CHARSET=US-ascii;Language=en-us:Bill's Soccer Team
C: OWNER:CAPCAR:bill
C: OWNER:CAPCAR:mary
C: CALMASTER:mailto:bill@example.com
C: PREFERRED-TZID: US_PST
C: BEGIN:VCAR
C: CARID:12345
C: GRANT;cn="bill jones":principal=capcar:bill;action=all;object=all
C: GRANT;cn="Mary Jones":principal=capcar:mary;action=read;object=all
C: END:VCAR
C: END:VCOMMAND
C: END:VCALENDAR
C: .
S: 10 6.0 cap://cal.example.com/
S: 10 2.0 cap://cal.example.com/relcal4
S: 10 3.1.4 cap://bobo.ex.com
S: 10 6.2 cap://cal.example.com/relcalBoo
S: 10 3.1.5 cap://cal.example.com/relcal8
S: 10 7.0 cap://cal.example.com/relcal9
cap://cal.example.com/rand1234
READ Command:
C: 10 READ VEVENT relcal2 ://bobo.ex.com/relcal3
S: 10 2.0 cap://cal.example.com/relcal2
S: 10 2.2 cap://bobo.ex.com/relcal3
C: 10 SENDATA
S: 10 2.0.1
C: Content-Type: text/calendar; method=read; compoent=vcommand C:
C: BEGIN:V
C: VERISON:2.1
C: METHOD:READ
C: BEGIN:VCOMMAND
C: BEGIN:VQUERY
C: MAXRESULTS:20
C: MAXSIZE:17000000
C: QUERYNAME:MyViewRange
C: QUERY:SELECT (DTSTART,DTEND,SUMMARY,UID);
C: FROM VEVENT;
C: WHERE (DTEND >=1999-310T080000Z AND DTSTART <= 19993010T190000Z);
C: ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY)
C: END:VQUERY
C: END:VCOMMAND
C: END:VCALENDAR
C: .
S: 10 2.0 cap://cal.example.com/relcal2
S: Content-Type: text/calendar; method=response; component=vdata;
optinfo=version 2.1 S: C-T-E: 7bit S:
S: BEGIN:vCalendar
S:..
S: end:VCALENDAR
S: .
S: 10 2.0 cap://bobo.ex.com/relcal3
S: Content-Type: text/calendar; method=response; component=vdata;
optinfo=version 2.1 S: C-T-E: 7bit S:
S: <MIME data from relcal3>
S: .
Questions:
Need suggestion on how to get "next 20" if just get 1st 20. Could add FIRSTRESULT: to the query and then resubmit it. Send suggestions to list (ie LDAPs ways, etc).
Can use same QUERYNAME to reissue w/o resending the QUERY info. Need to be careful about namespace collision and possbible security holes. There are also QUERY permanance issues to consider like how to keep them. Are the values persistent or not? Will follow-up to list.
Is the MAXSIZE per component or for the entire data? TBD, poll the list.
The QUERY mechanism is SQL like but not SQL-92. They are not 100% interchangeable and SQL is not appropriate so its a mishmash.
Searchings are parametric, not content search.; Will raise the query mechanism on the list. Need to look at the LDAP searching.
Is content searching a requirement of CAP or not? No but perhaps we should consider adding it as its an existing feature in C&S apps.
Need to add some way to indicate end of all responses. Will add something
Access Rights Notes (Proposal):
Access to some requested properties of an event but not all. For example, requestor does not have access to VEVENT.SUMMARY: ... Query SELECT (DTSTART, DTEND, SUMMARY, UID); ... Responses: .... RESPOSE-CODE:3.8
We have no way to differentiate between No access to the prop vs No prop of that name and also what property it applies to. Isn't the opt arg or format text parts of the reply code suitable to convey this (using > 1 RESPONSE-CODE in a response then).
Meeting adjourned.
Thanks to Co-scribes: Bruce Kahn (bruce_kahn@iris.com) and Alex Taler (alext@cst.ca)