|
Hi Addison, indeed, sorry for misrepresenting your review! I meant to write “I18n review”, and not “I18ndir review”, although the doc was brought to your and W3C attention by our I18ndir expert
John. Again, thank you so much for taking the time to provide useful feedback, it is much appreciated. Francesca
From: Phillips, Addison <addison@xxxxxxxxxx> Hello Francesca, Thank you for this summary. Please note that, although I believe I am an i18ndir reviewer, this review was actually done wearing my W3C I18N
working group chair hat. I have no objection to it being treated as an i18ndir review, provided no one else does. I just note that I wasn’t assigned this review. I apologize to the group for not filing separate issues, which generally is easier to deal with. To reiterate, I am satisfied by all of the changes and appreciate the support of the authors. I don’t think there are any issues that should
affect this I-D’s transition to RFC. Addison Addison Phillips Sr. Principal SDE
⇒ I18N
(Amazon.com) Chair I18N WG, Amazon AC Rep (W3C) Internationalization is not a feature.
It is an architecture.
From: Francesca Palombini <francesca.palombini@xxxxxxxxxxxx>
All,
This is a summary on one of the points raised by Addison in his I18ndir review of draft-ietf-httpapi-linkset. First of all, let me start by thanking him and John, as well as the authors for their reactivity and work on this feedback.
Rich, as chair, has provided a summary of the discussion on the github issue [1]. Although the working group uses github very extensively, I want to give a summary of the discussion via mail, provide my point of view as AD, make sure
everyone is aware of it, and that no one strongly objects to this way forward. I will be looking for objections up to May 4th.
Additionally to his other comments (which have been dealt with and acknowledged), Addison in his review pointed out a possible deficiency in RFC 8288 and/or RFC 8187 (on which this document depends on normatively) regarding matching
of language tags ranges. It was brought up that there might be a need for spelling that out and the authors have added editorial text to that effect in the document [2].
In the thread, there was talk of a possible need for stronger clarification and requirements, and it was shortly discussed how that would be done, with this document, an erratum, or a separate I-D being suggested as possible places.
Admitted (and not granted) the working group agrees that some substantial omission have taken place:
·
it should not be described and dealt with in an erratum, as that would not be the right place to reach consensus on the text
·
I believe this is beyond the scope of this document, which is not meant to update the base RFCs.
·
Would better be dealt with in a separate document, clarifying the omission and updating the base RFCs. Additionally I believe a stronger case should be made for these clarifications being fundamental
to this document, rather than to the base RFCs, for it to be directly referenced, rather than indirectly referenced from 8288 / 8187.
Given that, my AD summary is that the document has done its job of integrating Addison’s I18n comments, and is ready to move forward including the latest changes. This is the current final version of the I-D integrating these changes:
https://github.com/ietf-wg-httpapi/linkset/blob/master/draft-ietf-httpapi-linkset-10.txt
diff with last published version: https://www.ietf.org/rfcdiff?url1=draft-ietf-httpapi-linkset-09.txt&url2=https://raw.githubusercontent.com/ietf-wg-httpapi/linkset/master/draft-ietf-httpapi-linkset-10.txt
Please let me know of any misrepresentations or strong objections, by May 4th.
Thanks,
[1] https://github.com/ietf-wg-httpapi/linkset/issues/66
[2] https://github.com/ietf-wg-httpapi/linkset/commit/092bc61ea834da58e5792062902471541a2dde31 |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
