- From: Martin Duerst <duerst@w3.org>
- Date: Wed, 21 Apr 2004 09:20:44 +0900
- To: public-webarch-comments@w3.org
>Date: Tue, 20 Apr 2004 11:39:59 -0400 >From: Leslie Daigle <leslie@thinkingcat.com> >To: Martin Duerst <duerst@w3.org> >Subject: Re: [Fwd: W3C TAG report review] >I finally corralled the relevant folks and confirmed that >Patrik/the IAB are willing to make these remarks public. If >that's still relevant, please forward. > >Also, Jonathan Rosenberg, who joined the IAB during the >Seoul IETF (i.e., just as your last call was ending) offered >the following remarks (also publishable): > >[Jonathan Rosenberg wrote:] >>I also took a look at the document. I can offer up the following >>additional comments: >> From the introduction: >> >>>The World Wide Web (WWW, or simply Web) is an information space in which >>>the items of interest, referred to as resources, are identified >>> by global identifiers called Uniform Resource Identifiers (URIs). >> >>Thats a pretty broad definition; as it would include resources defined >>by other URI schemes (such as sip and tel) which I don't think are >>normally associated with the "web". The intent of the document, I think, >>is to generally think about resources that correspond to content. >>from section 1.1: >> >>>The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in the >>> good practice notes, principles, etc. in accordance with RFC 2119 >>> [RFC2119]. However, this document does not include conformance >>> provisions for at least these reasons: >> >>This may be a nit, but RFC2119 is really meant to be applicable to >>protocol specifications, not practices and principles. >>from section 1.2.3: >> >>>Silent recovery from error is harmful. >> >>I agree with this principle in cases where the way in which the agent >>recovers affects the resulting service provided to the user. There are >>error cases where this is not the case - for example, a 401 in http >>where the problem was a stale nonce, or an error indicating that a >>message was lost and should be retransmitted. In such cases, silent >>recovery probably makes sense. >> From section 2.4: >> >>>Authors of specifications SHOULD NOT introduce a new URI scheme when >>>an existing scheme provides the desired properties of identifiers and >>>their relation to resources >> >>The inverse (comverse?) is also true - you should reuse a scheme and >>protocol when they >>don't have the desired properties. It might be a good idea to reference >>RFC3205 in this regard. >>Section 3.7: >> >>>There remain open questions regarding Web interactions. The TAG >>>expects future versions of this document to address in more detail >>>the relationship between the architecture described herein, Web >>>Services, the Semantic Web, peer-to-peer systems (including Freenet, >>>MLdonkey, and NNTP [RFC977]), instant messaging systems (including >>>[XMPP]), and voice-over-ip (including RTSP [RFC2326]). >> >>RTSP does not qualify as voice over IP by most people's definitions. Its >>generally called "streaming media", and if you want to reference a VoIP >>protocol, try SIP (RFC 3261). >>Section 4.5.3: >>IETF has established an IANA registry for namespaces, so as to guarantee >>uniquess. It might be worth referencing the specification that creates >>this registry, RFC 3688. > > >Best regards, >Leslie. > >Martin Duerst wrote: >>Forwarded to the internal TAG list. Please at this moment >>do not consider these comments public. >>Leslie, the official address for comments is >>public-webarch-comments@w3.org, which is a public archive. >>If you don't have any problems with the IAB comments becomming >>public, please forward it there, or reply to this mail saying >>it's okay to forward. >>Regards, Martin. >> >>>Date: Sun, 07 Mar 2004 20:00:37 -0500 >>>From: Leslie Daigle <leslie@thinkingcat.com> >>>To: w3c-policy@apps.ietf.org >>>Cc: connolly@w3.org >> >>>I wasn't sure where to forward the comments -- but this can be >>>considered the IAB review of the W3C TAG document. >>> >>>Thanks for the request for input! >>> >>>Leslie. >>> >>> >>>-------- Original Message -------- >>>Subject: W3C TAG report review >>>Date: Tue, 02 Mar 2004 13:30:30 +0900 >>>From: Patrik Faltstrom <paf@cisco.com> >>>To: IAB <iab@ietf.org>, (E-mail) >>> >>>In general, it is a good document. The description is very good on what >>>"the web" actually is, and how it is used. >>> >>>The URL is http://www.w3.org/TR/webarch/ >>> >>>It is very long. >>> >>>Potential issues: >>> >>>---------- >>>General comment: >>> >>>It is easier to refer to "Good Practice" etc statements if they were >>>numbered. >>> >>>---------- >>>General comment: >>> >>>There is no discussion or mentioning of WebDAV. >>> >>>---------- >>>In section 3.2: SOAP >>> >>>The document list SOAP beside HTTP, FTP, NNTP and SMTP but the IETF see >>>SOAP as a different thing than the other protocols as everyone else is >>>transported on TCP while SOAP need some more "things" between TCP and >>>SOAP. Normally, SOAP is transported on HTTP, SMTP or BEEP according to >>>various specifications. This might be confusing for the reader if it is >>>not clarified. >>> >>>---------- >>>In section 3.3: Internet Media Type >>> >>>It should be noted in the beginning of the document the IETF term is >>>(just) "Media Types", not "Internet Media Types". If this document find >>>it needs to use a different term (i.e. prepend "Internet", that should >>>be clarified so readers don't end up being more confused than necessary. >>> >>>---------- >>>In section 3.3.2: Fragment Identifiers and Multiple Representations >>> >>>The section talks about Internet Media Type and Fragment Identifiers. >>>These are two orthogonal things. The selection of media type for a >>>resource is one thing, and potential use of fragment identifier another. >>> >>>It would be good if the statement about Fragment identifier consistency >>>was independent from the Fragment Identifier issues, because this >>>statement should be general for a URI. Potentially it should be moved to >>>the section earlier which talks about eqvivalence of URI's. >>> >>>This is described somewhat in section 3.6 but... >>> >>>----------- >>>In section 3.5.1: Unsafe Interactions and Accountability >>> >>>It would be better if the stories only talked about how a web server >>>should behave, and not show bad behaviour. In this case (the story >>>directly below 3.5.1), it should say Content-Location header is used. >>> >>>----------- >>>In section 3.5.1: Unsafe Interactions and Accountability >>> >>>The title of the section imply the section will talk about "unsafe >>>transactions" which to some readers might imply also discussion about >>>use of SSL/TLS. I would recomment a new title as the section more talks >>>about "stability and ability to bookmark" URI's. >>> >>>----------- >>>In section 4.1: Binary and Textual Data Formats >>> >>>It would be good if the overall differences between binary and textual >>>data formats were listed, the most important one being the linebreak >>>changes on textual data which in turn might make signing of data >>>difficult/different. >>> >>>----------- >>>In section 4.4: Hypertext >>> >>>The three (!) different link types have different meaning, and it should >>>be spelled out when to use which: >>> >>>- <a href="http://example.com/foo"> >>>- <a href="/foo"> >>>- <a href="foo"> >>> >>>----------- >>> >>> >>> >>>-- >>> >>>------------------------------------------------------------------- >>>"Reality: >>> Yours to discover." >>> -- ThinkingCat >>>Leslie Daigle >>>leslie@thinkingcat.com >>>------------------------------------------------------------------- >>> > >-- > >------------------------------------------------------------------- >"Reality: > Yours to discover." > -- ThinkingCat >Leslie Daigle >leslie@thinkingcat.com >------------------------------------------------------------------- >
Received on Tuesday, 20 April 2004 21:19:48 UTC