3 tier, 3 layer, MVC, a more 'thorough' comparison

Many comparison of the 3-xxx v.s. MVC on the web, I am trying to make a more thorough summary here:

1. 3-tier (physical architecture) is different from 3-layer (logical architecture) as Martin Fowler (PEAA, Chap1 "The Evolution of Layers in Enterprise Applications") and many others pointed out. 


2. So it is really the comparison between 3-layer (principally, Presentation, Domain Logic and Data Source layers (PEAA Chap1 "The Three Principal Layers") ) and the MVC

- Presentation Layer is similar to View, most would agree

- Model and Control is bit more ambiguous to map to Domain Logic and Data Source layers.

----- Not the actual data source (such as the actual DB or JMS) but data accessing 'sub-layer' (such as DAO) of the 'Data Source' layer can be mapped to part of 'Model' in a small system. In a large system, 'Data Source' layer could be separated from the entire 'MVC' and the Model of the 'MVC' will only contain logic for 'internal representation of data' that the 'View' can understand (e.g, similar to a 'Data Transfer Object' (PEAA, "Core J2EE Pattern'))*.

----- So therefore most things in Domain Logic belong 'Model' and 'Control', doesn't it?  Not necessarily, here is the trickier part: 


--------- We don't seem to agree on where the core part of 'Domain Logic' - the so-called 'Business Logic' should be, 
----------------A. Some say in Model (http://forums.asp.net/post/1380219.aspx) 
----------------B. Some say in Control (http://stackoverflow.com/a/698250)
----------------C. Some say in neither but a separately logical location (http://stackoverflow.com/a/9749694, http://stackoverflow.com/a/4577672) and leave the Control skinny and dumb (e.g. only for http request processing and parameter extracting)** -> this is perhaps the more common practice, especially in the large enterprise system, where 'Application Services' encapsulating business logic and can be called remotely through 'Service Facade' and 'Business Delegate' ("Core J2EE Patterns");


- You also hear people say that MVC could be an architecture for just the Presentation Layer of larger systems. Well it's probably true if you consider * and **; 

- Another well quoted explanation to the difference, rather a little too superficial and misleading to me, is that

"
Conceptually the three-tier architecture is linear. However, the MVC architecture is triangular: the view sends updates to the controller, the controller updates the model, and the view gets updated directly from the model.
"
(http://en.wikipedia.org/wiki/3-tier_architecture#Comparison_with_the_MVC_architecture)

I found it is a bit misleading as it sounds like if you do an Update operation, it has to go through the Control, but if you do a Retrieval operation, you don't. 
Nevertheless, if you have a 'Front Controller' (PEAA, "Core J2EE Patterns") as part of your control as your frontline to all requests, which most business systems that are open to web request do nowadays, either Update or Retrieval operation, you will need to go through the Control. 
 It probably better to say that 'The view sends update to controller (e.g. press the Buy button), the controller update the model (e.g. remove the item from the stocked item list) correspondingly and send it back to the view to display updated information (e.g. bring up the new stocked item list on the web page)'.
And if that is the case, it does not constitute a really legit difference from '3 Layer' as we can easily have a 'Transfer Object' (PEAA, "Core J2EE Pattern') that goes through all the layers, which will be used in quite similar capacity as the 'Model' in 'MVC'.

URL, URI, URN, ... the 'official' difference

URI:

Internet standard STD 66 (also RFC 3986) defines the generic syntax to be used in all URI schemes.

Syntax:
<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]

Both URN and the obsolete notion of URL therefore are URIs, and a URI does not have to be classified just URN or just URL.

"
URIs can be classified as locators (URLs), as names (URNs), or as both. A uniform resource name (URN) functions like a person's name, while a uniform resource locator (URL) resembles that person's street address. In other words: the URN defines an item's identity, while the URL provides a method for finding it
"

URN:

http://en.wikipedia.org/wiki/Uniform_Resource_Name

Syntax (RFC 2141):
<URN> ::= "urn:" <NID> ":" <NSS>

Example:
urn:isbn:0451450523 -  The URN for The Last Unicorn (1968 book), identified by its book number.
urn:isan:0000-0000-9E59-0000-O-0000-0000-2 - The URN for Spider-Man (2002 film) identified by its audiovisual number.
urn:issn:0167-6423 - The URN for the Science of Computer Programming (scientific journal), identified by its serial number.
urn:ietf:rfc:2648 - The URN for the IETF's RFC 2648.
urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66 - A URN using a version 1 UUID.


URL:

http://en.wikipedia.org/wiki/Uniform_resource_locator

(Informal) Syntax (RFC 1738 - Obsolete):
scheme://domain:port/path?query_string#fragment_id

Example:
http://<host>:<port>/<path>?<searchpart>
mailto:<rfc822-addr-spec>
news:<newsgroup-name>
news:<message-id>
telnet://<user>:<password>@<host>:<port>/

URI, URN and URL Clarification and Recommendation in RFCs:

RFC3986 - http://tools.ietf.org/html/rfc3986#section-1.1.3

"
An individual scheme does not have to be classified as being just one
   of "name" or "locator".  Instances of URIs from any given scheme may
   have the characteristics of names or locators or both, often
   depending on the persistence and care in the assignment of
   identifiers by the naming authority, rather than on any quality of
   the scheme.  Future specifications and related documentation should
   use the general term "URI" rather than the more restrictive terms
   "URL" and "URN" [RFC3305].
"

RFC3305: http://tools.ietf.org/html/rfc3305 - The general idea is that usage of the term 'URL' should be replace by the more generic term 'URI'