An open discussion list for topics related to the eduGAIN interfederation service.

[Stefan Winter <stefan.winter AT restena.lu>]

Hi,

> "A protocol should be conservative in its transmissions and clients should 
> be liberal in their acceptance of incoming messages." or words to that 
> effect. - Jon Postel.

Thanks for recalling to us the wisdoms of Jon Postel.

Those words are mainly used to make decisions in protocol design, e.g.
when there are code points in a protocol "reserved for future use". A
sending implementation should not use them unless that future use is
defined, and rather stick exactly to what is specified (that's the
"conservative in sending" part) and a receiving implementation should
not take offence if such code points are seen on incoming data even if
it does not understand them (the code point may meanwhile have been
defined, but the receiving end didn't get the news yet).

This usage mechanism doesn't apply here. XML 1.0 First Edition was
clearly *forbidding* the use of an empty lang tag; later editions were
explicitly *allowing* it. There is no leeway of interpretation here.

Even in the IETF, where Jon's principle emerged, a clear violation of a
spec is generally a totally fine justification to discard a packet.

That's why protocols are often designed with a viable upgrade path so
that new versions don't wreak havoc on a deployed base.

Sometimes that's not possible, and yes, then people have to upgrade to
remain in the game. To give an example, what used to be the simple RFCs
821/822 on email syntax and transport has changed very significantly
over time, and an implementation only adhering to those ancient original
specs will not have a good time today; chances are that email from such
systems gets classified as spam for not adhering to up-to-date
refinements of the specs (so much for being liberal on reception in that
particular domain).

Now I absolutely don't want to judge whether the jump from forbidden to
allowed, without backward compatibility guidance, was unavoidable in the
XML spec creation process (TBH, a version identifier "1.1" to handle
this as an easy test by recipients comes to mind). What I do see is that
this was a backward incompatible change and we have to live with that.

Looking at the timing of the specs, I have trouble having sympathy with
Shibboleth here. XML 1.0 allowed empty lang tags from 2004 onwards.
SAML2 was finalised in 2005. When writing an implementation of SAML2,
there was never any time window where using an earlier XML spec was
justified. I.e. a day one bug, which (unluckily) wasn't noticed early
when the deployed base was small to non-existent.

I certainly see that it is hard to update a large deployed base. Ask
every email admin out there how often they have to cope with new strides
to keep their email servers whitelisted, DNS entries up-to-date etc.

Can we maybe get a statement from the Shibboleth consortium that they
will update their XML spec ASAP? Did someone open a bug report yet,
maybe with a reply?

My suggestion would be that we see how long it will take to "wither out"
the problem. Once the oldest version with a 2001 variant of XML goes out
of official support by the consortium, that would be a day where we can
clear the use of empty lang tags, if we want that at all. Until then,
the corresponding metadata should ideally be marked as "having a
sigificant interop risk" or similar during import.

If we do not have any intention to support empty lang tags (there are
reasons to allow them, IMHO, but that would be a different thread) then
we can put that in paper and subsequently reject incoming metadata with
that inside. Doing away with empty lang tags as "something that makes no
sense at all" is IMHO a non-argument. BCP47 does not read as nonsensical
to me; it is a document that got a real lot of scrutiny by many clever
protocol people.

Greetings,

Stefan Winter

> 
> Nick
> 
> On 23 Sep 2019, at 16:32, Peter Schober wrote:
> 
>> * Tomasz Wolniewicz <twoln AT umk.pl> [2019-09-23 22:12]:
>>> eduGAIN validator was using a newer xml.xsd and the validation passed.
>>>
>>> So what is the correct approach here?
>>
>> As I said, the current Shibboleth SP release fails to load such
>> metadata. Sure, we can try to get that changed upstream and then wait
>> a few years until it's deployed everwhere where a Shib SP is running
>> today, hoping such XML will never occur in the meantime. And even when
>> it does and things break (SPs failing to update, leading to expired
>> metadata days or weeks later) we can still tell the SP owners that
>> we've let this error (or "former error") through on purpose because we
>> don't consider it an error any more and they should get their software
>> fixed. Let's see how that goes.
>>
>> Or... we could be as conservative as possible in what we publish to
>> avoid any such breakage (to me that means not being liberal in what I
>> accept, too), esp. in cases that make no sense at all (such as empty
>> xml:lang="" XML attributes or other effects of improper tooling or
>> human errors, not concious decisions that the XML should in fact look
>> exactly like that).
>>
>> But I've already made those choices for my (or our federation), it's
>> up to us all to decide how the MDS should behave being the man in the
>> middle. If the MDS allows it that doesn't mean we can't filter it out
>> in our local feeds, that merely raises the bar a bit further what it
>> means to particiate in eduGAIN for member federations.
>>
>> Cheers,
>> -peter [ offline for the next days ]


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

Attachment: 0xC0DE6A358A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature