RFC Errata System | 28 Jan 14:47 2015

[Editorial Errata Reported] RFC6351 (4247)

The following errata report has been submitted for RFC6351,
"xCard: vCard XML Representation".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6351&eid=4247

--------------------------------------
Type: Editorial
Reported by: Ivan Enderlin <ivan.enderlin <at> fruux.com>

Section: Appendix A

Original Text
-------------
# 4.3.2
value-time = element time {
    xsd:string { pattern = "(\d\d(\d\d(\d\d)?)?|-\d\d(\d\d?)|--\d\d)"
                         ~ "(Z|[+\-]\d\d(\d\d)?)?" }
  }

Corrected Text
--------------
# 4.3.2
value-time = element time {
    xsd:string { pattern = "(\d\d(\d\d(\d\d)?)?|-\d\d(\d\d)?|--\d\d)"
                         ~ "(Z|[+\-]\d\d(\d\d)?)?" }
  }

Notes
(Continue reading)

RFC Errata System | 28 Jan 10:15 2015

[Editorial Errata Reported] RFC6350 (4246)

The following errata report has been submitted for RFC6350,
"vCard Format Specification".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6350&eid=4246

--------------------------------------
Type: Editorial
Reported by: Ivan Enderlin <ivan.enderlin <at> fruux.com>

Section: 6.2.5

Original Text
-------------
             BDAY;19531015T231000Z

Corrected Text
--------------
             BDAY:19531015T231000Z

Notes
-----
A typo when declaring the third BDAY property example: It is a colon, not a semi-colon.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
(Continue reading)

RFC Errata System | 27 Jan 15:06 2015

[Technical Errata Reported] RFC6350 (4245)

The following errata report has been submitted for RFC6350,
"vCard Format Specification".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6350&eid=4245

--------------------------------------
Type: Technical
Reported by: Ivan Enderlin <ivan.enderlin <at> fruux.com>

Section: 6.7.7

Original Text
-------------
   Value type:  A semicolon-separated pair of values.  The first field
      is a small integer corresponding to the second field of a PID
      parameter instance.  The second field is a URI.  The "uuid" URN
      namespace defined in [RFC4122] is particularly well suited to this
      task, but other URI schemes MAY be used.

Corrected Text
--------------
   Value type:  A single structured text value consisting of components
      separated by the SEMICOLON character (U+003B). The first
      component is a small integer corresponding to the second
      component of a PID parameter instance.  The second component is a
      URI. The "uuid" URN namespace defined in [RFC4122] is particularly
      well suited to this task, but other URI schemes MAY be used.

(Continue reading)

RFC Errata System | 27 Jan 09:47 2015

[Errata Verified] RFC6351 (4243)

The following errata report has been verified for RFC6351,
"xCard: vCard XML Representation". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6351&eid=4243

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Ivan Enderlin <ivan.enderlin <at> fruux.com>
Date Reported: 2015-01-27
Verified by: Barry Leiba (IESG)

Section: 5.1

Original Text
-------------
   Examples:

     <x-my-prop>
       <parameters>
         <pref><integer>1</integer></pref>
       </parameters>
       <text>value goes here</text>
     </x-my-prop>

     <ext:my-prop
         ext:xmlns="http://example.com/extensions/my-vcard">
(Continue reading)

RFC Errata System | 27 Jan 09:40 2015

[Technical Errata Reported] RFC6351 (4243)

The following errata report has been submitted for RFC6351,
"xCard: vCard XML Representation".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6351&eid=4243

--------------------------------------
Type: Technical
Reported by: Ivan Enderlin <ivan.enderlin <at> fruux.com>

Section: 5.1

Original Text
-------------
   Examples:

     <x-my-prop>
       <parameters>
         <pref><integer>1</integer></pref>
       </parameters>
       <text>value goes here</text>
     </x-my-prop>

     <ext:my-prop
         ext:xmlns="http://example.com/extensions/my-vcard">
       <parameters>
         <pref><integer>1</integer></pref>
       </parameters>                 <!-- Core vCard elements  -->
       <text>value goes here</text>  <!-- are still accessible -->
(Continue reading)

RFC Errata System | 26 Jan 11:48 2015

[Errata Verified] RFC6351 (4241)

The following errata report has been verified for RFC6351,
"xCard: vCard XML Representation". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6351&eid=4241

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Ivan Enderlin <ivan.enderlin <at> fruux.com>
Date Reported: 2015-01-26
Verified by: Barry Leiba (IESG)

Section: 5

Original Text
-------------
     BEGIN:VCARD
     VERSION:4.0
     contact.FN=...
     contact.EMAIL=...
     media.PHOTO=...
     CATEGORIES=...
     END:VCARD

Corrected Text
--------------
     BEGIN:VCARD
(Continue reading)

RFC Errata System | 26 Jan 11:38 2015

[Editorial Errata Reported] RFC6351 (4241)

The following errata report has been submitted for RFC6351,
"xCard: vCard XML Representation".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6351&eid=4241

--------------------------------------
Type: Editorial
Reported by: Ivan Enderlin <ivan.enderlin <at> fruux.com>

Section: 5

Original Text
-------------
     BEGIN:VCARD
     VERSION:4.0
     contact.FN=...
     contact.EMAIL=...
     media.PHOTO=...
     CATEGORIES=...
     END:VCARD

Corrected Text
--------------
     BEGIN:VCARD
     VERSION:4.0
     contact.FN:...
     contact.EMAIL:...
     media.PHOTO:...
(Continue reading)

RFC Errata System | 2 Jan 18:06 2015

[Errata Held for Document Update] RFC6350 (4213)

The following errata report has been held for document update 
for RFC6350, "vCard Format Specification". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6350&eid=4213

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Eric Vought <evought <at> pobox.com>
Date Reported: 2014-12-28
Held by: Barry Leiba (IESG)

Section: 5.4

Original Text
-------------
"Two property instances are considered alternative representations of
the same logical property if and only if their names as well as the
value of their ALTID parameters are identical.  Property instances
without the ALTID parameter MUST NOT be considered an alternative
representation of any other property instance.  Values for the ALTID
parameter are not globally unique: they MAY be reused for different
property names."

Corrected Text
--------------
"Two property instances are considered alternative representations of
(Continue reading)

Barry Leiba | 29 Dec 21:51 2014
Picon

Re: [Technical Errata Reported] RFC6350 (4213)

> 1) What should the current spec say to make clear its current meaning given
> that errata are not permitted to change its meaning? and
...
> #1 is my real concern for purposes of the errata
...
> I am unfamiliar with this group's process. When I worked with
> interpretations for IEEE PASC, there was a basic form response to the effect
> of, "The spec says what it says, but what it says currently makes no sense
> (for this case), therefore implementations shall not depend upon that
> combination. The underlying question will be resolved in a future version."
> I imagine you have a similar way of wording that? That is more or less what
> I was expecting to get back.

Well, we do have something of that nature: I can mark the errata
report "Rejected", which means either that it's wrong or that it's
outside the scope of the errata system, or I can mark it "Held for
Document Update" (HFDU), which means that it's a reasonable errata
report, but the resolution needs to be left for a future document
revision.

I do have some latitude here, and, while I see this as a "Rejected"
case (on the "out of scope" grounds), your point that it's hard (or
impossible) to build an implementation of this feature that reliably
interoperates... makes me inclined to use the latitude and go with
"HFDU" instead.

So that's what I intend to do, unless someone screams in the next
couple of days.

Barry
(Continue reading)

RFC Errata System | 28 Dec 17:25 2014

[Technical Errata Reported] RFC6350 (4213)

The following errata report has been submitted for RFC6350,
"vCard Format Specification".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6350&eid=4213

--------------------------------------
Type: Technical
Reported by: Eric Vought <evought <at> pobox.com>

Section: 5.4

Original Text
-------------
"Two property instances are considered alternative representations of
the same logical property if and only if their names as well as the
value of their ALTID parameters are identical.  Property instances
without the ALTID parameter MUST NOT be considered an alternative
representation of any other property instance.  Values for the ALTID
parameter are not globally unique: they MAY be reused for different
property names."

Corrected Text
--------------
"Two property instances are considered alternative representations of
the same logical property if and only if their names as well as the
value of their ALTID parameters are identical.  Property instances
without the ALTID parameter MUST NOT be considered an alternative
representation of any other property instance.  Values for the ALTID
(Continue reading)

Evert Pot | 17 Apr 02:33 2014

WebDAV Collection Sharing

Hi All,

At CalConnect, we are looking to standardize a way for users to share
Address Book and Calendar collections with each other.

As of right now, there's a specification to enable this for Calendars,
written by Cyrus Daboo. This is currently already implemented by a wide
range of both clients and servers.

The specification consists of two parts, and can be found here:

http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk/doc/Extensions/caldav-sharing.txt
http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk/doc/Extensions/caldav-notifications.txt

On a very high level, this specification operates as follows:

* A user (owner of a calendar) invites a number of people, by email
  address using a POST method on a calendar collection.
* The invitee receives a notification-resource in a notification-
  collection with the invite inforomation.
* The invitee can then choose to accept or reject the invitation with
  a second POST request.
* The owner of the calendar receive a reply in his/her notification
  collection.
* If the invitee accepted in the invite, the calendar now also appears
  in the invitees calendar home.

This all works pretty well. Recently we've started talking about
implementing something similar for CardDAV, allowing users to also share
Address Books.
(Continue reading)


Gmane