9 Bře
2015
9 Bře
'15
16:21
Hi,
I'm successfully connecting to and able to login to FRED (demo) at TZNIC
- using the EPP Library that CentralNIC wrote (all PHP) - with some
modifications.
However - all "commands" after that seem to return the same (similar)
error message.
I've looked and copied examples from RFC5731...
As an example - the Info Command...
C:<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name hosts="all">example.com</domain:name>
C: </domain:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
So I actually send:
<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<info>
<domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
and get back:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="2001"><msg>Command syntax
error</msg><extValue><value><domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">dnssec.or.tz</domain:name>
</domain:info></value><reason>Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element declaration
available, but demanded by the strict
wildcard.</reason></extValue></result><trID><svTRID>ReqID-0002778177</svTRID></trID></response></epp>
What seems to be common is "Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element
declaration available, but demanded by the strict wildcard." and I have
no idea what that means.
What should I be sending then????
...and from a debugging prospective - getting the reply on more or less
one line is real hard to read for a Human. Yes - a Machine has no
problem. I wish there was a switch for "Human Readable XML" - all
neatly grouped and indented like in the RFC documents.
In case its my login - it looks like this - except with User/Passwd XXXX'ed out:
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<login>
<clID>REG-XXXXXXX</clID>
<pw>XXXXXXXX</pw>
<options>
<version>1.0</version>
<lang>en</lang>
</options>
<svcs>
<objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
<objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>
<svcExtension>
<extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI>
</svcExtension>
</svcs>
</login>
</command>
</epp>
Reply==>
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="1000"><msg>Command completed
successfully</msg></result><trID><svTRID>ReqID-0002778173</svTRID></trID></response></epp>
Please note - the current EPP XML works for the COZA System, Cocca and Central-NIC.
--
Mark James ELKINS - Posix Systems - (South) Africa
mje(a)posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
9 Bře
9 Bře
16:26
On 09/03/15 16:21, Mark Elkins wrote:
Hi,
I'm successfully connecting to and able to login to FRED (demo) at TZNIC
- using the EPP Library that CentralNIC wrote (all PHP) - with some
modifications.
However - all "commands" after that seem to return the same (similar)
error message.
I've looked and copied examples from RFC5731...
As an example - the Info Command...
C:<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name hosts="all">example.com</domain:name>
C: </domain:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
So I actually send:
<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<info>
<domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
and get back:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="2001"><msg>Command syntax
error</msg><extValue><value><domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">dnssec.or.tz</domain:name>
</domain:info></value><reason>Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element declaration
available, but demanded by the strict
wildcard.</reason></extValue></result><trID><svTRID>ReqID-0002778177</svTRID></trID></response></epp>
What seems to be common is "Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element
declaration available, but demanded by the strict wildcard." and I have
no idea what that means.
What should I be sending then????
...and from a debugging prospective - getting the reply on more or less
one line is real hard to read for a Human. Yes - a Machine has no
problem. I wish there was a switch for "Human Readable XML" - all
neatly grouped and indented like in the RFC documents.
In case its my login - it looks like this - except with User/Passwd XXXX'ed out:
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<login>
<clID>REG-XXXXXXX</clID>
<pw>XXXXXXXX</pw>
<options>
<version>1.0</version>
<lang>en</lang>
</options>
<svcs>
<objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
<objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>
<svcExtension>
<extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI>
</svcExtension>
</svcs>
</login>
</command>
</epp>
Reply==>
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="1000"><msg>Command completed
successfully</msg></result><trID><svTRID>ReqID-0002778173</svTRID></trID></response></epp>
Please note - the current EPP XML works for the COZA System, Cocca and Central-NIC.
Hello Mark
We don't abbreviate XML's namespaces, etc. So we send "full version",
which in your case would be
<?xml version="1.0" encoding="utf-8"
standalone="no"?><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><command><info><domain:info
xmlns:domain="http://www.nic.cz/xml/epp/domain-1.4"
xsi:schemaLocation="http://www.nic.cz/xml/epp/domain-1.4
domain-1.4.xsd"><domain:name>dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ydpg002#15-03-09at16:23:08</clTRID>
</command>
</epp>
It may seem odd to some people, but I always recommend taking a look at fred-client -v3
(extremely
verbose), to see the actual XML being sent.
Hope that helps.
Best regards
Piotr
16:47
On Mon, 2015-03-09 at 16:26 +0100, Piotr Przybył wrote:
On 09/03/15 16:21, Mark Elkins wrote:
Thanks for the quick reply.
That helps - I get a valid reply. However - the samples in the RFC's use
the "abbreviations" - and are they not what one should be following?
This also means you are sending longer messages (unnecessary bytes?).
I do understand the suggestion of using the FRED Client - I was trying
to avoid that if possible... and trying to instead follow what (I
interpret) the RFC's say..
CoCCA was initially barfing on the "Longer form" and I actually trimmed
many of these down to what seemed like a common denominator on all the
other EPP systems I use the same code for. I guess clients can't pass a
switch in the Login to change this behaviour????
--
Mark James ELKINS - Posix Systems - (South) Africa
mje(a)posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
Hi,
I'm successfully connecting to and able to login to FRED (demo) at TZNIC
- using the EPP Library that CentralNIC wrote (all PHP) - with some
modifications.
However - all "commands" after that seem to return the same (similar)
error message.
I've looked and copied examples from RFC5731...
As an example - the Info Command...
C:<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name hosts="all">example.com</domain:name>
C: </domain:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
So I actually send:
<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<info>
<domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
and get back:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="2001"><msg>Command syntax
error</msg><extValue><value><domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">dnssec.or.tz</domain:name>
</domain:info></value><reason>Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element declaration
available, but demanded by the strict
wildcard.</reason></extValue></result><trID><svTRID>ReqID-0002778177</svTRID></trID></response></epp>
What seems to be common is "Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element
declaration available, but demanded by the strict wildcard." and I have
no idea what that means.
What should I be sending then????
...and from a debugging prospective - getting the reply on more or less
one line is real hard to read for a Human. Yes - a Machine has no
problem. I wish there was a switch for "Human Readable XML" - all
neatly grouped and indented like in the RFC documents.
In case its my login - it looks like this - except with User/Passwd XXXX'ed out:
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<login>
<clID>REG-XXXXXXX</clID>
<pw>XXXXXXXX</pw>
<options>
<version>1.0</version>
<lang>en</lang>
</options>
<svcs>
<objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
<objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>
<svcExtension>
<extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI>
</svcExtension>
</svcs>
</login>
</command>
</epp>
Reply==>
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="1000"><msg>Command completed
successfully</msg></result><trID><svTRID>ReqID-0002778173</svTRID></trID></response></epp>
Please note - the current EPP XML works for the COZA System, Cocca and Central-NIC.
Hello Mark
We don't abbreviate XML's namespaces, etc. So we send "full version",
which in your case would be
<?xml version="1.0" encoding="utf-8"
standalone="no"?><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><command><info><domain:info
xmlns:domain="http://www.nic.cz/xml/epp/domain-1.4"
xsi:schemaLocation="http://www.nic.cz/xml/epp/domain-1.4
domain-1.4.xsd"><domain:name>dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ydpg002#15-03-09at16:23:08</clTRID>
</command>
</epp>
It may seem odd to some people, but I always recommend taking a look at fred-client -v3
(extremely
verbose), to see the actual XML being sent.
Hope that helps.
Best regards
Piotr
16:54
On 09/03/15 16:47, Mark Elkins wrote:
On Mon, 2015-03-09 at 16:26 +0100, Piotr Przybył
wrote:
Hello Mark
I'm not aware of such switch, but maybe it exists (although I doubt).
Also, the "XML correctness" may be enforced by your registry's FRED
settings.
I guess guys from cz.nic can say more. Or your from registry.
Best regards
Piotr Przybył
On 09/03/15 16:21, Mark Elkins wrote:
Thanks for the quick reply.
That helps - I get a valid reply. However - the samples in the RFC's use
the "abbreviations" - and are they not what one should be following?
This also means you are sending longer messages (unnecessary bytes?).
I do understand the suggestion of using the FRED Client - I was trying
to avoid that if possible... and trying to instead follow what (I
interpret) the RFC's say..
CoCCA was initially barfing on the "Longer form" and I actually trimmed
many of these down to what seemed like a common denominator on all the
other EPP systems I use the same code for. I guess clients can't pass a
switch in the Login to change this behaviour????
Hi,
I'm successfully connecting to and able to login to FRED (demo) at TZNIC
- using the EPP Library that CentralNIC wrote (all PHP) - with some
modifications.
However - all "commands" after that seem to return the same (similar)
error message.
I've looked and copied examples from RFC5731...
As an example - the Info Command...
C:<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name hosts="all">example.com</domain:name>
C: </domain:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
So I actually send:
<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<info>
<domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
and get back:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="2001"><msg>Command syntax
error</msg><extValue><value><domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">dnssec.or.tz</domain:name>
</domain:info></value><reason>Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element declaration
available, but demanded by the strict
wildcard.</reason></extValue></result><trID><svTRID>ReqID-0002778177</svTRID></trID></response></epp>
What seems to be common is "Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element
declaration available, but demanded by the strict wildcard." and I have
no idea what that means.
What should I be sending then????
...and from a debugging prospective - getting the reply on more or less
one line is real hard to read for a Human. Yes - a Machine has no
problem. I wish there was a switch for "Human Readable XML" - all
neatly grouped and indented like in the RFC documents.
In case its my login - it looks like this - except with User/Passwd XXXX'ed out:
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<login>
<clID>REG-XXXXXXX</clID>
<pw>XXXXXXXX</pw>
<options>
<version>1.0</version>
<lang>en</lang>
</options>
<svcs>
<objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
<objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>
<svcExtension>
<extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI>
</svcExtension>
</svcs>
</login>
</command>
</epp>
Reply==>
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="1000"><msg>Command completed
successfully</msg></result><trID><svTRID>ReqID-0002778173</svTRID></trID></response></epp>
Please note - the current EPP XML works for the COZA System, Cocca and Central-NIC.
Hello Mark
We don't abbreviate XML's namespaces, etc. So we send "full version",
which in your case would be
<?xml version="1.0" encoding="utf-8"
standalone="no"?><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><command><info><domain:info
xmlns:domain="http://www.nic.cz/xml/epp/domain-1.4"
xsi:schemaLocation="http://www.nic.cz/xml/epp/domain-1.4
domain-1.4.xsd"><domain:name>dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ydpg002#15-03-09at16:23:08</clTRID>
</command>
</epp>
It may seem odd to some people, but I always recommend taking a look at fred-client -v3
(extremely
verbose), to see the actual XML being sent.
Hope that helps.
Best regards
Piotr 
17:03
Hi Mark,
what we do on server side is just simply pass incoming XML through XML
Schema validation process. This is practically the same as calling
"xmlling --schema our_epp_schema.xsd epp_message.xml". We do that just
to avoid any incompatibility problems in further processing.
What you see is the output of this call.
I understand that this may cause problem to a general client. However,
maybe you are aware that FRED has slightly different schema (nssets
instead of hosts) so your client needs to be ready for differences in
any case.
Regards,
Jaromir
On Mon, 2015-03-09 at 17:47 +0200, Mark Elkins wrote:
On Mon, 2015-03-09 at 16:26 +0100, Piotr Przybył
wrote:
--
Jaromir Talir
technicky reditel / Chief Technical Officer
-------------------------------------------
CZ.NIC, z.s.p.o. -- .cz domain registry
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:jaromir.talir@nic.cz http://nic.cz/
sip:jaromir.talir@nic.cz tel:+420.222745107
mob:+420.739632712 fax:+420.222745112
-------------------------------------------
On 09/03/15 16:21, Mark Elkins wrote:
Thanks for the quick reply.
That helps - I get a valid reply. However - the samples in the RFC's use
the "abbreviations" - and are they not what one should be following?
This also means you are sending longer messages (unnecessary bytes?).
I do understand the suggestion of using the FRED Client - I was trying
to avoid that if possible... and trying to instead follow what (I
interpret) the RFC's say..
CoCCA was initially barfing on the "Longer form" and I actually trimmed
many of these down to what seemed like a common denominator on all the
other EPP systems I use the same code for. I guess clients can't pass a
switch in the Login to change this behaviour????
_______________________________________________
fred-users mailing list
fred-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users Hi,
I'm successfully connecting to and able to login to FRED (demo) at TZNIC
- using the EPP Library that CentralNIC wrote (all PHP) - with some
modifications.
However - all "commands" after that seem to return the same (similar)
error message.
I've looked and copied examples from RFC5731...
As an example - the Info Command...
C:<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name hosts="all">example.com</domain:name>
C: </domain:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
So I actually send:
<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<info>
<domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
and get back:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="2001"><msg>Command syntax
error</msg><extValue><value><domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">dnssec.or.tz</domain:name>
</domain:info></value><reason>Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element declaration
available, but demanded by the strict
wildcard.</reason></extValue></result><trID><svTRID>ReqID-0002778177</svTRID></trID></response></epp>
What seems to be common is "Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element
declaration available, but demanded by the strict wildcard." and I have
no idea what that means.
What should I be sending then????
...and from a debugging prospective - getting the reply on more or less
one line is real hard to read for a Human. Yes - a Machine has no
problem. I wish there was a switch for "Human Readable XML" - all
neatly grouped and indented like in the RFC documents.
In case its my login - it looks like this - except with User/Passwd XXXX'ed out:
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<login>
<clID>REG-XXXXXXX</clID>
<pw>XXXXXXXX</pw>
<options>
<version>1.0</version>
<lang>en</lang>
</options>
<svcs>
<objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
<objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>
<svcExtension>
<extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI>
</svcExtension>
</svcs>
</login>
</command>
</epp>
Reply==>
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="1000"><msg>Command completed
successfully</msg></result><trID><svTRID>ReqID-0002778173</svTRID></trID></response></epp>
Please note - the current EPP XML works for the COZA System, Cocca and Central-NIC.
Hello Mark
We don't abbreviate XML's namespaces, etc. So we send "full version",
which in your case would be
<?xml version="1.0" encoding="utf-8"
standalone="no"?><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><command><info><domain:info
xmlns:domain="http://www.nic.cz/xml/epp/domain-1.4"
xsi:schemaLocation="http://www.nic.cz/xml/epp/domain-1.4
domain-1.4.xsd"><domain:name>dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ydpg002#15-03-09at16:23:08</clTRID>
</command>
</epp>
It may seem odd to some people, but I always recommend taking a look at fred-client -v3
(extremely
verbose), to see the actual XML being sent.
Hope that helps.
Best regards
Piotr
18:55
On Mon, 2015-03-09 at 17:03 +0100, Jaromir Talir wrote:
Hi Mark,
what we do on server side is just simply pass incoming XML through XML
Schema validation process. This is practically the same as calling
"xmlling --schema our_epp_schema.xsd epp_message.xml". We do that just
to avoid any incompatibility problems in further processing.
What you see is the output of this call.
So I'm trying to find the binary "xmlling". Lots of "look at
xmllint" -
no xmlling... I run Gentoo. Can you suggest the name that this binary
might be in - eg xml-tools... (or did you mis-spell?)
Also - where can I get the appropriate schema from (or is this a bad
path to follow) ?
I understand that this may cause problem to a general
client. However,
maybe you are aware that FRED has slightly different schema (nssets
instead of hosts) so your client needs to be ready for differences in
any case.
That is a different problem eg COZA uses "host attributes" instead of
"Host objects" - so I expect to have to add some new XML to properly
support FRED.
Do you supply a full schema list? - or rather all the different EPP XML
commands?? (ie examples) .... That would fix my knowledge problem.
Regards,
Jaromir
On Mon, 2015-03-09 at 17:47 +0200, Mark Elkins wrote:
--
Mark James ELKINS - Posix Systems - (South) Africa
mje(a)posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
On Mon, 2015-03-09 at 16:26 +0100, Piotr Przybył
wrote:
On 09/03/15 16:21, Mark Elkins wrote:
Thanks for the quick reply.
That helps - I get a valid reply. However - the samples in the RFC's use
the "abbreviations" - and are they not what one should be following?
This also means you are sending longer messages (unnecessary bytes?).
I do understand the suggestion of using the FRED Client - I was trying
to avoid that if possible... and trying to instead follow what (I
interpret) the RFC's say..
CoCCA was initially barfing on the "Longer form" and I actually trimmed
many of these down to what seemed like a common denominator on all the
other EPP systems I use the same code for. I guess clients can't pass a
switch in the Login to change this behaviour????
_______________________________________________
fred-users mailing list
fred-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users Hi,
I'm successfully connecting to and able to login to FRED (demo) at TZNIC
- using the EPP Library that CentralNIC wrote (all PHP) - with some
modifications.
However - all "commands" after that seem to return the same (similar)
error message.
I've looked and copied examples from RFC5731...
As an example - the Info Command...
C:<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name hosts="all">example.com</domain:name>
C: </domain:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
So I actually send:
<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<info>
<domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
and get back:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="2001"><msg>Command syntax
error</msg><extValue><value><domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">dnssec.or.tz</domain:name>
</domain:info></value><reason>Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element declaration
available, but demanded by the strict
wildcard.</reason></extValue></result><trID><svTRID>ReqID-0002778177</svTRID></trID></response></epp>
What seems to be common is "Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element
declaration available, but demanded by the strict wildcard." and I have
no idea what that means.
What should I be sending then????
...and from a debugging prospective - getting the reply on more or less
one line is real hard to read for a Human. Yes - a Machine has no
problem. I wish there was a switch for "Human Readable XML" - all
neatly grouped and indented like in the RFC documents.
In case its my login - it looks like this - except with User/Passwd XXXX'ed out:
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<login>
<clID>REG-XXXXXXX</clID>
<pw>XXXXXXXX</pw>
<options>
<version>1.0</version>
<lang>en</lang>
</options>
<svcs>
<objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
<objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>
<svcExtension>
<extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI>
</svcExtension>
</svcs>
</login>
</command>
</epp>
Reply==>
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="1000"><msg>Command completed
successfully</msg></result><trID><svTRID>ReqID-0002778173</svTRID></trID></response></epp>
Please note - the current EPP XML works for the COZA System, Cocca and Central-NIC.
Hello Mark
We don't abbreviate XML's namespaces, etc. So we send "full version",
which in your case would be
<?xml version="1.0" encoding="utf-8"
standalone="no"?><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><command><info><domain:info
xmlns:domain="http://www.nic.cz/xml/epp/domain-1.4"
xsi:schemaLocation="http://www.nic.cz/xml/epp/domain-1.4
domain-1.4.xsd"><domain:name>dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ydpg002#15-03-09at16:23:08</clTRID>
</command>
</epp>
It may seem odd to some people, but I always recommend taking a look at fred-client -v3
(extremely
verbose), to see the actual XML being sent.
Hope that helps.
Best regards
Piotr
22:12
Hello Mark
FRED client should have .xsd files. If not, you can download
http://fred.nic.cz/sources/fred-mod-eppd-2.14.0.tar.gz
then take a look in schemas directory.
I diff them between versions if there are any changes in EPP.
When it comes to xmlling Jaromir _might_ have meant Debian (Ubuntu) package
libxml2-utils.
Best regards
Piotr
On 09/03/15 18:55, Mark Elkins wrote:
On Mon, 2015-03-09 at 17:03 +0100, Jaromir Talir
wrote:
Hi Mark,
what we do on server side is just simply pass incoming XML through XML
Schema validation process. This is practically the same as calling
"xmlling --schema our_epp_schema.xsd epp_message.xml". We do that just
to avoid any incompatibility problems in further processing.
What you see is the output of this call.
So I'm trying to find the binary "xmlling". Lots of "look at
xmllint" -
no xmlling... I run Gentoo. Can you suggest the name that this binary
might be in - eg xml-tools... (or did you mis-spell?)
Also - where can I get the appropriate schema from (or is this a bad
path to follow) ?
I understand that this may cause problem to a
general client. However,
maybe you are aware that FRED has slightly different schema (nssets
instead of hosts) so your client needs to be ready for differences in
any case.
That is a different problem eg COZA uses "host attributes" instead of
"Host objects" - so I expect to have to add some new XML to properly
support FRED.
Do you supply a full schema list? - or rather all the different EPP XML
commands?? (ie examples) .... That would fix my knowledge problem.
Regards,
Jaromir
On Mon, 2015-03-09 at 17:47 +0200, Mark Elkins wrote:
_______________________________________________
fred-users mailing list
fred-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users
On Mon, 2015-03-09 at 16:26 +0100, Piotr Przybył
wrote:
On 09/03/15 16:21, Mark Elkins wrote:
> Hi,
>
> I'm successfully connecting to and able to login to FRED (demo) at TZNIC
> - using the EPP Library that CentralNIC wrote (all PHP) - with some
> modifications.
>
> However - all "commands" after that seem to return the same (similar)
> error message.
>
> I've looked and copied examples from RFC5731...
>
> As an example - the Info Command...
>
> C:<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
> C: <command>
> C: <info>
> C: <domain:info
> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
> C: <domain:name
hosts="all">example.com</domain:name>
> C: </domain:info>
> C: </info>
> C: <clTRID>ABC-12345</clTRID>
> C: </command>
> C:</epp>
>
> So I actually send:
>
> <?xml version="1.0" encoding="UTF-8"
standalone="no"?>
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
> <command>
> <info>
> <domain:info
> xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
> <domain:name hosts="all">dnssec.or.tz</domain:name>
> </domain:info>
> </info>
> <clTRID>ABC-12345</clTRID>
> </command>
> </epp>
>
> and get back:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="2001"><msg>Command syntax
error</msg><extValue><value><domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
> <domain:name hosts="all">dnssec.or.tz</domain:name>
> </domain:info></value><reason>Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element declaration
available, but demanded by the strict
wildcard.</reason></extValue></result><trID><svTRID>ReqID-0002778177</svTRID></trID></response></epp>
>
>
> What seems to be common is "Schemas validity error: Element
> '{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element
> declaration available, but demanded by the strict wildcard." and I have
> no idea what that means.
>
> What should I be sending then????
>
> ...and from a debugging prospective - getting the reply on more or less
> one line is real hard to read for a Human. Yes - a Machine has no
> problem. I wish there was a switch for "Human Readable XML" - all
> neatly grouped and indented like in the RFC documents.
>
>
> In case its my login - it looks like this - except with User/Passwd XXXX'ed out:
>
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
> <command>
> <login>
> <clID>REG-XXXXXXX</clID>
> <pw>XXXXXXXX</pw>
> <options>
> <version>1.0</version>
> <lang>en</lang>
> </options>
> <svcs>
> <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
> <objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>
> <svcExtension>
> <extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI>
> </svcExtension>
> </svcs>
> </login>
> </command>
> </epp>
>
> Reply==>
> <?xml version="1.0" encoding="UTF-8"?>
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="1000"><msg>Command completed
successfully</msg></result><trID><svTRID>ReqID-0002778173</svTRID></trID></response></epp>
>
> Please note - the current EPP XML works for the COZA System, Cocca and Central-NIC.
>
Hello Mark
We don't abbreviate XML's namespaces, etc. So we send "full version",
which in your case would be
<?xml version="1.0" encoding="utf-8"
standalone="no"?><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><command><info><domain:info
xmlns:domain="http://www.nic.cz/xml/epp/domain-1.4"
xsi:schemaLocation="http://www.nic.cz/xml/epp/domain-1.4
domain-1.4.xsd"><domain:name>dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ydpg002#15-03-09at16:23:08</clTRID>
</command>
</epp>
It may seem odd to some people, but I always recommend taking a look at fred-client -v3
(extremely
verbose), to see the actual XML being sent.
Hope that helps.
Best regards
Piotr
Thanks for the quick reply.
That helps - I get a valid reply. However - the samples in the RFC's use
the "abbreviations" - and are they not what one should be following?
This also means you are sending longer messages (unnecessary bytes?).
I do understand the suggestion of using the FRED Client - I was trying
to avoid that if possible... and trying to instead follow what (I
interpret) the RFC's say..
CoCCA was initially barfing on the "Longer form" and I actually trimmed
many of these down to what seemed like a common denominator on all the
other EPP systems I use the same code for. I guess clients can't pass a
switch in the Login to change this behaviour????
_______________________________________________
fred-users mailing list
fred-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users
22:49
On Mon, 2015-03-09 at 19:55 +0200, Mark Elkins wrote:
I don't have examples for all possible xmls. There are only schemas and
'fred-client -v3' command as Piotr suggested.
Regards,
Jaromir
--
Jaromir Talir
technicky reditel / Chief Technical Officer
-------------------------------------------
CZ.NIC, z.s.p.o. -- .cz domain registry
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:jaromir.talir@nic.cz http://nic.cz/
sip:jaromir.talir@nic.cz tel:+420.222745107
mob:+420.739632712 fax:+420.222745112
-------------------------------------------
On Mon, 2015-03-09 at 17:03 +0100, Jaromir Talir
wrote:
Sorry, it's a typo. It's xmllint, part of libxml2 package -
http://xmlsoft.org/xmllint.html
Hi Mark,
what we do on server side is just simply pass incoming XML through XML
Schema validation process. This is practically the same as calling
"xmlling --schema our_epp_schema.xsd epp_message.xml". We do that just
to avoid any incompatibility problems in further processing.
What you see is the output of this call.
So I'm trying to find the binary "xmlling". Lots of "look at
xmllint" -
no xmlling... I run Gentoo. Can you suggest the name that this binary
might be in - eg xml-tools... (or did you mis-spell?) Also - where can I get the appropriate schema from (or
is this a bad
path to follow) ?
Either in fred-client or fred-mod-eppd packages at
http://fred.nic.cz/wiki/download
I understand that this may cause problem to a
general client. However,
maybe you are aware that FRED has slightly different schema (nssets
instead of hosts) so your client needs to be ready for differences in
any case.
That is a different problem eg COZA uses "host attributes" instead of
"Host objects" - so I expect to have to add some new XML to properly
support FRED.
Do you supply a full schema list? - or rather all the different EPP XML
commands?? (ie examples) .... That would fix my knowledge problem. Regards,
Jaromir
On Mon, 2015-03-09 at 17:47 +0200, Mark Elkins wrote:
On Mon, 2015-03-09 at 16:26 +0100, Piotr Przybył
wrote:
On 09/03/15 16:21, Mark Elkins wrote:
> Hi,
>
> I'm successfully connecting to and able to login to FRED (demo) at TZNIC
> - using the EPP Library that CentralNIC wrote (all PHP) - with some
> modifications.
>
> However - all "commands" after that seem to return the same (similar)
> error message.
>
> I've looked and copied examples from RFC5731...
>
> As an example - the Info Command...
>
> C:<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
> C: <command>
> C: <info>
> C: <domain:info
> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
> C: <domain:name
hosts="all">example.com</domain:name>
> C: </domain:info>
> C: </info>
> C: <clTRID>ABC-12345</clTRID>
> C: </command>
> C:</epp>
>
> So I actually send:
>
> <?xml version="1.0" encoding="UTF-8"
standalone="no"?>
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
> <command>
> <info>
> <domain:info
> xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
> <domain:name hosts="all">dnssec.or.tz</domain:name>
> </domain:info>
> </info>
> <clTRID>ABC-12345</clTRID>
> </command>
> </epp>
>
> and get back:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="2001"><msg>Command syntax
error</msg><extValue><value><domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
> <domain:name hosts="all">dnssec.or.tz</domain:name>
> </domain:info></value><reason>Schemas validity error:
Element '{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element
declaration available, but demanded by the strict
wildcard.</reason></extValue></result><trID><svTRID>ReqID-0002778177</svTRID></trID></response></epp>
>
>
> What seems to be common is "Schemas validity error: Element
> '{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element
> declaration available, but demanded by the strict wildcard." and I have
> no idea what that means.
>
> What should I be sending then????
>
> ...and from a debugging prospective - getting the reply on more or less
> one line is real hard to read for a Human. Yes - a Machine has no
> problem. I wish there was a switch for "Human Readable XML" - all
> neatly grouped and indented like in the RFC documents.
>
>
> In case its my login - it looks like this - except with User/Passwd XXXX'ed
out:
>
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
> <command>
> <login>
> <clID>REG-XXXXXXX</clID>
> <pw>XXXXXXXX</pw>
> <options>
> <version>1.0</version>
> <lang>en</lang>
> </options>
> <svcs>
> <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
> <objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>
> <svcExtension>
> <extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI>
> </svcExtension>
> </svcs>
> </login>
> </command>
> </epp>
>
> Reply==>
> <?xml version="1.0" encoding="UTF-8"?>
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="1000"><msg>Command completed
successfully</msg></result><trID><svTRID>ReqID-0002778173</svTRID></trID></response></epp>
>
> Please note - the current EPP XML works for the COZA System, Cocca and Central-NIC.
>
Hello Mark
We don't abbreviate XML's namespaces, etc. So we send "full version",
which in your case would be
<?xml version="1.0" encoding="utf-8"
standalone="no"?><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><command><info><domain:info
xmlns:domain="http://www.nic.cz/xml/epp/domain-1.4"
xsi:schemaLocation="http://www.nic.cz/xml/epp/domain-1.4
domain-1.4.xsd"><domain:name>dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ydpg002#15-03-09at16:23:08</clTRID>
</command>
</epp>
It may seem odd to some people, but I always recommend taking a look at fred-client -v3
(extremely
verbose), to see the actual XML being sent.
Hope that helps.
Best regards
Piotr
Thanks for the quick reply.
That helps - I get a valid reply. However - the samples in the RFC's use
the "abbreviations" - and are they not what one should be following?
This also means you are sending longer messages (unnecessary bytes?).
I do understand the suggestion of using the FRED Client - I was trying
to avoid that if possible... and trying to instead follow what (I
interpret) the RFC's say..
CoCCA was initially barfing on the "Longer form" and I actually trimmed
many of these down to what seemed like a common denominator on all the
other EPP systems I use the same code for. I guess clients can't pass a
switch in the Login to change this behaviour????
_______________________________________________
fred-users mailing list
fred-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users
3575
days inactive
3575
days old
7 comments
3 participants
participants (3)
-
Jaromir Talir -
Mark Elkins -
Piotr Przybył