Re: Access Control

[Tim Howes <howes@xxxxxxxxxxxx>]

Dr. Mark K. Joseph wrote:
> 
> I would also agree with this.  However, I remember the reciption that
> the ASID MIME-DIR draft received in Montreal.  It was unfavorable ?  I
> was in the meeting that got pretty hot discussing how the basic vCard
> format (similar to vCalendar format) that was being transported in
> the ASID MIME-DIR structure was all wrong.  So if we proceed with ASID
> MIME-DIR those concerns brought up in Montreal should be addressed up front.

There are two documents here, and it's important to understand the
differences. The first document, is "A MIME Content-Type for Directory
Information", available here:

   
http://ds.internic.net/internet-drafts/draft-ietf-asid-mime-direct-02.txt

This document defines the general framework for carrying type/value,
attribute- or property-like information in a MIME type. The second
document is "An Application/Directory MIME Content-Type Electronic
Business Card Profile", available here:

   
http://ds.internic.net/internet-drafts/draft-ietf-asid-mime-vcard-00.txt

This document uses the framework defined in the first document to
define specific information that should be carried to represent
personal contact and other information about a person. This is
also known as the "vcard" document, since it is aligned with the
versit consortium's vcard specification (same format inside the
mime type).

Our expectation is that other documents will be defined to support
other applications (e.g., a document that defines a "calendaring
information" profile). Like vcard, these documents use the framework
defined in the framework document.

In the Montreal meeting, there were several comments on the vcard
draft. I've included the appropriate excerpt from the ASID minutes
on this topic below. In summary, though, I don't think there was
anything too controversial.                              -- Tim

        - versit/pdi vcard profile

                Patrik Falstrom led the discussion of a number of
                problems/changes he has encountered with the vcard
                profile and application/directory framework. The issues
                included:

                - Character set: The default is currently 7-bit ascii.
                The group agreed that this default could safely be
                changed to UTF-8, since it is a superset of 7-bit
                ASCII, and since there were alternate methods of
                selecting character set within the specification
                already.

                - Encoding mechanism: The default is currently 7-bit
                clean encoding. The group agreed to change the default
                to 8-bit encoding, with the appropriate MIME or
                application/directory field-specific encoding to be
                used if a 7-bit encoding was required.

                - Linebreaks: The current versit vcard draft states
                that CR, LF, and CRLF sequences should all work as line
                break sequences. Frank Dawson confirmed that the
                intention here was to do the same thing RFC 822 does by
                allowing whatever end-system representation was
                natural, but using a canonical representation on the
                network.  Frank, Patrik, John Myers, and Dave Crocker
                agreed to come up with clarifying wording for the
                draft.

                ACTION: Frank, Patrik, John, and Dave to clarify
                        wording in the vcard draft.

                In the course of the discussion, Dave Crocker
                volunteered to write up a separate Internet Draft
                describing how to handle the linebreak problem in the
                general case, since it appears to be something many
                people have run into before.

                ACTION: Dave to produce "how to handle linebreaks"
                        draft.

                - Timezone representation: The current draft allows a
                number of timezone representations. The group agreed to
                standardize on always using the single format defined
                in RFC 822.

                ACTION: Frank and Tim to produce a new version of
                        the vcard draft with above revisions.