Skip to end of metadata
Go to start of metadata

URL Policy

URL Policy (revised)

2.1 Domains

Suggest we remove "In the future domains of the type xxx.bath.ac.uk (or www.xxx.bath.ac.uk) for non-University services will not be permitted." from the third bullet point.

2.2 Departmental URLs

Departmental, or other grouping, URLs will exist immediately under the main domains, in other words:

www.bath.ac.uk/physics/

URLs should always be all lower-case letters and contain no spaces, underscores or any URL-encoded characters.

Alison Wildish comments:
This is fine but one of the issues department have is long URLs. We are frequently asked for shorter version for say a topic or profile. I think we need to consider how we could offer this so that they can use www.bath.ac.uk/physics/nanoscience rather than /research/nanoscience/index.html The TinyURL idea being worked up by Matt Roper could potentially do this as he suggested you could choose the URL you wanted. Any other thoughts?

Richard Phillips comments:
2.2 & 2.3 - To an extent I agree, "level 1" directories having an added "importance" if you like, what users do underneath these created directories has always been pretty much up to them and will probably still be so with the increasing CMS deployment.  I'm reasonably pleased to see the back of /centre/<centrename> and /department/<departmentname> but someone still has to sign off on the creation of these new areas, it will require someone with elevated permissions to create and setup groups and/or CMS permissions also.  As far as I can see few people actually type out URLs from memory anyway, length of address is something of a sideshow.

I'm not sure about the tinyurl idea (not that I know what it is) but tinyurl.com has a lot of diverse content associated with it, probably (in some cases) not what the University as an institution would want to use.

FWIW I think these points are the day-to-day core of the policy

Alison Wildish comments:
With regard to TinyURL - I do agree but we have been discussing using something similar in-house. See Matthew Ropers notes on the wiki. 

2.3 "Centre" and non-departmental URLs

Occasionally there will be instances where certain groups would not wish to exist within the primary domain structure, even though they are within the University, and therefore require a discrete URL. Official Centres - passed by Senate and Council - may sit directly under the main domain (eg www.bath.ac.uk/casa/). Other centres will appear below the departmental domain (eg www.bath.ac.uk/education/epic/).

Decisions on exceptions rest with a group consisting of Marketing & Communications and Computing Services staff.

Alison Wildish comments:
If we brought in shorter URLs then presumably we could remove this? I would prefer to enable shorter URLs across the board than restrict them to research centres only.

The final sentence needs to be removed or revised. If we keep it, it should either say Web Management Board or Web Services.

2.4 non bath.ac.uk URLs

non-bath.ac.uk URLs are only acceptable when the 'service' is either:

  • a nationally-funded JISC service or
  • project-funded with multiple partners or
  • aimed at commercial spin-off or
  • targetted outside ac.uk domain for commercial customers

Alison Wildish comments:
I think this is fine but we should capture information relating to these requests. I suggest we use a form which asks people to specify which of those categories their site falls under and to briefly summarise why it does.

Final decisions should be made by Web Management Board or Web Services.

Richard Phillips comments:
"targetted outside ac.uk domain for commercial customers"

We have to abide by JANET rules on the traffic we can shift, Neil may be able to comment further on this one.

It's always been a difficult area in joint institution projects on just who should host content.

3. Strategy and Control

All matters of strategy and control relating to web-based infrastructures will be determined by the Information Services Planning Committee.

Alison Wildish comments:
This needs to be changed as that group doesn't exist.

4. Policy Revision

This policy is considered to be a "live" document and therefore the subject of revision at any time as determined by the Information Services Planning Committee.

Alison Wildish comments:
As above.

Domain naming and hosting of sites

Alison Wildish comments:
This policy/guidance doesn't fully support the URL policy and doesn't make the strict conditions for having a non Bath URL clear.

Departments and centres are encouraged to remain under www.bath.ac.uk and adopt the naming policy laid down by the URL policy. In certain cases, a Bath subdomain ie <anything>.bath.ac.uk may be used, for example:
- for important conferences organized by departments eg http://acoustics2005.bath.ac.uk/
- for companies that want to show affiliation to the University eg http://interactive.bath.ac.uk/
In both cases, the domain is automatically associated with The University of Bath and the files are physically located on the University web server.

Alison Wildish comments:
The contradicts our URL policy. This entire paragraph should be removed.

Suggest changing to:

The guidance is for non bath.ac.uk URLs. Only those sites/centres which have met the criteria outlined in the URL policy (section 2.4) can use a non bath.ac.uk URL and be hosted on the University web servers.

Non bath.ac.uk URLs can be managed in the following ways: 

Redirection: users are redirected to physical pages on the Bath server eg http://www.welldev.org.uk/(http://www.bath.ac.uk/econ-dev/wellbeing/). Shared mailboxes can be set up and aliased in a similar way.
URI masking: a domain name is registered, the site is located and built in an area under bath.ac.uk but anyone visiting this domain will have no knowledge of the physical web server, eg http://www.transdifferentiation.com/

Registering a domain name

If you have had approval to use a non bath.ac.uk URL and intend registering a domain name, please inform web-support@bath.ac.uk.
Once a suitable domain name has been chosen it can be registered via an ISP (Internet Service Provider) or naming authority (eg Nominet). You then need to delegate the name to at least two DNS (domain name system) servers and determine:
- what facilities are required by the site
- which host will act as the server for the new service
- how the site will be run and supported.

If DNS authority is delegated to Computing Services at Bath (NB this should be agreed prior to registration), they will be responsible for all DNS records including email, filestore, IP addresses and aliasing which will include the arranging of web content hosting as in the case of http://www.m4br.org.uk/. Where Computing Service servers are to be used to host the site, additional set up time will be required and additional charges may be incurred depending on the complexity of the service required. Computing Service reserves the right to provide this facility as required.

Richard Phillips comments:
The acoustics2005.bath.ac.uk example is a bad one, particularly as I think it was finally removed not all that long ago, which brings us onto the longevity of hosted content - how long do we host conference content for?  I tried to promote conference.bath.ac.uk/<conferencename> but people become fixated by the naming aspect of all this.

You do mention email addresses in your change paragraph, which is an interesting point and maybe one that overlaps with other policies.  It certainly pulls in a number of teams when these get created, webmaster, lanmaster and email admin personnel and possibly local supporters to setup email clients.

As for URI redirection/masking/external host redirection we may never have a complete list of who-registered-what, I think our 1 and 1 account was in some respect a method of keeping track.  Certainly when we changed the IP address of the webserver to bring it into an SLB arrangement on the router it highlighted a few domain we didn't necessarily know about.

http://www.welldev.org.uk I don't think are redirected, we set up a virtualhost that points to /www/vhosts/bath/econ-dev/welldev/.  It's available from two points as it reduces the administration on creating a new document root and then setting up SMB/CIFS mounts for users so they can access them and NFS exports on the user service machines.  This is an example of some of the work that has to go on in the background for each request, no one remembers to ask about specific logging (and actually I'd rather they didn't as I would need to find somewhere to put them), or tackles the issue of what the webmaster address should be when vhosts are set up.

  • No labels

1 Comment

  1. Unknown User (ccsya)

    Once the policy has been agreed I think it would be useful to have a flowchart enabling people to quickly work out what they are allowed to have.

    I agree with Richard that people don't type in URLs; however people still print URLs on leaflets, so I can understand the need for a short URL service; also tying it in with 3D barcodes is great.