Subject: [VCARDDAV] Geographic properties (issue 155)

From: Andy Mabbett <[email-masked]>
Date: Mon, 14 Jul 2008 22:23:38 +0100

The section on Geographic properties (issue 155)

        <http://www.vcarddav.org/issues.xhtml#155>

concludes:

        The reference to WGS 84 is now explicit. Other enhancements
        would probably best be served by extensions to the core vCard
        format.

        Current proposal: close without action.

I'm not clear by what is meant by "extensions to the core vCard format"
(as opposed to the changes debated here), but there seem to be several
overlapping issues here. I write as the author of the text quoted from
<http://microformats.org/wiki/vcard-suggestions>)

The proposed new properties are

  *  Coordinate Schema

        WGS 84 is indeed the most common schema for coordinates; but the
        WGS schema is revised every few years (previous versions were in
        1966 and 1972) and a replacement schema, EGM06 is already being
        worked on:

          <http://en.wikipedia.org/wiki/World_Geodetic_System#Updates_and_new_standards>

        Other schema for terrestrial coordinates also exist.

        I suggest that, while WGS 84 is a suitable default schema,
        others should be allowed, if specified.

  *  Body (child of ADR)

        Furthermore, it is likely that within the next few decades,
        there will be people living on The Moon, or Mars. It should, I
        contend, be possible to have vCards for such people, with an
        additional sub-property of ADR ("Body") and the relevant schema
        for coordinates on that body.

        This is discussed at length at:

                <http://microformats.org/wiki/luna>

                <http://microformats.org/wiki/mars>

                <http://microformats.org/wiki/geo-extension-strawman>

        and pages linked from those.

        Clearly, it is sensible for the default value to be "Earth".

  *  Altitude (aka elevation, depth)

        It was observed that many GPS devices record this third
        property, in addition to latitude and longitude. It is of
        particular relevance in aviation and submarine endeavours,
        including diving.

Other proposed, optional, child-of-ADR properties are:

  *  Vessel

        For people living on boats, ships, oil rigs, submarines, etc.
        Also people on the ISS or other spacecraft. This should be
        distinct from extended address, as in:

                "Saucy Sue"     (Vessel)
                The Harbour     (Extended address)
                Quayside        (Street)
                Seasideville    (Locality)

        and for a vessel under steam, the vessel name, but no other ADR
        properties, may be appropriate:

                Captain Bligh
                The Bounty      (Vessel)

  *  Continent

        Relevant if the person's location is known with no greater
        specificity (as may well be the case where contacts are made
        on-line, rather then by more traditional methods such as post)
        and for people in Antarctica, such as:

                <http://www.antarcticstation.org/>

Accordingly, I would urge reconsideration of the proposal to "close
without action". Thank you.

-- 
Andy Mabbett
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Darryl Champagne" <[email-masked]>
Date: Mon, 14 Jul 2008 18:53:49 -0400

Hi,
The reference to extensions is referring to the proposal I have copied
below.  It is not one I agree with, since I do not see it as at all likely
to happen in a reasonable timeframe (I would prefer to just include the
non-controversial things already in use elsewhere, rather than having to
deal with a bunch of different X- values), but for me this is a case of
choosing one's battles to focus on what is most important to me/my company
(Sync).

For reference, Geo was discussed back around Feb 26th, and Groups had a fair
bit of discussion around March 12/13 (and plus/minus a bit).

I wish you luck,

Hope this helps,
dgc

"
On Jul 11, 2008, at 2:41 PM, Chris Newman wrote:
> It's my opinion the vCard base spec should focus primarily on  
> properties that are already vCard standards track plus  
> synchronization issues.
>
> A separate draft on "Common vCard Extension Properties" that covered  
> many of the properties deployed in various other contexts would also  
> be a good work item.  Even better if it had a different editor so  
> work could proceed in parallel.
>
> But the more attributes we add to the vCard base spec, the longer it  
> will take to complete it so my default preference is to not add  
> properties to the base spec regardless of whether or not they're  
> good ideas.
>
> 		- Chris
>
"

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Andy Mabbett
> Sent: Monday, July 14, 2008 5:24 PM
> To: [email-masked]
> Subject: [VCARDDAV] Geographic properties (issue 155)
> 
...

---

From: "Javier Godoy" <[email-masked]>
Date: Tue, 15 Jul 2008 01:40:06 -0300

Darryl Champagne wrote:

> deal with a bunch of different X- values),
>

I also prefer to include those "non-controversial things", with the intention to 
fight against the extension nightmare (which, additionally, provides duplicated 
terms and other nastiness).
If we know that several vendors have identified information which cannot be 
described by vCard 3.0, and we are not fixing that in core vCard 4.0, we are 
motivating a lot of x-properties to fill the gap. However, things should be kept 
simple (for instance, extensions that are only relevant to some 
application-domain should not be in the core draft, but they should be 
somewhere).

In other words, if some vendor has additional information to be included in a 
vCard, it is material for a vendor extension; on the other hand, if several 
vendors have identified the same issue, it is a potential "common extension". 
The list will not (cannot) be complete, but it will be a good help for 
interoperability.

The IANA registry does not help for avoiding duplicated terms, unless we pretend 
it to be used in a "first come, first enforced" basis... which I think will not 
work: after Company 1 registers the "vnd-company1-foobar" property, Company 2 
will ask for "vnd-company2-foobar" (and will use "x-company2-foobar" if the 
registration were denied). Further, the value-spaces of vnd-company1-foobar and 
x-company2-foobar will be overlapped (*).

The solution would be to pre-allocate properties, parameters and values for 
expected use cases (the most the better *up to a reasonable limit*). Then 
vendors may register other values, which may or may not be understood by 
third-party implementations, but at least all will be able to understand the 
property/parameter semantics and implement a generic behaviour (e.g. this is a 
"vnd-company1-xyzzy" foobar), alike the text/x-* MIME subtypes. (I'm using 
metasyntactic examples in order to avoid discussing any proposed extension in 
this mail.)

Best Regards

Javier

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 15 Jul 2008 22:45:02 +0100

In message <00e001c8e604$7bc1df60$6f02a8c0@DGCSonyFS>, Darryl Champagne
<[email-masked]> writes

>below.

>> work could proceed in parallel.

Thank you. I'm not sure how to differentiate between "properties that
are already vCard standards" and "Common vCard Extension Properties".
Are these documented? Has the "separate draft" suggested by Chris been
started?

Neither of these questions appears to be answered on:

        <http://www.vcarddav.org/wiki>

nor the terms used above defined there, at least not so far as I can
tell.

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 17 Jul 2008 02:27:52 -0300

Andy Mabbett wrote:

> I'm not sure how to differentiate between "properties that
> Are these documented?

No. I guess "Common vCard Extension Properties" are (up to some exceptions) 
those properties which are not defined in RFC 2426 or RFC 4770, and were not 
proposed in draft-resnick-vcarddav-vcardrev-00 (the predecessor of 
draft-ietf-vcarddav-vcardrev).

> Has the "separate draft" suggested by Chris been
> started?

No, it hasn't. I'm very tempted to collect these issues and write an I-D.

> nor the terms used above defined there, at least not so far as I can

Right. (I think there should be an issue for indexing "good ideas and 
common/useful extensions".)

Best Regards

Javier