Subject: [Gen-art] RE: GenART review of draft-ietf-simple-rpid-09.txt

From: [email-masked]
Date: Wed, 23 Nov 2005 21:22:42 -0500

Henning,

It looks ok to me - the only thing it doesn't do is explain how
to choose an appropriate namespace URI for a non-standard extension
(e.g., for experimentation), but I don't have a problem with
that not being described in a standard.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Wednesday, November 23, 2005 8:19 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; 'Paul Kyzivat'; 
> Jonathan Rosenberg; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: GenART review of draft-ietf-simple-rpid-09.txt
> 
> David,
> 
> thank you for the helpful comments on this document. I've creating an 
> interim version of the draft at
> 
> http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rp
> id-10.html
> 
> that hopefully incorporates your feedback. I will await further IESG 
> feedback before submitting a new version to the I-D editor.
> 
> Thank you for volunteering your time as part of the GenART process.
> 
> Henning
> 
> [email-masked] wrote:
> > Background for those who may be unaware of GenART:
> > 
> > GenART is the Area Review Team for the General Area of the IETF.
> > We advise the General Area Director (i.e. the IETF/IESG chair) by
> > providing more in depth reviews than he could do himself of 
> documents
> > that come up for final decision in IESG telechat.  I was selected
> > as the GenART member to review this document.  Below is my review,
> > which was written specifically with an eye to the GenART 
> process, but
> > since I believe that it will be useful to have these comments more
> > widely distributed, others outside the GenART group are included.
> > 
> > Review criteria for WG submissions: "Is this document a reasonable
> > contribution to the area of Internet engineering which it covers? If
> > not, what changes would make it so?"
> > 
> > This draft is basically ready for publication, but has nits that
> > should be fixed before publication.
> > 
> > Overall, it's a well-written draft.  Of the nits below, I 
> would place
> > some emphasis on improving the discussion of extensibility, as the
> > cross-reference to RFC 3863 doesn't make everything obvious.
> > 
> > The term "presentity" is used extensively in this draft; it is a new
> > term (at least to me) that needs a definition and/or explanation,
> > including how it relates to "person".  My guess from context is that
> > a presentity is a proxy for presence 
> determination/reporting purposes.
> > 
> > Section 1, Introduction - CPIM acronym used without 
> expansion or prior
> > definition.  Please supply one.
> > 
> > Section 3.1 Overview - The From/until? column in Figure 1 is not
> > explained until a few paragraphs after the table.  This might be a
> > pagination issue, but the Notes? column in Figure 1 is not explained
> > at all, which is an omission.  The text should explain all 
> the columns
> > in the table just before or immediately after the table.
> > 
> > Near the end of Section 3.1, the following sentence describes
> > extensibility of enumerations:
> > 
> > 	Enumerations can be extended by elements from other namespaces.
> > 
> > There are a couple of important points that aren't obvious from this
> > statement that should be explained here:
> > - The namespaces for standard extensions are specified in Section 6.
> > - Anyone can define an extension by  defining a new namespace
> > 	(not using a standard extensions namespace).
> > In connection with the latter point ...
> > 
> > Section 6, Extending RPID - It would be useful to adapt the
> > following text from Section 4.2.1 of RFC 3863 to this section:
> > 
> >    Any developer can introduce their own element names,
> >    avoiding conflict by choosing an appropriate namespace URI.
> > 
> > to explain how to define new enumeration values without 
> conflict, and
> > as part of this an explanation of "appropriate" would be useful.
> > 
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > [email-masked]        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 23 Nov 2005 21:34:24 -0500

> that not being described in a standard.

That's a good question - I'm pretty sure I don't have a good answer. I 
wouldn't want to invent a convention just for this document. Maybe one 
of my co-authors has seen something we can reference.

(This is probably a general problem for lots of user-extendable XML 
documents.)

Henning

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 24 Nov 2005 11:34:53 -0600

> (This is probably a general problem for lots of user-extendable XML 

I don't know about something we can reference, but in the past
for experimentation and prototyping, I have included the company name
in the namespace to impart some uniqueness and avoid collisions
when we inter-operate in friendly environments.

Thanks,

- vijay