Jacob,

> Added text in section 3:
>
>    This standard can also be used to send sets of linked documents which
>    are not shown simultaneously, and where the user can use links to move
>    between them.
>
> (This addition was necessary, because a change of wording made by Nick
> Shelness could be interpreted to mean that the standard only applied to
> linked objects which are to be shown inline. I do not believe this is our
> intention? Or is it?)

It certainly wasn't my intent, and I agree that what you originally  wrote
and I cleaned up could be interpretted in that way. I think that adding the
sentence you did now makes our intent clear.

>
> Added text in section 6:
>
>     Although not normal, a text/html resource may be sent with
>     unresolvable links, for example when two authors exchange
>     drafts of unfinished resources.
>
> (Again, this addition was necessary, because a change of wording made by
> Nick Shelness might give the impression that the standard does not cover
> sending of such documents).

I modified your text to read:-

"Note that text/html resources containing URIs that reference resources
that a recipient cannot retrieve  MAY be sent, although this is
discouraged. For example, two persons developing a new Web page may
exchange incomplete versions of that page."

I have no problem with replacing this with your text.

> In section 7:
>
>     This standard does not cover links from one multipart/related to
>     another multipart/related in a message containing multiple
>     multipart/related objects
>
> added text at the end:
>
>     either in parallel or nested one within the other.

I modified your text to read:-

"This standard does not cover the case where a resource in a
multipart/related structure contains URIs that reference  MIME body parts
outside of the current multipart/related structure or in other MIME
messages, even if methods similar to those described in this standard are
used. Implementors who employ  such URIs are warned that receiving agents
implementing this standard may not be able to process them."

I can certainly see that "ouside" might be interpretted as not covering
nested and that there is a case for replacing "outside of the current" with
"in a parallel or nested" to clarify this point.

> I am a little wondering about one change which Nick Shelness made:
>
> He changed
>
>       Content-Location: ietflogo.gif
>       Content-Base: http://www.ietf.cnri.reston.va.us/images/
>       ; Note that the fact that the Content-Base comes after the
>       ; Content-Location within the same Content-Heading will not
>       ; influence their interpretation
>       Content-Type: IMAGE/GIF
>       Content-Transfer-Encoding: BASE64
>
> to
>
>       Content-Location:
http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
>       Content-Type: IMAGE/GIF
>       Content-Transfer-Encoding: BASE64
>
> I have made the change, but is not sure why Nick wanted this change.
> There is too little time left before the ietf draft submission
> deadline for me to ask him why he made this change.

I guess, I felt that the use of Content-Base to resolve relative
Content-Locations (though legal) as opposed to referencing URIs makes
little sense and should not be encouraged. This is probably a case of my
overstepping my copy editor's remit. If you view it as such, then I
apologize.

Nick