More Web Proxy on the site http://driver.im/
W3C | TAG | Previous: 1 Jul | Next: 15 July | IRC
log
Minutes of 8 July 2002 TAG teleconference
Nearby: issues list · www-tag archive
1. Administrative
- Roll call. TB, SW (Chair), DC, NW, IJ, CL, DO, PC. Regrets: TBL, RF
- Accepted this agenda.
- Next meeting: 15 July. Regrets: CL
- Accepted 1 July minutes
- Accepted summary of TAG
activity in June
- Confirmed status of completed
actions
- Quorum rules
- Prioritization of issues
- Action IJ: Publish architecture document, asking in particular for
input on issue httpRange-14. Done.
- Action SW: Respond to XMLP WG on behalf of TAG. Done.
- Action IJ: Integrate/combine one-page summaries (into architecture
document)
The TAG charter does not
include quorum requirements. The TAG agreed at this meeting not to institute
quorum requirements, to use common sense when making decisions when few
people are at a meeting.
The TAG began to discuss prioritization of its issues, when the topic
shifted to expectations of a timeline for publishing the draft Architecture Document as a W3C
Working Draft. There was general agreement that the TAG should do this as
soon as possible (and certainly before resolving all the issues on its issues list). The TAG set a goal of further
fleshing out this document and publishing a first Working Draft by
mid-August, with a drop-dead date of 30 August.
Action IJ: Find out whether the W3C Comm Team
expects to have a publishing moratorium in August.
2. Technical
See also: findings.
- ACTION TBL 2002/05/05:
Negotiate more of IJ time for arch doc
- ACTION RF 2002/06/24: Write a paragraph on technical and political
aspects of URIs and URI References.
Review of some portions of the 1 July architecture
document. The following notes have been reordered somewhat to map to
arch doc sections.
Section 1.1 URI schemes
[Ian]
- TB: What do we do to make 1.1 work? Some of the things in the list
under schemes are duplicates. Bullet one would apply to all URIs if we
took RF's wording. Are other people happy with 1.1?
DC: I think the list is interesting, but I'm not satisfied that it
works.
- SW: I'd like to mention 1.1 scheme-agnostic. What about a table of
schemes and properties? Section 1.1.1 is about persistence, also a
property in the table. Should we have prose for each of the properties
we identified?
- IJ: I think scheme properties are a useful entry point for other
issues we encounter later on.
- Parallel actions TB, DC: Propose text for
section 1.1.
Section 1.1.2 Central registries
[Ian]
- CL: I have a problem with 1.1.2 (central registries). Centralized
registries of formatting properties is also useful. As is the W3C /TR
page.
- DC: /TR is not a centralized registry. It's not necessary for every
party who does Web business to consult /TR to continue in life. /TR is
not central to the operation of the Web.
- CL: So what about browsers making up HTML?
- TB: There's a qualitative difference between DNS and /TR.
- DC: There is a central registry for MIME types.
- CL: You don't have to look up IANA registry each time as a user.
- TB: But browser developer needs to have hard-coded.
- CL: Is the definition "You looked up once in one place" or "You have
to look up each time." Having single points of failure is something
else.
- DC: As written, the text doesn't make the case why central registries
are bad. There are at least two: URI schemes, list of MIME types. I
would still claim these are exceptions.
- CL: Is 1.1.2 for the whole document or just 1.1?
- DC: I think in context. We like anyone to be able to make up names.
But there are exceptions (e.g., DNS).
- CL: Then we should say that 1.1.2 only applies to naming.
- DC: But naming is the only place where central registries would come
up.
- CL: Why is 1.4 part of section 1, not formats?
- SW: Part of a URI reference.
DC: Good point, though. Maybe it could move to 2 (with link to it from
chapter 1)
TB: On central registries - I think we are telling spec writers "Don't
assume a central registry at W3C must be required in order for your
spec to work." Given that principle, DNS is arguably unfortunate, but
we're stuck with it. I think DNS different from getting a MIME type
definition (since everyone does this all the time). I think that the
intent of 1.1.2 is fine. I support the principle as stated and I think
it applies to issues outside of URIs. Applies to protocols and formats
as well.
Section 1.1.1 Social expectations for URI persistence
SW: Just before 1.1.2, we do some URN-bashing. What should we say
about IETF efforts to make URNs dereferenceable?
- DC: This came up under Media type rubrique. I hope this is still on
todo list. Michael Mealing has made points about IETF decisions
regarding single points of failure. I was not aware of that decision. I
would like to track down how decisions are made in that area. Two
points
- TBL was out of line saying on the list that URNs are not
dereferenceable.
TB: But in fact URNs are *not* dereferenceable.
- Michael and Tim Bray seem to agree (on the list) to the fact that
we should use dereferenceable URIs, whatever scheme.
TB: I think we agreed that dereferenceability is a useful
characteristic and that it's a good thing to call that out.
DC: My issue with URNs is that they just recreate HTTP. HTTP has
administrative hierarchy, and you get to do whatever you want in your
HTTP space. As far as I can tell, URN technology doesn't change that -
login, then search, then one TCP transaction. There should be an arch
principle on not reinventing the wheel. Process question - how can TAG
and IETF parties communicate better?
TB: Principle - Persistence is a matter of policy, not technology.
Nothing in HTTP prevents you from managing your space well. Perhaps we
should just drop URN reference unless we take up DC's point that
harmful to reinvent wheel.
NW: I think we'd be hard pressed to argue that URN is a new scheme.
TB: Please add a boxed principle: "Persistence is a key characteristice
in URI design."
DC: A comment I made on the phone with IJ - a lot comes down to
"economics". Value to having name agreed by people. If it changes, then
the value goes down.
TB: We say "there are strong social expectations..."
DC: The document doesn't say what the expectations are.
- DC: Two decisions were made in the IETF pertaining to URNs:
- DDNS documents proposed standard; I tracked down
- Decision not to use HTTP URIs to name protocols. I don't know
where that decision was made.
Action DC: Ask Michael Mealing when IETF
decided not to use HTTP URis to name protocols.
Section 2: Formats
- [Ian]
- CL: Not sure what I would write in Section 2... Section 2 is the big
bleeding piece for me.
- TB: I think the meat is in section 2. All it needs is to invest time
to wrap text around each issue. Seems mostly editorial. You could build
short sections for 2, as done for current 1.4.1. I think we have
consensus on format properties as well.
- CL: You can put a list of alternatives around issues as well.
Action CL: Write up some text for section 2.
Deadline 30 July.
Additional principles
[Ian]
DC: One principle I've heard about formats is to separate
presentation from structure is an arch principle as well.
- ACTION DC: research the bug in the svg diagram. Done.
TB, CL: Remove. PC: Neutral.
DC: I'm happy to do without TBL since Martin said I18N folks would do
something with it if TAG doesn't.
- ACTION NW 2002/06/24: Produce PNG version of image as well. Done.
Resolved: Remove diagram from finding.
[TBray]
- The finding is not
done due to issue RFC3023Charset-21.
- [Ian]
- Current text:
- "If so, the IETF registration forms MUST be part of the language
specification, and SHOULD be part of the specification starting at
Candidate Recommendation status (or Last Call if the Working Group
plans to have sufficient implementation experience to bypass Candidate
Recommendation). "
- DC: IETF area directors didn't say you had to have the mime type in
registry before you could use it.
- [DaveO]
- hmm.. seeming less and less like an architectural principle and more
like w3c process issue.
- [Ian]
- IJ: The text must be in spec, but isn't required to be
registered.
- DC: Area directors said "Don't want to put in the registry until it
goes to Rec." They prefer to just have internet draft published every 6
months. They would rather your type not be in registry but not in
internet draft index.
- CL: What can we point to when people tell us we are doing it
wrong?
- TB: I agree with DO's point that this is a process issue. Let's
rewrite finding to say that registration process must proceed in
parallel with w3c process, and documents must be readily available from
w3c specs.
- DC: Water down more: Registration information is relevant and needs
to be reviewed along with everything else in your spec.
- IJ: Please note current best
practice as we understand it.
- TB: if we write a strong arch principle saying "You have to get this
work done" then that is enough for the Director to stand on.
- PC: I think we need a cookbook for chairs on what to do.
- DO: I'd rather us spend more time on arch principles and our issues
list.
- [TBray]
- Particularly given that the TAG has substantial consensus... it's
irritating that we have to keep investing time on this. If we want a
cookbook, how do we get it?
- [Ian]
- DC: I agree that this is process, but who do we hand this to?
- PC: Our finding should say "here lie alligators" if uncertain
process.
Action PC: Propose alternative wording for
finding.
Action CL: Send copy of information
sent to tag regarding RFC3023 to www-tag.
- NW: I see Håkon's
reply only now (due to email problem).
- CL: CSS WG wanted previous good behavior mentioned in the
finding.
- DC: HWL's message suggested a central regisry. Are we saying "no
thanks" to that suggestion?
- TB: Our finding is correct. Hakon suggested writing down a process. I
don't think this changes the finding.
- CL: In other words, we don't care how you get it right as long as you
do?
- DC: Works for me.
- NW: I will make another stab that mentions good behavior and
presumably we can call it done at that point.
- ACTION DC 2002/06/10: Send note to WSA WG expressing concern about
normative binding for GET. Done.
- SW: Are we done with issue
whenToUseGet-7?
DC: Not to my satisfaction. I haven't seen message to or reply from WSA
WG.
DO: In my court. I've had discussions with various people. I'm still
working on what possibly we should try to say to them. Certainly
dealing with SOAP 1.2 is an issue before WSDL. I think we should go to
them with something more refined.
- TB: I think that the news is good, however, notably on WSDL front.
It's now on their radar.: My understanding is that they will build
machinery to handle it.
- Status of discussions with WSA WG about SOAP/WSDL/GET/Query strings?
- 1. ACTION DC 2002/06/17: Talk to XML Schema WG about PSVI. Report to
tag, who expects to decide whether to add as an issue next week. Done
(email
to Schema WG).
- DC: I don't think we should close until we've heard back from
them.
- NW: Schema WG tried to consider DC message at meeting 2 weeks ago. I
don't think it was clear what we were asking them.
- DC: They need to tell me how they are confused. Please mark as open
Tim's action regarding communication with IETF about media type names
as URIs (issue
URIMediaType-9). See message
from DanC.
- Qnames as
identifiers
- Action NW 2002/06/24: Follow up on Rick
Jelliffe comments/proposal.
- httpRange-14: Need to make
progress here to advance in Arch Document.
- Status of URIEquivalence-15. Relation
to Character Model of the Web (chapter 4)? See text from TimBL on URI
canonicalization and email
from Martin in particular.
New issues?
- Bad practice: Overriding HTTP content-type with a URI reference.See
email from TBL.
- "Deep linking illegal" bad practice? See email
from Tim Bray.
Ian Jacobs, for TimBL
Last modified: $Date: 2003/12/17 18:51:15 $