Comments on Architectural Principles draft

Referring to the August 30 text (http://www.w3.org/TR/2002/WD-webarch-20020830/)

> 1.3. Limits of this document
> 
>          This document focuses on architectural principles specific to or fundamental to the Web. It does not address general principles of
>          design, which are also important to the success of the Web. Indeed, behind many of the principles of Web Architecture lie these
>          and other principles such as minimal constraint (fewer rules makes the system more flexible), modularity, minimum redundancy,
>          extensibility, simplicity, and robustness.

I think this would be the place to cite RFC 1958 "Architectural 
Principles of the Internet". We did cover a number of general
principles in that document, as they apply to the Internet, and
certain specific principles that the Web can't help but inherit.

> 1.5. Summary of good practice notes
> 
>          This document suggests the following good practice:
> 
>               1. Do not rely on URI case insensitivity: 
>                    It SHOULD NOT be assumed that URIs which differ only in character case can be used interchangeably. 

I understand that you don't want to go into internationalisation
in depth in this document. However, I think you need to mention
the issue here, since it is more than just case. It's tricky to say
in a few words, but something like this:

  Similarly, it SHOULD NOT be assumed that URIs represented in multi-lingual
  characters that resemble each other can be used interchangeably.

> The syntax of URIs and absolute URI references is defined in [RFC2396]

updated by [RFC2732].

(Larry said a while back that the contents of 2732 need to be integrated
in a revision of 2396, but for now you need to cite both.)

> Issue: deepLinking-25: What to say in defense of principle that deep linking is not an illegal act?

I think you should refer to Larry Lessig's arguments about fair use
provisions in the copyright laws.

> 2.6. Some generalities about absolute URI references
> 
>          The following generalities about absolute URI references are included to answer some frequently asked questions about URIs. Some of these
>          generalities do not hold for all URI schemes.
> 
>             1.The authority over an absolute URI reference determines which resource it identifies. 
>             2.It is not possible to inspect an absolute URI reference and determine what resource it identifies. For example, in general, one cannot look at
>               http://www.example.com/lj45sr and know that it refers to "my old car" or "the weather forecast for Oaxaca." 

or even that it has anything to do with a company called "example."

> 4. Protocols

I really don't understand where this section is going. How does it relate
to SOAP and Web Services, where most of the protocol action is?
SOAP is not bound to HTTP, and I would expect HTTP to fade in importance
as SOAP bindings over other protocols start to be used (I'm thinking
about timescales of years here).

> The REST constraints are:
> 
>          Client/server model 

This is a restrictive model. The interesting model is a generic
peer model, of which client/server is a degenerate case.

> 4.2. Ideas and issues
> 
... 
>             3.HTTP as a substrate protocol [TAG issue HTTPSubstrate-16] 

You need a reference to RFC 3205. 

    Brian

Received on Monday, 9 September 2002 09:13:03 UTC