@Tobion to summarize Larry concerns. When submitting an errata you can not update the interface docblock, but you have
- rewrote the text around InvalidArgumentException for all with* methods - removed some part of the __toString method docblock. But according to the bylaws this is not possible <http://www.php-fig.org/bylaws/psr-workflow/#3-6-errata>. Erratas can not change the voted docblock texts unless you submit a brand new PSR to supersede PSR7. That's why I'm suggesting using annotations to indicate the importance of the errata submitted. This annotation can be add in the paragraph which defines the URIInterface <https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-7-http-message.md#14-request-targets-and-uris> Without resorting to updating the UriInterface docblock directly. The errata text in itself is good IMHO, we just need to find a good formatting/highlighting mode to ensure everyone has access to it. Does anyone have a suggestion ? Le mercredi 20 juillet 2016 02:09:35 UTC+2, Tobion a écrit : > > I reverted the typo fixes that are unrelated to the errata. > > > Am Dienstag, 19. Juli 2016 10:07:19 UTC+2 schrieb ignace nyamagana: >> >> @Tobion >> >> could you then "expurge" your PR of all the typo changes so that we can >> move on with this vote. I don't think we should remove any text if the >> errata is well written and the bylaws accepts the use of annotations >> <http://www.php-fig.org/bylaws/psr-amendments/#3-1-annotations> for >> erratas to help implementations where confusion may arise. >> >> Le lundi 18 juillet 2016 20:11:37 UTC+2, Larry Garfield a écrit : >>> >>> As I recall, my issues weren't with the content per se (I am happy to >>> let MWOP manage that) but with the fact that the PR under vote modified the >>> spec itself, which is a no-no. Adding Errata to the metadoc to clarify >>> points that were unclear or not perfectly consistent in the original spec >>> is fine; for details of what that Errata should say, for my part if MWOP is >>> happy then I'm (probably) happy. >>> >>> --Larry Garfield >>> >>> On 07/18/2016 03:18 AM, ignace nyamagana wrote: >>> >>> >>> Bumping up this discussion as it seems it was overlooked/forgotten. >>> >>> @Larry did our responses correctly answer your concerns? If so can this >>> be put into vote. If not what still need to be addressed ? What changes do >>> you want tobion to make to his PR. FWIW there was an alternative to this >>> proposal here >>> >>> Ignace >>> >>> >>> Le jeudi 9 juin 2016 14:21:15 UTC+2, ignace nyamagana a écrit : >>>> >>>> Yep, but adding a default host is trying to solve a educational problem >>>> with something I'd consider being a hack. Better let the developer >>>> understand why it fails and learn from it too. >>>> >>>> my .2$ >>>> >>>> Le jeudi 9 juin 2016 00:12:50 UTC+2, Tobion a écrit : >>>>> >>>>> Yep. But that creates the problem that in theory one of the most >>>>> common approaches would turn invalid: >>>>> >>>>> (new Uri)->withScheme('http')->withHost('example.org'); >>>>> >>>>> >>>>> This would be invalid if you enforce that because the moment the URI >>>>> has the http scheme, there is no host yet. >>>>> To avoid this problem I proposed for guzzle/psr7 to just define >>>>> localhost as default host for http(s) URIs when >>>>> there is no host yet. See https://github.com/guzzle/psr7/pull/94 >>>>> >>>>> This also makes sure that you can call >>>>> >>>>> $uri->withPort(8080)->withHost('host') >>>>> >>>>> whatever the scheme might be. >>>>> >>>>> Am Mittwoch, 8. Juni 2016 22:02:13 UTC+2 schrieb Matthew Weier >>>>> O'Phinney: >>>>>> >>>>>> On Mon, Jun 6, 2016 at 4:29 AM, Tobion <tob...@gmail.com> wrote: >>>>>> > https://tools.ietf.org/html/rfc3986#appendix-A >>>>>> > >>>>>> > >>>>>> > authority = [ userinfo "@" ] host [ ":" port ] >>>>>> > >>>>>> > host = IP-literal / IPv4address / reg-name >>>>>> > >>>>>> > reg-name = *( unreserved / pct-encoded / sub-delims ) >>>>>> > >>>>>> > >>>>>> > As you can see reg-name can be empty which means the host can be >>>>>> empty which >>>>>> > means >>>>>> > >>>>>> > "urn://user:pass@:123/path" is a valid URI. The reasoning is also >>>>>> given: >>>>>> > >>>>>> > >>>>>> > https://tools.ietf.org/html/rfc3986#section-3.2.2 >>>>>> > >>>>>> >> If the URI scheme defines a default for host, >>>>>> >>>>>> That's the key phrase, then. HTTP and HTTPS, which are the only >>>>>> schemes supported by UriInterface, do not define defaults for the >>>>>> host, which would make lack of a host an invalid URI for those >>>>>> schemes. >>>>>> >>>>>> -- >>>>>> Matthew Weier O'Phinney >>>>>> mweiero...@gmail.com >>>>>> https://mwop.net/ >>>>>> >>>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "PHP Framework Interoperability Group" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to php-fig+u...@googlegroups.com. >>> To post to this group, send email to php...@googlegroups.com. >>> To view this discussion on the web visit >>> <https://groups.google.com/d/msgid/php-fig/013686ad-2615-4caf-a663-f69e5bdebe2f%40googlegroups.com?utm_medium=email&utm_source=footer> >>> https://groups.google.com/d/msgid/php-fig/013686ad-2615-4caf-a663-f69e5bdebe2f%40googlegroups.com >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/5bc439e7-a532-4d7c-ab28-20c05eed3007%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
