W3C home > Mailing lists > Public > public-webarch-comments@w3.org > April to June 2004

Fwd: Re: [Fwd: W3C TAG report review]

From: Martin Duerst <duerst@w3.org>
Date: Wed, 21 Apr 2004 09:20:44 +0900
Message-Id: <4.2.0.58.J.20040421091757.06b87ee0@localhost>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:37:32 GMT