--- a/spec/identity-respec.html	Fri Nov 23 12:02:34 2012 -0500
+++ b/spec/identity-respec.html	Fri Nov 23 14:51:44 2012 -0500
@@ -383,7 +383,7 @@
 <dd>A Service is a an agent listening for requests at a given IP address on a given Server.</dd>  
 
 <dt><tdef>WebID</tdef></dt>
-<dd>A WebID is a URI with an HTTP or HTTPS scheme, containing a URI fragment identifier (i.e. a # symbol) and which uniquely denotes an Agent (Person, Organization, Group, Device, etc.). The URI without the fragment identifier denotes the WebID <tref>Profile page</tref>.
+<dd>A WebID is a URI with an HTTP or HTTPS scheme which uniquely denotes an Agent (Person, Organization, Group, Device, etc.). This URI SHOULD include a fragment identifier (a string after a "#" character). The URI without the fragment identifier denotes the WebID <tref>Profile page</tref>.
 </dd>
 
 <dt><tdef>WebID Profile</tdef> or <tdef>Profile Page</tdef></dt>
@@ -422,7 +422,7 @@
 <p>For example, if a user Bob controls <code>https://bob.example/profile</code>,
 then his WebID can be <code>https://bob.example/profile#me</code>.</p>
 
-<p class="issue">Due to legacy support for URIs which do not contain URI fragment identifiers, verifiers MUST NOT fail when dereferencing hashless URIs, though they MAY flag them as potentially impacting on performance. Implementors need to take into account that the use of hashless URIs is deprecated and they must be avoided when creating new WebIDs.</p>
+<p class="note">Implementers are highly encouraged to use hash URIs for the WebID HTTP URI. Even though 303 redirects can be used instead, experience has shown that they can be difficult to deploy and can have an impact on performance. However WebID Verifiers MUST NOT fail when dereferencing hashless URIs, though they MAY flag them as potentially impacting on performance.</p>
 
 </section>