Von: Ulrich Wisser [ulr...@wisser.se]
Gesendet: Dienstag, 17. Juli 2018 15:25
An: Martin Casanova
Cc: Patrick Mevzek; regext@ietf.org
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D
Action: draft-ietf-regext-change-poll-07.txt)
Martin
;>
>> I think that this is hindering the development of EPP Poll extensions for
>> no good reason. Out of sight - out of mind...
>>
>> Martin
>>
>>
>>
>> --
>> *Von:* Ulrich Wisser [ulr...@wisser.se]
>> *Gesendet:* Monta
Von: Ulrich Wisser [ulr...@wisser.se]
Gesendet: Dienstag, 17. Juli 2018 02:27
An: Martin Casanova
Cc: Patrick Mevzek; regext@ietf.org
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D
Action: draft-ietf-regext-change-poll-07.txt)
Hi Martin,
as was said in the wg
by CDS. That is exactly our use case
>> where we want to use the change poll extension.
>>
>> Martin
>>
>> Von: regext [regext-boun...@ietf.org] im Auftrag von Patrick
>> Mevzek [p...@dotandco.com]
>> Gesendet:
An: Martin Casanova
Cc: Patrick Mevzek; regext@ietf.org
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D
Action: draft-ietf-regext-change-poll-07.txt)
Hi,
are we really sure this is a problem worth solving?
At .se registrars (with very few exceptions) fall into two
-Original Message-
From: regext On Behalf Of Martin Casanova
Sent: Monday, July 16, 2018 2:09 PM
To: Patrick Mevzek ; regext@ietf.org
Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D
Action: draft-ietf-regext-change-poll-07.txt)
Patrick
To be clear the domain info resp
ur use case
> where we want to use the change poll extension.
>
> Martin
>
> Von: regext [regext-boun...@ietf.org] im Auftrag von Patrick
> Mevzek [p...@dotandco.com]
> Gesendet: Montag, 16. Juli 2018 20:31
> An: regext@ietf.org
> Betreff: Re: [regext]
Re: [regext] Poll messages with unhandled namespaces (was Re: I-D
Action: draft-ietf-regext-change-poll-07.txt)
Patrick
To be clear the domain info response will be sent just without the DNSSec part.
Therefore a not DNSSec interested registrar will just not see the DNSSec
configuration but
See my comment below..
Von: regext [regext-boun...@ietf.org] im Auftrag von Patrick Mevzek
[p...@dotandco.com]
Gesendet: Montag, 16. Juli 2018 21:32
An: regext@ietf.org
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D
Action
On Mon, Jul 16, 2018, at 21:08, Martin Casanova wrote:
> To be clear the domain info response will be sent just without the
> DNSSec part. Therefore a not DNSSec interested registrar will just not
> see the DNSSec configuration but all the rest of the domain info
> resData. I don't see a
] Poll messages with unhandled namespaces (was Re: I-D
Action: draft-ietf-regext-change-poll-07.txt)
On Mon, Jul 16, 2018, at 19:58, Gould, James wrote:
> I believe that the login
> services defines what the server can return to the client, so if the
> client does not support the DNSSEC
] Poll messages with unhandled namespaces (was Re: I-D
Action: draft-ietf-regext-change-poll-07.txt)
On Mon, Jul 16, 2018, at 17:41, Patrick Mevzek wrote:
> This is indeed more pragmatic. But all this mechanism to define which
> messages to accept
> will be outside the EPP protocol an
On Mon, Jul 16, 2018, at 17:41, Patrick Mevzek wrote:
> This is indeed more pragmatic. But all this mechanism to define which
> messages to accept
> will be outside the EPP protocol and this WG.
But please also remember that if we want to tackle this problem in a generic
way (and also taking
Von: regext [regext-boun...@ietf.org] im Auftrag von Gould, James
[jgould=40verisign@dmarc.ietf.org]
Gesendet: Montag, 16. Juli 2018 13:06
An: Patrick Mevzek; regext@ietf.org
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D
Action: draft-ietf-regext
Patrick,
Yes, I believe the idea that Martin came up with to use the element
with the inclusion of the full unhandled XML block is the best option thus far.
It honors the client login services, it includes all of the XML for later
processing, and it does not cause XML parsing failures or
Patrick,
In this case the server is communicating an error condition, but the condition
does not result in an error code being returned. A poll message really cannot
fail, otherwise you get into the poison message scenario. Even if we disagreed
that this is an error condition, the RFC 5730
On Thu, Jun 14, 2018, at 16:04, Gould, James wrote:
> This approach looks good to me. It has the advantage of providing the
> unhandled information in an element that is meant for machine processing
> instead of using the element that’s meant is meant to be
> human readable. The other
On Thu, Jun 14, 2018, at 11:22, Martin Casanova wrote:
> While implementing, another idea came to mind, which I want to put to
> discussion here:
>
>
>
>
>
> Command completed successfully; ack to dequeue
>
>
>
> urn:ietf:params:xml:ns:changePoll-1.0
>
ed update of domain.
>
>
>
>
>
> ABC-12345
>
> 54321-XYZ
>
>
>
>
>
>
>
>
>
>
>
>
>
> —
>
>
>
> JG
>
>
> cid:image001.png@01D255E2.EB933A30
>
> *James Gould
> *Disting
l messages with unhandled namespaces (was
Re: I-D Action: draft-ietf-regext-change-poll-07.txt)
Hello
While implementing, another idea came to mind, which I want to put to
discussion here:
Command completed successfully; ack to dequeue
u
Hello
While implementing, another idea came to mind, which I want to put to
discussion here:
Command completed successfully; ack to dequeue
urn:ietf:params:xml:ns:changePoll-1.0
Msg incomplete due to missing extURI at login
cmd! To fix
Hello
Sorry I have not been checking the mails of this mailing list for a while...
In my opinion as registries we have a special role and should stick to
the RFC’s as close as possible for a strong EPP standard everybody can
rely on. Therefore I find it valuable to discuss the RFC’s and get
Hello,
On 5/22/18 14:23, Gould, James wrote:
> Patrick,
>
> Referring to the language in the RFC is the starting point in the
> discussion related to defining the problem that may or may not require a
> solution. I disagree that we should look at the various implementation
> policies
Patrick,
Referring to the language in the RFC is the starting point in the discussion
related to defining the problem that may or may not require a solution. I
disagree that we should look at the various implementation policies implemented
in the wild by registries and registrars to develop
On Mon, May 21, 2018, at 16:15, Gould, James wrote:
> The EPP greeting per RFC 5730 "identifies the services supported by the
> server". The EPP login command services per RFC 5730 includes "
> elements that contain URIs representing the objects to be managed during
> the session" and "MAY
Patrick,
I believe the goal here is to discuss the protocol itself and not deal with the
registry or registrar policies that conflict with it.
The EPP greeting per RFC 5730 "identifies the services supported by the
server". The EPP login command services per RFC 5730 includes "
elements
On Fri, May 4, 2018, at 16:15, Gould, James wrote:
> My recommendation is to move forward with draft-ietf-regext-change-poll
> and to leave the EPP server sending unsupported responses (mapping
> extension and / or command response extensions) to a client based on the
> login services up to a
n.com <http://verisigninc.com/>
> From: James Galvin <gal...@elistx.com <mailto:gal...@elistx.com>>
> Date: Friday, May 4, 2018 at 9:31 AM
> To: James Gould <jgo...@verisign.com <mailto:jgo...@verisign.com>>
> Cc: Patrick Mevzek <p...@dotandco.com <mailto:p.
Galvin <gal...@elistx.com>
Cc: Patrick Mevzek <p...@dotandco.com>; regext@ietf.org
Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D
Action: draft-ietf-regext-change-poll-07.txt)
Jim,
My recommendation is to move forward with draft-ietf-regext-change-poll a
n <gal...@elistx.com>
Date: Friday, May 4, 2018 at 9:31 AM
To: James Gould <jgo...@verisign.com>
Cc: Patrick Mevzek <p...@dotandco.com>, "regext@ietf.org" <regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] Poll messages with unhandled namespaces (was
Re: I-D Action: draft-ietf
The chairs would appreciate a suggestion from those in this discussion
as to what you would like to do next?
The change-poll document has been in WGLC that has now expired.
However, you have identified a technical issue but you have not been
clear as to whether you want a change in the
Patrick,
This may be an excellent topic for a working session at the next IETF. It
would be great to hear opinions from others on this topic, since there is
obviously a gap in the interpretation of the greeting and login services as it
relates to responses (command responses and poll
On Fri, Apr 20, 2018, at 16:06, Gould, James wrote:
> Thank you for the detailed description of your reasoning. I will leave
> it that we disagree on the purpose of the login services, the need for
> the server to honor the login services for poll messaging, and the
> impacts in returning
Patrick,
Thank you for the detailed description of your reasoning. I will leave it that
we disagree on the purpose of the login services, the need for the server to
honor the login services for poll messaging, and the impacts in returning
unsupported responses or response extensions to
On Wed, Apr 18, 2018, at 15:43, Gould, James wrote:
> This particular thread was started Martin Casanova, who brings up an
> excellent point that needs to be considered. Martin, you may want to
> weigh on this.
You can probably admit that, based on the amount of time the problem exists
Patrick,
This particular thread was started Martin Casanova, who brings up an excellent
point that needs to be considered. Martin, you may want to weigh on this.
I have the following questions and related thoughts:
1. Do you believe that it is protocol compliant for the server to return
On Mon, Apr 16, 2018, at 16:03, Gould, James wrote:
> Thanks for your thoughts of the 4 options presented for handling the
> returning of a poll message that the client does not support based on
> the client login services. To note, this is not specific to draft-ietf-
> regext-change-poll, so
37 matches
Mail list logo
