Subject: [VCARDDAV] Geographic properties (issue 155): low-granularity addresses.

From: Andy Mabbett <[email-masked]>
Date: Sun, 27 Jul 2008 18:34:03 +0100

What are user-agents supposed to do with addresses, where the data
provided by a system (or human user) is of unspecified format or
granularity?

For example, consider the output of a system which gives three
addresses, as single-property text strings:

        41 High Street, Anytown

        Bigtown, England

        34 Green Lane, B1 1AA

The method used by the hCard microformat is to use them to populate the
LABEL property, and include no ADR.

RFC 2426 defines LABEL as:

   Type purpose: To specify the formatted text corresponding to delivery
   address of the object the vCard represents.

Do folks think that the method described above matches that definition,
or is an abuse of it?

Should vCard have a separate property for non-granular address strings
such as the examples, given?

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

---

From: Mark Paterson <[email-masked]>
Date: Mon, 28 Jul 2008 09:24:19 -0400

> Do folks think that the method described above matches that definition,
Not sure it is an abuse of it but I can say that in many mobile 
implementations the LABEL attribute is used as a way to get away with 
not supporting ADR. So when a user creates a new contact and specifies 
an address and then syncs their address book the server receives just 
the LABEL and is left with the problem of trying to do something 
intelligent with it.

I'd prefer to see LABEL as only being allowed in combination with a 
properly specified ADR.

Mark

-- 

Oracle Email Signature Logo
Mark Paterson | Product Manager, UC & Mobile Services | 514.905.8649
Oracle Server Technologies - Collaboration
600 Blvd. de Maisonneuve West, Suite 1900, Montreal, Quebec, H3A 3J2
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Mon, 28 Jul 2008 15:56:21 +0100

> I'd prefer to see LABEL as only being allowed in combination with a 

The problem with this is that many very common address formats don't fit 
the ADR property's information model.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Mark Paterson <[email-masked]>
Date: Mon, 28 Jul 2008 11:41:02 -0400

Simon Perreault wrote:
> The problem with this is that many very common address formats don't 
> fit the ADR property's information model.
Then we should change the information model.

--

---

From: Simon Perreault <[email-masked]>
Date: Mon, 28 Jul 2008 16:48:13 +0100

> Then we should change the information model.

Please note that this is a tar pit. There has been a lot of work in the 
IETF toward this end but as far as I know there is nothing we can refer to.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Mon, 28 Jul 2008 13:43:28 -0300

Mark Paterson wrote:

>Simon Perreault wrote:
>>Mark Paterson wrote:
>>>
>>>I'd prefer to see LABEL as only being allowed in combination with a properly 
>>>specified ADR.
>>>
>>
>>The problem with this is that many very common address formats don't fit the 
>>ADR property's information model.

Could you give an example? Issue #155 refers to moon bases, Mars expeditions, 
lunar craters, Martian mountains, ships, live-aboard boats, oil rigs, and even 
space vehicles (and Antartica bases were recently discussed). While I don't want 
to deprive those people from their vCards, I think such use cases are by no 
means "common".

I'm certainly missing something, because I can only think of common addresses 
which are not defined in terms of "street", but there is always a reference 
which can replace the street component, then the information model fits.

>Then we should change the information model.

IMHO the problem is that no single information model (as defined for the currend 
ADR property, i.e. a list of values) fits all common address formats.
If we add a text component in ADR for the X part of an address, then we will 
realize that addresses defined in term of Y cannot be represented, and we will 
end with a long list of components, most of which will be empty.

Alternatively, we could kept the current information model (with minor 
variations if necessary) and allow extensible models to be used in other cases 
(and avoid dealing with particular cases in the core spec).

Would that solve the problem?

Javier

---

From: Simon Perreault <[email-masked]>
Date: Mon, 28 Jul 2008 18:01:39 +0100

Javier Godoy wrote:
> Could you give an example? Issue #155 refers to moon bases, Mars 
> expeditions, lunar craters, Martian mountains, ships, live-aboard boats, 
> oil rigs, and even space vehicles (and Antartica bases were recently 
> discussed). While I don't want to deprive those people from their 
> vCards, I think such use cases are by no means "common".

This was presented in Philadelphia:

http://tools.ietf.org/html/draft-wolf-civicaddresses-austria-01

> I'm certainly missing something, because I can only think of common 
> addresses which are not defined in terms of "street", but there is 
> always a reference which can replace the street component, then the 
> information model fits.

Yes, you're right. Anything can fit in there as long as you stretch the 
meaning of components large enough.

> variations if necessary) and allow extensible models to be used in other 
> cases (and avoid dealing with particular cases in the core spec).

+1

---

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

In message <9A709E1912694B2292865D947A395679@Javier2>, Javier Godoy
<[email-masked]> writes

>expeditions, lunar craters, Martian mountains, ships, live-aboard
>boats, oil rigs, and even space vehicles (and Antartica bases were
>recently discussed). While I don't want to deprive those people from
>their vCards, I think such use cases are by no means "common".

You're conflating two threads; the one about "uncommon" (sic [*])
addresses such as those on other bodies, in orbit, and on water/at sea;
and this one, which is about non-granular "common" addresses, where
systems output an address (or users enter one) as a single string,
without sub-dividing it into street address, locality, region etc.

I did title the threads separately, to try to clarify the distinction!

Examples of the unstructured, "common" addresses discussed in this
thread may be found in Wikipedia "infoboxes" (pull-out panels), which
are marked up as hCard microformats and thus may be exported as vCards.

See, for instance, the "company" infobox:

        <http://en.wikipedia.org/wiki/Template:Infobox_Company>

which allows editors to include the "location" of a company as a single
field, with content as disparate as:

        Ada, Michigan

                <http://en.wikipedia.org/wiki/Amway>

        The Walt Disney Studios [line break]
        Burbank, California, USA

                <http://en.wikipedia.org/wiki/The_Walt_Disney_Company>

        Googleplex, Mountain View, California, US

                <http://en.wikipedia.org/wiki/Google>

        Dulles, Loudoun County, Virginia, USA

                <http://en.wikipedia.org/wiki/Netscape>

        Leiden, South Holland, The Netherlands

                <http://en.wikipedia.org/wiki/IKEA>

        Sant'Agata Bolognese, Italy

                <http://en.wikipedia.org/wiki/Lamborghini>

        Ponzano Veneto

                <http://en.wikipedia.org/wiki/Benetton_Group>

        Greater London

                <http://en.wikipedia.org/wiki/Transport_for_London>

        Brentwood, Essex, UK

                <http://en.wikipedia.org/wiki/Amstrad>

        80-86 Old Street, London EC1V 9NN

                <http://en.wikipedia.org/wiki/Post_Office_Ltd.>

There are literally many thousands of such unstructured addresses on the
English-language Wikipedia alone (I stopped counting at 10,000 instances
of that one infobox), and there are hundreds of similar templates.

To rephrase the question: if a vCard-authoring application is presented
with two unstructured address strings, say:

        Greater London
and:

        80-86 Old Street, London EC1V 9NN

should that application write each of them to the "street address" or
"locality" component of the ADR property of the respective vCards, or to
the "LABEL" property (as currently suggested when the vCard is derived
from an hCard microformat); or should there be a separate,
"UNSTRUCTURED_ADDRESS" property?

[*] Though it applies to the other thread, I wonder how many people,
globally, live (or serve, in navies) on boats?

The BBC says that "there are thought to be around 15000 people living
aboard canal boats in the UK":

  <http://www.bbc.co.uk/insideout/northwest/series6/canal_boats.shtml>

and the number is certainly lower here than the Netherlands or many
delta regions; while a single US carrier (the US alone has 11 in active
service, plus all their other ships) has a crew of 5,780:

  <http://en.wikipedia.org/wiki/USS_Ronald_Reagan_(CVN-76)>

---

From: "Javier Godoy" <[email-masked]>
Date: Mon, 28 Jul 2008 22:07:25 -0300

Andy Mabbett wrote:

>Javier Godoy writes
>
>>Issue #155 refers to moon bases, Mars

I was confused about your first message in *this* thread 
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00532.html
When I read it, I also read Simon's response [[
 the problem with this is that many very common address formats don't fit the 
ADR property's information model
]] then I tried to understand your examples from this perspective.

(quoted out of order)
> "UNSTRUCTURED_ADDRESS" property?

So far we have two issues:

1. Constructing ADR values from formatted text:

IMHO, applications MUST NOT write an ADR property from formatted text, unless 
they know what they are doing. The A property introduces a semantic distinction 
among address components, while the LABEL property is formatted text intended 
for human consumption.

If an application writes "80-86 Old Street, London EC1V 9NN" as street-address, 
the semantics is lost (although the result may still be understood by a human, 
as the LABEL property is, hence it would be redundant to write it twice, and 
UNSTRUCTURED_ADDRESS is not required) .

2. Completeness of the ADR information model.

The information model is not complete, but your examples do not illustrate that 
point (right, it wasn't your question, but it was raised in this thread). This 
was the cause of my confusion.

> of that one infobox), and there are hundreds of similar templates.

The problem would be extracting the address components from the formatted 
address (and the challenge would be doing so automatically, with a low error / 
non-recognition rate).

I have written ADR properties for your examples just for proving that most of 
them fit the information model (with the only exception of counties, which 
cannot be represented, but I think it is out of the scope of your question). We 
could add a "county / regional sub-unit" component in the (standard) information 
model, other cases should be addressed by extension models.

ADR: post office box; extended address; street address; locality; region; postal 
code; country name.

>        Ada, Michigan
ADR: ;;;Ada;Michigan;;
(locality, region)

>        Burbank, California, USA

ADR: ;;;Burbank;California;;USA
(locality, region, country)

>        Googleplex, Mountain View, California, US
ADR: ;;Googleplex;Mountain View;California;;US
(pseudo street address, locality, region, country)

>        Dulles, Loudoun County, Virginia, USA

ADR: ;;;Dulles;Virginia;;USA
(locality, region, country)
Problem: the information model does not allow county.

>        Leiden, South Holland, The Netherlands
ADR: ;;;Leiden;South Holland;The Netherlands
(locality, region, country)

>        Sant'Agata Bolognese, Italy
ADR: ;;;Sant'Agata Bolognese;;Italy
(locality, country)

>        Ponzano Veneto
ADR: ;;;Ponzano Veneto;;
(locality)

>        Greater London
ADR: ;;;;Greater London;
(region)

>        Brentwood, Essex, UK
ADR: ;;;Brentwood;Essex;UK
(locality, region, country)

>        80-86 Old Street, London EC1V 9NN

ADR: ;; 80-86 Old Street;London;;EC1V 9NN;
(street address, locality; postal code)

Best Regards

Javier

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 29 Jul 2008 19:44:12 +0100

In message <B1A58215D20741BCAB8B9EC7A560A09F@Javier2>, Javier Godoy 
<[email-masked]> writes

>IMHO, applications MUST NOT write an ADR property from formatted text, 
>unless they know what they are doing. The A property introduces a 
>semantic distinction among address components, while the LABEL property 
>is formatted text intended for human consumption.
>
>If an application writes "80-86 Old Street, London EC1V 9NN" as 
>street-address, the semantics is lost (although the result may still be 
>understood by a human, as the LABEL property is, hence it would be 
>redundant to write it twice, and UNSTRUCTURED_ADDRESS is not required)

Do you mean to suggest that addresses of unknown construction should be 
written to the LABEL property?

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 30 Jul 2008 00:18:23 -0300

Andy Mabbett wrote:

>>they know what they are doing. The A property introduces a semantic 
>>distinction among address components, while the LABEL property is formatted 
>>text intended for human consumption.
>>
>>understood by a human, as the LABEL property is, hence it would be redundant 
>>to write it twice, and UNSTRUCTURED_ADDRESS is not required)
>

Exactly.

7.3.1. ADR. Purpose:  To specify the components of the delivery address for the 
vCard object.

7.3.2. LABEL. Purpose:  To specify the formatted text corresponding to delivery 
address of the object the vCard represents.

Javier

---

From: Mark Paterson <[email-masked]>
Date: Wed, 30 Jul 2008 09:38:54 -0400

Javier Godoy wrote:
>>> IMHO, applications MUST NOT write an ADR property from formatted 
>>> text, unless they know what they are doing. The A property 
>>> introduces a semantic distinction among address components, while 
>>> the LABEL property is formatted text intended for human consumption.
>>>
>>> street-address, the semantics is lost (although the result may still 
>>> be understood by a human, as the LABEL property is, hence it would 
>>> be redundant to write it twice, and UNSTRUCTURED_ADDRESS is not 
>>> required)
>>
>> Do you mean to suggest that addresses of unknown construction should 
>> be written to the LABEL property?
>
> Exactly.
>
> 7.3.1. ADR. Purpose:  To specify the components of the delivery 
> address for the vCard object.
>
> 7.3.2. LABEL. Purpose:  To specify the formatted text corresponding to 
> delivery address of the object the vCard represents.
I disagree. The text implies that Label is to show a formatted rendition 
of the delivery address which is stored in ADR.

Mark

--

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 30 Jul 2008 13:31:57 -0300

Mark Paterson  wrote:

>>7.3.1. ADR. Purpose:  To specify the components of the delivery address for 
>>the vCard object.
>>
>I disagree. The text implies that Label is to show a formatted rendition of 
>the delivery address which is stored in ADR.

At most it SHOULD, but it is not (and should not be) an absolute requirement.

LABEL is to ADR what FN is to N [1]. The N property was made optional because 
some names do not fit the N model [2].
ADR is optional, and should remain optional, because some addresses do not fit 
the ADR model (particularly those available as formatted text only).

[1] http://www.vcarddav.org/issues.xhtml#162
[2] http://www.ietf.org/mail-archive/web/vcarddav/current/msg00043.html

Javier

---

From: Mark Paterson <[email-masked]>
Date: Wed, 30 Jul 2008 18:22:19 -0400

Javier Godoy wrote:
> Mark Paterson  wrote:
>
>> Javier Godoy wrote:
>>> Andy Mabbett wrote:
>>>>
>>>> Do you mean to suggest that addresses of unknown construction 
>>>> should be written to the LABEL property?
>>>
>>> Exactly.
>>>
>>> 7.3.2. LABEL. Purpose:  To specify the formatted text corresponding 
>>> to delivery address of the object the vCard represents.
>>
>> I disagree. The text implies that Label is to show a formatted 
>> rendition of the delivery address which is stored in ADR.
>
> LABEL is to ADR what FN is to N [1]. The N property was made optional 
> because some names do not fit the N model [2].
> ADR is optional, and should remain optional, because some addresses do 
> not fit the ADR model (particularly those available as formatted text 
> only).
And then those vCards get passed around or sync'd and eventually someone 
has this really oddly formatted address in their favorite client (e.g 
Outlook).

I know that some people wnat this flexibility but it is this flexibility 
in the existing spec that allows for lack of precision and from that 
tons of IOP issues.

--

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 30 Jul 2008 21:12:05 -0300

Mark Paterson wrote:

>>ADR is optional, and should remain optional, because some addresses do not 
>>fit the ADR model (particularly those available as formatted text only).
>
>And then those vCards get passed around or sync'd and eventually someone has 
>this really oddly formatted address in their favorite client (e.g Outlook).

Then, what is your proposal? (in a previous email you wrote you'd prefer "to 
see LABEL as only being allowed in combination with a properly specified 
ADR").
I think it is a bad idea, because if we have a formatted string  (e.g. "80-86 
Old Street, London EC1V 9NN") and it is not feasible to derive a properly 
specified ADR from it, we should either ignore that value (which won't happen) 
or represent it in both LABEL and ADR (and have one of them dropped later by 
some memory-paranoid device).

>I know that some people wnat this flexibility but it is this flexibility in 
>the existing spec that allows for lack of precision and from that tons of IOP 
>issues.

ADR is a semantically precise property, but LABEL is not. I agree this 
flexibility is harmful, and the preferable behavior would be specify both of 
them if enough information is available, but there are "valid reasons in 
particular circumstances" for omitting ADR, then I suggested we make 
consistence between LABEL and ADR explicitly RECOMMENDED (instead of REQUIRED 
as I understood you were suggesting, and instead of an implicit statement as 
it is currently worded).

Best Regards

Javier