Subject: [VCARDDAV] GEO parameter across different vCard versions

From: <[email-masked]>
Date: Thu, 5 Mar 2009 10:23:02 +0100

Hi all,
I am looking for feedback from the working group.

Facts:
 - GEO field in vCard 2.1 BNF permits parameters.
 - GEO field in vCard 3.0 ABNF does not permit parameters.

Related question:
 - Why was it explicitly restricted in 3.0?

We are planning on including multiple GEO fields in the vCard, one for each address (HOME, WORK), representing the geo-location of the address. There is a need for a "link" between the two: the geo-location must be updated (or, dropped when cannot be updated) when the relevant address field is updated. The geo-location can be updated independently from the address (e.g. the user is on-site and updates the geo-location with the current position).

We could:
 - use vCard 2.1 and with it, the GEO parameters as permitted by the BNF.
 - use vCard 3.0 and create an extension (X-NOKIA-GEO or something like that).
 - for the new vCard draft, integrate the extension into the base spec.

The related questions:
Would it introduce IOP issue if we used 2.1 with the parameters?
What it be better to go for an extension in 2.1 as well?
What are the chances that the 3.0 extension will be widely adopted?
Can we make it part of the new vCard draft?

Is there a better way to solve this while ensuring that these address-specific geo-locations are retained across devices and the various specification versions?

Thank you for your feedback.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

---

From: Simon Perreault <[email-masked]>
Date: Thu, 05 Mar 2009 08:44:56 -0500

> - GEO field in vCard 3.0 ABNF does not permit parameters.

You mean exclusively X- parameters, right? I can't find predefined parameters
for both 2.1 and 3.0.

> - Why was it explicitly restricted in 3.0?

I'd guess a mistake. All properties should allow X- parameters.

> We are planning on including multiple GEO fields in the vCard, one for
> each address (HOME, WORK), representing the geo-location of the address.
> There is a need for a "link" between the two: the geo-location must be
> updated (or, dropped when cannot be updated) when the relevant address
> field is updated. The geo-location can be updated independently from the
> address (e.g. the user is on-site and updates the geo-location with the
> current position).
>  
> We could:

What extension? You can already do this in 4.0:

HOME.GEO:blah
WORK.GEO:blah

If you want to enforce the "this GEO must be updated when ADR changes"
semantics, then yes, an extension is the way to go. Not sure it needs to be
specified though. It's only a UA issue, i.e. "this UA automatically updates the
GEO property, neat!"

> What it be better to go for an extension in 2.1 as well?

No idea.

> What are the chances that the 3.0 extension will be widely adopted?

Now that 4.0 is almost done? I'd guess not good.

> Can we make it part of the new vCard draft?

Please elaborate on what exactly you're suggesting.

Thanks,
Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Markus Lorenz <[email-masked]>
Date: Thu, 05 Mar 2009 15:10:49 +0100

> I'd guess a mistake. All properties should allow X- parameters.

I checked the formats vCard 3.0 and draft 5 of 4.0. In both cases no
parameters are allowed for GEO.
And because you wrote "all parameters should allow x-parameters" I
checked for some more: PRODID, UID, VERSION, CLASS, NAME, KIND, PROFILE,
TZ. None of them allows any parameters. I guess for some it's
reasonable. But what I think for TZ and GEO it would make sense.

I also found that the "PROFILE" is not mentioned above the ABNF in 4.0
draft 5. There is no explanation.

Best regards

Markus

---

From: Simon Perreault <[email-masked]>
Date: Thu, 05 Mar 2009 09:12:59 -0500

> parameters are allowed for GEO.

Rewriting the ABNF is still on the TODO list.

---

From: <[email-masked]>
Date: Fri, 6 Mar 2009 10:18:03 +0100

Hi Simon,

>You mean exclusively X- parameters, right? I can't find 
>predefined parameters for both 2.1 and 3.0.

No, I mean the standard HOME and WORK parameters.
ADR;HOME -> GEO;HOME

>I'd guess a mistake. All properties should allow X- parameters.

I mean the GEO field (quoting RFC2426 here):
   ;For name="GEO"
   param        = ""
        ; No parameters allowed

   value        = float-value ";" float-value

So, GEO;TYPE=WORK is not possible.

>> field is updated. The geo-location can be updated independently from 
>> the address (e.g. the user is on-site and updates the geo-location 
>> with the current position).
>>  
>> We could:
>> - use vCard 3.0 and create an extension (X-NOKIA-GEO or 
>something like 
>> that).

Yes, it seems 4.9 will permit it again. I did not even check the ABNF because the description is identical to that in 3.0:
7.5.2. GEO
   Purpose:  To specify information related to the global positioning of
      the object the vCard represents.

The problem is "the object the vCard represents". It implies that there cannot be different geo-locations because there is only one object that the vCard represents.
I guess we should to correct this.

>semantics, then yes, an extension is the way to go. Not sure 
>it needs to be specified though. It's only a UA issue, i.e. 
>"this UA automatically updates the GEO property, neat!"

Yes, geo-location must be either updated, or removed if it cannot be updated.
I'd rather have an explicit requirement on this than leave it to UA.
Since there is support for the fields in 4.0, wouldn't it make sense to put this requirement into this draft?

>> What it be better to go for an extension in 2.1 as well?

Considering he requirement to update or delete the geo-location when the address changes, I guess an extension would be better for 2.1.

>Now that 4.0 is almost done? I'd guess not good.

Ok, I guess we can drop 3.0 then.

>Please elaborate on what exactly you're suggesting.

Well, since you have clarified that it is possible to have address-specific geo-locations in the new vcard draft, I guess the only thing missing is the requirement for the link (update or remove).

---

From: <[email-masked]>
Date: Fri, 6 Mar 2009 10:34:46 +0100

Hi Markus,

>I checked the formats vCard 3.0 and draft 5 of 4.0. In both 
>cases no parameters are allowed for GEO.
>And because you wrote "all parameters should allow 
>x-parameters" I checked for some more: PRODID, UID, VERSION, 
>CLASS, NAME, KIND, PROFILE, TZ. None of them allows any 
>parameters. I guess for some it's reasonable. But what I think 
>for TZ and GEO it would make sense.

Yes, 3.0 and 4.0 does not permit parameters.
Though in 4.0 there is no need for the type parameter anymore, some parameters have become groups:
   contentline  = [group "."] name *(";" param ) ":" value CRLF
       ; When parsing a content line, folded lines must first
       ; be unfolded according to the unfolding procedure
       ; described above. When generating a content line, lines
       ; longer than 75 characters SHOULD be folded according to
       ; the folding procedure described in [MIME DIR].

   group        = "WORK" / "HOME" / iana-token / x-name

   name         = iana-token / x-name
       ; Parsing of the param and value is
       ; based on the "name" or type identifier
       ; as defined in ABNF sections below

   iana-token   = 1*(ALPHA / DIGIT / "-")
       ; vCard type or parameter identifier registered with IANA

   x-name       = "X-" 1*(ALPHA / DIGIT / "-")
       ; Reserved for non-standard use

Here's the example from the draft:
10. Example: Authors' vCards
    ...
    WORK.ADR:;;2600 boul. Laurier\, suite 625;
     Quebec;QC;G1V 4W1;Canada
    ...
    WORK.GEO:46.772673,-71.282945
    ...

>
>I also found that the "PROFILE" is not mentioned above the 
>ABNF in 4.0 draft 5. There is no explanation.
>

Yes, the textual description is missing.

>Best regards
>
>
>Markus
>_______________________________________________
>VCARDDAV mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/vcarddav
>

---

From: <[email-masked]>
Date: Fri, 6 Mar 2009 10:35:56 +0100

Hi Simon,

>Rewriting the ABNF is still on the TODO list.

By this, you mean that the current one is not reliable.
That would explains a few things, thank you for the heads up.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 06 Mar 2009 11:17:16 -0500

> I guess we should to correct this.

I don't agree with this. There might be multiple bits of "information 
related to the global positioning" related to a single object. One 
saying where the object is when it is at work, another saying where the 
object is when it is at home, etc.

> Yes, geo-location must be either updated, or removed if it cannot be updated.

I strongly disagree. There is no guarantee that the information in vCard 
is current. It might have been valid in the 1800s, it might only be 
valid some of the time, etc.

vCard is a data format. It might be used in dynamic as well as static 
contexts. Context is out of scope for the data format specification.

Simon

---

From: <[email-masked]>
Date: Mon, 9 Mar 2009 14:03:56 +0100

Hi Simon,

>> Yes, it seems 4.9 will permit it again. I did not even check 
>the ABNF because the description is identical to that in 3.0:
>> 7.5.2. GEO
>> The problem is "the object the vCard represents". It implies 
>that there cannot be different geo-locations because there is 
>only one object that the vCard represents.
>I don't agree with this. There might be multiple bits of 
>"information related to the global positioning" related to a 
>single object. One saying where the object is when it is at 
>work, another saying where the object is when it is at home, etc.

Let's take two objects: a person and a building - me and the Capitolium.

I go whereever I please and that will be my current GEO - which, does not make much sense to be specified in the vCard because 10 minutes later I will be somewhere else - and vCard is not a presence. But, my HOME.GEO and WORK.Geo will not change when I move - those change when I go to live or work at another place/address.

The Capitolium does not go anywhere, it's GEO is always the same. Also, it does not make much sense to specify WORK.GEO and HOME.GEO for this object, does it?

So, "the object the vCard represents" is not good - because the HOME.GEO and HOME.WORK do not represent the vCard object (the person).

"the object the vCard represents" works only if one and only one GEO field could be specified (and there was no HOME.GEO and WORK.GEO, or, X-WHATEVER.GEO).

>I strongly disagree. There is no guarantee that the 
>information in vCard is current. It might have been valid in 
>the 1800s, it might only be valid some of the time, etc.
>
>vCard is a data format. It might be used in dynamic as well as 
>static contexts. Context is out of scope for the data format 
>specification.

When you know that something has been changed, you update it or remove it.
For example, if you had a copy of my vCard and you knew that I left Nokia, and
 - you know the new information, you will:
   - update the vCard with the new address and phone number
   - keep the old info (and have problems later on).
 - you don't know the new information, you will:
   - most likely deleted the old info (to avoid using the wrong info), or
   - keep the old info (and have problems later on).
I see this happening every day. Sure there can be wrong information - but why keep the old one when you do know that it's wrong and why not update it when you know the up-to-date information?

So, if there is a chance to keep the vCard clean, then why not specify some basic rules that can keep it clean?
You mention context - it would be still out of scope.