[regext] I-D Action: draft-ietf-regext-rdap-reverse-search-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.

Title   : Registration Data Access Protocol (RDAP) Reverse 
search capabilities
Authors : Mario Loffredo
  Maurizio Martinelli
Filename: draft-ietf-regext-rdap-reverse-search-05.txt
Pages   : 10
Date: 2020-10-26

Abstract:
   The Registration Data Access Protocol (RDAP) does not include query
   capabilities to find the list of domains related to a set of entities
   matching a given search pattern.  In the RDAP context, an entity can
   be associated to any defined object class.  Therefore, a reverse
   search can be applied to other use cases than the classic domain-
   entity scenario.  This document describes RDAP query extensions that
   allow servers to provide a reverse search feature based on the
   relationship between any searchable object and the related entities.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-rdap-reverse-search-05
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-reverse-search-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-05.txt

[Mario Loffredo]

Hi all,

sorry for the delay in publishing this version as a consequence of the 
WG feedback.


I have been very busy with the review of drafts under IESG evaluation 
and the implementation of jscontact-tools library.


Hope this version addresses the points raised by Jansdip, George, 
Patrick and Scott.


Best,

Mario



 Messaggio Inoltrato 
Oggetto: 	New Version Notification for 
draft-ietf-regext-rdap-reverse-search-05.txt

Data:   Mon, 26 Oct 2020 00:45:59 -0700
Mittente:   internet-dra...@ietf.org
A: 	Maurizio Martinelli , Mario Loffredo 






A new version of I-D, draft-ietf-regext-rdap-reverse-search-05.txt
has been successfully submitted by Mario Loffredo and posted to the
IETF repository.

Name: draft-ietf-regext-rdap-reverse-search
Revision: 05
Title: Registration Data Access Protocol (RDAP) Reverse search capabilities
Document date: 2020-10-26
Group: regext
Pages: 10
URL: 
https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-05.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search
Htmlized: 
https://tools.ietf.org/html/draft-ietf-regext-rdap-reverse-search-05
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-reverse-search-05


Abstract:
The Registration Data Access Protocol (RDAP) does not include query
capabilities to find the list of domains related to a set of entities
matching a given search pattern. In the RDAP context, an entity can
be associated to any defined object class. Therefore, a reverse
search can be applied to other use cases than the classic domain-
entity scenario. This document describes RDAP query extensions that
allow servers to provide a reverse search feature based on the
relationship between any searchable object and the related entities.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

[Gould, James]

Patrick,

We'll agree to disagree with the value and risk of 
draft-ietf-regext-unhandled-namespaces, since I can't think of a theoretical or 
real risk to existing clients with at least two independent implementations.  
Your objection can be included in the document shepherd writeup, but as noted 
before there is no consensus to make a change.  

-- 
 
JG



James Gould
Fellow Engineer
jgo...@verisign.com 


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 

On 10/25/20, 6:23 PM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Thu, Oct 22, 2020, at 08:47, Gould, James wrote:
> I do need to clarify one 
> thing, there was no specific changes needed on the client-side to 
> support draft-ietf-regext-unhandled-namespaces other than ensuring that 
> the draft-ietf-regext-unhandled-namespaces XML namespace is included in 
> the login services. 

There was no specific changes needed on the client-side... for YOUR client.
Great for you, but from that you can not draw a conclusion that your draft
creates no problem whatsoever.

Please take into account there are other clients out there, that may work
differently and do different assumptions.

Your draft changes the assumptions in RFC 5730. And hence may break existing
clients. By saying that there was no problem for one client is not a proof
that interoperability was not broken.

> Clients should be capable of parsing and marshaling the 
>  element regardless of whether or not 
> draft-ietf-regext-unhandled-namespaces is supported.  

This is unrelated. You are changing the text from RFC 5730 that says
explicitly this content is client provided. You are now redefining what
is in RFC 5730 by saying "any content is fine here".

> The 
> approach taken with draft-ietf-regext-unhandled-namespaces enables the 
> information to be returned without the chance of breaking a validating 
> client that doesn't support the service,

This is untrue, as you change the semantics of RFC 5730 at least twice
(content 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 deployed.

-- 
  Patrick Mevzek
  p...@dotandco.com

___
regext mailing list
regext@ietf.org

https://secure-web.cisco.com/1JXSBPoG-78NoxpuH19NNm2nvZTdQOhccfcp1QWP5dIEoQ6ekz0xXZM5s-sjWAtHoyCWUf_2JEydMxz45_96qI1YCrzvVHqo_auUMjwRjm8-vzii5f9vyKuSHuvmM1k3cQ0yIXjkmvgHMVJvCVWmcpbbHGNx0ZiX0M2UoaJSC_KsQkylfiD2W2c6kKOzUDsOD0A0YpWshVU8cx2Vl5xPIwkFkeDUxrAEM1QqgxxgX8Kl-TSaiWE0mnRbAdMiJ2hnWnQNYliLaaS3GpmXxZ8naGmsuWA4vrGgPbftN8s8SJt0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-secure-authinfo-transfer-03

[James Galvin]

Thanks to all who responded to the WG Last Call for this document.  
There have been 3 clear indications of support with no objections.


There was some discussion and support to change the document to 
Standards Track from BCP.  There have not been any issues noted during 
last call.


The WG last call is officially closed.

The document editor has posted a revised draft that is now ready for 
submission to the IESG.  The document shepherd, Jody Kolker, is request 
to please prepare the write-up and we will submit the document as soon 
as that is complete!


Antoin and Jim




On 2 Oct 2020, at 16:55, James Galvin wrote:

The following working group document is believed to be ready for 
submission to the IESG for publication as a standards track document:


https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-transfer/

This WG last call will end at close of business, Friday, 16 October 
2020.


Please review this document and indicate your support (a simple 
“+1” is sufficient) or concerns with the publication of this 
document by replying to this message on the list.


The document shepherd for this document is Jody Kolker.

Regards,

Antoin and Jim


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] The REGEXT WG has placed draft-blanchet-regext-rfc7484bis in state "Candidate for WG Adoption"

[IETF Secretariat]

The REGEXT WG has placed draft-blanchet-regext-rfc7484bis in state
Candidate for WG Adoption (entered by Antoin Verschuren)

The document is available at
https://datatracker.ietf.org/doc/draft-blanchet-regext-rfc7484bis/


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

[James Galvin]

The Chairs would like to extend this WG Last Call for an additional two 
weeks, to close on Friday, 30 October 2020.


Although there have been 3 indications of support, Patrick Mevzek and 
James Gould have been having an extended discussion on the mailing list 
about one issue.  The chairs believe it is important to get additional 
points of view, ideally from other EPP client developers but all 
opinions are welcome.


Current consensus is to seek publication.  However, we are a relatively 
small group and we would like all comments considered by multiple 
people.  Would others please indicate their point of view in the active 
thread between James and Patrick?


Thank you,

Antoin and Jim




On 2 Oct 2020, at 16:52, James Galvin wrote:

The following working group document is believed to be ready for 
submission to the IESG for publication as a standards track document:


https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/

This WG last call will end at close of business, Friday, 16 October 
2020.


Please review this document and indicate your support (a simple 
“+1” is sufficient) or concerns with the publication of this 
document by replying to this message on the list.


The document shepherd for this document is David Smith.

Regards,

Antoin and Jim


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03

[James Galvin]

The Chairs would like to extend this WG Last Call for an additional two 
weeks, to close on Friday, 30 October 2020.


Although there have been 2 indications of support, James Gould provided 
some extensive comments, most of which have been addressed in version 
-04 of the document.  However, Jody Kolker indicated in his response 
that he’d appreciate some additional comments on a few items.


The Chairs would like to see some discussion of the remaining items.  
Would others please indicate their point of view in the active thread 
between Jody and James.


Thank you,

Antoin and Jim



On 2 Oct 2020, at 16:57, James Galvin wrote:

The following working group document is believed to be ready for 
submission to the IESG for publication as a standards track document:


https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/

This WG last call will end at close of business, Friday, 16 October 
2020.


Please review this document and indicate your support (a simple 
“+1” is sufficient) or concerns with the publication of this 
document by replying to this message on the list.


The document shepherd for this document is James Galvin.

Regards,

Antoin and Jim


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis

[Antoin Verschuren]

Thank you Scott and all others that replied during the extended WGLC..
The chairs agree with the Authors that there was no consensus reached during 
the extended WGLC to make changes to the document.
Therefor this WGLC is now officially closed.
We had 3 explicit statements of support for this document, and one concern 
whose required changes were not supported by 3 others.
We will submit the document to the IESG as is.

The document shepherd for this document is Mario Loffredo.
Mario, could you please start your shepherd writeup?

Regards,

Jim and Antoin



> Op 12 okt. 2020, om 17:09 heeft Hollenbeck, Scott 
>  het volgende geschreven:
> 
>> -Original Message-
>> From: regext mailto:regext-boun...@ietf.org>> On 
>> Behalf Of James Galvin
>> Sent: Friday, October 2, 2020 4:15 PM
>> To: regext@ietf.org 
>> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>> 
>> The WGLC for this document was scheduled to end today.  While there is
>> support to move the document forward there is one minor comment that
>> has been raised during the last call.
>> 
>> The chairs would like to hear from other working group members as to what
>> to do with this comment.  Rather than close the last call and risk another 
>> last
>> call, we are extending this last call for another week.  If we can come to a
>> consensus as to how to proceed before the end of last call than the
>> document can stay on track to be submitted to the IESG after the last call.
>> 
>> The WG last call will end at close of business on Friday, 9 October 2020.
>> 
>> 
>> Here are the comments as seen on the mailing list.  Please respond with
>> your suggestions regarding these two comments.
>> 
>> 
>> James Gould:
>> 
>> Yes, lumping the registrar object with the contact object under a single
>> RDAP entity object interface is the rub.  We solved the problem in the
>> RDAP Profile, by supporting entity lookup by IANA ID (number) and
>> registrar name (string) for the registrar objects, and by ROID
>> (“((\w|_){1,80}-\w{1,8}") for the contact objects.  Where there is
>> overlap, which is registrar name (string) and ROID
>> ((“((\w|_){1,80}-\w{1,8}") the contact takes precedence.  My
>> recommendation is to provide guidance in the section 3.1.5 "Entity Path
>> Segment Specification" for this real world case:
>> 
>> The  parameter represents an entity (such as a contact,
>> registrant, or registrar) identifier whose syntax is specific to the
>> registration provider.  For example, for some DNRs, contact
>> identifiers are specified in [RFC5730] and [RFC5733], and
>> registrar identifiers are specified using the IANA Registrar ID
>> assigned by ICANN.  The server SHOULD define a scheme
>> for the  parameter to differentiate between the
>> supported entity object types (e.g., contact and registrar),
>> such as using different  formats, using a 
>> precedence order, or a combination of formats and precedence
>> order.
>> 
>> The SHOULD could be a MUST, but the point is to provide guidance to
>> implementers of the protocol.
>> 
>> Two responses have been offered:
>> 
>> Jasdip Singh response:
>> 
>> One thought is if it could be in the RDAP profile doc for the DNRs
>> (https://secure-web.cisco.com/1k4lL- 
>> ZaH_4UTeAlExqEDmWoj2i2M2JCucgN0US-
>> ZRaw3P13LwsVyTwARJxQoKgUo1ceNGMGoZaum_o86c9qFXMK28e6HYprdo
>> vBXG6JQKzs1SqqT5mQ_VEnMihHl3qiwMkTQ8qPKkPpbqOJbRIDs_UDppLFz2
>> yhs97pm3Ssnh2DxotUzdWsgbWlESVZbLzMg5Z-
>> ZTHevue2cVlwSwhdDlzQiyDBU4e0y9cLgcwXSXX7tJE5mUh04ocHwUI2Kcpqccf
>> u_lM-
>> d8029rv314sSAKQ/https%3A%2F%2Fwww.icann.org 
>> %2Fresources%2Fpages
>> %2Frdap-operational-profile-2016-07-26-en).
>> That way no need to update the spec.
>> 
>> James Gould response:
>> 
>> The RDAP Profile is dependent on the RFC, so I wouldn't create a
>> circular dependency.  My recommendation is to take the lessons learned
>> in implementing the RFC and provide guidance on how to handle it in the
>> RFC directly.
> 
> [SAH] I don't think we reached consensus to change anything in the draft, so 
> I left this one alone.
> 
> Scott
> ___
> regext mailing list
> regext@ietf.org 
> https://www.ietf.org/mailman/listinfo/regext 
> 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis

[Antoin Verschuren]

Thank you Scott and all others that replied during the extended WGLC..
This is to inform you that this WGLC is now officially closed.
We had 3 explicit statements of support for this document, and 2 concerns which 
led to an extended WGLC. 
1 of the concerns was addressed by the autor in a new version of the document, 
and 1 concern did not get support.
We will submit the new version of the document to the IESG as is.

The document shepherd for this document is Jasdip Singh.
Jasdip, could you please start your shepherd writeup?

Regards,

Jim and Antoin


> Op 12 okt. 2020, om 15:26 heeft Hollenbeck, Scott 
>  het volgende geschreven:
> 
>> -Original Message-
>> From: regext mailto:regext-boun...@ietf.org>> On 
>> Behalf Of James Galvin
>> Sent: Friday, October 2, 2020 4:06 PM
>> To: regext@ietf.org 
>> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis
>> 
>> The WGLC for this document was scheduled to end today.  While there is
>> support to move the document forward there are two minor comments that
>> have been raised during the last call.
>> 
>> The chairs would like to hear from other working group members as to what
>> to do with these comments.  Rather than close the last call and risk another
>> last call, we are extending this last call for another week.  If we can come 
>> to a
>> consensus as to how to proceed before the end of last call than the
>> document can stay on track to be submitted to the IESG after the last call.
>> 
>> The WG last call will end at close of business on Friday, 9 October 2020.
>> 
>> 
>> 
>> Here are the comments as seen on the mailing list.  Please respond with
>> your suggestions regarding these two comments.
>> 
>> 
>> 
>> James Gould:
>> 
>> I have one item to bring up with draft-ietf-regext-rfc7483bis, which is
>> associated with Section 5.1 “The Entity Object Class”.   The jCard
>> "version" and "fn" members are required according to RFC 6350, which
>> poses an issue if a contact name does not exist or needs to be redacted.
>>  To address this case, I recommend adding a sentence to the end of
>> section 3 "Common Data Types":
>> 
>> Contact information is defined using jCards as described in [RFC7095].
>> The “version” and “fn” members are required according to
>> [RFC6350], where an empty “fn” member MAY be used when the contact
>> name does not exist or is redacted.
>> 
>> Two response have been offered:
>> 
>> Scott Hollenbeck:
>> 
>> I'd like to see some discussion of this suggestion. If one understands
>> the normative references, the suggestion is already implicitly
>> addressed. There may be some value in describing this situation
>> explicitly since it came up in the ICANN gTLD implementation context,
>> but so others think this clarification is necessary?
>> 
>> Jasdip Singh:
>> 
>> Seems if the RDAP profile for the DNRs
>> (https://secure- 
>> web.cisco.com/11khs_gD3RqFuWkwSmkqxXidBMgZZIHUGiC- 
>> 
>> mnI0WBAe7ZaFAHesmDgIEQi6C5xdf4AFgOuCxci5Eg7TKAZOYRCMTpkn4HpQ
>> A0IDR_way6sBg1J7G75Fc6554SdNlt4CZkx6Y4of235gC9pdotYdG-
>> DmTSKFkMu7EbRZFxRQq2wuuUIJrvrbPz8ZGCf81LYvWGTfZrUMt-
>> DtcEm1hz8yHyNC2J1hOc_6YhTLsOG_N5ZHM81dqp6v_HPIIN9ppz69MwuaZA
>> ao62RBYsmFe3OyFzQ/https%3A%2F%2Fwww.icann.org 
>> %2Fresources%2Fpa
>> ges%2Frdap-operational-profile-2016-07-26-en)
>> could clarify this, the spec could be left as-is.
> 
> [SAH] I just updated the document to address this feedback.
> 
>> Mario Loffredo:
>> 
>> The document does not contain any requirement or recommendation about
>> when returning ldhName and unicodeName values. However, the examples
>> seem to convey the idea that ldhName must  always be returned and
>> unicodeName must be returned in case of an IDN.
> 
> [SAH] There was no additional discussion, so I left this one alone.
> 
> Scott
> ___
> regext mailing list
> regext@ietf.org 
> https://www.ietf.org/mailman/listinfo/regext 
> 
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis

[Mario Loffredo]

Hi Chairs,


Il 26/10/2020 16:10, Antoin Verschuren ha scritto:

Thank you Scott and all others that replied during the extended WGLC..
The chairs agree with the Authors that there was no consensus reached 
during the extended WGLC to make changes to the document.

Therefor this WGLC is now officially closed.
We had 3 explicit statements of support for this document, and one 
concern whose required changes were not supported by 3 others.

We will submit the document to the IESG as is.

The document shepherd for this document is Mario Loffredo.
Mario, could you please start your shepherd writeup?


I'll publish the shepherd writeup by tomorrow.

Best,

Mario



Regards,

Jim and Antoin



Op 12 okt. 2020, om 17:09 heeft Hollenbeck, Scott 
> het volgende 
geschreven:



-Original Message-
From: regext > On Behalf Of James Galvin

Sent: Friday, October 2, 2020 4:15 PM
To:regext@ietf.org 
Subject: [EXTERNAL] Re: [regext] WG LAST CALL: 
draft-ietf-regext-rfc7482bis


The WGLC for this document was scheduled to end today.  While there is
support to move the document forward there is one minor comment that
has been raised during the last call.

The chairs would like to hear from other working group members as to 
what
to do with this comment.  Rather than close the last call and risk 
another last
call, we are extending this last call for another week.  If we can 
come to a

consensus as to how to proceed before the end of last call than the
document can stay on track to be submitted to the IESG after the 
last call.


The WG last call will end at close of business on Friday, 9 October 
2020.



Here are the comments as seen on the mailing list.  Please respond with
your suggestions regarding these two comments.


James Gould:

Yes, lumping the registrar object with the contact object under a single
RDAP entity object interface is the rub.  We solved the problem in the
RDAP Profile, by supporting entity lookup by IANA ID (number) and
registrar name (string) for the registrar objects, and by ROID
(“((\w|_){1,80}-\w{1,8}") for the contact objects.  Where there is
overlap, which is registrar name (string) and ROID
((“((\w|_){1,80}-\w{1,8}") the contact takes precedence.  My
recommendation is to provide guidance in the section 3.1.5 "Entity Path
Segment Specification" for this real world case:

The  parameter represents an entity (such as a contact,
registrant, or registrar) identifier whose syntax is specific to the
registration provider.  For example, for some DNRs, contact
identifiers are specified in [RFC5730] and [RFC5733], and
registrar identifiers are specified using the IANA Registrar ID
assigned by ICANN.  The server SHOULD define a scheme
for the  parameter to differentiate between the
supported entity object types (e.g., contact and registrar),
such as using different  formats, using a 
precedence order, or a combination of formats and precedence
order.

The SHOULD could be a MUST, but the point is to provide guidance to
implementers of the protocol.

Two responses have been offered:

Jasdip Singh response:

One thought is if it could be in the RDAP profile doc for the DNRs
(https://secure-web.cisco.com/1k4lL-
ZaH_4UTeAlExqEDmWoj2i2M2JCucgN0US-
ZRaw3P13LwsVyTwARJxQoKgUo1ceNGMGoZaum_o86c9qFXMK28e6HYprdo
vBXG6JQKzs1SqqT5mQ_VEnMihHl3qiwMkTQ8qPKkPpbqOJbRIDs_UDppLFz2
yhs97pm3Ssnh2DxotUzdWsgbWlESVZbLzMg5Z-
ZTHevue2cVlwSwhdDlzQiyDBU4e0y9cLgcwXSXX7tJE5mUh04ocHwUI2Kcpqccf
u_lM-
d8029rv314sSAKQ/https%3A%2F%2Fwww.icann.org 
%2Fresources%2Fpages

%2Frdap-operational-profile-2016-07-26-en).
That way no need to update the spec.

James Gould response:

The RDAP Profile is dependent on the RFC, so I wouldn't create a
circular dependency.  My recommendation is to take the lessons learned
in implementing the RFC and provide guidance on how to handle it in the
RFC directly.


[SAH] I don't think we reached consensus to change anything in the 
draft, so I left this one alone.


Scott
___
regext mailing list
regext@ietf.org 
https://www.ietf.org/mailman/listinfo/regext



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


--
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

[Thomas Corte]

Hello,

On 10/26/20 15:01, James Galvin wrote:

> Current consensus is to seek publication.  However, we are a relatively
> small group and we would like all comments considered by multiple
> people.  Would others please indicate their point of view in the active
> thread between James and Patrick?

As both an EPP client (and server) developer, I think that both James and
Patrick make valid points, though I tend to agree more with Patrick's
point of view.

I'd fully agree with Patrick that the draft is somewhat abusing the
 mechanism, as it was clearly designed in RFC 5730 to
communicate "error diagnostic information", with the  containing a
"client-provided element (including XML tag and value)". In fact, from
this wording one could even derive that it's *not* proper server behavior
at all to include anything in the  element that didn't also appear
in the client's EPP command, which this draft is asking servers to do.

One the other hand, I'd agree that it's probably the only place where
non-parsed XML can be included in responses, which is the only way to
keep the server's responses from violating the contract by including
namespaces not listed as supported by the client.

In our own current client implementation, we're only consulting the
 content if the result code indicates an error. I'd assume that
many clients do it this way, which is why I doubt that the inclusions
defined by the draft will do any real harm or even cause confusion.

However, at best this means that clients will completely ignore the
unhandled data, i.e. simply ignore the (apparently empty) poll messages
and acknowledge them without processing. While this is nice in terms of
not blocking any other (understood) poll messages, it also poses the
problem that important poll messages may go unnoticed, potentially for
extended periods of time, which may (depending on the nature of the
messages) be a greater operational risk than blocking further polling.
If an unhandled namespace simply showed up (violating the contract), at
least my validating EPP client would croak, and I'd be forced to take
action (ideally by adding support for the namespace and resume polling then).

I know it's late in the game to come up with suggestions, but anyhow:
a compromise to solve this, at least for the polling issue, *could* be to
use  as described, but to return an *error response* (with a
special result code) instead of a success response to the  command.
This could (somewhat) justify the use of , while still alerting
the EPP client about something that it might be missing. Of course, this
would still mean that polling of further messages would come to a halt
until the issue is fixed on the client side.

Best regards,

Thomas

-- 

 |   |
 | knipp |Knipp  Medien und Kommunikation GmbH
  ---Technologiepark
 Martin-Schmeißer-Weg 9
 44227 Dortmund
 Deutschland

 Dipl.-Informatiker  Tel:+49 231 9703-0
 Thomas CorteFax:+49 231 9703-200
 Stellvertretender LeiterSIP:thomas.co...@knipp.de
 Software-EntwicklungE-Mail: thomas.co...@knipp.de

 Registereintrag:
 Amtsgericht Dortmund, HRB 13728

 Geschäftsführer:
 Dietmar Knipp, Elmar Knipp

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext