W3C | TAG | Previous: 26 Apr teleconference | Next: 12-14 May ftf
Nearby: Teleconference details · issues list (handling new issues)· www-tag archive
DC: Please continue.
Action PC, CL 2004/05/03: Review presentation materials when DC makes them available.
See also open actions by owner and open issues.
[IanJ] CL: Some news - deadline for comments extended by 2 weeks.
[timbl] Chris: The dxedalien for commnts has been extended by 14 days.
[Chris] ICANN has extended its Public Comment period for all of the new sTLD applications until 23.59 UTC 14 May. Interested parties are further encouraged to submit comments. ICANN will launch the independent evaluation process as scheduled, and proceed with the sTLD application timetable as originally published.
[Chris] http://www.icann.org/announcements/announcement-30apr04.htm
[timbl] http://www.w3.org/DesignIssues/TLD
[Chris] So we can give a comment as TAG is we want to
[IanJ] TBL: I'm happy to take comments from people as individuals; this is personal opinion. This is not a W3C document.
[Chris] tim is happy for his document, or icann is happy to take comments?
[IanJ] TBL: Half of this is generic, half is more specific to .mobi
[IanJ] PC: Would these arguments have been used against .name?
[IanJ] TBL: Some of them apply to .name as well, though a bit weaker (since a different namespace based on personal names) The DNS tree doesn't work at that level; the top-level is essentially flat.
[IanJ] PC: Does this essay talk about what resources .mobi will actually relate to? The .mobi domain is more aimed at people's mobile cell phone and roaming devices than at static content (or dynamic) served for mobile users. For instance, I'd have an address paulcotton.name but also paulcotton.mobi and that would be a web server running on my mobile device.
[Chris] hmm interesting
[IanJ] TBL: Looking at the proposal, I couldn't really read that.
[DanC_] gee... the prices I've seen for foo.mobi suggest it's not for an individual's phone web server
[Chris] servers on individual devices is a *good* thing. Yes the registrations is higher than other domains
[IanJ] TBL: People on the .mobi forum have addressed that issue as well. I also address both issues to a certain extent (foo.mobi as serving content for mobile devices, foo.mobi as mobile device address).
[IanJ] PC: I think the proposal from the .mobil proposers doesn't state clearly their intention
[IanJ] TBL: Any chance the TAG can get a consensus message together?
[IanJ] PC: It's likely that if the TAG has to take a position on this I'll have to recuse myself. PC: It may be useful for us to come up with a position by the end of the review period.
* IanJ see also: http://www.w3.org/2004/03/28-tld
[IanJ] TBL: I think CL's email probably incorporated a number of points i"ve made. Should we try to put together a finding (possibly with abstensions from some TAG participants)?
[IanJ] CL: I'd be quite happy to have TBL's essay endorsed. If there are too many people abstaining, might not be worth it.
[IanJ] DC: I have a mild feeling that this should not pre-empt our work. I think that even if we did nothing, I can't believe that this would go through.
[IanJ] TBL: I don't hear a lot of energy for getting a group statement on this.
[IanJ] MJ: I'm happy to contribute to a document to be published by the TAG.
[IanJ] TBL: If MJ is prepared to write something up, I'd suggest that we review /DesignIssues/TLD for a sanity check.
[IanJ] DC: I'd prefer that TBL send /DesignIssues/TLD to www-tag.
[IanJ] TBL: Are we asking the TAG to review it?
[IanJ] [E.g., answer before ftf meeting by email whether to endorse it]
[IanJ] DC: Tradition here is to get two reviewers.
[IanJ] TBL: Who wishes to review?
[IanJ] PC: I will read it.
[IanJ] CL: I volunteer to read it.
[IanJ] Action CL, PC: Read TBL's TLD essay, send comments to www-tag.
[IanJ] Action TBL: Send pointer to essay to www-tag.
Actions 2004/03/15 (due 25 March?) to review sections:
[IanJ] klyne12: Proposal to drop paragraph on inconsistent frag ids
[IanJ] CL: It's not untestable.
[IanJ] From the reviewer: "This seems a rather odd statement to make (specifically: "it is considered an error ...", because there is no specific way to determine if the would-be erroneous condition actually arises. Suggest: drop this paragraph; the intent is clear enough from the following good practice point."
[IanJ] DC: Error condition is that the publisher publishes two representations, using same fragid to mean two different things. Arch doc says "It's considered an error." Please say something like the representation provider is at fault in this case. NW's proposal was to keep the paragraph and make clearer who is responsible. I agree with NW and for the editor to salt to taste. I think it's worth making the point we were trying to make.
[IanJ] CL: I'd like some sort of action (i.e., text and response to reviewer). So yes to explain better and keep para.
[IanJ] RF: We have text for that in RFC2396 (IJ can take text from that revision).
[IanJ] IJ: I'm happy to steal from child-of-RFC2396
[Chris] cool, can we reuse?
[Roy] http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#fragment
[IanJ] Resolved to accept that reviewer's point that it could be improved, but decline to drop it.
[Roy] para after ABNF for fragment
[IanJ] Action IJ: Improve text regarding responsibility for inconsistent frag id semantics (looking at new RFC2396 text).
[IanJ] issue schema4: [3.3 Good practice: Fragment Identifier Consistency]
[IanJ] DC: Reviewer wants to know more about how the inconsistency is "detected".
[IanJ] CL: Same comment as before: how do you know when inconsistent?
[IanJ] DC: Bad news is ---- you don't ---- so don't create this error condition.
[IanJ] IJ: How do you know that you're doing it?
[IanJ] TBL: How do you know you're doing anything....
[IanJ] DC: We are not saying "it always has to work" we are saying "if it usually works; that's good. If it usually doesn't; that's useless."
[Chris] i am getting awful garbling from my vonage phone
[IanJ] TBL: I think we should say we're not using in the sense of formal logic.
[DanC_] "In general, content negotiation (like server-side browser sniffing) does not seem to us to be an obviously and universally good thing". translation: conneg sucks.
[IanJ] DC: Methinks she doth protest too much... Do they complain about the word ambiguous? They also want clarity on the nature of resource...
[DanC_] IJ: meanwhile, I'm demoting/removing "the owner of a resource" in the version scheduled for 5May... Nature of resource may become less and less a pertinent question.
[IanJ] DC: I don't see a straightforward way to dispatch with schema4 here. Whatever we used to explain ambiguity also applied to consistency....
[Roy] This has also been addressed by rfc2396bis, same section.
[IanJ] CL: I think their point here is that conneg can lead to inconsistency and therefore we should not be endorsing it.
[IanJ] TBL: To me, behind this, there is an unclosed issue. My first take on this is to say - suppose you have the same document in XHTML and SVG. Underlying issue is semantic web cross-links and hypertext web cross links; don't mix them via coneg.
[DanC_] hmm... perhaps we haven't said what's good about conneg.
[Chris] we have not, agreed
[IanJ] TBL: N3 equivalence with RDF/XML.
[timbl] for minutes
[Roy] The second and third paragraphs of [http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#fragment] is a different wording of the same practice note that avoids requiring that representations exist.
[IanJ] RF: RFC2396 current draft paragraphs address comments we've received in URI forum and about www-tag. What the schema WG wants is something that doesn't require representations to exist.
[IanJ] DC: Worth a try. We can update the text and see if they like it better.
[IanJ] TBL notes our proximity to httpRange-14
[IanJ] RF: We run into that problem regardless of the URI scheme. Given that it's instructions to the people responsible for creating mappings between names and mappings, it's ok if those instructions are only verifiable by humans.
[IanJ] TBL: We should give some guidance.
[IanJ] DC: I don't feel a big obligation to do much more than we did on 9 Dec. [Chris] so we have a case where the primary resource representations are 'equivalent' but the secondary resources are not 'equivalent'. I propose that IJ try to paste RFC2396 text in and ask the Schema WG to review.
[IanJ] Action IJ: paste RFC2396 text in and ask the Schema WG to review.
[IanJ] issue stickler8: Section 3.3.1, last para, last sentence: Nature of secondary resource not known through URI
[Roy] 3.3.1 "Per [URI], in order to know the authoritative interpretation of a fragment identifier, one must dereference the URI containing the fragment identifier." What triggered the question has to do with authoritative interpretation of a frag id.
[IanJ] TBL: If you do access the resource and get respresentation back, then content type of the representation determines semantics of the frag id.
[IanJ] RF: Patrick is saying that even if you access a resource, you can't determine the authoritative representation of it.
[IanJ] Postponed
issue stickler9: Good practice note on URIs without fragids?
Question: are the methods PUT, POST or DELETE meaningful for URI references with fragment identifiers, in terms of interacting with the state of the secondary resources denoted?
[DanC_] (ah... the "maximize utility..." text isn't from webarch. whew.)
[IanJ] Proposal: Say "no" as answer to stickler 9.
[IanJ] TBL: I would say that it's an error to do a PUT/POST/DELETE using URI with frag id.
[DanC_] (when somebody asks about methods PUT and POST, has one already limited the scope to http URIs? we reckon that one can GET an ftp URI, yes? you can PUT to ftp too... hmm...)
[IanJ] TBL: Secondary resources are on a completely different level; their properties are determined by the content type of representations.
[DanC_] (serious crosstalk today!)
[IanJ] TBL: Secondary resources are things referred to using a language in which the primary resource is written. HTTP only gives access to the primary resource. [Roy] I think it is a good principle that one should use the most specific URI available for the resource that one intends to identify. User agents are capable of controlling interactions beyond that.
[IanJ] Action IJ: Respond to reviewer's comment that HTTP PUT/POST/DELETE do not work with URIs with fragment identifiers since HTTP does not give access to the secondary resource.
The TAG does not expect to discuss issues below this line.
See also TAG findings