- From: Cyrus Daboo <cyrus@daboo.name>
- Date: Thu, 09 Sep 2010 12:32:40 -0400
- To: Simon Perreault <simon.perreault@viagenie.ca>, Joseph Smarr <jsmarr@google.com>
- cc: jsmarr@stanfordalumni.org, Joseph Smarr <jsmarr@gmail.com>, Thomas Roessler <tlr@w3.org>, public-contacts-coord@w3.org, vcarddav@ietf.org
Hi Simon, --On September 9, 2010 10:27:12 AM -0400 Simon Perreault <simon.perreault@viagenie.ca> wrote: >> Make sense? Any objections? > > Makes sense to me, although I'd prefer to just drop the fields entirely. > > The only potential objection I see would be "we're trying to follow > X.520", but that seems pretty weak since ADR right now is some kind of > blend of what they call "Geographical Attributes" and "Postal > Addressing", and some X.520 fields are missing too. > > So I personally would have no objection in removing those two fields. > > If the working group agrees, I'll remove them. This would generate a serious incompatibility with vcard 3. Better would be to add a statement that those fields are typically empty and can be ignored and should not be used. Note that in the past I had proposed doing away with ADR and instead having a "civic address" field based on the geoprov civic address format. Those folks took a lot of time to consider all the various civic addressing formats and came up with a comprehensive specification (lots of fields). If the real intent is to have an address field that is machine parseable and expected to have various field reliably extracted then I think replacing ADR would be a better solution than messing with what is there now. >> PS: Do you know if there's any way in vCard to say "this 'adr' and this >> 'label' correspond to the same physical address?". Just saying "they >> both have type=work" isn't really sufficient since you might work out of >> multiple offices, say, or have a second vacation home. > > Very good observation! There is no such way. We need one. Group prefix can be used for this. >> In PoCo, we chose >> to combine them by having a "formatted" value for the unstructured >> address alongside the structured counterparts. This is very useful for >> "round-tripping" complex addresses with programs like Outlook that let >> you edit both the structured and unstructured versions of the same >> address. > > How would the working-group feel about merging ADR and LABEL to solve > this issue? LABEL would simply be an additional field in ADR, much like > in PoCo. > > (How would these changes affect the last call status of the draft?) Group prefix is sufficient. No need to change. -- Cyrus Daboo
Received on Thursday, 9 September 2010 16:33:15 UTC