Re: tightening element adr

This is a multipart message in MIME format.
--=_alternative 0058F9C58525681F_=
Content-Type: text/plain; charset="us-ascii"

Actually, the values for the Adr element type content particles are 
parsable character data. The \n is parsable. No problem. But agree that if 
the intent is to convey multiple instances of the address component, then 
having multiple element types for the component is better.
About multiple locality, region, pcode and country. We don't want to provide any greater functionality than that provided in 
standard vCard, as defined in RFC 2426. This spec specifies:
adr-value    = 0*6(text-value ";") text-value
        ; PO Box, Extended Address, Street, Locality, Region, Postal
        ; Code, Country Name

Where text-value is specified as:
text-value-list      = 1*text-value *("," 1*text-value)

So, stictly speaking, the ability for multiple locality, region, pcode and country is correct. Let remember, we are defining a different semantic here than 
in the RFC. I do agree, though, that having multiple of these address 
components does not make much sense, as it would for Extended Address or 
Street components.
Maybe we need to fix the ABNF in the RFC 2426? I know of no implementation 
that will support multiple locality, region, pcode and country values.
-- Frank

--=_alternative 0058F9C58525681F_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Actually, the values for the Adr element type content particles are parsable character data. The \n is parsable. No problem. But agree that if the intent is to convey multiple instances of the address component, then having multiple element types for the component is better.</font>
<p><font size=3 face="Courier New">About multiple </font><font size=2 face="Courier New">locality, region, pcode and country</font><font size=3 face="Courier New">. We don't want to provide any greater functionality than that provided in standard vCard, as defined in RFC 2426. This spec specifies:</font>
<p><font size=3 face="Courier New">adr-value &nbsp; &nbsp;= 0*6(text-value &quot;;&quot;) text-value<br>
 &nbsp; &nbsp; &nbsp; &nbsp;; PO Box, Extended Address, Street, Locality, Region, Postal<br>
 &nbsp; &nbsp; &nbsp; &nbsp;; Code, Country Name<br>
</font>
<p><font size=3 face="Courier New">Where text-value is specified as:</font>
<p><font size=3 face="Courier New">text-value-list &nbsp; &nbsp; &nbsp;= 1*text-value *(&quot;,&quot; 1*text-value)<br>
</font>
<p><font size=3 face="Courier New">So, stictly speaking, the ability for multiple </font><font size=2 face="Courier New">locality, region, pcode and country</font><font size=3 face="Courier New"> is correct. Let remember, we are defining a different semantic here than in the RFC. I do agree, though, that having multiple of these address components does not make much sense, as it would for Extended Address or Street components.</font>
<p><font size=3 face="Courier New">Maybe we need to fix the ABNF in the RFC 2426? I know of no implementation that will support multiple </font><font size=2 face="Courier New">locality, region, pcode and country</font><font size=3 face="Courier New"> values.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 0058F9C58525681F_=--