Question on DIAL URL

[pramodkvarma]

@vrayulu within the documentation, I see that you have provided https://diksha.gov.in/DIAL/v1/WYG392 as the DIAL code URL in DIKSHA DIAL registry. Is this real URL? I am getting the following response

{"id":"api.error","ver":"1.0","ts":"2021-12-16 06:04:10:740+0000","params":{"resmsgid":"fcb15340-5e35-11ec-9b60-fddd9f867d03","msgid":null,"status":"failed","err":"FORBIDDEN_ERROR","errmsg":"Forbidden: API WHITELIST Access is denied"},"responseCode":"FORBIDDEN","result":{}}

Is this because the DIAL code is invalid? Or is it because of some access issue of this GET URL within DIKSHA?

[vrayulu]

@pramodkvarma - it is not the correct URL. The correct URL is in the format "https://diksha.gov.in/DIAL/6J19XQ" (without the version number). I will update the documentation.

There is a small niggle in the current implementation that needs to be addressed and wanted to update the spec after we have a solution for it:
The current implementation in DIKSHA DIAL registry (and Sunbird DIAL) is in such a way that when the DIAL url (e.g.: https://diksha.gov.in/DIAL/6J19XQ) is accessed, the user is redirected to a web page that renders the linked content. This was done to enable QR codes to be consumable by any QR scanning app.

I am thinking of the following approach for this:

• Spec defines two URLs to be provided by the DIAL registry:
  1. URL that returns a human consumable web page (https://diksha.gov.in/DIAL/6J19XQ)
  2. URL that returns a machine consumable JSON-LD response. This URL can be of the form "https://diksha.gov.in/DIAL/6J19XQ.json"

It enables the following:

• all the generated QR codes so far remain usable
• any QR scanning app can also be used to scan the DIAL codes and render the default web page provided by the registry
• third party DIAL consumption apps need to append ".json" extension to the DIAL URL to get the data in JSON-LD format

Does this solution look fine? Please share your thoughts/suggestions.

[pramodkvarma]

With respect to URL, my suggestion is to remove version number from URL then. Since schema version is already there inside, do we need it in URL?

[vrayulu]

Yes, we dont need the version number in the URL, will remove it.

[pramodkvarma]

OK great!

[pramodkvarma]

With respect to the human viewable vs machine readable, can we use HTTPS header (accept-... type header) to indicate to the registry that it should return the schema JSON. If that header is missing, simply return human viewable version. That way we don't need to do anything with current implementation within Sunbird-ED. But, if appending .json at the end is easier, let us go with that idea. We need to fix Sunbird DIAL registry to respond to this so that DIKSHA is upgraded for this purpose.

Can you trigger a ticket within Sunbird DIAL (Sunbird-ED code?) repo to get this fixed? Should be a minor fix I presume and will not have any implications to current app/portal since this new header or .json at the end is anyway not used today.

In the long run, we should decouple the registry function vs the app showing linked content. That way, registry always returns the resource descriptor schema and Sunbird-ED app decides what to do with it. What do you think?

[alok-os]

@pramodkvarma - for long term, I am wondering if we let DIAL registry to enable a default App experience (can be a configuration option). That way if user scan QR code using any scanner App - they still get to experience a default browser based App experience (what Diksha does right now). The DIAL spec compliant Apps can use use accept construct you have suggested to get resource descriptor and in case App is not able to provide relevant user experience based on DIAL resource descriptor - they also have an fall back option to direct user to default browser based App enabled thru DIAL registry

[pramodkvarma]

@alok-os This is taken care through http header. When the specific header is not passed current behavior of user being taken to a page continues for Sunbird-ED. For other registries they can choose to respond in their own way showing a user friendly page. When header is passed (DIAL apps should do this ideally) registry returns the JSON containing resource descriptor.

@vrayulu correct me if I am wrong.

[vrayulu]

That is correct. both the options exist for apps to use based on the header value is sent or not sent.

[vrayulu]

HTTP header accept is a better idea than the extension .json extension. It gives us the flexibility to swap human-readable response with machine-readable response in future. I will follow up with Sunbird team to enable the support for accept header (will be a fairly small change).

yes, the DIAL registry should return only resource descriptor schema in the long run. basic QR scanning apps will show only JSON data when users use it to scan the codes, but I think it should be fine. Will schedule to address this also in Sunbird-Ed.

[pramodkvarma]

Great! Then two action items:

1. Update spec to indicate the necessary header attribute.
2. Fix Sunbird-ED DIAL registry code to respond with pure JSON when this header is present so that DIKSHA gets a fix for this soon.

@vrayulu please action it. Thanks.

[alok-os]

@vrayulu - for immediate need - does the fix required only in Sunbird-ED (WebApp) or also in Knowlg components

[pramodkvarma]

Not sure where this is implemented. Maybe we can talk offline and figure out.

[vinukumar-vs]

@vrayulu

• Is anybody can access any dialcode context? The user/creator can define is the context should be available for public or private?
• If the dialcode is linked to draft content or textbook unit which is not yet published (or not present in v1 version of the published book). What is the expectation here? Krishnaj20 kameshbhr

@pramodkvarma

[pramodkvarma]

I suppose this can be left to the DIAL registry to handle not the specs. Does that make sense?

[vrayulu]

Yes.. Agree @pramodkvarma . Specs will only define the data model and URL specification. Access rules should be part of the registry implementation.