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

[Nick Roy <nroy AT internet2.edu>]

On 25 Sep 2019, at 1:48, Stefan Winter wrote:

> 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.

SAML metadata is the protocol I’m talking about here, not XML. Metadata 
should be conservative in what it "sends", if there is a breaking difference 
between an old and new version, what is "sent" should be in the intersection 
of compatibility. Metadata clients that break in the case where something in 
metadata is outside the intersection should be fixed so that they don’t break 
in that case.

Nick

>
> 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: signature.asc
Description: OpenPGP digital signature