Interfederation

[Ian Young <>]

On 9 Jun 2013, at 20:39, Tom Scavo 
<>
 wrote:

> - The eduGAIN spec requires an mdrpi:RegistrationPolicy element but no
> xml:lang attribute is required so various languages are encountered. I
> don't want to seem en-centric but what good is a registration policy
> document in a language that can't be read and/or understood? Yes, I
> realize this cuts both ways, so I don't know what to suggest.

I hadn't noticed that was the case for the RegistrationPolicy element, but 
you should note that it's optional in the eduGAIN profile anyway.  I don't 
imagine anyone would object to the metadata profile saying that if present, 
there SHOULD be a version in English.

On the other hand, the membership process also requires a policy document 
link to be submitted (which is to say, it's *not* optional) and if you look 
at the status page you will find that all but one of them are available in 
English:

http://www.edugain.org/technical/status.php

So, it's perhaps not as bad as it looks.

> - Similarly, there are other elements (e.g., mdui:DisplayName) with
> xml:lang="en" that clearly are not.

This is the sort of thing that one can help the originating registrar out 
with by suggesting the appropriate translation.  In many cases, I suspect 
that the "English" but obviously untranslated values are coming from 
automated defaulting, or registrants who don't actually speak English and are 
thus unable to provide translations.

> - Of the mdrpi:RegistrationPolicy element, the MDRPI spec says:
> 
> "The URL MUST represent a single, immutable, policy document. Any
> changes made to an existing policy document MUST result in a new URL."
> 
> I'm pretty sure I'm seeing URLs in eduGAIN metadata for which this is
> NOT true.

That may be true, but how could you tell?

> Perhaps the eduGAIN spec should explicitly call this out?

We've done this for a couple of other things where it seemed critical, so I 
don't see that it would be a problem to add that.  One can go too far in just 
copying things up from underlying specifications, though.

Incidentally, as Leif has mentioned, the metadata profile is up for vote just 
now, and it's bound in with a number of other things so it's either going to 
be accepted as it stands or rejected as part of a rejection of the whole 
bundle (vanishingly unlikely, I'd have thought).

I have spoken to Brook about this, though, and there's nothing stopping work 
on a new version beginning pretty much as soon as this version is agreed.  As 
long as such a new version did not introduce any mandatory constraints which 
existing members could not meet (i.e., as long as no member was in danger of 
being excluded from eduGAIN by a proposed change) then the process to pass 
such a revised profile towards the end of the year sounds fairly 
straightforward.

        -- Ian

Attachment: smime.p7s
Description: S/MIME cryptographic signature