attachments-v3.html final editing issues

√1. As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

This text is included in the Conformance section - which eliminates the need to have subsections marked as informational for Example sections (as was done for some of the other specifications).

2. Why is attachmentSize included in the attachment meta-data. Can’t that be determined in a standard way with HEAD request on the attachment URI? This is probably included to avoid requiring the client to do a HEAD request to determine if they can handle an attachment or not if they already have done a GET on the AttachmentDescriptor.

3. 7.3.1, why can’t the attachment be an LDP-RS? 7.3.1 says the attachment MUST be a valid LDP-NR. An LDP-NR is an LDPR whose state is not represented in RDF. That means an attachment couldn't be an RDF resource. Is that necessary? What was the motivation for this restriction? Is it simply that RDF resources should be handled in LDP containers directly as a good practice? Then Section 7.4.6 says servers can use an LDP-NR interaction model by including a Link header to indicate an RDF resources is actually a NonRDFSource in order to attach an RDF resource. Why restrict it then make a special case to allow it?

4. 7.4.6 What is an interaction model? LDP 1.0 doesn't define it. LDP only specifies LDPR and LDPC interaction models, but doesn't provide any details. There is no LDP-NR interaction model - or is that what this clause is defining? What impact would this have on the creation of the attachment or its descriptor other than simply allowing clients to override the type of an RDFSource to tell the server its a NonRDFSource in order to allow the attachment?

I'm guessing the reason for 3 and 4 is that for an LDP server, RDFSources should be accessed from LDPCs, not as binary attachments. 7.4.6 is a special case that allows servers to override this if there is some compelling reason. This seems unnecessary.

√5. The specification does not say how AttachmentDescriptor properties such as description, identifier, title are set. The AttachmentDescriptor may be created as a side effect of a POST to create an attachment, and may be updated when a PUT to an attachment updates the attachment. There is no entity body or request headers that contain this information. PUT to an attachment description wouldn’t seem to be appropriate because most of the other metadata is calculated from the attachment itself and shouldn’t be updated in a manner that would make the information inconsistent. But this is true of many other resources, so PUT is appropriate on an AttachmentDescriptor.