No-follow-ref parameter question from Wil

["Drummond Reed" <drummond.reed@cordance.net>]

Wil (cc'ing the XRI list so this can be discussed there),

We covered two of your three suggestions below on today's XRI TC call but
did not finish on #3, the on about "no-follow-ref" processing instruction.

While I think I understand your rationale, it seems to me that the standard
behavior for client-side resolvers is going to be to follow refs subject to
some reasonable time-out or iteration limit. So the no-follow-ref parameter
should only be needed for server-side lookahead resolvers.

If so, I'd much rather have them specify their "no-follow-ref" policy
locally than for them to expect all their clients to know that they need to
explicitly ask for refs to be followed.

So that's my .02. If you can explain in more detail why you think the
default should be no-follow-refs, I'm happy to listen.

=Drummond 

-----Original Message-----
From: Tan, William [mailto:William.Tan@neustar.biz] 

Questions:

1. Wouldn't the "append" attribute make more sense as an attribute of
the URI element? It allows XRD author to lump different URIs capable of
processing the same Service but requiring different construction rules
together in a single Service element.

2. It seems confusing that the Service element could have a nullPath /
nullType attribute and yet contain a non-null Path and Type element. The
same can be achieved with a "null" attribute in the Path and Type
elements, no?

3. Does it make sense to reverse the logic of the "no-follow-ref" PI?
That is, by default the resolver does not follow Ref's unless
specifically instructed to do so with the "follow-ref" PI. I feel that
while standardizing nested XRD is a good idea, it would be practical to
leave it as an enhancement. For example, the OpenXRI code base already
has the ability to process external synonyms (redirects), so if the
default behavior is to *not* return nested XRDS, there is a lower entry
barrier for apps wishing to convert from 2.0-cd01.

=wil