Draft: draft-ietf-httpapi-rfc7807bis

Commentary: Following the discussion in made me think that we could tighten the language around extension member scope . " Effectively " seems a bit odd here . Are they put into a namespace or not ? If they do , then processing rules follow that we may want to spell out : Maybe that 's not good wording , but it seems to me that the current wording may be a little too vague . 
 I just realized that my above text clashes with but once that one is merged I can come up with a suggestion that works with the updated draft text . 
 I do n't think adding new requirements here is a good idea . I 've tweaked a bit to make things clearer . 
 this proposal was n't meant as adding new requirements , but as clarifying rules that may have been implicit before . thanks for the tweaks . 
 ( , which I think is blocked by this issue . ) I would call this specification " forward compatible " if we can add new features to it without interfering with existing compliant implementations . This is important so that standards can evolve to support new functionality , like proposed in . It does not appear to me that there 's any mechanism for forward compatibility , and this is noted : the problem type , it is not possible to define new " standard " members without defining a new media type . While the media type can be " extended " in some fashion , this is not the same as forward compatibility , because all extensions are by definition user extensions , so they can not be standardized . I.e. there is no way to define new " global " members . I think this is important to fix . I see a few options : ( 1 ) Note how the concept of " user " extensions has some amount of ambiguity . In order to know what a non - standard member means , you have to know who issued the Problem document . But there 's no standard way to encode this ! ( It does say the type is " effectively " a namespace for extensions , but this does n't seem like particularly authoritative language . ) Applications that are tightly coupled with a specific API may not have trouble consuming user extensions , but other user - agents ( e.g. spiders ) may have a problem deciphering them . Because of this , I think we could more rigorously specify the behavior without significant breakage " in the wild " . For example , specify that extension members must use a URI , and all other members have a standard definition . Or , choose some prefix that sorts high in ASCII , like or , to indicate standard " global " members . ( 2 ) If this still causes too much breakage , we could either reserve the member names that would cause breakage , or I would support minting a new media type . We could also consider defining a JSON - LD vocabulary . There 's likely a good way to encode the problem details that 's easily detectable as a document describing the error , and having a standardized form and properties , while also being easily extensible for specific types of problems / errors . 
 This has been discussed as part of a few other issues , but it 's good to separate it out into an explicit one . I think you 're in the ballpark here -- to allow new standard extensions ( i.e. , those not in the original spec and not explicitly nominated by the type in use ) , we have two choices : a naming convention that does n't conflict with existing usage ( e.g. , a prefix ) a new media type ( 1 ) is hard , because we do n't and ca n't know the extent of existing usage . However , we might be able to create a convention that 's extremely unlikely to conflict with existing usage , advertise it widely , and make sure there 's a transition period before it 's actually used . If we do all that , the risks could be low enough to be acceptable . ( 2 ) is certainly possible , but when we 've discussed this in the past , the concern has been that it would further fragment usage . There is a third option . We can define conventions that individual types opt into , saving them the work of defining the mechanism . For things like ( or whatever it becomes ) , that might be enough . 
 based on the IETF 113 discussion it looks like option ( 1 ) with a prefix that is n't too upsetting for  users is the best option going forward . it 's called " faking forward compatibility when you ignored it initially " and looks good enough to me . 
 How would clients know if a type has opted in or not ? And this enjoys some precedent from some other JSON media types ( JSON - LD ,   ) . Reserving a prefix seems to have also been deployed in e.g. HTTP cookies ( the double underscore prefix ) without too much breakage in the wild . Also , as I sort of hinted , it would be nice to add some stronger language about how to namespace or interpret extension members . Can we guarantee that two " balance " extensions are n't necessarily the same , if the " type " is different ? And what do we do if there is no type ? 
 If we choose a prefix , I think it needs to conform to the constraints that I just to -- That rules out things like . Of the two , Dictionary keys are more constrained - their first characters need to be lcalpha or . So how about ? 
 i am fairly open to anything since it 's nothing but an opaque thing that we will have to adhere to for future standard members . would it be ' " or ' - ' ? i may have a slight preference for the latter for readability . 
 Either one . is a bit weird IMO . Eg vs ( keep in mind that if does n't eventuate the possibilities open up quite a bit ) 
 See PR 
 Merging , with the expectation that we 'll discuss it on list and advertise this change to make sure we 're not clashing with anyone . Even if we do n't do the header field now , doing something compatible with SH dictionaries seems like a good idea so that it 's future - proof .
Note that because extensions are effectively put into a namespace by
the problem type, it is not possible to define new "standard" members
without defining a new media type.
Future updates to this specification might define additional members
that are available to all problem types.  To avoid conflicts,
extension member names SHOULD NOT start with the "*" character.