ext, not 1024 bit (sic).
Also, I see no reason for this limit, can you care to explain why description
content, being freeform for human consumption, should be limited at the
protocol level?
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
be multiple drafts in fact for multiple definitions.
PS: the argument in A.1 about the complexity arising out of jCard can "soon"
become obsolete if draft-loffredo-regext-rdap-jcard-deprecation goes through,
so maybe some text should have addressed other non jCard cases (or explaining
why
s the URI associated with the entire HTML document. "
There is no real explanation of the context for RDAP, but based on that maybe
it should be a link to the same query with fieldSet "full"?
On Mon, Apr 27, 2020, at 00:45, Patrick Mevzek wrote:
>
>
> On Fri, Feb 28, 2020
009.pdf
(both do an automatic redirect from http:// to https:// anyway)
And with all planned changes to RFC7483, it is time to introduce
rdap_level_1
in rdapConformance values?
If we say: "we shouldn't because clients will not be upgra
483].
"
Shouldn't RFC7483 be replaced by the draft rfc7483bis?
PS: there is currently a problem in the tracker,
on https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7482bis/
a version 03 is shown as existing but you can't vie
Hello Mario,
A quick follow-up that could be a closure in fact, as your answer fills
the missing points I had.
On Mon, Apr 27, 2020, at 10:30, Mario Loffredo wrote:
> Il 27/04/2020 07:45, Patrick Mevzek ha scritto:
> >
> > On Fri, Feb 28, 2020, at 09:43, Antoin Verschuren
On Mon, Apr 27, 2020, at 06:27, Hollenbeck, Scott wrote:
> > -Original Message-
> > From: regext On Behalf Of Patrick Mevzek
> > Sent: Monday, April 27, 2020 4:06 AM
> > To: regext@ietf.org
> > Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck
On Mon, Apr 27, 2020, at 11:46, Mario Loffredo wrote:
> Il 27/04/2020 08:04, Patrick Mevzek ha scritto:
> > Also:
> > couldn't each fieldset have a list of jsonPath elements (similar to what is
> > done in
> > draft-ietf-regext-rdap-sorting-and-paging)
> >
I do not think that "MUST NOT exceed 1024 bit." is
the adequate description for a string of characters.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ht after creation and creation only.
This is for me more policy stuff (and good registry documentation would specify
that somewhere, even if I bet it doesn't happen), as it has no real consequences
on the protocol or interoperability matters.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
e RDAP
protocol and of any extensions, as specified in RFC7483.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ease" framework, but I am really
not sold that any technical solution can solve the problem there.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ole ecosystem.
(the last one transitioning and finally removing the old version completely from
all systems may be even the one with the highest benefit to the community).
But in short, no one gets benefit of starting first.
Hence, outside forces need to come into play to tilt the current balanc
Considering that, in the future, for the same query, the reply can be different
based on the client and its level of access.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
matter of
> server policy.
If you introduce options (the list is either related to the content OR the full
list of server features), how is a client supposed to know in which case he is?
He can't right now,
which is why I don't think such options should be added.
--
P
pported
> extensions that are available to that client.
Yes, the help response allows to "discover" all possible extensions from a
specific client.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
recall correctly.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
data,
which also removes IANA from the hot operational path when RDAP clients do
queries.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Hello Marc,
On Tue, Aug 11, 2020, at 13:55, Marc Blanchet wrote:
> On 4 Aug 2020, at 15:47, Patrick Mevzek wrote:
> >
> > PS: related but not directly, at least for domain registries, it would
> > be
> > nice to have an `SRV` record on `_rdap._tcp` or something to poin
://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml#rdap-extensions-1
- arin_originas0
- artRecord
- cidr0
- fred
- icann_rdap_response_profile_0
- icann_rdap_technical_implementation_guide_0
- platformNS
- rdap_objectTag
- regType
It would be very good hence to see there also r
2 already has "The RDAP service MUST be provided over HTTPS only."
so that will already cover a not small amount of entries in the bootstrap
registry.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://w
P track or if you believe a different track
> should be used for one or both drafts.
I believe they both should be "Experimental" instead.
They are not long term widespread "current practices" at all.
As for "best" ones, I
t should certainly not be "Best Current Practice".
It is neither proved to be "best" nor is it "current practice".
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
that new view on them, without any possible negotiation.
At this point it seems we are just repeating our own arguments on both side,
so I don't think either will move their position and we have to keep our
disagreement, which is fine.
I wanted to record my disagreement on this draft during
t all
clients will suddenly
be upgraded to use this specification (as if all EPP servers out there will
be updated...), then so be it, it does not really matter.
Again, I am not trying to convince anyone, I know it won't happen,
I just phrased my justifications on the problems I see.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ent of extValue, and possibly having value/extValue with NON error codes)
Your draft *clearly* creates a _risk_ for any existing client starting to break
once a server enables this feature. Saying that one client works fine is
not a measure of interoperability risks when it is
e responsibility clearly
falls on his end and he is in control of his fate because he signaled the
namespaces
at login, without the registry forcing delivery to it of messages with "dubious"
validity per RFC 5730).
--
Patrick Mevzek
p...@dotandco.com
_
't be
aware
of the change.
That is exactly the risk, because the change is not 100% aligned with what was
in past specifications.
As I said already I don't think there is pretty much anything else/again to
discuss.
The consensus is clear considering the silent m
der, like it was done for login-security
seems to me just a poor way to try doing basically whatever XML namespaces
are trying to do without doing it properly.
I sincerely do not hope this is the way things are going
(speaking as an implementer of multiple EPP servers and clients).
--
Patrick M
s namespaces X, Y, Z and registrars
have to deal with them somehow"?
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ided or only the one to
change,
I don't know).
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
to reject things if only because the new
one can not handle something.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
t breaking current software but 2)
allows
updated software to enjoy more features)
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
to email addresses.
Long gone are the days when only an email sent was enough to trigger a transfer,
and for good reasons.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
to sell their TLDs, which can be fine or not, but a
problem
for the registry to decide and for which this protocol called EPP can not do
anything.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ot disrupt all other
registrars NOT wanting to support this scenario.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
see how they work.
Another options is to first document the problem and constraints space, and then
in a separate document offer a solution.
Making everyone first agreeing exactly on what problems need to be solved
can frame discussions efficiently.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
as many similar cases as possible, to lower
risks of fragmentation.
Also all of this is obviously related to Universal Acceptance, and at least in
gTLD
world, ICANN has a specific team/workgroup on that subject.
--
Patrick Mevzek
p...@dotandco.com
___
r "Informational".
Without any clear signal we would have just to infer things based on who
interacts
on the subject and opinions expressed. And right now I don't see a clear signal
on going ahead with placeholders, the discussion seems pretty mixed on the
issue.
--
Pat
s down the line.
> I wish that ICANN/Universal Acceptance people would participate in this
> discussion.
+1, but also noting of course the issue may be more "pressing"/urgent in case
of some IDN ccTLDs than gTLDs.
--
Patrick Mevzek
p...@dotandco.com
_
the server needs to use when constructing some reply.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ve or change public key material (e.g., DNSKEY or DS
resource records) on behalf of customers to the Registries that support DNSSEC."
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
rs.
I think the authentication/authorization stuff is orthogonal to the features
provided
by the protocol.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
fact
to know if that is really a factor for them.
Third, for any registrar stack, adding a new "client" for RDAP stuff
may be easier than changing their EPP stack to add yet one more extension.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
by domain name registrars and registries, EPP/RDAP
are used for things that are not related to the DNS at all (ex: contacts).
Second because EPP was created as a generic provisioning protocol that
technically could handle things completely unrelated to domain names,
even if it is its only major
will anyway need to handle that on their end in some cases, so they should
just be prepared to do it for all cases, and hence no extra new work needed
for any servers.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
t can
consult the certificate given.
It can be considered a weak or partial authentication, until the EPP login
is successfully executed.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
lp any team, I
would happy to contribute, just let me know how.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
201 - 248 of 248 matches
Mail list logo
