Dear Benjamin,
I have confirmed with others about this wording. Your understanding is right
that "service message" means using the <poll> mechanism. So I suggest changing
the text in section 4.3 like,
The server operator reviews the request offline, and MUST inform the client of
the outcome of the review either by queuing a service message for retrieval via
the <poll> command and MAY use an out-of-band mechanism to inform the client of
the outcome.
Regards,
Linlin
Linlin Zhou
From: Linlin Zhou
Date: 2018-11-01 10:57
To: Benjamin Kaduk
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org
Subject: Re: [regext] Benjamin Kaduk's No Objection on
draft-ietf-regext-org-11: (with COMMENT)
Dear Benjamin,
I re-read the two paragraphs again and again. And I think I have the thought in
mind that "service message" may be the key words to make you confused.
In section 4.2, "the client MUST be notified using a service message", this
"service message" has a relatively broad meaning, that it means the in-band or
out-or-band service message. And "MUST" means you must send the message whether
online or offline to the client.
If the above understanding is proper, In section 4.3 "either by queuing a
service message for retrieval via the <poll> command...", this "service
message" is not specified for <poll> excusively.
Of course, I'll try to confirm with other EPP experts in parallel.
Regards,
Linlin
Linlin Zhou
From: Linlin Zhou
Date: 2018-10-31 13:45
To: Benjamin Kaduk
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org
Subject: Re: Re: [regext] Benjamin Kaduk's No Objection on
draft-ietf-regext-org-11: (with COMMENT)
Dear Benjamin,
Please see my feedbacks below.
Regards,
Linlin
Linlin Zhou
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > Section 4.3
> >
> > The status of the organization object after returning this response
> > MUST include "pendingCreate". The server operator reviews the
> > request offline, and informs the client of the outcome of the review
> > either by queuing a service message for retrieval via the <poll>
> > command or by using an out-of-band mechanism to inform the client of
> > the request.
> >
> > I don't think the "either" is appropriate; the earlier text *requires* the
> > service message, and allows for additional optional notification
> > mechanisms.
> > [Linlin] This <poll>mechanism is supported in section 2.9.2.3 of RFC5730.
> > So this is a easy and convinient way to inform the clients.
>
> I'm saying that the choice for the server is not "do X or do Y", it's: "do
> X, then either do Y or don't do Y". The word "either" here implies that it
> is sometimes acceptable to not do X (where X is the queuing of the service
> message).
> [Linlin] In my understanding, I think the text means do X or do Y. You can
> have two choices to inform the result by <poll> of EPP command or by
> out-of-band actions. The following <poll> response is an example using <poll>
> mechanism. Of course you can also send an email to to contact of the
> organization.
> The text is consistent with EPP RFCs. Maybe we can ask the author to confirm:)
>
Perhaps I am misreading, but I see this text in Section 4.2 that says that
the server MUST always send a service message to notify the client:
Once
the action has been completed, the client MUST be notified using a
service message that the action has been completed and that the
status of the object has changed. Other notification methods MAY be
used in addition to the required service message..
The text here in Section 4.3 says:
The status of the organization object after returning this response
MUST include "pendingCreate". The server operator reviews the
request offline, and informs the client of the outcome of the review
either by queuing a service message for retrieval via the <poll>
command or by using an out-of-band mechanism to inform the client of
the request.
which would allow either the service message, or an out-of-band mechanism,
or both mechanisms used together.
My issue with the document is that the document is internally inconsistent
-- in Section 4.2 it says "always do X", but Section 4.3 contradicts that
by saying "you could do X, or you could not do X and do Y instead". An
implementor has to pick whether to believe Section 4.2 or Section 4.3, and
we should not force them to make such a choice.
[Linlin] I can understand your concerns now. I think I had better propose a
thread and ask the author or other EPP experts for confirmation. Once I get the
feedback, I'll have a response. Thank you.
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
