[gnso-rds-pdp-wg] For your review - updated RDS Statement of Purpose
Volker Greimann
vgreimann at key-systems.net
Tue Oct 11 08:48:29 UTC 2016
Hi Greg,
I wish it were so, but at ICANN, both are the same. Incorrectly
formatted whois is incorrect whois in the books of ICANN compliance.
And yes, I agree, that the terminology should be changed and used as a
basis for our discussions.
Best,
Volker
Am 10.10.2016 um 18:51 schrieb Greg Aaron:
>
> In the post below, Volker is talking about data FORMATTING, not
> ACCURACY. Formatting and accuracy are distinct concepts. They can
> have a relationship, but they are not one and the same. It is very
> important to understand the difference.
>
> Formatting is the way in which something is arranged or set out. For
> example, do you format country name in the written-out form
> ("Canada"), or do you use the two-letter abbreviation ("CA")? Either
> way the data is accurate; you know the contact is in Canada.
>
> The formatting of many registration data fields is specified in the
> EPP RFCs, which registries and registrars have been required to follow
> for years. For example, RFC5733 says registries and registrars must
> use certain standard conventions for timestamps, use email address
> syntax as per RFC5322, use two-character country codes per ISO
> standards, and must format contact telephone numbers a certain way
> derived from international standards.
>
> The benefits of standardized data formatting are obvious, and RFCs are
> designed to bring those benefits to the Internet. In the case of EPP,
> registries and registrars can store and trade data easily and
> accurately. As the SSAC has noted, these standards make it easier for
> people and applications to understand and use registration data (SAC051).
>
> The 2013 RAA requires that registrars validate that certain data
> fields are FORMATTED CORRECTLY as per the standards. In SAC058, the
> SSAC described it this way: "Syntactic Validation refers to the
> assessment of data with the intent to ensure that they satisfy
> specified syntactic constraints, conform to specified data standards,
> and are transformed and formatted properly for their intended use."
>
> Validating that the data is ACCURATE -- that it's truthful, or that an
> address is deliverable, or is suitable for operational purposes, or
> however you want to say it -- is a different concept. Validation of
> accuracy has different procedures and can have different standards.
> For more about that, please see the sections about Operational
> Validation and Identity Validation in SAC058.
> https://www.icann.org/en/system/files/files/sac-058-en.pdf The 2013
> contains an operational validation requirement.
>
> Recommendation 1 from SAC058 was: “The SSAC recommends that the ICANN
> community should consider adopting the terminology outlined in this
> report in documents and discussions.” The RDS WG should discuss that.
>
> We have protocol standards so that things will work, and RFCs should
> be adhered to. Hopefully that is uncontroversial.
>
> With best wishes,
>
> --Greg
>
> *From:*gnso-rds-pdp-wg-bounces at icann.org
> [mailto:gnso-rds-pdp-wg-bounces at icann.org] *On Behalf Of *Volker Greimann
> *Sent:* Monday, October 10, 2016 4:42 AM
> *To:* gnso-rds-pdp-wg at icann.org
> *Subject:* Re: [gnso-rds-pdp-wg] For your review - updated RDS
> Statement of Purpose
>
> I still do not agree: A phone n umber may be technically incorrect but
> still functional.
>
> Consider these examples:
>
> 0049-1234-56789
> +49-123456789
> +49.0123456789
> 0049(0)123456789
>
> and variations thereof.
>
> All of these numbers will be readily usabla for anyone with half a
> brain cell, yet each and every one of these numbers is inaccurate
> under wcurrent whois policies.
> For reference, this would be the "correct" number:
>
> +49.123456789
>
> So what does this tell us? It tells me that on the march to accuracy,
> we will create more issues than we will solve.
>
> I have seen mail delivered to horribly spelled addresses, yet otoh, I
> have also seen time and again that mail sent to perfectly correct
> addresses was not delivered, because the postman could not find it
> (for example because the entrance to a building in one street actually
> was located around the corner in another street) and the mail was
> returned undelivered.
>
> Best,
>
> Volker
>
> Am 09.10.2016 um 19:09 schrieb Richard Leaning:
>
> Michele,
>
> I don't disagree with you. There will always be scenarios where
> common sense prevails.
>
> But if you want to phone me you will need the accurate number -
> not something that looks like my number.
>
> If you want to respond to me about these comments, you will need
> the accurate email address not something that is sort of my email
> address.
>
> All am saying is we should strive for accuracy knowing that we may
> not achieve it but at least let's try.
>
> Cheers
>
> Dick
>
> Richard Leaning
>
> RIPE NCC
>
> External Relations
>
> (Sent by iPhone)
>
>
> On 9 Oct 2016, at 13:41, Michele Neylon - Blacknight
> <michele at blacknight.com <mailto:michele at blacknight.com>> wrote:
>
> Dick
>
> Sorry, but that’s absolutely untrue. So I agree with Greg.
>
> I have been getting postal mail for more than 30 years and
> over that period my name, my gender and my address have been
> listed inaccurately hundreds of times.
>
> Yet the postal services in the various countries that I’ve
> lived in have been able to get the mail to me.
>
> There is a very big difference between “functional” and
> “accurate”.
>
> As others have pointed out, it’s often impossible to provide
> 100% accurate addresses on web forms etc., Try updating your
> ESTA for a visit to the US and you’ll find 9 times out of 10
> that the address form doesn’t allow enough space for the hotel
> name and address. But if you provide the hotel name the
> authorities will know exactly where you are without the full
> address.
>
> Our office address, for example, lists us as being in Carlow.
> If you actually looked at a map you’d see that we aren’t in
> Carlow, but in Laois.
>
> Regards
>
> Michele
>
> --
>
> Mr Michele Neylon
>
> Blacknight Solutions
>
> Hosting, Colocation & Domains
>
> http://www.blacknight.host/
>
> http://blacknight.blog/
>
> http://ceo.hosting/
>
> Intl. +353 (0) 59 9183072
>
> Direct Dial: +353 (0)59 9183090
>
> -------------------------------
>
> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside
> Business Park,Sleaty
>
> Road,Graiguecullen,Carlow,R93 X265,
>
> Ireland Company No.: 370845
>
> *From: *<gnso-rds-pdp-wg-bounces at icann.org
> <mailto:gnso-rds-pdp-wg-bounces at icann.org>> on behalf of
> Richard Leaning <rleaning at ripe.net <mailto:rleaning at ripe.net>>
> *Date: *Friday 7 October 2016 at 19:20
> *To: *Greg Shatan <gregshatanipc at gmail.com
> <mailto:gregshatanipc at gmail.com>>
> *Cc: *gnso-rds-pdp-wg <gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>>
> *Subject: *Re: [gnso-rds-pdp-wg] For your review - updated RDS
> Statement of Purpose
>
> Thats Greg for articulating it so well.
>
> all i was going to say was -
>
> 'You can’t contact someone if the contact information is
> inaccurate’
>
> So i can’t see how you can split the two.
>
> Richard Leaning
>
> External Relations
>
> RIPE NCC
>
>
>
>
> _______________________________________________
>
> gnso-rds-pdp-wg mailing list
>
> gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
>
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
>
>
> --
> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
> Mit freundlichen Grüßen,
> Volker A. Greimann
> - Rechtsabteilung -
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email:vgreimann at key-systems.net <mailto:vgreimann at key-systems.net>
> Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net>
> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
> Geschäftsführer: Alexander Siffrin
> Handelsregister Nr.: HR B 18835 - Saarbruecken
> Umsatzsteuer ID.: DE211006534
> Member of the KEYDRIVE GROUP
> www.keydrive.lu <http://www.keydrive.lu>
> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
> --------------------------------------------
> Should you have any further questions, please do not hesitate to contact us.
> Best regards,
> Volker A. Greimann
> - legal department -
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email:vgreimann at key-systems.net <mailto:vgreimann at key-systems.net>
> Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net>
> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
> Follow us on Twitter or join our fan community on Facebook and stay updated:
> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
> CEO: Alexander Siffrin
> Registration No.: HR B 18835 - Saarbruecken
> V.A.T. ID.: DE211006534
> Member of the KEYDRIVE GROUP
> www.keydrive.lu <http://www.keydrive.lu>
> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20161011/99718bf1/attachment.html>
More information about the gnso-rds-pdp-wg
mailing list