[standards-jig] software version
richard at dobson-i.net
Tue Jul 29 08:37:40 UTC 2003
> >>A namespace is for grouping elements and attributes that belong
> >>Adding a new element, while not changing the others, in general doesn't
> >>break backwards compatibility at all.
> >>If you change something to the namespace so that semantics change in a
> >>fundamental way or documents that used to conform are now illegal,
> >>would be a reason to use another namespace.
> >Who decides what change constitutes a "fundamental" change?
> The owner of a JEP, I would say. For an informational JEP, I would say
> the author. For a standards-track JEP, I'd vote the standards-jig as a
> whole. In either case, the changes should be re-approved by the council.
I agree, although IMO a fundamental change to a namespace such as this would
be to alter/remove the existing elements in such a way that they could not
be processed by a non-updated client. So if you are just adding an extra
element it should not hurt any correctly coded clients, it certainly should
not cause them to crash or malfunction, any that do have serious
problems/bugs and should not be used, so IMO we should not be trying to work
around any potensially badly coded software, it is upto the developers of
that software to fix it.
> Implementations that improperly implement a spec should not be worked
> around for standards-track JEPs. Of course the author of an
> informational JEP can do what they wish, since they are just documenting
> 'the way things are' - informational JEPs (at least should) describe
> existing systems, so this change supposedly already happened.
Exactly if a client crashes because an unexpected element has been added to
a namespace without altering existing elements then IMO it is very badly
coded and we should not be worrying too much about those because properly
coded clients would be fine and should ignore the extra element (or if they
want to be super secure drop or bounce the packet because it doesnt match
what it thinks is the schema for that element). The reason I say this is
what happens if someone maliciously sends you an altered packet?? It
certainly shouldnt crash a client, it should handle it and continue on
running otherwise this sort of bug in a client is as bad as leaving a buffer
overrun in, and any clients with these sort of bugs should definately not be
More information about the Standards