See also: IRC log
<scribe> Scribe: Rhys
<scribe> Scribenick: Rhys
SW: Reviews the agenda and invites comments
DO: Could add links to the updated versioning draft
SW: I'll do that
NM: Don has joined us as the AC rep from Web 3D. He's also been helping me with identification in virtual worlds
... There is no formal issue for this yet
... In IBM I look at new technologies appearing and point these out. There is a lot going on in the virtual worlds space, including starting businesses and signing up users. Some are talking about standards, but there is limited interoperabilty at the moment
... Any interop is in a very piecewise way
... Interop rather limited. Seems that starting with identification might be a good idea
... Suppose on a billboard, there is a URI, I could use the URI and access the information from the web
... In virtual worlds, could I click on a virtual URI on a virtual billboard and access a virtual view of the information
TBL: So does the URI identify a point in 3 space
NM: This is one of the questions
... I'd like to find out what the community is doing in this area, which is why Don is with us
... I've skimmed the note, but not gone through the detail
... The Web3d does seem to be doing something in this space, and I'd like to understand this
... W3C needs to have a relationship with the Web3D folks, and then we should discuss if we think that things are going in the right direction
DO: A friend of mine does some second life development. He has a way of using Amazon gift tokens within second life. You can transfer these between people, and effectively move money.
NM: Second life doesn't know its a URI though presumably?
DO: Right
NM: What do you want to identify within these virtual worlds? Is it just an item like a showroom, or is it a point in 3 space
DB: There are a lot of issues in what has just been layed out.
... Backdrop is that Web3D is small but persistent. I've been coming to liason meetings since 2000.
TBL: There was a 3D workshop at the first web conference
DB: There are 40 company and 200 personal members. Been around for more than 10 years. Stable working group structure. Similar approach to W3C. Aligned with web architecture
... Industry players often think they can own 3D on the web.
... Familiar with second life. I need to be careful about IP.
... I am familiar with the approaches that such systems use
... Everything will eventually align with the Web, I believe
TBL: There is some open source 3D stuff. How aligned is that with your standards?
DB: There is lots of open source. We require two implementations, and one has to be open source. We have a total of 18 implementations
NM: XJ3D is a set of code. What's its scope?
DB: It implements the specs that we have for 3D on the web, geometry, spatial component, etc.
... We've just been working on globe-building code bases using the technology.
... We don't show a formal preference for open source, as there are company implementations too.
NM: How extensive is the industry support
DB: There is healthy churn in the industry. Efforts come and go. We could position ourselves as a virtual worlds technology.
... We have about 80% of the complete technology stack needed to deploy a complete stack, though that would be a mission change for us
NM: One of the specs, is aimed at the virtual worlds or not?
DB: Actually no, though it could work there
... The summary is that we've always had a URL field in objects that need network resources. We have an anchor, so that a URL can be activated
... It could be a bookmark, etc. We have a convention for these viewports.
NM: Are these HTTP?
DB: Yes. Actually, we had forgotten to update the specs to URI, but we have done that now.
TBL: From this anchor, I follow a link to one of these, I get a view?
DB: Typically we're just accessing some other 3D world view or a texture wrapped on something. Could be imported into the current world?
TBL: Do you have some idea of level of detail as you zoom in?
DB: Yes, based on distance of view from the object. The URIs could reference anything.
TBL: You move to the new point, and then render whatever is there
NM: I have a URI. I click on the object and activate the http URI and there could be a # sign and a viewport.
... What comes back has your media type, and that spec defines the rules for the fragid which you process and then render the result
DB: We have a fixed coordinate system in the base, but others in extensions
TBL: Suppose I have a 3d plugin in my browser, can I bookmark a coordinate?
DB: Right now that would be a browser feature
TBL: That would be a good point for interoperability
DB: Its a good point. There is a potential tension between the various players. We sometimes get pushback if you save bookmarks and maybe e-mail them to someone else, the quesiton arises about what then you do with them
TBL: Surely the place I am at is just a coordinate.
NM: What fraction of the references tend to be symbolic, and what are 3 space coordinates?
DB: More coordinates, but they are not in a common coordinate space
... There is no global reference other than the URI
TBL: So if in my world im building a town, and I place your house at a particular place in my town.
DB: And if you wanted to be in a particular lat/long location, you can do that.
TBL: So if someone comes to my world and goes to your house, I should be able to bookmark your house.
DB: Almost, because there is a limitation right now about moving from one coordinate system in an included item shared with the one in which it is embedded
NM: I think there may be a slightly different use case here
... The web got the cosmic goal early. The Web3D approach seems to have been a collection of point solutions that interoperate
TBL: Second life has a global 3D coordinate system.
DB: There is actually a variety of SURLS.
NM: A SURL is based on a region, and then has an x,y,z. So the island name is the base for the SURL
SW: So the web3d approach is to use URIs to point out elements within the world.
... Anchors provide named view points.
DB: And those anchors can include behaviour.
NM: I think that the mechanisms are there in the Web. You have them too, but the statistics are different. On the Web, not being accessible is unusual. On Web3D, people have used the specs differently.
... The default is local serving rather than making them available. via the web
s/avaialble/available/
DB: There has been an historic lack of consensus, that has meant that a common view of how to use URIs for this has no common definition yet.
... Our model is that anyone can have a 3D scene and point to parts of it
TBL: Anyone with a 3D web browser could go directly from the current web straight into the 3D world. I think we are at the point where there could be value in enablihng that.
... The ideal could be that the virtual worlds links are used just like web links
NM: We should identify a set of things that we should follow up.
... Tell us about the list of links
DB: Our problem was that we often needed multiple alternate links for the same resource, for connectivity, performance, reliability reasons
... Typically you need a set of objects for a view. You'd normally use a relative link first, then other links
... They all point to the same thing, but ordered for performance. They are tried in order
NM: Is there a URI that represents this list?
DB: It's possible that people might do that, but its not inherent. The references are ordered lists of URIS
SW: What do they look like?
DB: They are a list of quoted strings
NM: So in X3D you could have an attribute that includes a string as the list of URIs
SW: So is the syntax attr='"uri1" "uri2" ...'
DB: yes.
SW: There are things in XML that accept lists of URIs
NM: Yes, but in this case these are treated as what is effectively the same thing
TBL: So you have to use this list each time you want to refer to a URI. Also the URI could refer to an entire view, so maybe you don't have to access these that often
... Typically on the web people would have a single URI that references the list.
<Noah> Noodling on questions we might track:
DB: So we also allow relative and absolute URIs and URNs.
<Noah> * Are particular specs such as Web 3D specs using the Web and URIs in a good way?
SW: Architecturally it would be good not to restrict the types of URI
<Noah> * Is there a need for something resembling conneg, in which the same URI could sometimes resolve to a traditional Web resource (product demonstration on the traditional web) vs. 3D representation (product demonstration in virtual world)
TBL: The classic approach would be to use this canonical URI approach. Actually, my laptop does this. It looks in the local filespace first, uses that if its there
... The other approach could be to use a catalog
NM: I just typed into IRC a couple of questions. They are the things with the asterisks
... Are particular specs such as Web 3D specs using the Web and URIs in a good way?
... that's the kind of thing we could look at
<timbl> A catalog is a chunk of metadata which gives for each canonical URI a set of equivalent URIs to try, or a set of rewriting rules for URI patterns.
DB: Web 3d would like to engage in that discussion
NM: Is there a need for something resembling conneg, in which the same URI could sometimes resolve to a traditional Web resource (product demonstration on the traditional web) vs. 3D representation (product demonstration in virtual world)
... If I have a product specification, I may send you a different representation if you are on a cell phone than if you are on a desktop
... Maybe I could give you a 3D representation if I knew you were in a virtual world
... Maybe it just needs a redirection. The question is whether anyone cares about the use case. I don't think anyone is doing this yet
TBL: It should just work shouldn't it?
NM: In Web3D this looks promising, but in other worlds, there doesn't seem to be this capability
... The issue is about virtual worlds in general. So part of this is that the Web3D approach looks like it could work, but for other players this might not be the case
DB: Also, would the same facilities be available via other mechanisms too, like web services catalogues etc.
SW: I'd like to understand things that need to be addressed by the TAG
NM: I thought that TAG has a role to liase with communities beyond the web, I could be wrong
... Is it in scope? If so, what is its priority?
<Noah> Mission statement
<Noah> The mission of the TAG is stewardship of the Web architecture. There are three aspects to this mission:
<Noah> 1. to document and build consensus around principles of Web architecture and to interpret and clarify these principles when necessary;
<Noah> 2. to resolve issues involving general Web architecture brought to the TAG;
<Noah> 3. to help coordinate cross-technology architecture developments inside and outside W3C.
TBL: I'd like to encourage the Web3D community to develop a technology that could cross link via HTTP and in which there are bookmarkable links by coordinate
... to enable references that can be shared and can be used from anywhere in the Web
... I think it could be really valuable and that it would create interesting markets
... Decentralised worlds and decentralised development to encourage scalability
<Noah> FWIW: I think the use case where the same http link sometimes gives a representation in the form of an HTML product description for desktop, sometimes resolves to one tailored to cell phone, and sometimes gives you a 3D representation (if you've got the necessary client), is very, very important. I think it's a good use of the TAG's time in principle to keep an eye on that, but I'm not strongly saying higher priority than other things we're trying to do.
<dorchard> right, I wanted to ask about URIs for things.
DB: I'd like to talk about this with our partners.
DO: How about URIs for things rather than places. That's the httpRange-14 question in virtual worlds
... Could have a URI for a real thing that could be referenced in a virtual world.
TBL: For lots of things they have this. For example, if the representation is a bunch of polygons
<Noah> I'm not sure I'm looking forward to discussing the question: "Is there anything about the essence of an avatar that cannot be conveyed in a computer message?"
TBL: Sometimes the refrence will be to an instance, sometimes to a 'class'. By class I mean a design for an object, from which instances can be created at specific 3 space coordinate
Discussion ensues about the relationship between instances and models (classes), where they are, how they might be transferred and how ownership might be transferred...
<timbl> The instance of an object needs an IS so we can say things about it like who owns it, whether it s for sale, and so on
<dorchard> I mean can we have a URI for a thing in the real world
<dorchard> then we transfer the "thing" from place to place
NM: Resources have URIs, but representations tend not to.
<dorchard> Or even link to thing in the real world, for transfer, etc.
TBL: I don't think there is a philosophical issue here. It's just like images. It's just that in 3D its a set of polygons
DB: We do worry about the ownership of the model when it is being used in multiple scenes
... We support specific protocols. One problem has been a lack of network capability in ECMAScript. There are other approaches including Ajax for 3D worlds. There are other approaches, but networking is tricky
TBL: What is the relationship with the distributed 3D communities?
DB: complete mixture of overlaps and alternative architectures
... We continue to try and apply the web approach to distributed 3D simulation
TBL: One of the ways this might go is that there are large databases of interesting information that is geographically related.
... There is increasing interest in streaming this kind of data across networks so that multiple people can see views of changes immediately
... We might end up with streams of changes flowing over the Web. This is roughly the same challenge as might be needed to keep views consistent across 3D worlds
<dorchard> I think I heard that the polygons of an object have URI(s) but not the thinng.
<dorchard> Don: common thing is to worry about multi-user representation
<dorchard> Don: not so much a URI for the thing.
DB: We don't have an equivalent of DRM. We will use EXI when it becomes available.
SW: What is the follow up?
NM: I think that there is a lot of interest for me. I think this could be a big deal because its similar to the cell phone situation. The key is that you can call land lines from cell phones
... There is an analog here. I don't think it's urgent yet. I think it will be. There is fragmentation now, which it will be important to fix over time. It's equivalent to a situation where cell phones could not call land lines.
... Not sure we need to open an issue right now.
SW: Reviews agenda progress
TAG thanks Don for participating
Don Brutzman leaves
DO: changed the first good practice to 'server or resource' from server
NM: Should include the notion of the representation
<dorchard> Server, or more specifically the representations served such as forms, should not solicit ...
<dorchard> Server, or more specifically the representations served such as forms, should not solicit ...
<Noah> suggest s/served/it serves/
<dorchard> A server, or more specifically the representations it serves such as forms, should not solicit any passwords in clear text.
<Stuart> http://www.w3.org/2007/11/06-wsc-minutes.html
<dorchard> fugged about it, back to A server should not solicit any passwords in clear text.
<dorchard> A server should not solicit any passwords in clear text.
<dorchard> A server should not solicit any passwords in clear text.
DO: The paragraph about warning the end user has been removed. I've added text to describe why a good practice about this is not possible
TBL: I think there is a case for having a 'mode' of javascript that is hampered to prevent unsafer operations
<dorchard> Noah: don't do paragraph break
<dorchard> Noah: don't say "can provide", say "provides"
NM: Let me clarify this. If I don't have network access, for example, why would I ask for a password?
TBL: If you don't have javascript that could make the request, you would have to use a form, for example when the padlock is on
NM: This doesn't cover the situation for other sensitive data. Should this feature that Tim is advocating cover more than just passwords
... Lots of people won't understand the issue. People will simply assume that if the site they are using is reputable that they will be doing something reasonable with a password.
... You could imagine defining more field types in, say HTML, where these could reflect additional uses. This sounds like its beyond what we want to design in this finding
DO: I removed the problematic good practice guide about warning users when sending a password in the clear.
<dorchard> http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20061212.html
<dorchard> Timbl: note that it's dangerous to send sensitive information such as passwords in clear text, there's no obvious method by which a web browser can reliably know when the data entered is sensitive.
<dorchard> furthermore, in browsers which enable scripting, it may be impossible to know whether the information is transmitted in clear text.
<dorchard> (and the same for versioning...)
NM: Begs the question about the password type in HTML. We need to explain that
DO: Can we get some words?
NM: Points out that the HTML spec says that type=password can be used for sensitive information such as passwords
DO: I added text for digest authentication from Hal.
NM: There was a part of the finding that encouraged the use of digest, but actually because of this issue of salted hashes, you actually can't do this.
... You can't get the secrets to the correct place to enable use of digests in some use cases. These were the cases that Hal thought were the majority, hence there was no value in using digest.
... I think there may be cases where it can be used, in some kinds of newly written web applications
... Suggest that we add something about issues with digest where passwords are already stored as salted hashes
TBL: I thought that the problem was about accessing the secret key.
... suggest change to 'Because many systems store passwords as salted hashes....'
<dorchard> NM: change "because most passwords are stored.." to "Because many systems store passwords"
DO: Next, in section 3, the good practice changed to should from must. Added an explanation about circumstances under which masking is not required
NM: Could we change the 'It is the TAG's opinion...' because its not our normal phrasing.
<dorchard> NM: s/It is the TAG's opinion that if the form field is a password, password masking must take "/If the form field is a password, password masking should take
<dorchard> nm: s/is displayed/be displayed
<dorchard> nm: s/or the password/or that the password/
<dorchard> One example is that the uswer may request that the password be displayed in the clear in order to check the password as it is being entered.
<dorchard> Another example is that the password is intended to prevent search engine access and so it is not particularly sensitive.
<dorchard> Another example is a password that is intended to prevent search engine access and so it is not particularly sensitive.
<dorchard> Another example is that the password is intended to prevent search engine access and so the password is not particularly sensitive.
Another example is a password intended merely to prevent search engine access, and which consequently is not particularly sensitive
TBL: Do we cover temporal versioning and exensibility, or just the temporal aspect?
NM: I don't want to lose the sense of extensibility
<dorchard> http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies
<dorchard> nm: change because evolution to "because support for evolution"
DO: Any objections up to section 1.1?
<Stuart> suggest for 3. s/...., then a given language version/....then a given language version specification/
Discussion ensues on the text of list item #3 in section 1, and whether it requires clarification.
scribe: should define a set of future version identifiers that will be considered compatible. This set could, of course, be empty.
RL notes that the previous line was his attempt to help a discussion, but was not discussed
Discussing section 1.1
<dorchard> nm: section 1.1, bullet 2: common is unclear, name structure should be something like person name structure
SW: Is there a section elsewhere where the name example is discussed?
... Could you link to it rather than explaining it here?
DO: Yes
<dorchard> NM: #3 change "schemas" to languages.
NM: In point 3, could we use langauage instead of schema
<dorchard> all three of thouse languages employ markup from the same namespace but they are different languages.
<dorchard> tbl: sentences shouldn't start with "And.."
<dorchard> tbl: change to separate bullet, #4.
<dorchard> nm: kill last paragraph.
<dorchard> nm: swap last 2 sentences.
<dorchard> nm: change "those applications" to "the applications using it"
DO: Any other other changes for 1.1?
None raised
Section 1.2
<dorchard> NM: in some languages, each instance contains just a name.
DO: Maybe I need to remove the first bullet ("Just Names")
SW: I might choose a URI as the example.
DO: I did mean the abstract, when I first wrote it. I need to think whether I want to extend the notion of language to deal with this kind of abstraction
NM: Please don't. We started with texts because these are things that can be exchanged across the Web
<dorchard> I need to remove the abstract names from this..
NM: I thought you were building this up from the simplest case, where there is just a name
DO: Ok, I'll craft something
SW: Points out that we are runing out of time.
<dorchard> nm: move non-markup text before markup
NM: Any reason not to put text languages ahead of markup? If we did it would be in the sequence of increasing elaboration.
<dorchard> put link to versioning xml
DO: Have we got to the end of section 1.2?
NM: Not sure about the bullet on binary. We said that we were talking about languages composed of texts
<dorchard> I'd prefer to include gif, jpeg in our versioning strategy
<dorchard> while our formal definition of language restricts itself to text based language, the advice herein may be useful for binary languages such as gif, jpeg.
DO: We could move the GIF and JPEG to a section that mentions non-text languages to which many of the findings in the documnent apply.
... What about binary coded XML
SW: There is some layering going on here.
NM: Dave wants to be able to deal with abstract trees, for example. I think we chose not to do that in Edinburgh
SW: I'm not sure we did say that.
NM: We could change the definition of languages or we could restrict this to text-based languages
<RhysL> TBL: We're not covering APIs
<RhysL> TBL: I would be loath to talk about versioning and APIs
<RhysL> DO: Serialisations are languages, but they have an affect on the API
<dorchard> tbl: can relax definitions to be sequence of characters or bytes
<dorchard> nm: need to be on bits
<RhysL> DO: I could live with Tim's suggestion of defining a text as a sequence of characters or bits
<RhysL> TBL: Let's just leave it for now and work on text for the definition of texts in languages
<dorchard> How about changing text to Text is a sequence of characters or bits
<RhysL> NM: I think we need to re-read the terminology section, to check that there are no additional issues that are caused
<dorchard> tbl: happy down to 2 Versioning Strategies
<Stuart> rrsagent pointer?
<Stuart> rrsagent pointer
<Stuart> logger, pointer
<Stuart> logger, pointer?