<div dir="ltr"><div>On Wed, Nov 21, 2018 at 4:04 PM marc marc <<a href="mailto:marc_marc_irc@hotmail.com">marc_marc_irc@hotmail.com</a>> wrote:</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I already have trouble imagining that there are mobile apps so badly <br>
made that it asks the user to transcribe the parking ref instead<br>
of finding it by geolocation<br></blockquote><div><br></div><div>Then you have not tried as many badly-designed apps as I have.  None of them were for parking,</div><div>but they were all badly designed.  Anyway, a parking app might offer alternatives to geolocation for</div><div> those with stupid phones rather than smart phones.  And for people who prefer not to face a parking</div><div>fine because bad weather meant they couldn't get a GPS lock.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
but for those apps, it seems more convenient to me to use<br>
payment:<appname>=<the number the app need><br></blockquote><div><br></div><div>That's one possibility.  It is better than ref=12345 and  you have to guess whether or not that</div><div>ref is an SMS payment number, and whether you send an SMS to 12345 or you send an SMS to</div><div>some other number quoting 12345 in the body.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<about a different ref for each payment method><br>
> ALL of them might be possible<br>
<br>
might ? of course ! but does this situation exist or it's it's purely <br>
fictional ?<br></blockquote><div><br></div><div>All of them might be possible because older technology hangs around.  And some people don't</div><div>adopt new technology.  So it may be possible to pay by SMS because that was set up years ago</div><div>and some people don't have phones capable of anything better.  It may be possible to pay by app,</div><div>but some people may not have the app installed and the signal may be too weak to install it at that</div><div>moment.  It may be possible to pay by NFC, but not everyone has a phone with that capability.  So</div><div>all of those alternatives might be possible at the same car park, along with machines accepting coins</div><div>and debit cards.  Coin payments are likely to go away in the future because they're a temptation to</div><div>break into the vending machines but other payment methods will hang around a lot longer.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
of course we can put several ref:<target1> ref:<target2> on all parking <br>
of the planet just in case another entity would designate this parking <br>
lot with another ref... but if the majority of car parks have only one <br>
reference, their operator's ref, it seems to me to bring no advantage to <br>
use several ref:*=* over using ref=* without suffix and add suffixes <br>
only when necessary.<br></blockquote><div><br></div><div>I wasn't suggesting tagging every possible option in advance.  Just anticipating what might happen</div><div>in the future by not overloading the already-overloaded ref=*.  Operators do have unique references</div><div>for car parks.  Several payment options may be available.  Using ref=* on a first-come, first-served</div><div>basis is not helpful ("Of course it means the SMS number because I mapped that first and added</div><div>NFC later.")  If we're going to have ref:*=* for other payment methods it makes no sense to</div><div> appropriate ref=* for just one of those methods, especially when ref=* is better reserved for the</div><div>operator's unique reference for the car park (if there is one).  We shouldn't have to GUESS what</div><div>a bare ref=* means for any particular car park, which is what you appear to be suggesting.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In this case, the suffix should be the same between the payment key<br>
and the ref key like payment:sms=yes with ref:sms=*<br>
not payment:sms=yes with ref:payement-by-sms=*<br></blockquote><div><br></div><div>That seems sensible.  What I wouldn't want to see is "ref=12345 means the pay-by-sms reference</div><div>UNLESS it means the operator's unique reference and you'll have to guess which it is."  Nor do I</div><div>want to see "ref=12345 is the pay-by-sms reference but ref:nfc is the pay-by-nfc reference because</div><div>we didn't anticipate future needs and anyway a foolish consistency is the hobgoblin of little minds."</div><div><br></div><div>-- <br></div><div>Paul</div><div><br></div></div></div>