There are 82 comments (sorted by their types, and the section they are about).
1-20
21-40
41-60
61-80
81-82
question comments
Comment LC-1636
Commenter: Micah Dubinko <mdubinko@yahoo.com> (archived message ) Context: 1.2 Applicability
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :1.2 Applicability
"The tests apply to a URI. Passing the tests means that under the right circumstances, resolving a URI will retrieve conformant content"
What is "conformant content"?
Related issues: (space separated ids)
WG Notes: poss needs the addition of mobileOK conformant
Resolution: Change to "mobileOK conformant content" (Please make sure the resolution is adapted for public consumption)
Comment LC-1637
Commenter: Micah Dubinko <mdubinko@yahoo.com> (archived message ) Context: 3.4 CONTENT_FORMAT_SUPPORT
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Charles McCathie Nevile
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :3.4 CONTENT_FORMAT_SUPPORT
Is the intent that all WML content is excluded from the possibility of being mobileOK? In some regions, WML devices still represent the majority of mobile UAs. To ask another way, it the intent of these tests to specifically exclude testable guidelines for WML?
Related issues: (space separated ids)
WG Notes: The answer is that if you can't respond with XHTML then no you are not mobileOK. THere's nothing stopping you providing WML in addition.
Resolution: The answer is that if you can't respond with XHTML then no you are not mobileOK. There's nothing stopping you providing WML in addition. (Please make sure the resolution is adapted for public consumption)
general comment comments
Comment LC-1608
Commenter: Loretta Guarino Reid <lorettaguarino@google.com> (archived message ) Context: 3 mobileOK Basic Tests
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Sean Owen
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :MobileOK Basic 1.0 limits itself to machine-testable properties, while
WCAG2 includes human-testable as well as machine-testable properties.
There may be occasions where MobileOK Basic tests can be used to test
all or part of a WCAG2 technique.
Related issues: (space separated ids)
WG Notes: (srowen) I'm relabeling this as a comment. I think consideration of how this may or may not apply to WCAG is out of scope.
Resolution: Leave text as is. Shadi from the EARL WG is participating in the checker activity so hopefully this will be an outcome. (Please make sure the resolution is adapted for public consumption)
Comment LC-1646
Commenter: Christoph Richter <Christoph.Richter@bwin.org> (archived message ) Context: 3.11 MEASURES
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :And btw, because of the Measures point, there is always an need to define 1px size of whatever for lines. And since we can produce for each handset the right page for their resolution we make everything in pixel…
Related issues: (space separated ids)
WG Notes:
Resolution: We accept this comment for the next version of the BP document. (Please make sure the resolution is adapted for public consumption)
typo comments
Comment LC-1647
Commenter: Bert Bos <bert@w3.org> on behalf of CSS Working Group (archived message ) Context: 2.3.4 CSS Style
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :The "not" in "style elements whose type attribute is not
"text/css"" is erroneous since the type attribute on the style
element is REQUIRED as per [2]. Maybe just a typo?
Related issues: (space separated ids)
WG Notes:
Resolution: Thanks this was a typo (Please make sure the resolution is adapted for public consumption)
Comment LC-1613
Commenter: Carlos Iglesias <carlos.iglesias@fundacionctic.org> on behalf of ERT Working Group (archived message ) Context: 2.3.4 CSS Style
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Jo Rabin
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :#5: Section "2.3.4 CSS Style" reads: "Style elements whose type attribute _is not_ text/css"
Souldn't be "Style elements whose type attribute _is_ text/css?
Related issues: (space separated ids)
WG Notes: Changed to editorial. This is a duplicate of other LCs.
Resolution: Yes, thanks, this is a typo. (Please make sure the resolution is adapted for public consumption)
Comment LC-1597
Commenter: Jo Rabin <>Context: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :the example xml declaration is missing the mandatory version attribute
Related issues: (space separated ids)
WG Notes:
Resolution: Corrected the typo. (Please make sure the resolution is adapted for public consumption)
Comment LC-1618
Commenter: Carlos Iglesias <carlos.iglesias@fundacionctic.org> on behalf of ERT Working Group (archived message ) Context: 3.7 GRAPHICS_FOR_SPACING
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Jo Rabin
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :#10: Section "3.7 GRAPHICS_FOR_SPACING" reads: "If image height and width are both less than 2 pixels, warn"
As 2x2 images are allowed ("at most 2x2" in the prose), the test should be: "If image height and width are both less than _or equal to_ 2 pixels, warn" to be in agreement with the prose.
Moreover, shouldn't also non-transparent graphics for spacing be considered?
Related issues: (space separated ids)
WG Notes: Downgraded to typo
Resolution: Thanks, we agree. (Please make sure the resolution is adapted for public consumption)
Comment LC-1663
Commenter: Jo Rabin <jrabin@mtld.mobi>Context: 3.24 TABLES_LAYOUT (partial)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :real = actual
Related issues: (space separated ids)
WG Notes:
Resolution: Thank you for your perspicacious observation, Mr Rabin. (Please make sure the resolution is adapted for public consumption)
substantive comments
Comment LC-1629
Commenter: Kai Hendry <hendry@iki.fi> (archived message ) Context: Document as a whole
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Daniel Appelquist
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Anyway it would be good if some mobile developing hints were just
implemented by a normal W3C HTML validator like http://validator.w3.org/
or Unicorn. Anyone working on that? Banging out this bureaucratic
document "W3C mobileOK Basic Tests 1.0" seems a waste of time and
resources.
You need to evolve faster.
Related issues: (space separated ids)
WG Notes:
Resolution: Thank you for your comment. We feel this is out of scope for this group as we focus on mobile specifically, and mobile is different enough from the web to warrant separate attention and tools right now. However, the reference implementation for mobileOK checker (based on mobileOK Basic Tests) may be become part of a future general HTML validation scheme if appropriate, and will hopefully replace the implementation behind validator.w3.org/mobile (Please make sure the resolution is adapted for public consumption)
Comment LC-1635
Commenter: Micah Dubinko <mdubinko@yahoo.com> (archived message ) Context: Document as a whole
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Abel Rionda
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Overall impression
The overall impression the tests give me is that, given a non-whitelisted device, the safer alternative is to exclude all CSS. This seems like the wrong impression to give mobile developers.
Related issues: (space separated ids)
WG Notes:
Resolution: No we don't see how the document supports this interpretation.
The only tests related to CSS styles are:
MEASURES: This test set a restriction on using only relative measures of length.
STYLE_SHEETS_SUPPORT: This tests searches properties such as position, display or float getting a warning in the worst case. In addition, a human test should verify if the page is readable without style sheet.
STYLE_SHEETS_USE: This test looks for elements not supported in XHTML Basic.
From these tests, we think that you cannot infer that the safer alternative is to exclude all CSS. It is only STYLE_SHEETS_SUPPORT which recommends that a page should be readable without style sheets, which is really helpful in devices not supporting them or just configured by the user in order to not use them. (Please make sure the resolution is adapted for public consumption)
Comment LC-1630
Commenter: Bruno von Niman <ANEC_W3CRep_Bruno@vonniman.com> (archived message ) Context: Abstract
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Ignacio Marin
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Comment #1: In the perspective of the above, we believe that this may be understood as
(strongly) misleading consumers, who will have other, natural assumptions about the
meaning of the trust mark. Assumably, if a mobile Web site is declared to be “mobileOK�?,
consumers will assume the trust mark to is some kind of guarantee for aspects that will mean
OK to them. In other words, it may well be assumed as a guarantee for reliable content, safe
access, and trustable connections with a fair usability and some minimum levels of
accessibility. Furthermore, depending on the consumer’s age, assumptions may even be
made about the some kind of appropriateness of the content, when accessed by young
children.
An analogy to the above is TV sets marketed as “HD ready�?. Even if this is only a declaration
of one of the TV set’s capabilities, consumers (typically uninterested in details of this and
other technologies) will naturally assume this to be a declaration of compatibility and
capabilities for receiving and displaying high definition TV broadcasts without further needs to
buy additional products (such as a set-top box) and most probably, subscriptions (that will
also imply a considerable monthly fee). Consumers are often not aware that HD displays will
only display an HD picture when connected to an HD receiver (set-top box).
This will lead to consumer disappointment and the product may even be handed back. To
continue with the analogy, “Real HD ready�? TV sets are now marketed and the situation is
becoming very confusing…what was “HD ready�?? And what may be next? False marketing
does not aid the successful uptake of new consumer technologies.
Therefore, we suggest the re-branding of the mobileOKâ„¢ and mobileOK Basicâ„¢ trust marks
in some way that reflects their true and proper meanings. Due to the complexity of the
required branding, this may be a challenging task but worth the effort. It is not our task, nor
competence area to propose alternative names that would work properly on a global market
but wording that consumers would understand may include:
• Ready for mobile use;
• Mobile device adapted site;
• This content displays OK on mobile devices.
We believe that third party provisioning (or certification) is the only way to provide a reliable
trust mark information to consumers as often, products do not match qualities declared by
manufacturers, entailing a loss of consumer confidence. ANEC therefore encourages third-
party certification.
Related issues: ISSUE-186
(space separated ids)
WG Notes:
Resolution: It is not possible to fit all of this meaning in a short brand name, and any given name will have potential problems. That is why sections 1.1.1 and 1.1.2 explain in detail what mobileOK Pro and mobileOK Basic mean. We'd welcome better terms, but as you say you don't have a better idea.
We have to choose something, and the names "mobileOK Basic" and "mobileOK Pro" were selected as the most appropriate ones, as they are fairly universal, short, and do not directly imply incorrect interpretations. "mobileSafe" would have been a poor choice for example. "mobileOK" itself seems to address the three points you believe consumers should understand.
mobileOK Pro will be third-party certified. We believe that specifying *only* third-party-certified trustmarks will severely limit adoption, to the point that concerns about consumer understanding are moot. Hence a the machine-verifiable "mobileOK Basic" trustmark exists. (Please make sure the resolution is adapted for public consumption)
Comment LC-1639
Commenter: Micah Dubinko <mdubinko@yahoo.com> (archived message ) Context: Status of this Document
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Abel Rionda
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :3.10 LINK_TARGET_FORMAT
Should this mention non-200 responses? 404, 500, etc..? In the case where the linked resource is a form submit with method="post", a GET request might properly fail.
Related issues: 192
(space separated ids)
WG Notes: Discussed on call 29th March resulting in Kai's ACTION-460, ISSUE-192
Also note that the specific point raised needs answering viz: post method is allowed but not tested so the specific example is out of scope.
Sean has a compromise proposal (in minutes for 12 April) but we need to check this with Kai.
Resolution: Yes, we will mention non 200 responses.
No we do not test form submit with method POST, and this is covered in section 2.3.7 (Visible linked resources)... (Please make sure the resolution is adapted for public consumption)
Comment LC-1585
Commenter: Timo Skytta <timo.skytta@nokia.com>Context: 1 Introduction
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Hi,
This is kind of a stupid feedback, but I think I should mention it since
I have
now faced the problem several times.....
I have gotten a lot of feedback from people who have misunderstood that
the MOK Basic
test doc is setting requirements for a mobile web browser, like for
example people are
wondering why in 2.3.2 http://www.w3.org/TR/mobileOK-basic10-
tests/#http_request
we define such a limited HTTP Request etc....
So I have had to explain people that this doc is about defining how a
web site can be tested
for it's ability to deliver content based on the limitations set forth
by DDC and selected BPs
we chose to test. Meaning that the doc is about how to exercise a web
site with an imaginary
DDC client which MOK tester pretends to be to see if indeed the web site
can deliver MOK
content. Also I needed to make it clear to them that the doc is NOT
about testing a mobile
browser for MOK or setting any requirements to a mobile browser.....
I wonder if we should somewhere in the doc, like on the Abstract or on
the Introduction make it
clear that MOK is not about testing a mobile browser or setting any
requirements for it, but it is
about testing a web site and setting requirements for it.
Or maybe people providing me feedback are ignorant enough not to read
the doc in enough details...
-------------
Jo Rabin says:
I agree that if this is a common misconception then that misconception
should be put to rest. However, I think that what is missing is mainly a
statement of what mobileOK _is_ rather than a statement about what it is
_not_.
Also under 1.3 Claiming mobileOK conformance, we say "mobileOK does not
imply endorsement or suitability ... or is appropriate for children".
That statement is actually out of place (in that it is not about
claiming mobileOK conformance), so we should move it and put it with a
"not user agent test" disclaimer, to a proper section.
I think the right place is in section 1 Introduction. I suggest:
Current Text:
This document describes W3C mobileOK Basic tests, which are based on
Mobile Web Best Practices [BestPractices].
mobileOK Basic is the lesser of two levels of claim, the greater level
being mobileOK (W3C mobileOK?), described separately. Claims to be W3C
mobileOK Basic are represented using content labels, also described
separately.
The intention of mobileOK is to help catalyze development of Web sites
that provide a functional user experience in a mobile context.
Proposed Text:
mobileOK is a scheme for assessing whether Web resources (Web pages) can
be delivered in a manner that is conformant with Mobile Web Best
Practices [BestPractices].
This document describes W3C mobileOK Basic tests. mobileOK Basic is the
lesser of two levels of claim, the greater level being mobileOK (W3C
mobileOK?), described separately. Claims to be W3C mobileOK Basic are
represented using content labels, also described separately.
The intention of mobileOK is to help catalyze development of Web sites
that provide a functional user experience in a mobile context.
mobileOK does not imply endorsement or suitability of content. For
example, it must not be assumed that mobileOK content is of higher
informational value, is more reliable, more trustworthy or is
appropriate for children.
mobileOK is not a test for user agents and is not intended to imply
anything about the way that user agents should behave.
---------------------
Yes, thanks, I think there is an important aspect of Sean's proposal
that I missed out which is that the DDC needs significant mention. I
don't think that the tests 'emulate a request' as such. Rather they
describe how to emulate the DDC when making a request and how to assess
content delivered as a result.
So forgive me but I have a further elaboration:
Proposed Text:
mobileOK Basic is a scheme for assessing whether Web resources (Web
content) can be delivered in a manner that is conformant with Mobile Web
Best Practices [BestPractices] to a simple and largely hypothetical
mobile user agent, the Default Delivery Context [DDC].
This document describes W3C mobileOK Basic tests for delivered content,
and describes how to emulate the DDC when requesting that content.
mobileOK Basic is the lesser of two levels of claim, the greater level
being mobileOK (W3C mobileOK?), described separately. Claims to be W3C
mobileOK Basic are represented using content labels, also described
separately.
The intention of mobileOK is to help catalyze development of Web content
that provides a functional user experience in a mobile context. It is
not a test for browsers, user agents or mobile devices, and is not
intended to imply anything about the way these should behave.
mobileOK does not imply endorsement or suitability of content. For
example, it must not be assumed that mobileOK content is of higher
informational value, is more reliable, more trustworthy or is
appropriate for children.
Related issues: (space separated ids)
WG Notes: Inserted in 1x
Resolution: Resolved on Feb. 8 to adopt Jo / Phil's proposed text. (Please make sure the resolution is adapted for public consumption)
Comment LC-1606
Commenter: Loretta Guarino Reid <lorettaguarino@google.com> (archived message ) Context: 1.1 Levels of mobileOK
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Jo Rabin
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :We are concerned that the statement "Content which passes the tests
has taken some steps to provide a functional user experience for
users of basic mobile devices whose capabilities at least match those
of the Default Delivery Context (DDC)." would lead authors to conclude
that these guidelines will also meet the basic functional needs of
users with disabilities who use basic mobile devices. here is much in
common but these guidelines do not cover all of WCAG. We recommend
adding "To accommodate users with disabilities, WCAG should also be
met.", or "You should follow other guidelines that are applicable to
Web content, including the Web Content Accessibility Guidelines."
Related issues: ACTION-440
(space separated ids)
WG Notes: from call of 8 mar suggest adding the text: Note that other guidelines are applicable to the development of Web content. Note that there is more than one place wehre this caveat belongs
relates to ACTION 440
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/440
Resolution: See http://lists.w3.org/Archives/Member/member-bpwg/2007Mar/0176 for updates following from this comment. (Please make sure the resolution is adapted for public consumption)
Comment LC-1631
Commenter: Bruno von Niman <ANEC_W3CRep_Bruno@vonniman.com> (archived message ) Context: 1.1.4 Beyond mobileOK
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Ignacio Marin
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Comment #2: The above is a valuable statement to developers but, again, misleading to
consumers, who should understand the trust mark in the right way.
Related issues: (space separated ids)
WG Notes:
Resolution: We feel that enough caveats have been given earlier in the document to cover this (Please make sure the resolution is adapted for public consumption)
Comment LC-1607
Commenter: Loretta Guarino Reid <lorettaguarino@google.com> (archived message ) Context: 2.2 Testing Outcomes
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :We like the similarity in approach to the descriptions of these test
and WCAG2 techniques. For MobileOK Basic Tests 1.0, the tests are
written in "programmatic" style. Test outcomes for MobileOK Basic 1.0
tests are pass, fail, and informative warnings. WCAG2.0 test outcomes
are "true", or "false". It would be worth exploring whether we could
use consistent language.
Related issues: (space separated ids)
WG Notes: (srowen) It's a fair point. I personally think "pass" and "fail" make much more sense as test outcomes than "true" and "false", so, not sure why WCAG decided to use those terms.
Resolution: Consistency is important, all else being equal, but here we believe that "pass" and "fail" are more understandable as test outcomes. The EARL specification also uses these terms, and we would also like to remain consistent with EARL. (Please make sure the resolution is adapted for public consumption)
Comment LC-1611
Commenter: Carlos Iglesias <carlos.iglesias@fundacionctic.org> on behalf of ERT Working Group (archived message ) Context: 2.2 Testing Outcomes
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Jo Rabin
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :#3: Section "2.2 Testing outcomes"
The MWBP group have know made clear that warnings are _no_ test outcomes but it was also said that the group do not want to specify _which_ warning may be generated. In order for the tool developer to create a reasonable warning, it would help him to know at least the specific purpose why a warning has to be generated.
Related issues: (space separated ids)
WG Notes: My own position is that I think that this is a good idea, but we did discuss this point in Gijon and both Dom and Chaals were against it.
I suppose that the checker reference implementation will supply this information. So I don't see the harm in writing it in the mobileOK doc.
Resolution: The checker will provide a reference implementation of what the warning/error text should be for each warning or error, also linking back to appropriate reference material. (Please make sure the resolution is adapted for public consumption)
Comment LC-1632
Commenter: Bruno von Niman <ANEC_W3CRep_Bruno@vonniman.com> (archived message ) Context: 2.3 Conduct of Tests
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Ignacio Marin
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Comment #3: In addition to the above information recommended for provision, the consumer
should be informed about the reason of failure in an understandable way. Additional
information relating to other functionalities should also be provided. Furthermore and in
addition, a technical reason or code may be provided to help the operator or creator of the
implementation to identify the source of the error.
Last but not least, consumers should be able to contact customer services through a single
point of access per modality (e.g. by calling the “usual�? number for all issues).
Related issues: (space separated ids)
WG Notes:
Resolution: mobileOK Basic Tests is not a consumer facing product. It's up to mobileOK checkers to provide informative error messages. Where it is not clear what the point of a FAIL is we will consider additional information (Please make sure the resolution is adapted for public consumption)
1-20
21-40
41-60
61-80
81-82
Add a comment .