draft-laugstol-apache-maven-repository-rest-applications-04.txt		draft-laugstol-apache-maven-repository-rest-applications-05.txt
	skipping to change at page 1, line 43		skipping to change at page 1, line 43
	This Internet-Draft will expire on May 14, 2012.		This Internet-Draft will expire on May 14, 2012.
	Table of Contents		Table of Contents
	1. TODOs and Notes . . . . . . . . . . . . . . . . . . . . . . . 2		1. TODOs and Notes . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Goals: . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Goals: . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Implementation goals . . . . . . . . . . . . . . . . . . . 3		2.2. Implementation goals . . . . . . . . . . . . . . . . . . . 3
	2.3. Areas explicitly not covered . . . . . . . . . . . . . . . 3		2.3. Areas explicitly not covered . . . . . . . . . . . . . . . 3
	2.4. Deployment scenarios . . . . . . . . . . . . . . . . . . . 3		2.4. Deployment scenarios . . . . . . . . . . . . . . . . . . . 4
	3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Operations . . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. Operations . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.3. Uploading Artifacts . . . . . . . . . . . . . . . . . . . 5		3.3. Uploading Artifacts . . . . . . . . . . . . . . . . . . . 5
	3.4. Downloading Artifacts . . . . . . . . . . . . . . . . . . 5		3.4. Downloading Artifacts . . . . . . . . . . . . . . . . . . 5
	3.4.1. Download a single artifact . . . . . . . . . . . . . . 5		3.4.1. Download a single artifact . . . . . . . . . . . . . . 5
	3.4.2. Download a set of artifacts . . . . . . . . . . . . . 5		3.4.2. Download a set of artifacts . . . . . . . . . . . . . 5
	3.5. Searching . . . . . . . . . . . . . . . . . . . . . . . . 5		3.5. Searching . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 5		3.6. List Repositories . . . . . . . . . . . . . . . . . . . . 6
	4.1. Response Bindings . . . . . . . . . . . . . . . . . . . . 5		4. Security Aspects . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Aspects . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. Authentication and Authorization . . . . . . . . . . . . . 6
	5.1. Authentication and Authorization . . . . . . . . . . . . . 5
	6. User-Agent Considerations . . . . . . . . . . . . . . . . . . 5		5. User-Agent Considerations . . . . . . . . . . . . . . . . . . 6
	7. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 6		5.1. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8. Appendix: Words and Definitions . . . . . . . . . . . . . . . 6		5.2. Multiple links . . . . . . . . . . . . . . . . . . . . . . 6
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 6		5.3. Forms . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5.4. Server Responses . . . . . . . . . . . . . . . . . . . . . 6
	10.1. Link Relation: http://maven.apache.org/rel/pom . . . . . 6		5.4.1. Single Artifact . . . . . . . . . . . . . . . . . . . 6
	10.2. Link Relation: http://maven.apache.org/rel/md5 . . . . . 6		5.4.2. Multiple Artifacts . . . . . . . . . . . . . . . . . . 6
	10.3. Link Relation: http://maven.apache.org/rel/sha1 . . . . . 6		5.4.2.1. text/uri-list . . . . . . . . . . . . . . . . . . 7
	10.4. Media Type: text/vnd.maven.pom . . . . . . . . . . . . . 7		5.5. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . 7
	10.5. Media Type: text/vnd.maven.md5 . . . . . . . . . . . . . 7		6. Appendix: Words and Definitions . . . . . . . . . . . . . . . 7
	10.6. Media Type: text/vnd.maven.sha1 . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 7		8.1. Link Relation: http://maven.apache.org/rel/pom . . . . . . 8
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		8.2. Link Relation: http://maven.apache.org/rel/md5 . . . . . . 8
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		8.3. Link Relation: http://maven.apache.org/rel/sha1 . . . . . 8
	14.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.4. Media Type: text/vnd.maven.pom . . . . . . . . . . . . . . 8
	14.2. Informative References . . . . . . . . . . . . . . . . . 7		8.5. Media Type: text/vnd.maven.md5 . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7		8.6. Media Type: text/vnd.maven.sha1 . . . . . . . . . . . . . 8
			8.7. URN Registration: urn:maven:artifact . . . . . . . . . . . 8
			9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
			10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
			11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
			11.1. Normative References . . . . . . . . . . . . . . . . . . 8
			11.2. Informative References . . . . . . . . . . . . . . . . . 9
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. TODOs and Notes		1. TODOs and Notes
	o How should an artifact be identified?		o How should an artifact be identified?
	* A "Maven Coordinate" HTTP header? Maven-Coordinate:		* A "Maven Coordinate" HTTP header? Maven-Coordinate:
	groupId=com.example, artifactId=example, type=jar,		groupId=com.example, artifactId=example, type=jar,
	classifiers=awesome, version=1.2.3		classifiers=awesome, version=1.2.3
	* A maven URI type? maven://groupId/artifactId/version?		* A maven URI type? maven://groupId/artifactId/version?
	skipping to change at page 5, line 17		skipping to change at page 5, line 26
	It should be possible to:		It should be possible to:
	o Upload a single artifact		o Upload a single artifact
	o Upload a bundle of artifacts in a single upload		o Upload a bundle of artifacts in a single upload
	o Attach signatures to an artifact		o Attach signatures to an artifact
	3.4. Downloading Artifacts		3.4. Downloading Artifacts
	It should be possible to
	3.4.1. Download a single artifact		3.4.1. Download a single artifact
			Steps to download a single artifact with a specific version:
			Download the start resource and find a form named "download-
			artifact".
			Artifacts can be identified either through an artifact URN or a full
			set of coordinates. To use the URN mechanism fill out the "urn"
			field, to use the coordinate version fill out the fields named
			"groupId", "artifactId", "version", "type" and "classifier". The
			"classifier" field is optional. These fields MUST be present in the
			form.
			TODO: Some possible optional controls: "filename".
			Submit the form. The server MAY return a single artifact, see
			Section 5.4.1.
	3.4.2. Download a set of artifacts		3.4.2. Download a set of artifacts
	The set might be a search, or just a list of artifacts. The server		The set might be a search, or just a list of artifacts. The server
	is free to choose to send a container format with all the files in		is free to choose to send a container format with all the files in
	it, or just an URL list with pointers.		it, or just an URL list with pointers.
	3.5. Searching		3.5. Searching
	Servers SHOULD implement conditional controls so it's possible to		Servers SHOULD implement conditional controls so it's possible to
	poll the server regularly.		poll the server regularly.
	4. Protocol Bindings		TODO: specify how to query for only changes after a certain
			timestamp.
	4.1. Response Bindings		3.6. List Repositories
	5. Security Aspects		4. Security Aspects
	5.1. Authentication and Authorization		4.1. Authentication and Authorization
	Authentication and authorization is generally not specified by this		Authentication and authorization is generally not specified by this
	specification as it is assumed that the transport mechanisms will		specification as it is assumed that the transport mechanisms will
	specify the different options for authentication.		specify the different options for authentication.
	6. User-Agent Considerations		5. User-Agent Considerations
	A user-agent should include information on how stale data it allows.		5.1. Caching
	This make it possible for caches to in
			A user-agent should include information on how stale data it allows
			when requesting artifacts. This make it possible for caches to
			include caching information in the return response that intermediates
			also will use.
			TODO: Are there any standard ways in HTTP to do this?
	A user agent must always check that it got the data it required after		A user agent must always check that it got the data it required after
	receiving a response.		receiving a response. This means checking response code and content
			type in particular.
			5.2. Multiple links
	If a response include many links with the same relation and content		If a response include many links with the same relation and content
	type, it should can try all links to get the data. This makes it		type, it should can try all links to get the data. This makes it
	possible for a server to include pointers to many servers that can		possible for a server to include pointers to many servers that can
	respond to the same request. A user agent should try to stick to the		respond to the same request. A user agent should try to stick to the
	same host (as defined by the URI) for the following requests.		same host (as defined by the URI) for the following requests.
	7. HTTP Binding		TODO: It this mainly covered by metalink?
			5.3. Forms
			When the user agent is downloading a form with unknown controls they
			MUST be sent back to the server with any value specified.
			5.4. Server Responses
			5.4.1. Single Artifact
			HTTP responses SHOULD include a "Content-Disposition" header with
			Disposition Type set to "attachment" to indicates that the artifact
			shouldn't be processed according to its media type. See also
			Content-Disposition in HTTP [RFC6266]. Those implementations that
			use generic HTTP servers to serve the artifacts might not include the
			header as it could be shared between many applications.
			5.4.2. Multiple Artifacts
			When the server replies with a set of artifacts it MAY send one of
			the following responses. If the response is one of the specified
			responses, it MUST follow this specification.
			5.4.2.1. text/uri-list
			See the text/uri-list specification [RFC2483].
			TODO: Specify "application/atom+xml", "text/collection+json"
			responses too.
			5.5. HTTP Binding
	Explain what extra headers can be given with each response for		Explain what extra headers can be given with each response for
	artifacts:		artifacts:
	o Checksums: MD5, SHA-1		o Checksums: MD5, SHA-1
	o Cryptographic signatures, either complete signatures or links to		o Cryptographic signatures, either complete signatures or links to
	signatures		signatures
	o File size		o File size
	8. Appendix: Words and Definitions		6. Appendix: Words and Definitions
	Maven Repository A Maven Repository contain a set of artifacts. Each		Maven Repository A Maven Repository contain a set of artifacts. Each
	artifact is identified by a:		artifact is identified by a:
	* group id		* group id
	* artifact id		* artifact id
	* version		* version
	* type		* type
	* classifier - this is optional		* classifier - this is optional
	See Also (The Maven site at apache)[http://maven.apache.org]		See Also (The Maven site at apache)[http://maven.apache.org]
	9. Security Considerations		7. Security Considerations
	10. IANA Considerations		8. IANA Considerations
	o TODO: Move media types here or this section down.		o TODO: Move media types here or this section down.
	o TODO: Check if there are other checksum relations that are as		o TODO: Check if there are other checksum relations that are as
	useful. It might be possible to reuse something here. Would be		useful. It might be possible to reuse something here. Would be
	make sense to register a "text/checksum" type and assume that all		make sense to register a "text/checksum" type and assume that all
	clients can use content negotiation to find it? Should it be		clients can use content negotiation to find it? Should it be
	registered at all, or should it be assumed that the application		registered at all, or should it be assumed that the application
	always can implement RFC3230?		always can implement RFC3230?
	10.1. Link Relation: http://maven.apache.org/rel/pom		8.1. Link Relation: http://maven.apache.org/rel/pom
	A pointer to a Maven POM file.		A pointer to a Maven POM file.
	TODO: Should probably not be here, a link with rel=describedby,		TODO: Should probably not be here, a link with rel=describedby,
	contentType=text/vnd.maven.pom is probably fine.		contentType=text/vnd.maven.pom is probably fine.
	10.2. Link Relation: http://maven.apache.org/rel/md5		8.2. Link Relation: http://maven.apache.org/rel/md5
	10.3. Link Relation: http://maven.apache.org/rel/sha1		8.3. Link Relation: http://maven.apache.org/rel/sha1
	10.4. Media Type: text/vnd.maven.pom
	10.5. Media Type: text/vnd.maven.md5		8.4. Media Type: text/vnd.maven.pom
	10.6. Media Type: text/vnd.maven.sha1		8.5. Media Type: text/vnd.maven.md5
	11. IANA Considerations		8.6. Media Type: text/vnd.maven.sha1
	12. Security Considerations		8.7. URN Registration: urn:maven:artifact
	13. Acknowledgments		Should it be "urn:maven:artifact" or "urn:maven"
	14. References		Use template in http://tools.ietf.org/html/rfc3406#appendix-A
	14.1. Normative References		Creating an informal registration seems the right way to do as long
			as this document doesn't become an RFC.
			9. Security Considerations
			10. Acknowledgments
			11. References
			11.1. Normative References
	[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC		[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC
	1864, October 1995.		1864, October 1995.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services
			Necessary for URN Resolution", RFC 2483, January 1999.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", RFC		[RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", RFC
	3230, January 2002.		3230, January 2002.
	[RFC4287] Nottingham, M.Ed., and R. Sayre, Ed., "The Atom		[RFC4287] Nottingham, M.Ed., and R. Sayre, Ed., "The Atom
	Syndication Format", RFC 4287, December 2005.		Syndication Format", RFC 4287, December 2005.
	skipping to change at page 7, line 47		skipping to change at page 9, line 16
	JavaScript Object Notation (JSON)", RFC 4627, July 2006.		JavaScript Object Notation (JSON)", RFC 4627, July 2006.
	[RFC5854] Bryan, A., Tsujikawa, T., McNab, N. and P. Poeml, "The		[RFC5854] Bryan, A., Tsujikawa, T., McNab, N. and P. Poeml, "The
	Metalink Download Description Format", RFC 5854, June		Metalink Download Description Format", RFC 5854, June
	2010.		2010.
	[RFC6249] Bryan, A., McNab, N., Tsujikawa, T., Poeml, P. and H.		[RFC6249] Bryan, A., McNab, N., Tsujikawa, T., Poeml, P. and H.
	Nordstrom, "Metalink/HTTP: Mirrors and Hashes", RFC 6249,		Nordstrom, "Metalink/HTTP: Mirrors and Hashes", RFC 6249,
	June 2011.		June 2011.
	14.2. Informative References		[RFC6266] Reschke, J., "Use of the Content-Disposition Header Field
			in the Hypertext Transfer Protocol (HTTP)", RFC 6266, June
			2011.
			11.2. Informative References
	[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,		[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	April 1992.		April 1992.
	[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1		[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
	(SHA1)", RFC 3174, September 2001.		(SHA1)", RFC 3174, September 2001.
			[RFC3406] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,
			"Uniform Resource Names (URN) Namespace Definition
			Mechanisms", BCP 66, RFC 3406, October 2002.
	Author's Address		Author's Address
	Trygve		Trygve
	Arktekk		Arktekk
	NO		NO
	Phone: +47 926 99 070		Phone: +47 926 99 070
	Email: trygvis@inamo.no		Email: trygvis@inamo.no
End of changes. 29 change blocks.
	49 lines changed or deleted		131 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/