Non-namespace aware Yadis file parsing

[Johannes Ernst]

Dan raised the issue of namespaces in the Yadis file. I've been  
giving it some thought, in particular whether we require implementors  
to truly process them all under all circumstances, or we think people  
might get aware of namespace-unaware XML parsing, or even regexes.

It appears to me that if we don't require full XML parsing on the  
other end,
  - there may be security problems (relying parties may mis-interpret  
the content of a Yadis file)
  - there may be interoperability problems (because it's hard to test  
against a spec -- for "restricted namespaces a la Yadis conventions"  
-- that doesn't exist)
  - there may be substantial extensibility problems (e.g. can't  
insert CDATA into Yadis files, may conflict with other namespaces in  
the future etc.)

So the conclusion I have come to so far is that we got to require  
full namespace support.

Does anybody agree or disagree with that?


On May 19, 2006, at 10:26, Dan Lyke wrote:

> A general note. Johannes has forwarded some questions about the  
> test to me, and I've answered some directly. The "why don't you  
> like my YADIS URL?" questions so far seem to boil down to two issues:
>
> 1. XML namespaces. There'll be a version along shortly which warns  
> when it finds a "Service", "URI" or "Type" element in a namespace  
> that isn't the one associated with 'xri://$xrd*($v*2.0)', but as a  
> general practice I'd suggest just using the template in the spec  
> rather than trying to get too fancy with namespaces, if only to  
> save some trouble for the poor soul who thinks they can get away  
> with implementing a relying party parser with regular expressions.
>
> 2. Returning the YADIS document as a mime-type that isn't  
> 'application/xrds+xml' when 'appplication/xrds+xml' is included in  
> the initial "Accept" headers. My interpretation of the spec is that  
> it's okay to serve the YADIS document as a different MIME type if  
> you use one of the redirection methods and offer that up from a  
> separate URL (although users who find themselves unable to specify  
> a proper MIME type for a served document should discuss this with  
> their sysadmins, a sledgehammer should be unnecessary but is  
> recommended), but sections 6.2.5 and 6.2.9 are pretty plain that if  
> that initial URL serves up a YADIS document it had better be  
> application/xrds+xml.
>
> (Of course now I need to go double-check that we're not checking  
> the MIME type when we do subsequent requests to a different URL,  
> and we should still warn if we find a conflicting MIME type.)
>
> This has also been an interesting exercise for me because normally  
> when I implement this sort of code I use the spec as a rough  
> guideline and the existing implementations as my final test. If I  
> can tweak my code to handle input more flexibly, that's good. In  
> this case I'm trying to make the spec the final arbiter, and as we  
> find exceptions in other implementations build heuristics to try to  
> inform people about why this bit of code doesn't like it rather  
> than extracting the data where-ever we can.
>
> And I've also no illusions that my reading of the spec and  
> implementation in this code is the final arbiter, I've already  
> discovered two pretty embarassing omissions (Josh pointing out the  
> missing "x" in application/xrds+xml,  and the fact that you can  
> have one *or more* <Type>s per <Service>). And if my first response  
> to your concern seems a little boneheaded, press harder. It could  
> be that I'm being boneheaded.
>
> I now return to my usual 3d graphics programming...
>
> Dan

Johannes Ernst
NetMesh Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20060519/ecd23e27/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst